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

[Andre Merzky]

Hi Sam, all,

Quoting [Sam Johnston] (Mar 24 2010):
> 
> Andre,
>
> This has been on my todo list for a week so I figure some random
> thoughts at 1am are better than nothing...

Yes, indeed - appreciated!


> I firmly believe that it's time for us to raise the bar for
> standards openness, and part of that is using a license that
> people are comfortable with such that they won't feel the need to
> engage a lawyer before [re]using our documents. As evidenced by
> the W3C notice I posted a few hours ago, I'm not alone on this.

I found the W3C discussion very interesting, thanks again for the
link.  However, it seems that they come basically to the same
conclusion as we do: its great to grant basically total freedom for
standards docs, as long as forking of the actual specification is
avoided.  See page 4 on
http://www.w3.org/2010/Talks/doclicense-20100323/#%281%29 which is
the summary of the license discussion of the W3C advisory Committe
from 2 days ago:

  "Survey results on question "should W3C publish HTML 5 under a
  license that allows forking?". Of those who responded,
  approximately 79% answered "no" and 14% answered "yes" (and the
  rest abstained)."

This is exactly our point :-)


> Most existing cloud computing specifications are available under
> CC licenses and I don't want to give anyone any excuses to choose
> another standard over ours.

I have asked this before: which standards do you mean?  FWIW, I
checked again under cloud-standards.org (nice job!), and the only
real specs listed there are OCCI/IGF, OVF/DMTF and CDMI/SNIA.
OCCI/OGF has the most free license of the three, IMHO.

SNIA says
(http://www.snia.org/tech_activities/publicreview/Cloud_Data_Management_Interface_Draft1.0.pdf
page 2):

  "The SNIA hereby grants permission for individuals to use this
  document for personal use only, and for corporations and other
  business entities to use this document for internal use only
  (including internal copying, distribution, and display) provided
  that: 
   
   - Any text, diagram, chart, table, or definition reproduced shall
     be reproduced in its entirety with no alteration, and, 
  
   - Any document, printed or electronic, in which material from
     this document (or any portion hereof) is reproduced shall
     acknowledge the SNIA copyright on that material, and shall
     credit the SNIA for granting permission for its reuse. 

  Other than as explicitly provided above, you may not make any
  commercial use of this document, sell any excerpt or this entire
  document, or distribute this document to third parties. 

  All rights not explicitly granted are expressly reserved to SNIA.
  Permission to use this document for purposes other than those
  enumerated above may be requested by e-mailing tcmd at snia.org.
  Please include the identity of the requesting individual and/or
  company and a brief description of the purpose, nature, and scope
  of the requested use."

Note: SNIA does not allow annotations etc.
  

and DMTF says (
http://www.dmtf.org/standards/published_documents/DSP0243_1.1.0.pdf
page 2): 

  "Members and non-members may reproduce DMTF specifications and
  documents, provided that correct attribution is given."

Note: DMTF allows only reproduction, but not reuse, annotation, etc.


Can you please let us know what other cloud standards you are
refering to?  In fact, so far I could not find *any* standard
specification under CC, apart from RSS
(http://cyber.law.harvard.edu/rss/rss.html).  Well, and the RSS
situation is *exactly* what we want to avoid for OGF standards:
http://diveintomark.org/archives/2004/02/04/incompatible-rss.  The
wikipedia page on RSS and its variations is also scary ;)

If there are other standards under CC which manage a more
successfull evolution, I would be very happy to learn about those!


> It's too bad Creative Commons don't have a sensible license for
> standards that covers patents, but perhaps that's something they
> would consider if we ask nicely - I think I'll do just that.

I still don't think patents come into the discussion here, really.
As you said yourself before: one cannot completely shield a
standards specification from 3rd part patent claims, no matter what.
The best OCCI can do is to collect excemption statements like those
on http://www.ogf.org/About/abt_policies_ipr.php from all major
stakeholders.

Yes, OGF generally operates on a RAND model, but
http://www.ogf.org/About/abt_policies_ipr.php explicitely states
that we consider royalty-free to be very acceptable, too, in case
OCCI wants to go that route.


> Cutting to the chase, as a primary contributor to the
> specification documents I "grant to the OGF and its participants
> certain licenses and rights" (per [1]OGF Intellectual Property
> Policy), but I do not assign the copyrights to OGF. As such I can
> do pretty much what I want with my contributions, including
> granting non-exclusive licenses to other organisations and
> publicly releasing them under a license of my choice or into the
> public domain (no license required).

