On Fri, Mar 5, 2010 at 1:32 PM, Andre Merzky <span dir="ltr">&lt;<a href="mailto:andre@merzky.net">andre@merzky.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I understand that you want to provide the user with more rights<br>
(more on that below).  But what has attributions to do with<br>
licensing?  By all means: contribuions need to be acknowledged - but<br>
either by co-authorship, or by explicit statements.  Licensing does<br>
not really help here IMHO.</blockquote><div><br></div><div>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&#39;ll also note the absence of CC licenses which lack the attribution clause (CC-0 et al excluded).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Like, OASIS has a very similar statement:</blockquote><div>&lt;snip&gt; </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

which is almost 1:1 the OGF statement.  Well, OASIS standards get<br>
adopted.  Docbook is a notable example ;-)<br>
<br>
Same for W3C:<br></blockquote><div>&lt;snip&gt;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
and others.<br>
<br>
Could you provide an example where such statements actually hinder<br>
standards adoption?</blockquote><div><br></div><div>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 <a href="http://www.gogrid.com/company/press-releases/gogrid-moves-api-specification-to-creativecommons.php">press release</a> regarding the GoGrid API which summarises nicely as follows:</div>
<div><br></div><div><i>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.</i></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
&gt; It&#39;s going to be hard enough as it is getting people to adopt the<br>
&gt; API without giving them any excuses whatsoever not to (for<br>
&gt; example, being left high and dry should OGF implode or decide to<br>
&gt; get out of the standards game).<br>
<br>
</div>The OGF copyright notice explicitely states:<br>
<br>
  &quot;The limited permissions granted above are perpetual and will<br>
   not be revoked by the OGF or its successors or assignees.&quot;</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">&gt; [I]mplementing a spec may require (among other things) licensing of</div><div class="im">

&gt; pending utility and design patent claims, copyrights, trade dress<br>
&gt; and trademark rights. Putting a specification under a CC license<br>
&gt; gives you a copyright license to the text of the specification; it<br>
&gt; does not give license to the necessary trademarks, or to the<br>
&gt; patents, and depending on the license chosen, may not even give you<br>
&gt; the right to make a derivative work [...]<br>
<br>
</div>Uhm, I think the above is all correct, and important - but I am<br>
missing the bit where th OGF license gives you trouble.  IANAL, so<br>
maybe I am misparsing things - sorry...<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">&gt; That&#39;s why all the news about cloud computing specifications being<br>
&gt; available under CC licenses is essentially non-news, while still<br>
&gt; being a big step forward in standards openness.<br>
&gt;<br>
&gt;&gt; I am not sure I see that, so please indulge me.  From a standard<br>
&gt;&gt; specification I expect it to be freely available, and to be able<br>
&gt;&gt; to distribute it unlimitely, and to be able to implement the<br>
&gt;&gt; described standard w/o any penalty.  OGF IPR allows that.  What<br>
&gt;&gt; are the OGF IPR restrictions you worry about?<br>
&gt;<br>
&gt; OGF&#39;s copyright grants barely enough freedom to implement the<br>
&gt; specification, translate it, and &quot;comment on or otherwise explain it or<br>
&gt; assist in its implementation&quot;.<br>
<br>
</div>Sorry, Sam, I think this is FUD - at least you should have left the<br>
&#39;barely&#39; out ;-)  As said above: the IPR works well for a waste set<br>
of standards very well, and I don&#39;t see complains like this for,<br>
fir example, DocBook...</blockquote><div><br></div><div>Ok, so s/barely/precisely/. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
&gt; You can&#39;t modify it, reuse it, extend it in any way, etc.<br>
<br>
</div>Well, its a *standard* - you are not supposed to change it, thats<br>
the point ;-)  If you want to extend it, or build upon it, that is<br>
surely possible, and frequently done.  One way is to use extension<br>
points defined by the standard.  OCCI has lots of those.  A second<br>
way is to profile a standard, so to define a set of limitations and<br>
boundary conditions to a standard, and to standardize that<br>
separately.  That is what, IIRC, many of the WS specs are doing.<br>
<br>
*changing* a standard spec will, by definition, void the benefits of<br>
having a standard in the first place.</blockquote><div><br></div><div>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&#39;s useless.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
&gt;&gt;&gt; That may have made sense in an environment where standards<br>
&gt;&gt;&gt; organisations are jostling for control over their patch of the<br>
&gt;&gt;&gt; playing field, but this is not my concern.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; CC allows the same, but *also* allows to change the document, and to<br>
&gt;&gt;&gt; distribute that modified document again under the same terms.<br>
&gt;&gt;<br>
&gt;&gt; What<br>
&gt;&gt; I wonder, and sorry if I formulated that unclearly before: what is<br>
&gt;&gt; the use case for that, i.e. what is the problem you are trying to<br>
&gt;&gt; solve by Dual-licensing under OGF/CC?<br>
&gt;<br>
&gt; Here&#39;s some examples:<br>
&gt; * Extending the specification or annotating it<br>
<br>
</div>See above: extenting is possible.<br>
<br>
Annotation: please read again:<br>
<br>
  &quot;This document and translations of it may be copied and furnished<br>
  to others, and derivative works that comment on or otherwise<br>
  explain it or assist in its implementation may be prepared,<br>
  copied, published and distributed, in whole or in part, without<br>
  restriction of any kind, provided that the above copyright notice<br>
  and this paragraph are included on all such copies and derivative<br>
  works.&quot;<br>
