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

[Sam Johnston]

On Mon, Feb 22, 2010 at 9:39 AM, Andre Merzky <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 also seek to avoid any possible
barriers to entry - of which overly restrictive licensing is one (especially
now people are aware <http://twitter.com/bpiatt/status/9441771369> that it's
an issue). 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).

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 "Did You Say “Intellectual Property”? It's a Seductive
Mirage<http://www.gnu.org/philosophy/not-ipr.html>"
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 Apache 2.0
license<http://www.apache.org/licenses/LICENSE-2.0.html>which do
include a patent grant).

Creative Commons' What good is a CC licensed
specification?<http://creativecommons.org/weblog/entry/8165>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 [...]*


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*". You can't modify it, reuse it, extend it in any way, etc.
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
   - Correcting errors
   - Deriving a new specification from it (be it for a similar or different
   application altogether)
   - Including (parts of) the specification in documentation
   - Including other documentation (Wikipedia, standards, etc.) in the
   specification and/or association explanatory documents
   - Incorporating (parts of) the specification in (eg Wikipedia) articles

Woah, full stop please: I am just curious about the licensing mode,
> and ask questions about it, in order to *understand* it.  No need to
> get defensive :-)


I hope that by referring to the nuclear option I won't have to use it is
all...


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

Sam


> >    Sam
> >    On Thu, Feb 18, 2010 at 7:41 PM, Andre Merzky <[2]andre at merzky.net>
> >    wrote:
> >
> >    Quoting [Sam Johnston] (Feb 18 2010):
> >    >
> >    > We maintain a Google Code repository at
> >
> >      > [3]http://code.google.com/p/occi/ ...
> >      Hi Sam, all,
> >      the project states on the entry page, as it should :-), that all
> >      material is under OGF IPR.
> >      [4]
> http://code.google.com/p/occi/source/browse/docs/occi-copyright.p
> >      df
> >      states pretty much the same, but additionally states that
> >       "The Open Cloud Computing Interface (OCCI) by Open Grid Forum is
> >       dual-licensed under a Creative Commons Attribution 3.0 Unported
> >       License"
> >      While I am a big fan of dual- or multi-licensing for source code, I
> >      would appreciate the motivation for dual-licensing the OCCI
> >      specification: what is the problem you are trying to solve?
> >      In particular, I do not understand how Creative Commons makes sense
> >      for a *normative* specification, as the usual use case for CC is to
> >      create derivative work - which almost by definition will break the
> >      standard, and will lead to confusion what document remains normative
> >      etc.
> >      Also, there are two modi operandi for dual licensing, AFAICS: either
> >      the end user is free to pick what license to apply to the document,
> >      or the end user is required to adhere to the specifics of both
> >      licenses.  I assume that you choose the first modus, but that is not
> >      explicitely stated in the document - as statement to that respect
> >      should be added.  The second modus wuld not make much sense IMHO, as
> >      the OGF IPR seems, to me, more constrained than CC (no changes
> >      allowed), and the additional CC license would thus have no effect
> >      whatsoever?
> >      I know that license discussions can be tedious and tend to be
> >      emotional.  Also, we all are probably not lawyers :-)  Anyway, if
> >      you or someone initiated could shed some light on how and why that
> >      approach was chosen, I would appreciate the insight.
> > Best, Andre.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100223/d760e16b/attachment.html