[occi-wg] OCCI Editor Getting Started Guide (docs/README.txt)

[Sam Johnston]

On Fri, Mar 5, 2010 at 1:32 PM, Andre Merzky <andre at merzky.net> wrote:

> 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<http://www.gogrid.com/company/press-releases/gogrid-moves-api-specification-to-creativecommons.php>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100305/526246bf/attachment.html