<br>
&quot;derivative works that comment on or otherwise explain it&quot;!<br></blockquote><div><br></div><div>&quot;derivative works that comment on or otherwise explain it or assist in its implementation&quot; 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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; * Correcting errors<br>
<br>
OGF has an errata process for that.<br></blockquote><div><br></div><div>So long as OGF exists...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; * Deriving a new specification from it (be it for a similar or<br>
&gt; different application altogether)<br>
<br>
See above.<br></blockquote><div><br></div><div>Ditto.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; * Including (parts of) the specification in documentation<br>
<br>
See above<br></blockquote><div><br></div><div>Really? Including product documentation? I&#39;m sufficiently unconvinced that I wouldn&#39;t do it myself... </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; * Including other documentation (Wikipedia, standards, etc.) in the</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">&gt; specification and/or association explanatory documents<br>
<br>
</div>See above<br></blockquote><div><br></div><div>No, that is definitely <b><span class="Apple-style-span" style="text-decoration: underline;">not</span></b> possible as Wikipedia at least is CC-BY-SA licensed. Although I&#39;ve so far only copied snippets here and there, I intend to include large passages in explanatory documentation.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; * Incorporating (parts of) the specification in (eg Wikipedia)<br>
&gt; articles<br>
<br>
Again, see above.  That is all covered nicely.</blockquote><div><br></div><div>No it isn&#39;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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">&gt; To clarify, if we exercise the &quot;Open Cloud Computing Interface&quot;, &quot;OCCI&quot;<br>

&gt; and/or logo trademarks (all of which are common law but could easily be<br>
&gt; registered) then nobody would be able to release a specification with<br>
&gt; the same or similar name, nor claim compatibility with it. Sure I could<br>
&gt; exercise my rights granted under copyright but I would have to call my<br>
&gt; derivative something else, like the Super Awesome Cloud API. This is by<br>
&gt; far the most effective way to ensure that implementations are<br>
&gt; interoperable, rather than trying to beat copyright into the role -<br>
&gt; after all, anyone else could document the API under whatever license<br>
&gt; they wanted anyway.<br>
<br>
</div>Yes, that makes sense I guess, but still does not explain the CC ;-)<br></blockquote><div><br></div><div>No, but it does provide a simple, effective alternative to the copyright restrictions that are usually in place.</div>
<div><br></div><div>Computing standards only get more open over time - cloud is a great opportunity to take the next step and one that I personally don&#39;t plan to miss.</div><div><br></div><div>Perhaps it would be more insightful to turn this argument around and have you explain what benefit you think these additional restrictions provide?</div>
<div><br></div><div>Sam</div><div><br></div></div>