On Mon, Feb 22, 2010 at 9:39 AM, Andre Merzky <andre@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 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" 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 which do include a patent grant).

Creative Commons' 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 [...]

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