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

Wed Feb 24 09:33:19 CST 2010

Alexander,

It seems your "open" is my "closed" so I'd honestly rather discuss what font
we use - reuse rights are far too important to give up in the name of
maintaining control.

Sam

On Wed, Feb 24, 2010 at 3:31 PM, Alexander Papaspyrou <
alexander.papaspyrou at tu-dortmund.de> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100224/f31bb2fe/attachment.html 