Uhm - I never met you personally, but are you always like this? 
I mean, you are basically saying the  third time in this thread:
"Either it goes my way, or I go elsewhere".  I must admit that this
is becoming somewhat frustrating. 

Sam, please be aware that about 20 people spend hours last week
dissecting your mails and arguments, and trying to understand the
problems *you* have with OGF IPR, in order to fix those.  So far, we
could not get to the meat of your arguments I think - please help us
to do so.  We do have an open process, and are very willing to fix
things where they are broken.  

To summarize our previous points, and the arguments above again:
what freedom, apart from forking the spec, are you missing?  We are
considering to change OGF IPR so that documents are released into
the public domain if OGF disappears - what other changes would you
think would increase the usability of our specs?  What other
successful standards under CC are you aware of?

And yes, we think that forking a specification is a bad thing, and I
have not yet seen compelling arguments or use cases otherwise.



FWIW, you say "... I do not assign the copyrights to OGF".  You are
probably aware that this is actually *limiting* OGF's ability to
manage document licenses?  For example, this would not allow OGF to
release documents into the public domain - we can only relicense
documents for which OGF owns the Copyright.


> I would obviously prefer for the OGF to release the official
> documents of their own volition (even as an exception for OCCI),
> but don't think I won't do what is required in order to ensure
> adequate levels of freedom for our users and implementors
> (including rewriting contributions from others who reject more
> liberal licensing). Nor do I see how this would in any way prevent
> the OGF from reaching the three goals you described below.

Could you please let us know exactly what text of the OCCI docs you
consider to be under other contributors copyright?  Could we ask
those contributors to speak up personally, please?  

Thanks, Andre.


> On Tue, Mar 16, 2010 at 4:56 PM, Andre Merzky
> <[2]andre at merzky.net> wrote:
> 
>> Hi Sam, all,
>>
>> ready to discuss licensing again? :-)
>>
>> here is an update from OGF28: first, we heard rumours that you
>> may show up here - this would be great, not in the least so that
>> we can discuss the licensing thingie F2F.  Usually that is way
>> more productive than endless mailing threads like this one, isn't
>> it :) Anyway, I just wanted to tell you that we have been
>> discussing the issues from the recent email exchanges (and I hope
>> sincerely that these are the issues you are in fact concerned
>> about) within the GFSG.
>>
>> So, there was some discussion to review the current IPR text, and
>> to clarify those passages which seem, in your reading, to hide
>> the fact/intent that using any amount of text from a GFD for
>> documentation and any other purpose is legally perfectly fine:
>>
>>   "...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..."
>>
>> We will be cross-checking with similar texts of other standards
>> bodies, in particular including IETF, which seem to recently have
>> updated their IPR texts as well, to remove some ambiguities.  The
>> OGF IPR was originally modeled after IETF's, and, IIRC, was
>> basically reproducing the OGF IPR word by word.
>>
>> Further we have been discussing the point you raised that the
>> state of OGF documents would be frozen in the case of OGF's
>> disappearance.  If this turns out to be a concern for the
>> community, we will consider adding a clause which would release
>> the documents into the public domain in the case of OGF's demise
>> - we certainly don't want to hold anybody back in continuing to
>> work with OGF documents in that case.
>>
>> Both of the above changes however need to be evaluated, and need
>> to be approved by the OGF board.  While we don't think this is a
>> problem per se, this will need time to be changed.
>>
>> The OGF IPR is designed as it is to fulfil three goals: (a)
>> support the production and consumption of standards, (b) ensure
>> that OGF documents (i.e.  documents released under OGF copyright)
>> went through the OGF document process, and (c) secure OGF against
>> legal litigations.  The board will need to make sure that in
>> particular (b) and (c) are not affected by the proposed changes.
>> If this sounds overly bureaucratic to you: well, that is the way
>> we work ;-) Please let us know if changes along those lines would
>> make you sleep better :-D
>>
>> FWIW: for the same reasons as above (a-c), we do actually require
>> that OGF documents are under full OGF copyright, and it does not
>> seem likely that a proposal for dual licensing would find much
>> support, if any.
>>
>> Looking forward to see you in Munich!
>>
>> Best, Andre.

-- 
Nothing is ever easy.