I understand that you want to provide the user with more rights
(more on that below). But what has attributions to do with
licensing? By all means: contribuions need to be acknowledged - but
either by co-authorship, or by explicit statements. Licensing does
not really help here IMHO.
We should acknowledge contributors not only for ethical reasons but because authors have certain inalienable rights in many jurisdictions. It is also a useful reward for those who have volunteered (or been paid for!) their time and encourages people to take ownership of the success of the specification. You'll also note the absence of CC licenses which lack the attribution clause (CC-0 et al excluded).
Like, OASIS has a very similar statement:
<snip>
which is almost 1:1 the OGF statement. Well, OASIS standards get
adopted. Docbook is a notable example ;-)
Same for W3C:
<snip>
and others.
Could you provide an example where such statements actually hinder
standards adoption?
For better or worse there is a [mis]conception that CC licensing is necessary/useful/positive and even sufficient for cloud APIs. For example, this
press release regarding the GoGrid API which summarises nicely as follows:
This allows any Cloud Computing provider to build an API based on this OpenSpec, as well as to modify, share, and republish changes to the specification itself and profit from these efforts.
> It's going to be hard enough as it is getting people to adopt the
> API without giving them any excuses whatsoever not to (for
> example, being left high and dry should OGF implode or decide to
> get out of the standards game).
The OGF copyright notice explicitely states:
"The limited permissions granted above are perpetual and will
not be revoked by the OGF or its successors or assignees."
Sure, but then the standard is dead and needs to be rewritten/reverse engineered from scratch. Not so with a CC licensed specification which can be updated/expanded as needed.
> [I]mplementing a spec may require (among other things) licensing of
> pending utility and design patent claims, copyrights, trade dress
> and trademark rights. Putting a specification under a CC license
> gives you a copyright license to the text of the specification; it
> does not give license to the necessary trademarks, or to the
> patents, and depending on the license chosen, may not even give you
> the right to make a derivative work [...]
Uhm, I think the above is all correct, and important - but I am
missing the bit where th OGF license gives you trouble. IANAL, so
maybe I am misparsing things - sorry...
It is more restrictive than CC and our requirements (in terms of ensuring compliance with a static, normative specification) can be met with trademark law alone.
> That's why all the news about cloud computing specifications being
> available under CC licenses is essentially non-news, while still
> being a big step forward in standards openness.
>
>> I am not sure I see that, so please indulge me. From a standard
>> specification I expect it to be freely available, and to be able
>> to distribute it unlimitely, and to be able to implement the
>> described standard w/o any penalty. OGF IPR allows that. What
>> are the OGF IPR restrictions you worry about?
>
> OGF's copyright grants barely enough freedom to implement the
> specification, translate it, and "comment on or otherwise explain it or
> assist in its implementation".
Sorry, Sam, I think this is FUD - at least you should have left the
'barely' out ;-) As said above: the IPR works well for a waste set
of standards very well, and I don't see complains like this for,
fir example, DocBook...
Ok, so s/barely/precisely/.
> 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.
>>> That may have made sense in an environment where standards
>>> organisations are jostling for control over their patch of the
>>> playing field, but this is not my concern.
>>>
>>> CC allows the same, but *also* allows to change the document, and to
>>> distribute that modified document again under the same terms.
>>
>> What
>> I wonder, and sorry if I formulated that unclearly before: what is
>> the use case for that, i.e. what is the problem you are trying to
>> solve by Dual-licensing under OGF/CC?
>
> Here's some examples:
> * Extending the specification or annotating it
See above: extenting is possible.
Annotation: please read again:
"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."
"derivative works that comment on or otherwise explain it"!
"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.
> * Correcting errors
OGF has an errata process for that.
So long as OGF exists...
> * Deriving a new specification from it (be it for a similar or
> different application altogether)
See above.
Ditto.
> * Including (parts of) the specification in documentation
See above
Really? Including product documentation? I'm sufficiently unconvinced that I wouldn't do it myself...
> * 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.
> * 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).
> To clarify, if we exercise the "Open Cloud Computing Interface", "OCCI"
> and/or logo trademarks (all of which are common law but could easily be
> registered) then nobody would be able to release a specification with
> the same or similar name, nor claim compatibility with it. Sure I could
> exercise my rights granted under copyright but I would have to call my
> derivative something else, like the Super Awesome Cloud API. This is by
> far the most effective way to ensure that implementations are
> interoperable, rather than trying to beat copyright into the role -
> after all, anyone else could document the API under whatever license
> they wanted anyway.
Yes, that makes sense I guess, but still does not explain the CC ;-)
No, but it does provide a simple, effective alternative to the copyright restrictions that are usually in place.
Computing standards only get more open over time - cloud is a great opportunity to take the next step and one that I personally don't plan to miss.
Perhaps it would be more insightful to turn this argument around and have you explain what benefit you think these additional restrictions provide?
Sam