Hi Sam, Again, sorry for the late reply... Quoting [Sam Johnston] (Mar 05 2010):
You can't modify it, reuse it, extend it in any way, etc.
Well, its a *standard* - you are not supposed to change it, thats the point ;-) If you want to extend it, or build upon it, that is surely possible, and frequently done. One way is to use extension points defined by the standard. OCCI has lots of those. A second way is to profile a standard, so to define a set of limitations and boundary conditions to a standard, and to standardize that separately. That is what, IIRC, many of the WS specs are doing. *changing* a standard spec will, by definition, void the benefits of having a standard in the first place.
What if I want to create a new standard, or extend this one to cover, say, platform services? Sure I can license my extension however I want, but without the core spec it's useless.
Derive/extend the standard, errata to the standard, and attribution: those seem to be the focus of most of your points I think - so I hope its ok to focus on those? DERIVE A NEW STANDARD --------------------- Assume I specify a communication API standard called 'EP' class endpoint { public: // constructor endpoint (url contact); // io ops string read (int size); size write (string data); }; The standard further defines state model, exceptions, yadayadayada. Several implementations of this API exist, and applications use the API just as shown, and are able to interop (switch between implementations). Now, for the life of me I can't imagine how one would take that standard, change it to class endpoint { public: // constructor endpoint (url contact); // io ops void* read (int size); size write (void* data); }; and still call it EP. That would make no sense whatsoever, as any implementation would be incompatible to the original EP implementations. Also, expanding makes no sense, really: class endpoint { public: // constructor endpoint (url contact); // c'tor does not connect anymore - new method here void connect (void); // io ops string read (int size); size write (string data); }; Any application coded against the old standard will compile against the new API, but will not work, as it never calls connect. So, semantic changes are out, too. As you say elsewhere: the key here is that the new spec should not be called EP: this is enforced by trademark. So, you probably would call the new spec SuperEP or so. But that can just as well be achieved by deriving the new standard, w/o rewriting it: // see EP specification[3] for details on endpoint class super_endpoint : public endpoint { public: // overload constructor, not connecting endpoint (url contact); // c'tor does not connect anymore - new method here void connect (void); }; Again: a spec should have extension points, and should allow for profiling, as valid options to create a derived specification. Also, that process should go through a review process. If you are worried that those options are closed by the OGF IPR, for either deriving new specs within our outside of OGF, then thats needs fixing on OGF side. Please give us a specific use case you feel we do not cover, so we can discuss specific adjustements. A spec under CC which is just edited by someone and called NewSpec, *without* approval by some standards body, will have a hard time to be accepted IMHO - so I don't think CC helps you really. [API: Yes, I choose a favourable example here, obviously. But the same mechanism should hold for other standards, and for protocols instead of APIs etc.] ERRATA ------ In the class above, int should actually be 'unsigned'. But if anybody comes along and can fix it (it is out there under CC, right?), than one party might change that to 'unsigned int', another changes it to 'unsigned long', etc. Which version is normative? How are implementations supposed to interop? IMHO, errata need to undergo the exact same rigorous standardization process as the original spec (and yes, I am too aware that this is a major PITA.) If you think the errata process in OGF is insufficient, or are worried about errata after OGF's demise: those may be valid concerns. Let us know about those, and we can discuss changes there. Attribution: ------------ I violently agree that attribution is important, and needs to be prominent in the document. However, I still don't understand how that affect licensing: contributors contribute by adding ideas, code, or actual text, but as OGF works, that is all automatically under OGF IPR, as soon as it enters OGF WG discussions. All OGF members agree to that procedure when signing up, and this is how IETF, IEEE, OASIS etc etc work as well I think. If text is contributed under a different license, then it must be ensured that the original license allows to apply the OGF IPR. Has CC-BY-SA licensed text entered the specification? Some more replies inlined below
"derivative works that comment on or otherwise explain it or assist in its implementation" is hardly the entire scope of derivative works. This would permit, for example, writing a book which includes the spec along with some explanatory guidance provided you did not make any modification to the specification itself.
Correct - so what do you think is *not* covered?
* Correcting errors
OGF has an errata process for that.
So long as OGF exists...
Well, this is the first point I can subscribe to. That is something to ponder over - thanks. I don't think CC helps though - see above.
* Including (parts of) the specification in documentation See above
Really? Including product documentation? I'm sufficiently unconvinced that I wouldn't do it myself...
FWIW, we regularily do that, for our SAGA reference implementation.
* Including other documentation (Wikipedia, standards, etc.) in the specification and/or association explanatory documents
See above
No, that is definitely not possible as Wikipedia at least is CC-BY-SA licensed. Although I've so far only copied snippets here and there, I intend to include large passages in explanatory documentation.
Whoever creates or edits an Wikipedia article has the copyright on the text (see http://en.wikipedia.org/wiki/Wikipedia:About#Trademarks_and_copyrights). Adding any citations therein fall under fair use, as usual. In the case of OGF specs, that also holds for the *complete* text, the OGF copyright statement covers that case explicitely: "This document and translations of it may be copied and furnished to others, and 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,* provided that the above copyright notice and this paragraph are included on all such copies and derivative works." (emphasis/structure mine). So, yes, you can cite the complete text if you wish to do so. What must remain unchanged is the document *itself* - so, you cannot change the document and distribute it as *the* specification.
* Incorporating (parts of) the specification in (eg Wikipedia) articles
Again, see above. That is all covered nicely.
No it isn't, because the license is more restrictive than CC-BY-SA. This is an important point because while it would currently be possible to write a detailed article including relevant parts and examples from the specification, if the CC licensing clause were removed it would not be possible to include any part of it without a fair use rationale (that would be unlikely to be accepted).
See above - that is perfectly accepable.
Perhaps it would be more insightful to turn this argument around and have you explain what benefit you think these additional restrictions provide?
Fair enough. Two arguments from my side: a formal one, and a generic one. Generic: I don't want to see specifications to change. Ever. Errata: yes -> needs due process, just as the spec itself Profiles: yes -> will be a new standard Derivations: yes -> will be a new standard Changes: no -> this *will* break compliance Formal: all work in OGF is under OGF IPR, by definition. This is what everybody who attents a WG session signs. This is what you agree to when creating a GridForge account. I don't think you can simply change that. Even if one assumes that you wrote most of the spec, it is the brainchild of a group of people who contributed their input under OGF IPR. Best, Andre. PS.: I realize that answering such long mails takes significant time which you likely want to spend more productively elsewhere. But I think this issue needs to be resolved at some point. At the lates, the OGF editor will request a clarification/justification: the documents which are under OGF public review right now do not mention CC, but there are likely to be questions once a CC tagged doc gets officially submitted. -- Nothing is ever easy.