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

[Andre Merzky]

Hi Sam, 

Again, sorry for the late reply...

Quoting [Sam Johnston] (Mar 05 2010):
> 
>>> You can't modify it, reuse it, extend it in any way, etc.
>> 
>> Well, its a *standard* - you are not supposed to change it, thats
>> the point ;-)  If you want to extend it, or build upon it, that is
>> surely possible, and frequently done.  One way is to use extension
>> points defined by the standard.  OCCI has lots of those.  A second
>> way is to profile a standard, so to define a set of limitations and
>> boundary conditions to a standard, and to standardize that
>> separately.  That is what, IIRC, many of the WS specs are doing.
>> *changing* a standard spec will, by definition, void the benefits of
>> having a standard in the first place.
> 
> 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's useless.


Derive/extend the standard, errata to the standard, and
attribution: those seem to be the focus of most of your points I
think - so I hope its ok to focus on those?


DERIVE A NEW STANDARD
---------------------

Assume I specify a communication API standard called 'EP'

  class endpoint
  {
    public:
      // constructor
      endpoint (url contact);

      // io ops
      string  read  (int    size);
      size    write (string data);
  };

The standard further defines state model, exceptions, yadayadayada.
Several implementations of this API exist, and applications use the
API just as shown, and are able to interop (switch between
implementations).

Now, for the life of me I can't imagine how one would take that
standard, change it to
  
  class endpoint
  {
    public:
      // constructor
      endpoint (url contact);

      // io ops
      void*   read  (int   size);
      size    write (void* data);
  };

and still call it EP.  That would make no sense whatsoever, as any
implementation would be incompatible to the original EP
implementations.


Also, expanding makes no sense, really:

  class endpoint
  {
    public:
      // constructor
      endpoint (url contact);

      // c'tor does not connect anymore - new method here
      void connect (void);

      // io ops
      string  read  (int    size);
      size    write (string data);
  };

Any application coded against the old standard will compile against
the new API, but will not work, as it never calls connect.  So,
semantic changes are out, too.


As you say elsewhere: the key here is that the new spec should not
be called EP: this is enforced by trademark.  So, you probably would
call the new spec SuperEP or so.  But that can just as well be
achieved by deriving the new standard, w/o rewriting it:

  // see EP specification[3] for details on endpoint
  class super_endpoint : public endpoint
  {
    public:
      // overload constructor, not connecting
      endpoint (url contact);

      // c'tor does not connect anymore - new method here
      void connect (void);
  };


Again: a spec should have extension points, and should allow for
profiling, as valid options to create a derived specification.
Also, that process should go through a review process. 

If you are worried that those options are closed by the OGF IPR, for
either deriving new specs within our outside of OGF, then thats
needs fixing on OGF side.  Please give us a specific use case you
feel we do not cover, so we can discuss specific adjustements.

A spec under CC which is just edited by someone and called NewSpec,
*without* approval by some standards body, will have a hard time to
be accepted IMHO - so I don't think CC helps you really.

[API: Yes, I choose a favourable example here, obviously.  But the
 same mechanism should hold for other standards, and for protocols
 instead of APIs etc.]


ERRATA
------

In the class above, int should actually be 'unsigned'.  But if
anybody comes along and can fix it (it is out there under CC,
right?), than one party might change that to 'unsigned int', another
changes it to 'unsigned long',  etc.  

Which version is normative?  How are implementations supposed to
interop?

IMHO, errata need to undergo the exact same rigorous standardization
process as the original spec (and yes,  I am too aware that this is
a major PITA.)

If you think the errata process in OGF is insufficient, or are
worried about errata after OGF's demise: those may be valid
concerns.  Let us know about those, and we can discuss changes
there.


Attribution:
------------

I violently agree that attribution is important, and needs to be
prominent in the document.  However, I still don't understand how
that affect licensing: contributors contribute by adding ideas,
code, or actual text, but as OGF works, that is all automatically
under OGF IPR, as soon as it enters OGF WG discussions.  All OGF
members agree to that procedure when signing up, and this is how
IETF, IEEE, OASIS etc etc work as well I think.  If text is
contributed under a different license, then it must be ensured that
the original license allows to apply the OGF IPR.

Has CC-BY-SA licensed text entered the specification?




Some more replies inlined below

> "derivative works that comment on or otherwise explain it or assist in
> its implementation" 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.

Correct - so what do you think is *not* covered?


>>> * Correcting errors
>>>
>> OGF has an errata process for that.
> 
> So long as OGF exists...

Well, this is the first point I can subscribe to.  That is something
to ponder over - thanks.

I don't think CC helps though - see above.


>>> * Including (parts of) the specification in documentation
>>See above
> 
> Really? Including product documentation? I'm sufficiently unconvinced
> that I wouldn't do it myself...

FWIW, we regularily do that, for our SAGA reference implementation.  


>> > * Including other documentation (Wikipedia, standards, etc.) in
>> >   the specification and/or association explanatory documents
>> 
>> See above
> 
> No, that is definitely not possible as Wikipedia at least is CC-BY-SA
> licensed. Although I've so far only copied snippets here and there, I
> intend to include large passages in explanatory documentation.


Whoever creates or edits an Wikipedia article has the copyright on
the text (see
http://en.wikipedia.org/wiki/Wikipedia:About#Trademarks_and_copyrights).
Adding any citations therein fall under fair use, as usual.   In the
case of OGF specs, that also holds for the *complete* text, the OGF
copyright statement covers that case explicitely: 
  
  "This document and translations of it may be copied and furnished
  to others, and 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,*
    
  provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works."

(emphasis/structure mine).  So, yes, you can cite the complete text
if you wish to do so.  What must remain unchanged is the document
*itself* - so, you cannot change the document and distribute it as
*the* specification.  


>> > * Incorporating (parts of) the specification in (eg Wikipedia)
>> > articles
>> >
>> Again, see above.  That is all covered nicely.
> 
> No it isn'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).

See above - that is perfectly accepable.


> Perhaps it would be more insightful to turn this argument around and
> have you explain what benefit you think these additional restrictions
> provide?

Fair enough.

Two arguments from my side: a formal one, and a generic one.

Generic:  I don't want to see specifications to change.  Ever. 
          Errata:      yes -> needs due process, just as the spec
                              itself
          Profiles:    yes -> will be a new standard
          Derivations: yes -> will be a new standard
          Changes:     no  -> this *will* break compliance


Formal: all work in OGF is under OGF IPR, by definition.  This is
what everybody who attents a WG session signs.  This is what you
agree to when creating a GridForge account.  I don't think you can
simply change that.  Even if one assumes that you wrote most of the
spec, it is the brainchild of a group of people who contributed
their input under OGF IPR.

Best, Andre.


PS.: I realize that answering such long mails takes significant time
which you likely want to spend more productively elsewhere.  But I
think this issue needs to be resolved at some point.  At the lates,
the OGF editor will request a clarification/justification: the
documents which are under OGF public review right now do not mention
CC, but there are likely to be questions once a CC tagged doc gets
officially submitted.

-- 
Nothing is ever easy.