On Wed, Mar 24, 2010 at 9:26 PM, Andre Merzky <andre@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