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

Wed Feb 24 08:31:30 CST 2010

Sam, Andre,

Am 23.02.2010 um 13:04 schrieb Sam Johnston:

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

This probably holds for any kind of organization, and I pretty much still don't see the entry barriers. People have been implementing standards for ages, and as long as the spec is free, available, distributable, and implementable, I really can't see the problem here. 

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

Can you clarify that with respect to the needs of the OCCI spec?

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

Then, actually, it provides everything what a normative standards spec needs, doesn't it? Modifying and deviating the spec probably is not a great idea anyway, since (by definition) it is not normative anymore...

> 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

Makes no sense w.r.t. to being normative.

> 	• Correcting errors

Same.

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

Can't come up with a concrete use case for that. And: there is nothing against coming up with a new spec embracing ideas from OCCI, or is it, Andre?

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

Regarding this topic, we should probably contact Greg Newby and Joel Replogle and ask them for their opinion before using a sledgehammer to crack a nut.

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

+1

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

Alas, Sam, I still don't get it. But maybe it is just me...

Best,
Alexander

> >    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.
> 
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg

-- 
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100224/964be226/attachment.bin 
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100224/964be226/attachment-0001.bin 