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

[Sam Johnston]

On Wed, Mar 24, 2010 at 9:26 PM, Andre Merzky <andre at merzky.net> wrote:

>
>  "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 :-)


Mine too - if you can't reuse/remix the work then it's not free
enough. This<http://www.digistan.org/open-standard:definition>is where
I think we need to get to for Internet standards in general (and
will eventually, given the ongoing trend towards openness):

*The Digital Standards Organization defines free and open standard as
follows:*

   - *A free and open standard is immune to vendor capture at all stages in
   its life-cycle. Immunity from vendor capture makes it possible to freely
   use, improve upon, trust, and extend a standard over time.*
   - *The standard is adopted and will be maintained by a not-for-profit
   organization, and its ongoing development occurs on the basis of an open
   decision-making procedure available to all interested parties.*
   - *The standard has been published and the standard specification
   document is available freely. It must be permissible to all to copy,
   distribute, and use it freely.*
   - *The patents possibly present on (parts of) the standard are made
   irrevocably available on a royalty-free basis.*
   - *There are no constraints on the re-use of the standard.*

*The economic outcome of a free and open standard, which can be measured, is
that it enables perfect competition between suppliers of products based on
the standard.*

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

Most of the standards I care about are available under CC - Rackspace Cloud
APIs <http://www.theregister.co.uk/2009/07/23/rackspace_open_apis/>, Sun
Cloud APIs <http://www.sun.com/aboutsun/pr/2009-03/sunflash.20090318.2.xml>,
GoGrid APIs<http://www.gogrid.com/company/press-releases/gogrid-moves-api-specification-to-creativecommons.php>,
etc. which means that we can remix parts we like - for example if they have
a decent implementation of asynchronous operations (or vice versa)... not to
mention the benefit of having access to the whole of Wikipedia now it's been
relicensed.


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

I tend to agree - very few companies have patents on cloud APIs (Amazon have
at least one) and there's not much we can do about them.


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


I can assure you that RAND is out - if we find a patent (RAND or otherwise)
then we'll work around
it<http://news.swpat.org/2010/03/transcript-tridgell-patents/>
.


> Uhm - I never met you personally, but are you always like this?
>

For things I believe in/care about, yes.

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

The fear of forking doesn't stop people releasing code under open source
licenses now, does it? Forking is a last resort that people only really
exercise when the wheels fall off upstream (for example, withdrawing open
source versions, changing licensing conditions, serious management
issues<http://en.wikipedia.org/wiki/Joomla#History>,
etc.). It requires getting a critical mass of contributors, and in our case
implementors, users, etc. as well - not something that's really feasible
unless there's real problems - in which case everyone will appreciate not
being up the creek without a paddle.


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


OGF never asked and I never offered... but for the record, OGF is welcome to
release any and all of my contributions under any license that is *less
restrictive* than what we have today (including public domain).

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

In the documents I care about most (the specifications), I'm not aware of
any. Maybe Andy?

Overall I don't think that it's excessive openness that will kill off the
standard, but lack of it certainly could. I believe there is an expectation
that cloud specifications will be available under unrestrictive licenses and
that if we don't meet this expectation then we could well be criticised for
it. I also see it as a key differentiator (in addition to our open process)
from specs like DMTF's vCloud-based API. That is, we have nothing to risk
and everything to gain. So what if someone takes the document and makes a
success out of it - at least they'll have succeeded where we've failed.
Finally, if we're worried about interoperability problems then we're better
off enforcing the trademark so they can't call it OCCI than trying to use
copyrights to prevent them copying/reverse engineering us.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100325/97302040/attachment.html