Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt)
Hi Sam, all, ready to discuss licensing again? :-) here is an update from OGF28: first, we heard rumours that you may show up here - this would be great, not in the least so that we can discuss the licensing thingie F2F. Usually that is way more productive than endless mailing threads like this one, isn't it :) Anyway, I just wanted to tell you that we have been discussing the issues from the recent email exchanges (and I hope sincerely that these are the issues you are in fact concerned about) within the GFSG. So, there was some discussion to review the current IPR text, and to clarify those passages which seem, in your reading, to hide the fact/intent that using any amount of text from a GFD for documentation and any other purpose is legally perfectly fine: "...derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind..." We will be cross-checking with similar texts of other standards bodies, in particular including IETF, which seem to recently have updated their IPR texts as well, to remove some ambiguities. The OGF IPR was originally modeled after IETF's, and, IIRC, was basically reproducing the OGF IPR word by word. Further we have been discussing the point you raised that the state of OGF documents would be frozen in the case of OGF's disappearance. If this turns out to be a concern for the community, we will consider adding a clause which would release the documents into the public domain in the case of OGF's demise - we certainly don't want to hold anybody back in continuing to work with OGF documents in that case. Both of the above changes however need to be evaluated, and need to be approved by the OGF board. While we don't think this is a problem per se, this will need time to be changed. The OGF IPR is designed as it is to fulfil three goals: (a) support the production and consumption of standards, (b) ensure that OGF documents (i.e. documents released under OGF copyright) went through the OGF document process, and (c) secure OGF against legal litigations. The board will need to make sure that in particular (b) and (c) are not affected by the proposed changes. If this sounds overly bureaucratic to you: well, that is the way we work ;-) Please let us know if changes along those lines would make you sleep better :-D FWIW: for the same reasons as above (a-c), we do actually require that OGF documents are under full OGF copyright, and it does not seem likely that a proposal for dual licensing would find much support, if any. Looking forward to see you in Munich! Best, Andre. -- Nothing is ever easy.
I'm still mostly out of action but thought you'd appreciate this<http://www.w3.org/QA/2010/03/update_on_html_5_document_lice.html> : Update on HTML 5 Document License Today at the W3C Advisory Committee meeting, we discussed the document license for HTML 5. We discussed use cases from the HTML Working Group<http://lists.w3.org/Archives/Public/public-html/2009Feb/0388.html> that call for a more open license than the current W3C Document License<http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231.html> . The result of discussion among the Membership is that there is strong support for: - a license that allows the reuse of excerpts in software, software documentation, test suites, and other scenarios; - a license (or licenses) that are familiar to the open source community; - processes that encourage innovation and experimentation about Web technology, so that work can be easily brought to W3C for standardization; - making the HTML Working Group a forum that is conducive to participation by the community at large; - ensuring that the HTML 5 specification remains valuable to the entire Web community (see an update from Philippe Le Hégaret on HTML</2010/Talks/0323-html-plh/> that he presented to the Membership). In short, there is strong support in the Membership (but not unanimity) for all of the use cases cited by the HTML Working Group *except* forking the specification. Several W3C Members do feel strongly that the document license should allow forking, however. People at the meeting agreed that, in any case, copyright is not likely to prevent fragmentation. Several points were made: - people do not expect copyright to be instrumental to the successful deployment of HTML 5. Quality and market relevance will determine whether the W3C specification is successful. - innovation and experimentation are valued at W3C. Jeff Jaffe, W3C's new CEO, has already blogged<http://www.w3.org/QA/2010/03/first_impressions.html> about the fact that W3C should encourage participation from more developers as they are significant drivers of innovation. - W3C needs to continue to listen closely to the community's views on technical direction, including strongobjections<http://www.w3.org/2005/10/Process-20051014/policies.html#FormalObjection>. Although it may not always be possible to bridge certain cultural divides, W3C must continue to encourage the expression of opposing views and treat them with respect. For instance, Tim Berners-Lee's blog on reinventing HTML <http://dig.csail.mit.edu/breadcrumbs/node/166> discusses how W3C needed to adjust its course around HTML based on community input. We have work to do to find the right license to meet the stated goals: to make it easy for people to reuse W3C specifications in almost all of the scenarios people have expressed are important to them. We plan to work with the community on the details as we move forward. More information can be found in my slides<http://www.w3.org/2010/Talks/doclicense-20100323/> from the meeting. We welcome your feedback. On Tue, Mar 16, 2010 at 4:56 PM, Andre Merzky <andre@merzky.net> wrote:
Hi Sam, all,
ready to discuss licensing again? :-)
here is an update from OGF28: first, we heard rumours that you may show up here - this would be great, not in the least so that we can discuss the licensing thingie F2F. Usually that is way more productive than endless mailing threads like this one, isn't it :)
Anyway, I just wanted to tell you that we have been discussing the issues from the recent email exchanges (and I hope sincerely that these are the issues you are in fact concerned about) within the GFSG.
So, there was some discussion to review the current IPR text, and to clarify those passages which seem, in your reading, to hide the fact/intent that using any amount of text from a GFD for documentation and any other purpose is legally perfectly fine:
"...derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind..."
We will be cross-checking with similar texts of other standards bodies, in particular including IETF, which seem to recently have updated their IPR texts as well, to remove some ambiguities. The OGF IPR was originally modeled after IETF's, and, IIRC, was basically reproducing the OGF IPR word by word.
Further we have been discussing the point you raised that the state of OGF documents would be frozen in the case of OGF's disappearance. If this turns out to be a concern for the community, we will consider adding a clause which would release the documents into the public domain in the case of OGF's demise - we certainly don't want to hold anybody back in continuing to work with OGF documents in that case.
Both of the above changes however need to be evaluated, and need to be approved by the OGF board. While we don't think this is a problem per se, this will need time to be changed.
The OGF IPR is designed as it is to fulfil three goals: (a) support the production and consumption of standards, (b) ensure that OGF documents (i.e. documents released under OGF copyright) went through the OGF document process, and (c) secure OGF against legal litigations. The board will need to make sure that in particular (b) and (c) are not affected by the proposed changes. If this sounds overly bureaucratic to you: well, that is the way we work ;-)
Please let us know if changes along those lines would make you sleep better :-D
FWIW: for the same reasons as above (a-c), we do actually require that OGF documents are under full OGF copyright, and it does not seem likely that a proposal for dual licensing would find much support, if any.
Looking forward to see you in Munich!
Best, Andre.
-- Nothing is ever easy.
Sam, thanks for that link, very interesting discussion indeed. Best, Andre. Quoting [Sam Johnston] (Mar 23 2010):
Date: Tue, 23 Mar 2010 20:09:36 +0100 Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) From: Sam Johnston <samj@samj.net> To: Andre Merzky <andre@merzky.net> Cc: occi-wg@ogf.org, Steven Newhouse <s.newhouse@omii.ac.uk>, Christopher Smith <csmith@platform.com>, Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk>
I'm still mostly out of action but thought you'd appreciate [1]this:
Update on HTML 5 Document License
Today at the W3C Advisory Committee meeting, we discussed the document license for HTML 5. We discussed [2]use cases from the HTML Working Group that call for a more open license than the current [3]W3C Document License.
The result of discussion among the Membership is that there is strong support for: * a license that allows the reuse of excerpts in software, software documentation, test suites, and other scenarios; * a license (or licenses) that are familiar to the open source community; * processes that encourage innovation and experimentation about Web technology, so that work can be easily brought to W3C for standardization; * making the HTML Working Group a forum that is conducive to participation by the community at large; * ensuring that the HTML 5 specification remains valuable to the entire Web community (see an [4]update from Philippe Le Hégaret on HTML that he presented to the Membership).
In short, there is strong support in the Membership (but not unanimity) for all of the use cases cited by the HTML Working Group except forking the specification. Several W3C Members do feel strongly that the document license should allow forking, however.
People at the meeting agreed that, in any case, copyright is not likely to prevent fragmentation. Several points were made: * people do not expect copyright to be instrumental to the successful deployment of HTML 5. Quality and market relevance will determine whether the W3C specification is successful. * innovation and experimentation are valued at W3C. Jeff Jaffe, W3C's new CEO, has already [5]blogged about the fact that W3C should encourage participation from more developers as they are significant drivers of innovation. * W3C needs to continue to listen closely to the community's views on technical direction, including strong[6]objections. Although it may not always be possible to bridge certain cultural divides, W3C must continue to encourage the expression of opposing views and treat them with respect. For instance, Tim Berners-Lee's blog on [7]reinventing HTML discusses how W3C needed to adjust its course around HTML based on community input.
We have work to do to find the right license to meet the stated goals: to make it easy for people to reuse W3C specifications in almost all of the scenarios people have expressed are important to them.
We plan to work with the community on the details as we move forward. More information can be found in my [8]slides from the meeting. We welcome your feedback. On Tue, Mar 16, 2010 at 4:56 PM, Andre Merzky <[9]andre@merzky.net> wrote:
Hi Sam, all, ready to discuss licensing again? :-) here is an update from OGF28: first, we heard rumours that you may show up here - this would be great, not in the least so that we can discuss the licensing thingie F2F. Usually that is way more productive than endless mailing threads like this one, isn't it :) Anyway, I just wanted to tell you that we have been discussing the issues from the recent email exchanges (and I hope sincerely that these are the issues you are in fact concerned about) within the GFSG. So, there was some discussion to review the current IPR text, and to clarify those passages which seem, in your reading, to hide the fact/intent that using any amount of text from a GFD for documentation and any other purpose is legally perfectly fine: "...derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any
kind..." We will be cross-checking with similar texts of other standards bodies, in particular including IETF, which seem to recently have updated their IPR texts as well, to remove some ambiguities. The OGF IPR was originally modeled after IETF's, and, IIRC, was basically reproducing the OGF IPR word by word. Further we have been discussing the point you raised that the state of OGF documents would be frozen in the case of OGF's disappearance. If this turns out to be a concern for the community, we will consider adding a clause which would release the documents into the public domain in the case of OGF's demise - we certainly don't want to hold anybody back in continuing to work with OGF documents in that case. Both of the above changes however need to be evaluated, and need to be approved by the OGF board. While we don't think this is a problem per se, this will need time to be changed. The OGF IPR is designed as it is to fulfil three goals: (a) support the production and consumption of standards, (b) ensure that OGF documents (i.e. documents released under OGF copyright) went through the OGF document process, and (c) secure OGF against legal litigations. The board will need to make sure that in particular (b) and (c) are not affected by the proposed changes. If this sounds overly bureaucratic to you: well, that is the way we work ;-) Please let us know if changes along those lines would make you sleep better :-D FWIW: for the same reasons as above (a-c), we do actually require that OGF documents are under full OGF copyright, and it does not seem likely that a proposal for dual licensing would find much support, if any. Looking forward to see you in Munich! Best, Andre. -- Nothing is ever easy.
Andre, This has been on my todo list for a week so I figure some random thoughts at 1am are better than nothing... As you saw, I didn't make it to OGF 28. I went to visit a Google datacenter in another country and imported some cold/flu mongrel hybrid that's kept me coughing for 3 weeks. That's [part of] the reason why I've missed calls and haven't been pushing the spec to completion. That will change very soon. I firmly believe that it's time for us to raise the bar for standards openness, and part of that is using a license that people are comfortable with such that they won't feel the need to engage a lawyer before [re]using our documents. As evidenced by the W3C notice I posted a few hours ago, I'm not alone on this. Most existing cloud computing specifications are available under CC licenses and I don't want to give anyone any excuses to choose another standard over ours. It's too bad Creative Commons don't have a sensible license for standards that covers patents, but perhaps that's something they would consider if we ask nicely - I think I'll do just that. Cutting to the chase, as a primary contributor to the specification documents I "*grant to the OGF and its participants certain licenses and rights*" (per OGF Intellectual Property Policy<http://www.ogf.org/About/abt_policies.php>), but I *do not assign* the copyrights to OGF. As such I can do pretty much what I want with my contributions, including granting non-exclusive licenses to other organisations and publicly releasing them under a license of my choice or into the public domain (no license required). I would obviously prefer for the OGF to release the official documents of their own volition (even as an exception for OCCI), but don't think I won't do what is required in order to ensure adequate levels of freedom for our users and implementors (including rewriting contributions from others who reject more liberal licensing). Nor do I see how this would in any way prevent the OGF from reaching the three goals you described below. Sam On Tue, Mar 16, 2010 at 4:56 PM, Andre Merzky <andre@merzky.net> wrote:
Hi Sam, all,
ready to discuss licensing again? :-)
here is an update from OGF28: first, we heard rumours that you may show up here - this would be great, not in the least so that we can discuss the licensing thingie F2F. Usually that is way more productive than endless mailing threads like this one, isn't it :)
Anyway, I just wanted to tell you that we have been discussing the issues from the recent email exchanges (and I hope sincerely that these are the issues you are in fact concerned about) within the GFSG.
So, there was some discussion to review the current IPR text, and to clarify those passages which seem, in your reading, to hide the fact/intent that using any amount of text from a GFD for documentation and any other purpose is legally perfectly fine:
"...derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind..."
We will be cross-checking with similar texts of other standards bodies, in particular including IETF, which seem to recently have updated their IPR texts as well, to remove some ambiguities. The OGF IPR was originally modeled after IETF's, and, IIRC, was basically reproducing the OGF IPR word by word.
Further we have been discussing the point you raised that the state of OGF documents would be frozen in the case of OGF's disappearance. If this turns out to be a concern for the community, we will consider adding a clause which would release the documents into the public domain in the case of OGF's demise - we certainly don't want to hold anybody back in continuing to work with OGF documents in that case.
Both of the above changes however need to be evaluated, and need to be approved by the OGF board. While we don't think this is a problem per se, this will need time to be changed.
The OGF IPR is designed as it is to fulfil three goals: (a) support the production and consumption of standards, (b) ensure that OGF documents (i.e. documents released under OGF copyright) went through the OGF document process, and (c) secure OGF against legal litigations. The board will need to make sure that in particular (b) and (c) are not affected by the proposed changes. If this sounds overly bureaucratic to you: well, that is the way we work ;-)
Please let us know if changes along those lines would make you sleep better :-D
FWIW: for the same reasons as above (a-c), we do actually require that OGF documents are under full OGF copyright, and it does not seem likely that a proposal for dual licensing would find much support, if any.
Looking forward to see you in Munich!
Best, Andre.
-- Nothing is ever easy.
Hi Sam, all, Quoting [Sam Johnston] (Mar 24 2010):
Andre,
This has been on my todo list for a week so I figure some random thoughts at 1am are better than nothing...
Yes, indeed - appreciated!
I firmly believe that it's time for us to raise the bar for standards openness, and part of that is using a license that people are comfortable with such that they won't feel the need to engage a lawyer before [re]using our documents. As evidenced by the W3C notice I posted a few hours ago, I'm not alone on this.
I found the W3C discussion very interesting, thanks again for the link. However, it seems that they come basically to the same conclusion as we do: its great to grant basically total freedom for standards docs, as long as forking of the actual specification is avoided. See page 4 on http://www.w3.org/2010/Talks/doclicense-20100323/#%281%29 which is the summary of the license discussion of the W3C advisory Committe from 2 days ago: "Survey results on question "should W3C publish HTML 5 under a license that allows forking?". Of those who responded, approximately 79% answered "no" and 14% answered "yes" (and the rest abstained)." This is exactly our point :-)
Most existing cloud computing specifications are available under CC licenses and I don't want to give anyone any excuses to choose another standard over ours.
I have asked this before: which standards do you mean? FWIW, I checked again under cloud-standards.org (nice job!), and the only real specs listed there are OCCI/IGF, OVF/DMTF and CDMI/SNIA. OCCI/OGF has the most free license of the three, IMHO. SNIA says (http://www.snia.org/tech_activities/publicreview/Cloud_Data_Management_Inter... page 2): "The SNIA hereby grants permission for individuals to use this document for personal use only, and for corporations and other business entities to use this document for internal use only (including internal copying, distribution, and display) provided that: - Any text, diagram, chart, table, or definition reproduced shall be reproduced in its entirety with no alteration, and, - Any document, printed or electronic, in which material from this document (or any portion hereof) is reproduced shall acknowledge the SNIA copyright on that material, and shall credit the SNIA for granting permission for its reuse. Other than as explicitly provided above, you may not make any commercial use of this document, sell any excerpt or this entire document, or distribute this document to third parties. All rights not explicitly granted are expressly reserved to SNIA. Permission to use this document for purposes other than those enumerated above may be requested by e-mailing tcmd@snia.org. Please include the identity of the requesting individual and/or company and a brief description of the purpose, nature, and scope of the requested use." Note: SNIA does not allow annotations etc. and DMTF says ( http://www.dmtf.org/standards/published_documents/DSP0243_1.1.0.pdf page 2): "Members and non-members may reproduce DMTF specifications and documents, provided that correct attribution is given." Note: DMTF allows only reproduction, but not reuse, annotation, etc. Can you please let us know what other cloud standards you are refering to? In fact, so far I could not find *any* standard specification under CC, apart from RSS (http://cyber.law.harvard.edu/rss/rss.html). Well, and the RSS situation is *exactly* what we want to avoid for OGF standards: http://diveintomark.org/archives/2004/02/04/incompatible-rss. The wikipedia page on RSS and its variations is also scary ;) If there are other standards under CC which manage a more successfull evolution, I would be very happy to learn about those!
It's too bad Creative Commons don't have a sensible license for standards that covers patents, but perhaps that's something they would consider if we ask nicely - I think I'll do just that.
I still don't think patents come into the discussion here, really. As you said yourself before: one cannot completely shield a standards specification from 3rd part patent claims, no matter what. The best OCCI can do is to collect excemption statements like those on http://www.ogf.org/About/abt_policies_ipr.php from all major stakeholders. Yes, OGF generally operates on a RAND model, but http://www.ogf.org/About/abt_policies_ipr.php explicitely states that we consider royalty-free to be very acceptable, too, in case OCCI wants to go that route.
Cutting to the chase, as a primary contributor to the specification documents I "grant to the OGF and its participants certain licenses and rights" (per [1]OGF Intellectual Property Policy), but I do not assign the copyrights to OGF. As such I can do pretty much what I want with my contributions, including granting non-exclusive licenses to other organisations and publicly releasing them under a license of my choice or into the public domain (no license required).
Uhm - I never met you personally, but are you always like this? I mean, you are basically saying the third time in this thread: "Either it goes my way, or I go elsewhere". I must admit that this is becoming somewhat frustrating. Sam, please be aware that about 20 people spend hours last week dissecting your mails and arguments, and trying to understand the problems *you* have with OGF IPR, in order to fix those. So far, we could not get to the meat of your arguments I think - please help us to do so. We do have an open process, and are very willing to fix things where they are broken. To summarize our previous points, and the arguments above again: what freedom, apart from forking the spec, are you missing? We are considering to change OGF IPR so that documents are released into the public domain if OGF disappears - what other changes would you think would increase the usability of our specs? What other successful standards under CC are you aware of? And yes, we think that forking a specification is a bad thing, and I have not yet seen compelling arguments or use cases otherwise. FWIW, you say "... I do not assign the copyrights to OGF". You are probably aware that this is actually *limiting* OGF's ability to manage document licenses? For example, this would not allow OGF to release documents into the public domain - we can only relicense documents for which OGF owns the Copyright.
I would obviously prefer for the OGF to release the official documents of their own volition (even as an exception for OCCI), but don't think I won't do what is required in order to ensure adequate levels of freedom for our users and implementors (including rewriting contributions from others who reject more liberal licensing). Nor do I see how this would in any way prevent the OGF from reaching the three goals you described below.
Could you please let us know exactly what text of the OCCI docs you consider to be under other contributors copyright? Could we ask those contributors to speak up personally, please? Thanks, Andre.
On Tue, Mar 16, 2010 at 4:56 PM, Andre Merzky <[2]andre@merzky.net> wrote:
Hi Sam, all,
ready to discuss licensing again? :-)
here is an update from OGF28: first, we heard rumours that you may show up here - this would be great, not in the least so that we can discuss the licensing thingie F2F. Usually that is way more productive than endless mailing threads like this one, isn't it :) Anyway, I just wanted to tell you that we have been discussing the issues from the recent email exchanges (and I hope sincerely that these are the issues you are in fact concerned about) within the GFSG.
So, there was some discussion to review the current IPR text, and to clarify those passages which seem, in your reading, to hide the fact/intent that using any amount of text from a GFD for documentation and any other purpose is legally perfectly fine:
"...derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind..."
We will be cross-checking with similar texts of other standards bodies, in particular including IETF, which seem to recently have updated their IPR texts as well, to remove some ambiguities. The OGF IPR was originally modeled after IETF's, and, IIRC, was basically reproducing the OGF IPR word by word.
Further we have been discussing the point you raised that the state of OGF documents would be frozen in the case of OGF's disappearance. If this turns out to be a concern for the community, we will consider adding a clause which would release the documents into the public domain in the case of OGF's demise - we certainly don't want to hold anybody back in continuing to work with OGF documents in that case.
Both of the above changes however need to be evaluated, and need to be approved by the OGF board. While we don't think this is a problem per se, this will need time to be changed.
The OGF IPR is designed as it is to fulfil three goals: (a) support the production and consumption of standards, (b) ensure that OGF documents (i.e. documents released under OGF copyright) went through the OGF document process, and (c) secure OGF against legal litigations. The board will need to make sure that in particular (b) and (c) are not affected by the proposed changes. If this sounds overly bureaucratic to you: well, that is the way we work ;-) Please let us know if changes along those lines would make you sleep better :-D
FWIW: for the same reasons as above (a-c), we do actually require that OGF documents are under full OGF copyright, and it does not seem likely that a proposal for dual licensing would find much support, if any.
Looking forward to see you in Munich!
Best, Andre.
-- Nothing is ever easy.
On Wed, Mar 24, 2010 at 9:26 PM, Andre Merzky <andre@merzky.net> wrote:
"Survey results on question "should W3C publish HTML 5 under a license that allows forking?". Of those who responded, approximately 79% answered "no" and 14% answered "yes" (and the rest abstained)."
This is exactly our point :-)
Mine too - if you can't reuse/remix the work then it's not free enough. This<http://www.digistan.org/open-standard:definition>is where I think we need to get to for Internet standards in general (and will eventually, given the ongoing trend towards openness): *The Digital Standards Organization defines free and open standard as follows:* - *A free and open standard is immune to vendor capture at all stages in its life-cycle. Immunity from vendor capture makes it possible to freely use, improve upon, trust, and extend a standard over time.* - *The standard is adopted and will be maintained by a not-for-profit organization, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties.* - *The standard has been published and the standard specification document is available freely. It must be permissible to all to copy, distribute, and use it freely.* - *The patents possibly present on (parts of) the standard are made irrevocably available on a royalty-free basis.* - *There are no constraints on the re-use of the standard.* *The economic outcome of a free and open standard, which can be measured, is that it enables perfect competition between suppliers of products based on the standard.* I have asked this before: which standards do you mean? FWIW, I
checked again under cloud-standards.org (nice job!), and the only real specs listed there are OCCI/IGF, OVF/DMTF and CDMI/SNIA. OCCI/OGF has the most free license of the three, IMHO.
Most of the standards I care about are available under CC - Rackspace Cloud APIs <http://www.theregister.co.uk/2009/07/23/rackspace_open_apis/>, Sun Cloud APIs <http://www.sun.com/aboutsun/pr/2009-03/sunflash.20090318.2.xml>, GoGrid APIs<http://www.gogrid.com/company/press-releases/gogrid-moves-api-specification-to-creativecommons.php>, etc. which means that we can remix parts we like - for example if they have a decent implementation of asynchronous operations (or vice versa)... not to mention the benefit of having access to the whole of Wikipedia now it's been relicensed.
It's too bad Creative Commons don't have a sensible license for standards that covers patents, but perhaps that's something they would consider if we ask nicely - I think I'll do just that.
I still don't think patents come into the discussion here, really. As you said yourself before: one cannot completely shield a standards specification from 3rd part patent claims, no matter what. The best OCCI can do is to collect excemption statements like those on http://www.ogf.org/About/abt_policies_ipr.php from all major stakeholders.
I tend to agree - very few companies have patents on cloud APIs (Amazon have at least one) and there's not much we can do about them.
Yes, OGF generally operates on a RAND model, but http://www.ogf.org/About/abt_policies_ipr.php explicitely states that we consider royalty-free to be very acceptable, too, in case OCCI wants to go that route.
I can assure you that RAND is out - if we find a patent (RAND or otherwise) then we'll work around it<http://news.swpat.org/2010/03/transcript-tridgell-patents/> .
Uhm - I never met you personally, but are you always like this?
For things I believe in/care about, yes. And yes, we think that forking a specification is a bad thing, and I
have not yet seen compelling arguments or use cases otherwise.
The fear of forking doesn't stop people releasing code under open source licenses now, does it? Forking is a last resort that people only really exercise when the wheels fall off upstream (for example, withdrawing open source versions, changing licensing conditions, serious management issues<http://en.wikipedia.org/wiki/Joomla#History>, etc.). It requires getting a critical mass of contributors, and in our case implementors, users, etc. as well - not something that's really feasible unless there's real problems - in which case everyone will appreciate not being up the creek without a paddle.
FWIW, you say "... I do not assign the copyrights to OGF". You are probably aware that this is actually *limiting* OGF's ability to manage document licenses? For example, this would not allow OGF to release documents into the public domain - we can only relicense documents for which OGF owns the Copyright.
OGF never asked and I never offered... but for the record, OGF is welcome to release any and all of my contributions under any license that is *less restrictive* than what we have today (including public domain). Could you please let us know exactly what text of the OCCI docs you
consider to be under other contributors copyright? Could we ask those contributors to speak up personally, please?
In the documents I care about most (the specifications), I'm not aware of any. Maybe Andy? Overall I don't think that it's excessive openness that will kill off the standard, but lack of it certainly could. I believe there is an expectation that cloud specifications will be available under unrestrictive licenses and that if we don't meet this expectation then we could well be criticised for it. I also see it as a key differentiator (in addition to our open process) from specs like DMTF's vCloud-based API. That is, we have nothing to risk and everything to gain. So what if someone takes the document and makes a success out of it - at least they'll have succeeded where we've failed. Finally, if we're worried about interoperability problems then we're better off enforcing the trademark so they can't call it OCCI than trying to use copyrights to prevent them copying/reverse engineering us. Sam
On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> wrote:
Mine too - if you can't reuse/remix the work then it's not free enough.
The ability to remix a standard seems an essential freedom: if a standard becomes too complex or encumbered by patents then this is the only way to save parts of it. That's why for Digistan we defined[1] the ability to fork a standard under a share-alike license as a necessary aspect. We chose the GPLv3 mainly because it includes some safeguards against software patents, which CC does not. -Pieter [1] http://www.digistan.org/text:rationale#toc6
Hi Pieter, its great to see some additional response, besides Sam :-) Quoting [Pieter Hintjens] (Mar 25 2010):
On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> wrote:
Mine too - if you can't reuse/remix the work then it's not free enough.
The ability to remix a standard seems an essential freedom: if a standard becomes too complex or encumbered by patents then this is the only way to save parts of it.
*sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard? What I (naively) think is that I can always create a specification like "This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1." Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry... Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO.
That's why for Digistan we defined[1] the ability to fork a standard under a share-alike license as a necessary aspect. We chose the GPLv3 mainly because it includes some safeguards against software patents, which CC does not.
I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange. We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either. Thanks, Andre.
-Pieter
-- Nothing is ever easy.
Hi, I've been staying away from this discussion, but, I like Andre, am a little confused by the position and would like to see proven successes. My point of confusion was based in my own incorrect definition of the word "specification". I was getting the word "specification" confused with word "standard". Maybe clarification of the two words will help reset expectations, like it did for me. From examining the dictionary definitions of the words, I didn't find anywhere in the definition of the word specification indicating it should be used as an authoritative reference. With this new understanding, I think it is acceptable and permissible to alter any specification as long as it does not violate any intellectual property ownership agreements, infringe on property rights, license agreements or copyright laws. Interest in the stability of specifications is a legitimate concern, and a common risk for anyone using a 'specification' that's not a "standard". If this is concern for OCCI specifications, I would suggest moving the OCCI "specifications" and Getting Started Guide on a path toward "standardization" backed by an "authoritative" organization. Or did I miss the point of the 50 some odd emails :) -gary I took the liberty to go to dictionary.com and copied the six relevant definitions of the word "specification". --noun 1.theact of specifying. 2.Usually, specifications. a detailed description or assessment of requirements, dimensions, materials, etc., as of a proposed building, machine, bridge, etc. 3.a particular item, aspect, calculation, etc., in such a description. 4.something specified, as in a bill of particulars; a specified particular, item, or article. 5.an act of making specific. 6.the state of having a specific character. Here is the definition of the word "standard": --noun 1.something considered by an authority or by general consent as a basis of comparison; an approved model. 3.a rule or principle that is used as a basis for judgment: They tried to establish standards for a new philosophical approach. 5.standards, those morals, ethics, habits, etc., established by authority, custom, or an individual as acceptable: He tried to live up to his father's standards. 23.serving as a basis of weight, measure, value, comparison, or judgment. Here is the definition of the word "authority" used in one definition of "standard": noun,plural-ties. 1. the power to determine, adjudicate, or otherwise settle issues or disputes; jurisdiction; the right to control, command, or determine. 2. a power or right delegated or given; authorization: Who has the authority to grant permission? 3. a person or body of persons in whom authority is vested, as a governmental agency. 4. Usually, authorities. persons having the legal power to make and enforce the law; government: They finally persuaded the authorities that they were not involved in espionage. 5. an accepted source of information, advice, etc. Here is the definition of the word anarchy: --noun 1. a state of society without government or law. 2. political and social disorder due to the absence of governmental control: The death of the king was followed by a year of anarchy. 3. a theory that regards the absence of all direct or coercive government as a political ideal and that proposes the cooperative and voluntary association of individuals and groups as the principal mode of organized society. 4. confusion; chaos; disorder: Intellectual and moral anarchy followed his loss of faith. Andre Merzky wrote:
Hi Pieter,
its great to see some additional response, besides Sam :-)
Quoting [Pieter Hintjens] (Mar 25 2010):
On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> wrote:
Mine too - if you can't reuse/remix the work then it's not free enough.
The ability to remix a standard seems an essential freedom: if a standard becomes too complex or encumbered by patents then this is the only way to save parts of it.
*sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard?
What I (naively) think is that I can always create a specification like
"This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1."
Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry...
Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO.
That's why for Digistan we defined[1] the ability to fork a standard under a share-alike license as a necessary aspect. We chose the GPLv3 mainly because it includes some safeguards against software patents, which CC does not.
I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange.
We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either.
Thanks, Andre.
-Pieter
Hi Gary, Quoting [Gary Mazz] (Mar 28 2010):
Hi, I've been staying away from this discussion, but, I like Andre, am a little confused by the position and would like to see proven successes. My point of confusion was based in my own incorrect definition of the word "specification". I was getting the word "specification" confused with word "standard". Maybe clarification of the two words will help reset expectations, like it did for me.
From examining the dictionary definitions of the words, I didn't find anywhere in the definition of the word specification indicating it should be used as an authoritative reference. With this new understanding, I think it is acceptable and permissible to alter any specification as long as it does not violate any intellectual property ownership agreements, infringe on property rights, license agreements or copyright laws.
You are right, there are differences between specifications and standards (aka standard specifications, aka standardized specifications). OGF is a standardization body, so more concerned about standards (those OGF documents which become OGF Recommendations). While I agree that evolving specifications is a natural process, I would argue that *standardized* specifications carry an implicit promise that, if 2 implementation adhere to that standard, they are interoperable. That promise is broken if two different specifications exist (same name, same version). Basically, all OGF is asking for right now is, that instead of forking, a new name or version number is applied to a specification, so that a specific OGF recommendation can still carry that interop promise. Cheers, Andre.
Interest in the stability of specifications is a legitimate concern, and a common risk for anyone using a 'specification' that's not a "standard". If this is concern for OCCI specifications, I would suggest moving the OCCI "specifications" and Getting Started Guide on a path toward "standardization" backed by an "authoritative" organization. Or did I miss the point of the 50 some odd emails :) -gary I took the liberty to go to dictionary.com and copied the six relevant definitions of the word "specification".
ânoun 1.theact of specifying.
2.Usually, specifications. a detailed description or assessment of requirements, dimensions, materials, etc., as of a proposed building, machine, bridge, etc.
3.a particular item, aspect, calculation, etc., in such a description.
4.something specified, as in a bill of particulars; a specified particular, item, or article.
5.an act of making specific.
6.the state of having a specific character.
Here is the definition of the word "standard":
ânoun
1.something considered by an authority or by general consent as a basis of comparison; an approved model.
3.a rule or principle that is used as a basis for judgment: They tried to establish standards for a new philosophical approach.
5.standards, those morals, ethics, habits, etc., established by authority, custom, or an individual as acceptable: He tried to live up to his father's standards.
23.serving as a basis of weight, measure, value, comparison, or judgment.
Here is the definition of the word "authority" used in one definition of "standard":
noun,plural-ties.
1. the power to determine, adjudicate, or otherwise settle issues or disputes; j urisdiction; the right to control, command, or determine.
2. a power or right delegated or given; authorization: Who has the authority to grant permission?
3. a person or body of persons in whom authority is vested, as a governmental ag ency.
4. Usually, authorities. persons having the legal power to make and enforce the law; government: They finally persuaded the authorities that they were not involved in espionage.
5. an accepted source of information, advice, etc.
Here is the definition of the word anarchy:
ânoun
1. a state of society without government or law.
2. political and social disorder due to the absence of governmental control: The death of the king was followed by a year of anarchy.
3. a theory that regards the absence of all direct or coercive government as a p olitical ideal and that proposes the cooperative and voluntary association of individuals and groups as the principal mode of organized society.
4. confusion; chaos; disorder: Intellectual and moral anarchy followed his loss of faith.
Andre Merzky wrote:
Hi Pieter,
its great to see some additional response, besides Sam :-)
Quoting [Pieter Hintjens] (Mar 25 2010):
On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston [1]<samj@samj.net> wrote:
Mine too - if you can't reuse/remix the work then it's not free enough.
The ability to remix a standard seems an essential freedom: if a standard becomes too complex or encumbered by patents then this is the only way to save parts of it.
*sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard?
What I (naively) think is that I can always create a specification like
"This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1."
Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry...
Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO.
That's why for Digistan we defined[1] the ability to fork a standard under a share-alike license as a necessary aspect. We chose the GPLv3 mainly because it includes some safeguards against software patents, which CC does not.
I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange.
We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either.
Thanks, Andre.
-Pieter
[1] [2]http://www.digistan.org/text:rationale#toc6
References
1. mailto:samj@samj.net 2. http://www.digistan.org/text:rationale#toc6
-- Nothing is ever easy.
On Sun, Mar 28, 2010 at 6:25 PM, Andre Merzky <andre@merzky.net> wrote:
Basically, all OGF is asking for right now is, that instead of forking, a new name or version number is applied to a specification, so that a specific OGF recommendation can still carry that interop promise.
A trademark will do a better job of doing that than copyrights ever would have anyway. @Gary: A standard is described by a specification - indeed one standard could be described by many specifications (for example, one official specification and one reverse engineered from a compliant implementation). Ideally you want your standard to be well described in specifications (supported by test suites, interop bake-offs, etc.) such that the implementations are interoperable. Sam
Dear group, To finally close this issue I wanna setup a concall to discuss this matter. Please fill in the doodle so we can find the best time for this discussion... http://doodle.com/irv86rayupyzfwe4 Cheers, -Thijs -----Original Message----- From: Andre Merzky <andre@merzky.net> Reply-to: Andre Merzky <andre@merzky.net> To: Pieter Hintjens <ph@imatix.com> Cc: Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk>, Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Fri, 26 Mar 2010 23:28:37 +0100 Hi Pieter, its great to see some additional response, besides Sam :-) Quoting [Pieter Hintjens] (Mar 25 2010):
On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> wrote:
Mine too - if you can't reuse/remix the work then it's not free enough.
The ability to remix a standard seems an essential freedom: if a standard becomes too complex or encumbered by patents then this is the only way to save parts of it.
*sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard? What I (naively) think is that I can always create a specification like "This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1." Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry... Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO.
That's why for Digistan we defined[1] the ability to fork a standard under a share-alike license as a necessary aspect. We chose the GPLv3 mainly because it includes some safeguards against software patents, which CC does not.
I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange. We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either. Thanks, Andre.
-Pieter
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
Thijs, Haven't we got a spec to finish? I wasn't even able to sit through the last weekly call because it veered so far off course (granted I had a filthy headache at the time courtesy a nasty flu), but I see little value in wasting what little volunteer time we have when it seems pretty clear we're at an impasse on the copyright issue. Sam On Sun, Mar 28, 2010 at 11:29 AM, Thijs Metsch <Thijs.Metsch@sun.com> wrote:
Dear group,
To finally close this issue I wanna setup a concall to discuss this matter. Please fill in the doodle so we can find the best time for this discussion...
http://doodle.com/irv86rayupyzfwe4
Cheers,
-Thijs
-----Original Message----- From: Andre Merzky <andre@merzky.net> Reply-to: Andre Merzky <andre@merzky.net> To: Pieter Hintjens <ph@imatix.com> Cc: Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk>, Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Fri, 26 Mar 2010 23:28:37 +0100
Hi Pieter,
its great to see some additional response, besides Sam :-)
Quoting [Pieter Hintjens] (Mar 25 2010):
On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> wrote:
Mine too - if you can't reuse/remix the work then it's not free enough.
The ability to remix a standard seems an essential freedom: if a standard becomes too complex or encumbered by patents then this is the only way to save parts of it.
*sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard?
What I (naively) think is that I can always create a specification like
"This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1."
Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry...
Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO.
That's why for Digistan we defined[1] the ability to fork a standard under a share-alike license as a necessary aspect. We chose the GPLv3 mainly because it includes some safeguards against software patents, which CC does not.
I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange.
We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either.
Thanks, Andre.
-Pieter
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
A simple solution to 'the copyright issue' is to grant a shared copyright to the OGF while keeping your own copyright as well. On Sun, Mar 28, 2010 at 8:38 AM, Sam Johnston <samj@samj.net> wrote:
Thijs, Haven't we got a spec to finish? I wasn't even able to sit through the last weekly call because it veered so far off course (granted I had a filthy headache at the time courtesy a nasty flu), but I see little value in wasting what little volunteer time we have when it seems pretty clear we're at an impasse on the copyright issue. Sam
On Sun, Mar 28, 2010 at 11:29 AM, Thijs Metsch <Thijs.Metsch@sun.com> wrote:
Dear group,
To finally close this issue I wanna setup a concall to discuss this matter. Please fill in the doodle so we can find the best time for this discussion...
http://doodle.com/irv86rayupyzfwe4
Cheers,
-Thijs
-----Original Message----- From: Andre Merzky <andre@merzky.net> Reply-to: Andre Merzky <andre@merzky.net> To: Pieter Hintjens <ph@imatix.com> Cc: Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk>, Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Fri, 26 Mar 2010 23:28:37 +0100
Hi Pieter,
its great to see some additional response, besides Sam :-)
Quoting [Pieter Hintjens] (Mar 25 2010):
On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> wrote:
Mine too - if you can't reuse/remix the work then it's not free enough.
The ability to remix a standard seems an essential freedom: if a standard becomes too complex or encumbered by patents then this is the only way to save parts of it.
*sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard?
What I (naively) think is that I can always create a specification like
"This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1."
Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry...
Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO.
That's why for Digistan we defined[1] the ability to fork a standard under a share-alike license as a necessary aspect. We chose the GPLv3 mainly because it includes some safeguards against software patents, which CC does not.
I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange.
We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either.
Thanks, Andre.
-Pieter
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Sun, Mar 28, 2010 at 5:39 PM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
A simple solution to 'the copyright issue' is to grant a shared copyright to the OGF while keeping your own copyright as well.
Works for me - let's move on. Sam
On Sun, Mar 28, 2010 at 8:38 AM, Sam Johnston <samj@samj.net> wrote:
Thijs, Haven't we got a spec to finish? I wasn't even able to sit through the last weekly call because it veered so far off course (granted I had a filthy headache at the time courtesy a nasty flu), but I see little value in wasting what little volunteer time we have when it seems pretty clear we're at an impasse on the copyright issue. Sam
On Sun, Mar 28, 2010 at 11:29 AM, Thijs Metsch <Thijs.Metsch@sun.com> wrote:
Dear group,
To finally close this issue I wanna setup a concall to discuss this matter. Please fill in the doodle so we can find the best time for this discussion...
http://doodle.com/irv86rayupyzfwe4
Cheers,
-Thijs
-----Original Message----- From: Andre Merzky <andre@merzky.net> Reply-to: Andre Merzky <andre@merzky.net> To: Pieter Hintjens <ph@imatix.com> Cc: Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk>, Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Fri, 26 Mar 2010 23:28:37 +0100
Hi Pieter,
its great to see some additional response, besides Sam :-)
Quoting [Pieter Hintjens] (Mar 25 2010):
On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> wrote:
Mine too - if you can't reuse/remix the work then it's not free enough.
The ability to remix a standard seems an essential freedom: if a standard becomes too complex or encumbered by patents then this is the only way to save parts of it.
*sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard?
What I (naively) think is that I can always create a specification like
"This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1."
Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry...
Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO.
That's why for Digistan we defined[1] the ability to fork a standard under a share-alike license as a necessary aspect. We chose the GPLv3 mainly because it includes some safeguards against software patents, which CC does not.
I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange.
We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either.
Thanks, Andre.
-Pieter
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
How do you wanna finish a spec without this issue fixed? I wanna finish it now...We can leave the conall. But I have the feeling that not everything is settled/cleared out yet. So we need to discuss it and if we do that by mail it's gonna take ages... -Thijs -----Original Message----- From: Sam Johnston <samj@samj.net> To: Thijs Metsch <Thijs.Metsch@Sun.COM> Cc: Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg <occi-wg@ogf.org>, Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk> Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Sun, 28 Mar 2010 17:38:31 +0200 Thijs, Haven't we got a spec to finish? I wasn't even able to sit through the last weekly call because it veered so far off course (granted I had a filthy headache at the time courtesy a nasty flu), but I see little value in wasting what little volunteer time we have when it seems pretty clear we're at an impasse on the copyright issue. Sam On Sun, Mar 28, 2010 at 11:29 AM, Thijs Metsch <Thijs.Metsch@sun.com> wrote: Dear group, To finally close this issue I wanna setup a concall to discuss this matter. Please fill in the doodle so we can find the best time for this discussion... http://doodle.com/irv86rayupyzfwe4 Cheers, -Thijs -----Original Message----- From: Andre Merzky <andre@merzky.net> Reply-to: Andre Merzky <andre@merzky.net> To: Pieter Hintjens <ph@imatix.com> Cc: Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk>, Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Fri, 26 Mar 2010 23:28:37 +0100 Hi Pieter, its great to see some additional response, besides Sam :-) Quoting [Pieter Hintjens] (Mar 25 2010): > > On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> > wrote: > > > Mine too - if you can't reuse/remix the work then it's not free > > enough. > > The ability to remix a standard seems an essential freedom: if a > standard becomes too complex or encumbered by patents then this is > the only way to save parts of it. *sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard? What I (naively) think is that I can always create a specification like "This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1." Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry... Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO. > That's why for Digistan we defined[1] the ability to fork a > standard under a share-alike license as a necessary aspect. We > chose the GPLv3 mainly because it includes some safeguards against > software patents, which CC does not. I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange. We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either. Thanks, Andre. > -Pieter > > > [1] http://www.digistan.org/text:rationale#toc6 -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
Thijs, On Sun, Mar 28, 2010 at 6:39 PM, Thijs Metsch <Thijs.Metsch@sun.com> wrote:
How do you wanna finish a spec without this issue fixed? I wanna finish it now...We can leave the conall. But I have the feeling that not everything is settled/cleared out yet. So we need to discuss it and if we do that by mail it's gonna take ages...
I've said all I care to say on the subject - if you guys want to have a conf call about it then knock yourselves out, just don't expect it to change anything on my side. We have *far* more important things to be doing right now. Sam
I would imagine that achieving consensus on various issues related to the OCCI spec should be one of the important things for the OCCI-WG to be doing right now, as the version 1.0 specification is now out of public comment and is in the final stages before becoming a GFD. This most definitely includes the issue of copyright/license of the final GFD, and just because Sam Johnston decides he¹s done with the conversation does not indicate consensus in the group and/or the organization. -- Chris On 28/3/10 16:29 , "Sam Johnston" <samj@samj.net> wrote:
Thijs,
On Sun, Mar 28, 2010 at 6:39 PM, Thijs Metsch <Thijs.Metsch@sun.com> wrote:
How do you wanna finish a spec without this issue fixed? I wanna finish it now...We can leave the conall. But I have the feeling that not everything is settled/cleared out yet. So we need to discuss it and if we do that by mail it's gonna take ages...
I've said all I care to say on the subject - if you guys want to have a conf call about it then knock yourselves out, just don't expect it to change anything on my side. We have far more important things to be doing right now.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Mon, Mar 29, 2010 at 7:14 PM, Christopher Smith <csmith@platform.com>wrote:
I would imagine that achieving consensus on various issues related to the OCCI spec *should* be one of the important things for the OCCI-WG to be doing right now, as the version 1.0 specification is now out of public comment and is in the final stages before becoming a GFD. This most definitely includes the issue of copyright/license of the final GFD, and just because Sam Johnston decides he’s done with the conversation does not indicate consensus in the group and/or the organization.
The spec out for public comment is *far from complete* so before we do * anything* else it needs to be finished - at least we'll then have something (long overdue) to talk about and market. My time is extremely and increasingly limited and I don't plan to waste any more of it discussing something that I was quite clear about from the outset - unjustifiably restrictive licensing *will* unnecessarily stifle adoption. Ironically trying to avoid forking by seeking consensus where there is apparently none to be had virtually guarantees a fork from the outset. Sam
Just as a procedural aside from copyright/license issues.... If you have very substantive changes to the document that has been through public comment already, do you realize another 60 day comment period might be necessary (i.e. if the changes aren¹t just for addressing the current set of public comments)? -- Chris On 29/3/10 10:58 , "Sam Johnston" <samj@samj.net> wrote:
On Mon, Mar 29, 2010 at 7:14 PM, Christopher Smith <csmith@platform.com> wrote:
I would imagine that achieving consensus on various issues related to the OCCI spec should be one of the important things for the OCCI-WG to be doing right now, as the version 1.0 specification is now out of public comment and is in the final stages before becoming a GFD. This most definitely includes the issue of copyright/license of the final GFD, and just because Sam Johnston decides he¹s done with the conversation does not indicate consensus in the group and/or the organization.
The spec out for public comment is far from complete so before we do anything else it needs to be finished - at least we'll then have something (long overdue) to talk about and market. My time is extremely and increasingly limited and I don't plan to waste any more of it discussing something that I was quite clear about from the outset - unjustifiably restrictive licensing will unnecessarily stifle adoption. Ironically trying to avoid forking by seeking consensus where there is apparently none to be had virtually guarantees a fork from the outset.
Sam
On Mon, Mar 29, 2010 at 8:24 PM, Christopher Smith <csmith@platform.com>wrote:
Just as a procedural aside from copyright/license issues....
If you have very substantive changes to the document that has been through public comment already, do you realize another 60 day comment period might be necessary (i.e. if the changes aren’t just for addressing the current set of public comments)?
Yes, so be it. At least this time round we will have a feature complete draft so subsequent changes should be cosmetic (which is to say people can fairly safely start implementing). From an openness point of view it's hard to criticise having not one but TWO rounds of public comments :) Sam
I¹m all in favour of a well reviewed spec. Just wanted to make sure this was understood. Thanks, -- Chris On 29/3/10 11:34 , "Sam Johnston" <samj@samj.net> wrote:
On Mon, Mar 29, 2010 at 8:24 PM, Christopher Smith <csmith@platform.com> wrote:
Just as a procedural aside from copyright/license issues....
If you have very substantive changes to the document that has been through public comment already, do you realize another 60 day comment period might be necessary (i.e. if the changes aren¹t just for addressing the current set of public comments)?
Yes, so be it. At least this time round we will have a feature complete draft so subsequent changes should be cosmetic (which is to say people can fairly safely start implementing). From an openness point of view it's hard to criticise having not one but TWO rounds of public comments :)
Sam
Speaking about the outset: I would assume that the OGF copyright rules were clear and known from the very beginning, when people first got involved, while personal opinions naturally were not. Perhaps it is reasonable to expect that people would respect and accept the rules commonly understood when the effort started. A crazy thought? Costas On 29 Mar 2010, at 20:58, Sam Johnston wrote:
wrote: I would imagine that achieving consensus on various issues related to the OCCI spec should be one of the important things for the OCCI- WG to be doing right now, as the version 1.0 specification is now out of public comment and is in the final stages before becoming a GFD. This most definitely includes the issue of copyright/license of
On Mon, Mar 29, 2010 at 7:14 PM, Christopher Smith <csmith@platform.com the final GFD, and just because Sam Johnston decides he’s done with the conversation does not indicate consensus in the group and/or the organization.
The spec out for public comment is far from complete so before we do anything else it needs to be finished - at least we'll then have something (long overdue) to talk about and market. My time is extremely and increasingly limited and I don't plan to waste any more of it discussing something that I was quite clear about from the outset - unjustifiably restrictive licensing will unnecessarily stifle adoption. Ironically trying to avoid forking by seeking consensus where there is apparently none to be had virtually guarantees a fork from the outset.
Sam
On Wed, Mar 31, 2010 at 12:05 AM, Constantinos (Costas) Kotsokalis < constantinos.kotsokalis@udo.edu> wrote:
Speaking about the outset:
I would assume that the OGF copyright rules were clear and known from the very beginning, when people first got involved, while personal opinions naturally were not. Perhaps it is reasonable to expect that people would respect and accept the rules commonly understood when the effort started.
A crazy thought?
I've been dealing with this issue behind the scenes the whole time and am only discussing it in public now because my attempts to convince the OGF to loosen up on arcane copyright restrictions have thus far failed. My only concern is the success of the specification and having invested countless hours of my time I'll break as many eggs as necessary to ensure that - I've even volunteered to assist with the registration of the requisite trademarks to prevent the confusion people are concerned about. We've now exchanged well over 50 emails in this thread alone on a subject that is not getting us any closer to having the long overdue specification finished - that worries me greatly in terms of this group's ability to focus and deliver. It's also disconcerting that, after having (necessarily) given the group some breathing space over the last few months, there has not been a single substantive edit<http://code.google.com/p/occi/source/list?path=/docs/occi-core.xml> in my absence. While I appreciate that important work is being done, our number one priority remains outstanding. Sam On 29 Mar 2010, at 20:58, Sam Johnston wrote:
On Mon, Mar 29, 2010 at 7:14 PM, Christopher Smith <csmith@platform.com>wrote:
I would imagine that achieving consensus on various issues related to the OCCI spec *should* be one of the important things for the OCCI-WG to be doing right now, as the version 1.0 specification is now out of public comment and is in the final stages before becoming a GFD. This most definitely includes the issue of copyright/license of the final GFD, and just because Sam Johnston decides he’s done with the conversation does not indicate consensus in the group and/or the organization.
The spec out for public comment is *far from complete* so before we do * anything* else it needs to be finished - at least we'll then have something (long overdue) to talk about and market. My time is extremely and increasingly limited and I don't plan to waste any more of it discussing something that I was quite clear about from the outset - unjustifiably restrictive licensing *will* unnecessarily stifle adoption. Ironically trying to avoid forking by seeking consensus where there is apparently none to be had virtually guarantees a fork from the outset.
Sam
Costas - you make a good point, far from a crazy idea :) and perhaps for everyone here it is wise to review the copyright rules again.
From what I have seen so far OGF has been very flexible and open to changes in licensing and have actively and positively engaged especially in the area of enforcement through trademark as Sam has suggested.
Regarding substantive edits, we all well know that the docs are currently just coming out of public comment, after which any comments received will be dealt with, resulting in updates. As Chris said, any substantive updates to the specification before official publication may require another 60 days period of public comment. Andy From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: Wednesday, March 31, 2010 12:12 AM To: Constantinos (Costas) Kotsokalis Cc: occi-wg; Thijs Metsch Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) On Wed, Mar 31, 2010 at 12:05 AM, Constantinos (Costas) Kotsokalis <constantinos.kotsokalis@udo.edu<mailto:constantinos.kotsokalis@udo.edu>> wrote: Speaking about the outset: I would assume that the OGF copyright rules were clear and known from the very beginning, when people first got involved, while personal opinions naturally were not. Perhaps it is reasonable to expect that people would respect and accept the rules commonly understood when the effort started. A crazy thought? I've been dealing with this issue behind the scenes the whole time and am only discussing it in public now because my attempts to convince the OGF to loosen up on arcane copyright restrictions have thus far failed. My only concern is the success of the specification and having invested countless hours of my time I'll break as many eggs as necessary to ensure that - I've even volunteered to assist with the registration of the requisite trademarks to prevent the confusion people are concerned about. We've now exchanged well over 50 emails in this thread alone on a subject that is not getting us any closer to having the long overdue specification finished - that worries me greatly in terms of this group's ability to focus and deliver. It's also disconcerting that, after having (necessarily) given the group some breathing space over the last few months, there has not been a single substantive edit<http://code.google.com/p/occi/source/list?path=/docs/occi-core.xml> in my absence. While I appreciate that important work is being done, our number one priority remains outstanding. Sam On 29 Mar 2010, at 20:58, Sam Johnston wrote: On Mon, Mar 29, 2010 at 7:14 PM, Christopher Smith <csmith@platform.com<mailto:csmith@platform.com>> wrote: I would imagine that achieving consensus on various issues related to the OCCI spec should be one of the important things for the OCCI-WG to be doing right now, as the version 1.0 specification is now out of public comment and is in the final stages before becoming a GFD. This most definitely includes the issue of copyright/license of the final GFD, and just because Sam Johnston decides he's done with the conversation does not indicate consensus in the group and/or the organization. The spec out for public comment is far from complete so before we do anything else it needs to be finished - at least we'll then have something (long overdue) to talk about and market. My time is extremely and increasingly limited and I don't plan to waste any more of it discussing something that I was quite clear about from the outset - unjustifiably restrictive licensing will unnecessarily stifle adoption. Ironically trying to avoid forking by seeking consensus where there is apparently none to be had virtually guarantees a fork from the outset. Sam ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Perhaps we can discuss this on Weds confcall? -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Thijs Metsch Sent: Sunday, March 28, 2010 5:40 PM To: occi-wg Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) How do you wanna finish a spec without this issue fixed? I wanna finish it now...We can leave the conall. But I have the feeling that not everything is settled/cleared out yet. So we need to discuss it and if we do that by mail it's gonna take ages... -Thijs -----Original Message----- From: Sam Johnston <samj@samj.net> To: Thijs Metsch <Thijs.Metsch@Sun.COM> Cc: Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg <occi-wg@ogf.org>, Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk> Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Sun, 28 Mar 2010 17:38:31 +0200 Thijs, Haven't we got a spec to finish? I wasn't even able to sit through the last weekly call because it veered so far off course (granted I had a filthy headache at the time courtesy a nasty flu), but I see little value in wasting what little volunteer time we have when it seems pretty clear we're at an impasse on the copyright issue. Sam On Sun, Mar 28, 2010 at 11:29 AM, Thijs Metsch <Thijs.Metsch@sun.com> wrote: Dear group, To finally close this issue I wanna setup a concall to discuss this matter. Please fill in the doodle so we can find the best time for this discussion... http://doodle.com/irv86rayupyzfwe4 Cheers, -Thijs -----Original Message----- From: Andre Merzky <andre@merzky.net> Reply-to: Andre Merzky <andre@merzky.net> To: Pieter Hintjens <ph@imatix.com> Cc: Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk>, Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Fri, 26 Mar 2010 23:28:37 +0100 Hi Pieter, its great to see some additional response, besides Sam :-) Quoting [Pieter Hintjens] (Mar 25 2010): > > On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> > wrote: > > > Mine too - if you can't reuse/remix the work then it's not free > > enough. > > The ability to remix a standard seems an essential freedom: if a > standard becomes too complex or encumbered by patents then this is > the only way to save parts of it. *sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard? What I (naively) think is that I can always create a specification like "This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1." Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry... Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO. > That's why for Digistan we defined[1] the ability to fork a > standard under a share-alike license as a necessary aspect. We > chose the GPLv3 mainly because it includes some safeguards against > software patents, which CC does not. I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange. We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either. Thanks, Andre. > -Pieter > > > [1] http://www.digistan.org/text:rationale#toc6 -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
I know that some people can't make that timeslot...who I would like to have on the concall... -Thijs -----Original Message----- From: Edmonds, AndrewX <andrewx.edmonds@intel.com> To: Thijs Metsch <Thijs.Metsch@Sun.COM>, occi-wg <occi-wg@ogf.org> Subject: RE: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Mon, 29 Mar 2010 11:21:02 +0100 Perhaps we can discuss this on Weds confcall? -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Thijs Metsch Sent: Sunday, March 28, 2010 5:40 PM To: occi-wg Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) How do you wanna finish a spec without this issue fixed? I wanna finish it now...We can leave the conall. But I have the feeling that not everything is settled/cleared out yet. So we need to discuss it and if we do that by mail it's gonna take ages... -Thijs -----Original Message----- From: Sam Johnston <samj@samj.net> To: Thijs Metsch <Thijs.Metsch@Sun.COM> Cc: Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg <occi-wg@ogf.org>, Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk> Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Sun, 28 Mar 2010 17:38:31 +0200 Thijs, Haven't we got a spec to finish? I wasn't even able to sit through the last weekly call because it veered so far off course (granted I had a filthy headache at the time courtesy a nasty flu), but I see little value in wasting what little volunteer time we have when it seems pretty clear we're at an impasse on the copyright issue. Sam On Sun, Mar 28, 2010 at 11:29 AM, Thijs Metsch <Thijs.Metsch@sun.com> wrote: Dear group, To finally close this issue I wanna setup a concall to discuss this matter. Please fill in the doodle so we can find the best time for this discussion... http://doodle.com/irv86rayupyzfwe4 Cheers, -Thijs -----Original Message----- From: Andre Merzky <andre@merzky.net> Reply-to: Andre Merzky <andre@merzky.net> To: Pieter Hintjens <ph@imatix.com> Cc: Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk>, Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg@ogf.org Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Date: Fri, 26 Mar 2010 23:28:37 +0100 Hi Pieter, its great to see some additional response, besides Sam :-) Quoting [Pieter Hintjens] (Mar 25 2010): > > On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj@samj.net> > wrote: > > > Mine too - if you can't reuse/remix the work then it's not free > > enough. > > The ability to remix a standard seems an essential freedom: if a > standard becomes too complex or encumbered by patents then this is > the only way to save parts of it. *sigh* my mail thread to that topic is counting well over 50 mails by now, and I still did not understand why people think that to be the case. Would you or Sam please so kind and provide either an explicit example for a spec which has successfully been forked, or an explicit use case where that would be neccessary, and where the same cannot be achieved by referencing or profiling the old (complex or encumbered) standard? What I (naively) think is that I can always create a specification like "This specification defines an API API-B, which consists of the API defined in [orig], names API-A, with the call A removed, and the calls B added. The call C changes its semantics to perform a nil operation. Call D takes an additional parameter 'int size' which defaults to 1." Voila, new API specified. Same for interfaces, protocols, etc etc. Why do you need to fork a spec? I don't get it, sorry... Yes, the new API is called differently. This is a *good* thing - I don't want to see two specs for API-A which define different syntax and semantics! Are there use cases where one wants to break interoperability on purpose? *scratch* I can't think of any. At least the version number of the spec needs to change, IMHO. > That's why for Digistan we defined[1] the ability to fork a > standard under a share-alike license as a necessary aspect. We > chose the GPLv3 mainly because it includes some safeguards against > software patents, which CC does not. I understand the concerns about patents. But I think we agreed that this is out of scope for this specific discussion. I am not sure if you are on the OCCI mailing list, so you may have not seen that part of our exchange. We basically agreed I think, and this is also what you say I guess, that neither the OGF IPR nor CC-SA can provide any protection against 3rd party patent claims on technology required to implement a specification. The best one can do is to obtain explicit patent waivers from those parties known to have claims on the relevant technology. GPLv3 helps to some extent of course, but cannot provide protection against 3rd party patent claims either. Thanks, Andre. > -Pieter > > > [1] http://www.digistan.org/text:rationale#toc6 -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
While I could see there are good intentions behind it, doesn't "forking" dilute the value of the original standard due to potential for different forked variations of the same theme? ------- Peter Buonora Global Architecture Andre Merzky <andre@merzky.net> Sent by: occi-wg-bounces@ogf.org 03/24/2010 04:26 PM Please respond to Andre Merzky <andre@merzky.net> To Sam Johnston <samj@samj.net> cc Steven Newhouse <s.newhouse@omii.ac.uk>, occi-wg@ogf.org, Richard Hughes-Jones <Richard.Hughes-Jones@dante.org.uk> Subject Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt) Hi Sam, all, Quoting [Sam Johnston] (Mar 24 2010):
Andre,
This has been on my todo list for a week so I figure some random thoughts at 1am are better than nothing...
Yes, indeed - appreciated!
I firmly believe that it's time for us to raise the bar for standards openness, and part of that is using a license that people are comfortable with such that they won't feel the need to engage a lawyer before [re]using our documents. As evidenced by the W3C notice I posted a few hours ago, I'm not alone on this.
I found the W3C discussion very interesting, thanks again for the link. However, it seems that they come basically to the same conclusion as we do: its great to grant basically total freedom for standards docs, as long as forking of the actual specification is avoided. See page 4 on http://www.w3.org/2010/Talks/doclicense-20100323/#%281%29 which is the summary of the license discussion of the W3C advisory Committe from 2 days ago: "Survey results on question "should W3C publish HTML 5 under a license that allows forking?". Of those who responded, approximately 79% answered "no" and 14% answered "yes" (and the rest abstained)." This is exactly our point :-)
Most existing cloud computing specifications are available under CC licenses and I don't want to give anyone any excuses to choose another standard over ours.
I have asked this before: which standards do you mean? FWIW, I checked again under cloud-standards.org (nice job!), and the only real specs listed there are OCCI/IGF, OVF/DMTF and CDMI/SNIA. OCCI/OGF has the most free license of the three, IMHO. SNIA says ( http://www.snia.org/tech_activities/publicreview/Cloud_Data_Management_Inter... page 2): "The SNIA hereby grants permission for individuals to use this document for personal use only, and for corporations and other business entities to use this document for internal use only (including internal copying, distribution, and display) provided that: - Any text, diagram, chart, table, or definition reproduced shall be reproduced in its entirety with no alteration, and, - Any document, printed or electronic, in which material from this document (or any portion hereof) is reproduced shall acknowledge the SNIA copyright on that material, and shall credit the SNIA for granting permission for its reuse. Other than as explicitly provided above, you may not make any commercial use of this document, sell any excerpt or this entire document, or distribute this document to third parties. All rights not explicitly granted are expressly reserved to SNIA. Permission to use this document for purposes other than those enumerated above may be requested by e-mailing tcmd@snia.org. Please include the identity of the requesting individual and/or company and a brief description of the purpose, nature, and scope of the requested use." Note: SNIA does not allow annotations etc. and DMTF says ( http://www.dmtf.org/standards/published_documents/DSP0243_1.1.0.pdf page 2): "Members and non-members may reproduce DMTF specifications and documents, provided that correct attribution is given." Note: DMTF allows only reproduction, but not reuse, annotation, etc. Can you please let us know what other cloud standards you are refering to? In fact, so far I could not find *any* standard specification under CC, apart from RSS (http://cyber.law.harvard.edu/rss/rss.html). Well, and the RSS situation is *exactly* what we want to avoid for OGF standards: http://diveintomark.org/archives/2004/02/04/incompatible-rss. The wikipedia page on RSS and its variations is also scary ;) If there are other standards under CC which manage a more successfull evolution, I would be very happy to learn about those!
It's too bad Creative Commons don't have a sensible license for standards that covers patents, but perhaps that's something they would consider if we ask nicely - I think I'll do just that.
I still don't think patents come into the discussion here, really. As you said yourself before: one cannot completely shield a standards specification from 3rd part patent claims, no matter what. The best OCCI can do is to collect excemption statements like those on http://www.ogf.org/About/abt_policies_ipr.php from all major stakeholders. Yes, OGF generally operates on a RAND model, but http://www.ogf.org/About/abt_policies_ipr.php explicitely states that we consider royalty-free to be very acceptable, too, in case OCCI wants to go that route.
Cutting to the chase, as a primary contributor to the specification documents I "grant to the OGF and its participants certain licenses and rights" (per [1]OGF Intellectual Property Policy), but I do not assign the copyrights to OGF. As such I can do pretty much what I want with my contributions, including granting non-exclusive licenses to other organisations and publicly releasing them under a license of my choice or into the public domain (no license required).
Uhm - I never met you personally, but are you always like this? I mean, you are basically saying the third time in this thread: "Either it goes my way, or I go elsewhere". I must admit that this is becoming somewhat frustrating. Sam, please be aware that about 20 people spend hours last week dissecting your mails and arguments, and trying to understand the problems *you* have with OGF IPR, in order to fix those. So far, we could not get to the meat of your arguments I think - please help us to do so. We do have an open process, and are very willing to fix things where they are broken. To summarize our previous points, and the arguments above again: what freedom, apart from forking the spec, are you missing? We are considering to change OGF IPR so that documents are released into the public domain if OGF disappears - what other changes would you think would increase the usability of our specs? What other successful standards under CC are you aware of? And yes, we think that forking a specification is a bad thing, and I have not yet seen compelling arguments or use cases otherwise. FWIW, you say "... I do not assign the copyrights to OGF". You are probably aware that this is actually *limiting* OGF's ability to manage document licenses? For example, this would not allow OGF to release documents into the public domain - we can only relicense documents for which OGF owns the Copyright.
I would obviously prefer for the OGF to release the official documents of their own volition (even as an exception for OCCI), but don't think I won't do what is required in order to ensure adequate levels of freedom for our users and implementors (including rewriting contributions from others who reject more liberal licensing). Nor do I see how this would in any way prevent the OGF from reaching the three goals you described below.
Could you please let us know exactly what text of the OCCI docs you consider to be under other contributors copyright? Could we ask those contributors to speak up personally, please? Thanks, Andre.
On Tue, Mar 16, 2010 at 4:56 PM, Andre Merzky <[2]andre@merzky.net> wrote:
Hi Sam, all,
ready to discuss licensing again? :-)
here is an update from OGF28: first, we heard rumours that you may show up here - this would be great, not in the least so that we can discuss the licensing thingie F2F. Usually that is way more productive than endless mailing threads like this one, isn't it :) Anyway, I just wanted to tell you that we have been discussing the issues from the recent email exchanges (and I hope sincerely that these are the issues you are in fact concerned about) within the GFSG.
So, there was some discussion to review the current IPR text, and to clarify those passages which seem, in your reading, to hide the fact/intent that using any amount of text from a GFD for documentation and any other purpose is legally perfectly fine:
"...derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind..."
We will be cross-checking with similar texts of other standards bodies, in particular including IETF, which seem to recently have updated their IPR texts as well, to remove some ambiguities. The OGF IPR was originally modeled after IETF's, and, IIRC, was basically reproducing the OGF IPR word by word.
Further we have been discussing the point you raised that the state of OGF documents would be frozen in the case of OGF's disappearance. If this turns out to be a concern for the community, we will consider adding a clause which would release the documents into the public domain in the case of OGF's demise - we certainly don't want to hold anybody back in continuing to work with OGF documents in that case.
Both of the above changes however need to be evaluated, and need to be approved by the OGF board. While we don't think this is a problem per se, this will need time to be changed.
The OGF IPR is designed as it is to fulfil three goals: (a) support the production and consumption of standards, (b) ensure that OGF documents (i.e. documents released under OGF copyright) went through the OGF document process, and (c) secure OGF against legal litigations. The board will need to make sure that in particular (b) and (c) are not affected by the proposed changes. If this sounds overly bureaucratic to you: well, that is the way we work ;-) Please let us know if changes along those lines would make you sleep better :-D
FWIW: for the same reasons as above (a-c), we do actually require that OGF documents are under full OGF copyright, and it does not seem likely that a proposal for dual licensing would find much support, if any.
Looking forward to see you in Munich!
Best, Andre.
-- Nothing is ever easy. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg This email message and any attachments are for the sole use of the intended recipient(s) and may contain information that is proprietary to Ahold and/or its subsidiaries (Ahold) or otherwise confidential or legally privileged. If you have received this message in error, please notify the sender by reply, and delete all copies of this message and any attachments. If you are the intended recipient you may use the information contained in this message and any files attached to this message only as authorized by Ahold. Files attached to this message may only be transmitted using secure systems and appropriate means of encryption, and must be secured using the same level of password and security protection with which the file was provided to you. Any unauthorized use, dissemination or disclosure of this message or its attachments is strictly prohibited.
participants (10)
-
Alexis Richardson -
Andre Merzky -
Christopher Smith -
Constantinos (Costas) Kotsokalis -
Edmonds, AndrewX -
Gary Mazz -
Peter Buonora -
Pieter Hintjens -
Sam Johnston -
Thijs Metsch