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

[Andre Merzky]

Hi Sam, 

thanks for your thoughful answer - and sorry for the late reply.
Life got in the way of things, as usual...

Quoting [Sam Johnston] (Feb 23 2010):
> 
> On Mon, Feb 22, 2010 at 9:39 AM, Andre Merzky <[1]andre at merzky.net>
> wrote:
> 
>>> The intention is that the specification be available under
>>> both licenses (at the user's discretion).
>> 
>> "at the user's discretion" -- that is good to know, and should
>> be added to the text, IMHO. Thanks.
> 
> Ok so there are two sides to this:
>
> a) incorporating content others have made available under CC-BY[-SA]
> 
> and
> 
> b) making our content available to others under CC-BY[-SA] for others
> to use
>
> Perhaps "at the users discretion" is not the right wording - the
> intention is that the user has more rights than would be afforded by
> the OGF license alone and also that all those directly and indirectly
> involved in its creation get credited (while contributors' names may
> not be rendered yet, there is a list in the DocBook source). 

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.


> I also seek to avoid any possible barriers to entry - of which
> overly restrictive licensing is one (especially now people [2]are
> aware that it's an issue). 

I still don't see what those barriers are.  I don't think that not
being able to change a spec has any impact on adoption.

Like, OASIS has a very similar statement:

  "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 section are included on all such copies and derivative
  works. However, this document itself may not be modified in any
  way, including by removing the copyright notice or references to
  OASIS, except as needed for the purpose of developing any document
  or deliverable produced by an OASIS Technical Committee (in which
  case the rules applicable to copyrights, as set forth in the OASIS
  IPR Policy, must be followed) or as required to translate it into
  languages other than English."

which is almost 1:1 the OGF statement.  Well, OASIS standards get
adopted.  Docbook is a notable example ;-)

Same for W3C:

  "No right to create modifications or derivatives of W3C documents
  is granted pursuant to this license. However, if additional
  requirements (documented in the Copyright FAQ) are satisfied, the
  right to create modifications or derivatives is sometimes granted
  by the W3C to individuals complying with those requirements"

and others.

Could you provide an example where such statements actually hinder
standards adoption?  


> 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."


> Basically we have three things that we're able to protect:
> - The actual API itself (which can be protected by patents)
> - References to the API (which can be protected by trademarks)
> - Documentation of the API (which is by default protected by
>   copyright)
> FSF's "[3]Did You Say Intellectual Property? It's a Seductive Mirage"
> rant goes into more detail on this topic.
> We go to great lengths to ensure that the API itself, as in the
> specific version(s) approved by the OGF (but not necessarily
> derivatives of it), do not infringe patents held by working group
> participants in the process. We can't guarantee that others don't hold
> patents over it (nobody can) and we don't want to write a "blank
> cheque" to anyone who cares to modify the specification - so we
> specifically exclude patents from the copyright licensing provisions
> (in contrast with licenses like the [4]Apache 2.0 license which do
> include a patent grant).
> Creative Commons' [5]What good is a CC licensed specification? article
> explains this topic in detail, confirming that:
> 
> [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...


> 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...


> 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.  


>>> 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"!

> * Correcting errors

OGF has an errata process for that.


> * Deriving a new specification from it (be it for a similar or
> different application altogether)

See above.


> * Including (parts of) the specification in documentation

See above


> * Including other documentation (Wikipedia, standards, etc.) in the
> specification and/or association explanatory documents

See above

> * Incorporating (parts of) the specification in (eg Wikipedia)
> articles

Again, see above.  That is all covered nicely.


>>> I think the important thing in terms of the *normative* specification
>>> is to rely on trademark rather than copyright law - at the end of the
>>> day it's more effective anyway and it doesn't prevent your APIs from
>>> being reused by others.
>>
>> I think I understand what you mean by trademark in respect to
>> standard specs.  I am not sure I see what you mean, that trademark
>> prevents your API from being reused.  Isn't that (a) the idea of
>> interface standardization, and (b) enforced by licenses rather than
>> trademarks?  I never felt compelled not to use some API just because
>> it has trademarks attached, as long as it was free...  Am I
>> misparsing your statement?
> 
> 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 ;-)

Thanks for your patience, 

  Andre.


-- 
Nothing is ever easy.