Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt)
Good question so I'm copying the list (especially for the benefit of the newcomers). We maintain a Google Code repository at http://code.google.com/p/occi/ which includes a Mercurial (hg) repository at https://occi.googlecode.com/hg/ - this is in addition to the (currently fairly ordinary) marketing site at http://www.occi-wg.org/ and OGF's GridForge at http://forge.ogf.org/ The best way to get at up-to-the-second updates is to go to the Source tab, then Browse. There you'll find a "code" and "docs" directory (the purpose of which should be fairly obvious) and under docs you'll find 3 versions (DocBook XML, PDF and HTML) of each file. Click on e.g. occi-core.html<http://code.google.com/p/occi/source/browse/docs/occi-core.html>and on the right hand side you'll find a "View raw file" link (in this case occi-core.html <http://occi.googlecode.com/hg/docs/occi-core.html>). Note that sometimes the PDF and HTML renderings fall behind the DocBook XML renderings by a few hours/days but regenerating them is fairly straightforward, following the instructions in README.txt<http://occi.googlecode.com/hg/docs/README.txt> Hope this helps, Sam On Thu, Feb 18, 2010 at 6:23 PM, X wrote:
Dear Sam:
Does your changes to occi docs are available online?
Regards, X
Afternoon all, As you know I've been quieter than usual lately (I've been busy changing companies/countries) but now I have a little bit of time on my hands I've been fleshing out the OCCI spec. Much of the feedback we've received has been that it's too abstract (which you'll recall was by design following
format wars of 2009) so I've added some examples to help people visualise what's going on. I've also added the following guide to the repository as README.txt so as to make it as easy as possible for others to get involved in the editing of
OCCI documents. I had a clash for the call this week but understand this issue was raised for the 17th time so hopefully this will put it to bed and make it a lot easier for more of you to get involved - if you have any questions you know where to find me. Cheers, Sam
Open Cloud Computing Interface (OCCI)
Editor Getting Started Guide
Overview
========
"DocBook is a semantic markup language for technical documentation. It
was
originally intended for writing technical documents related to computer hardware and software but it can be used for any other sort of documentation."
It was selected for OCCI in order to allow us to maintain a single
On Thu, Feb 18, 2010 at 1:09 PM, Sam Johnston <samj@samj.net> wrote: the the source
and publish to multiple formats:
* HyperText Markup Language (HTML)
* Portable Document Format (PDF)
* Plain Text (TXT)
Getting Started
===============
You will need the following to get started editing OCCI:
* Mercurial (http://mercurial.selenic.com/)
* XML Editor (XMLmind: http://www.xmlmind.com/xmleditor/download.shtml )
1. Download and install Mercurial and your preferred XML editor.
2. Get a local copy of the occi repository with this command:
hg clone https://occi.googlecode.com/hg/ occi
3. Edit the DocBook source (Hint: TDG5 is a great resource both for getting started and as a reference)
Checking In
===========
If you want to check in changes you'll likely need to create a ~/.hgrc file something like this:
[ui]
username = John Citizen <john@example.com>
[auth]
occi.prefix = occi.googlecode.com/hg/
occi.username = john@example.com
occi.password = LF3W8dKKJG5X7
occi.schemes = https
You can now commit your changes (with a useful changelog entry please!) using:
hg ci
hg push
Rendering
=========
You will need DocBook tools if you want to render the DocBook XML to other formats (which you should do each time you check in changes):
* DocBook XSLT (http://sourceforge.net/projects/docbook/files/docbook-xsl-ns/)
* Apache FOP Binaries (http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop)
Under Mac OS X (using the default Makefile):
1. Extract docbook-xsl-ns into ~/Library/XML/XSL
2. Extract Apache FOP and copy build/fop.jar and lib/*.jar into /Library/Java/Extensions
Then whenever you make changes simply run "make" to generate new HTML and PDF versions.
Resources
=========
* Official Site (http://www.docbook.org/)
* Wikipedia - DocBook (http://en.wikipedia.org/wiki/DocBook)
* DocBook 5.0 - The Definitive Guide (http://www.docbook.org/tdg5/en/html/docbook.html)
* DocBook XSL: The Complete Guide (http://www.sagehill.net/docbookxsl/index.html)
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Regards, X
Quoting [Sam Johnston] (Feb 18 2010):
We maintain a Google Code repository at 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. http://code.google.com/p/occi/source/browse/docs/occi-copyright.pdf 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. -- Nothing is ever easy.
Andre, The intention is that the specification be available under both licenses (at the user's discretion). Being available under a Creative Commons license is basically a requirement<http://www.google.com/search?q=cloud+api++%22creative+commons%22>for Cloud APIs nowdays (much to my satisfaction) and anything else - especially the OGF default (which is far more restrictive than even the DMTF license!) - will surely stifle adoption whether justified or not. If that doesn't work for the OGF then I'll just release it under CC myself and remove/rewrite others' contributions (assuming they don't agree to do the same, which would surprise me). 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. Sam On Thu, Feb 18, 2010 at 7:41 PM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Sam Johnston] (Feb 18 2010):
We maintain a Google Code repository at 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. http://code.google.com/p/occi/source/browse/docs/occi-copyright.pdf 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.
-- Nothing is ever easy.
Quoting [Sam Johnston] (Feb 21 2010):
Andre,
Hi Sam,
The intention is that the specification be available under both licenses (at the user's discretion).
"at the user's discretion" -- that is good to know, and should be added to the text, IMHO. Thanks.
Being available under a Creative Commons license is [1]basically a requirement for Cloud APIs nowdays (much to my satisfaction) and anything else - especially the OGF default (which is far more restrictive than even the DMTF license!) - will surely stifle adoption whether justified or not.
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? 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?
If that doesn't work for the OGF then I'll just release it under CC myself and remove/rewrite others' contributions (assuming they don't agree to do the same, which would surprise me).
Woah, full stop please: I am just curious about the licensing mode, and ask questions about it, in order to *understand* it. No need to get defensive :-)
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? Thanks, Andre.
Sam On Thu, Feb 18, 2010 at 7:41 PM, Andre Merzky <[2]andre@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.
On Mon, Feb 22, 2010 at 9:39 AM, Andre Merzky <andre@merzky.net> wrote:
The intention is that the specification be available under both licenses (at the user's discretion).
"at the user's discretion" -- that is good to know, and should be added to the text, IMHO. Thanks.
Ok so there are two sides to this: a> incorporating content others have made available under CC-BY[-SA] and b> making our content available to others under CC-BY[-SA] for others to use 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 <http://twitter.com/bpiatt/status/9441771369> 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). Basically we have three things that we're able to protect: - The actual API itself (which can be protected by *patents*) - References to the API (which can be protected by *trademarks*) - Documentation of the API (which is by default protected by *copyright*) FSF's "Did You Say “Intellectual Property”? It's a Seductive Mirage<http://www.gnu.org/philosophy/not-ipr.html>" rant goes into more detail on this topic. We go to great lengths to ensure that the API itself, as in the specific version(s) approved by the OGF (but not necessarily derivatives of it), do not infringe patents held by working group participants in the process. We can't guarantee that others don't hold patents over it (nobody can) and we don't want to write a "blank cheque" to anyone who cares to modify the specification - so we specifically exclude patents from the copyright licensing provisions (in contrast with licenses like the Apache 2.0 license<http://www.apache.org/licenses/LICENSE-2.0.html>which do include a patent grant). Creative Commons' What good is a CC licensed specification?<http://creativecommons.org/weblog/entry/8165>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 [...]*
That's why all the news about cloud computing specifications being available under CC licenses is essentially non-news, while still being a big step forward in standards openness. 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. 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 - Correcting errors - Deriving a new specification from it (be it for a similar or different application altogether) - 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 Woah, full stop please: I am just curious about the licensing mode,
and ask questions about it, in order to *understand* it. No need to get defensive :-)
I hope that by referring to the nuclear option I won't have to use it is all...
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?
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. Sam
Sam On Thu, Feb 18, 2010 at 7:41 PM, Andre Merzky <[2]andre@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.
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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
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@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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
Sam, Am 24.02.2010 um 16:33 schrieb Sam Johnston:
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.
well, this seems to be the usual problem with the term of "open systems", which has its very own legacy of different understandings. Not quoting the whole debate again in my fixed font-only message style, I'd still like to stress one aspect from my previous thoughts:
• 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.
While personally I don't consider the issues you stated as too important, I must admit that either of us may or may not be right (including both or neither). That's also the reason why I proposed the former: I think that the correct process to cope with the points you rightfully raised and put to discussion would be to escalate them to the appropriate OGF roles and committees. This would, provided that we find the current policies not appropriate for the purpose they strive to achieve, allow the whole OGF community benefit from the IPR-related findings within OCCI and give the opportunity to circumvent the iceberg by making global steering corrections. Best, Alexander -- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
With AMQP we created two docs, one with an AMQP open license, and one that is BSD for things like codegen, which then passes DFSG. alexis On Wed, Feb 24, 2010 at 6:31 PM, Alexander Papaspyrou <alexander.papaspyrou@tu-dortmund.de> wrote:
Sam,
Am 24.02.2010 um 16:33 schrieb Sam Johnston:
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.
well, this seems to be the usual problem with the term of "open systems", which has its very own legacy of different understandings.
Not quoting the whole debate again in my fixed font-only message style, I'd still like to stress one aspect from my previous thoughts:
• 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.
While personally I don't consider the issues you stated as too important, I must admit that either of us may or may not be right (including both or neither). That's also the reason why I proposed the former: I think that the correct process to cope with the points you rightfully raised and put to discussion would be to escalate them to the appropriate OGF roles and committees. This would, provided that we find the current policies not appropriate for the purpose they strive to achieve, allow the whole OGF community benefit from the IPR-related findings within OCCI and give the opportunity to circumvent the iceberg by making global steering corrections.
Best, Alexander
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi Sam, thanks for your thoughful answer - and sorry for the late reply. Life got in the way of things, as usual... Quoting [Sam Johnston] (Feb 23 2010):
On Mon, Feb 22, 2010 at 9:39 AM, Andre Merzky <[1]andre@merzky.net> wrote:
The intention is that the specification be available under both licenses (at the user's discretion).
"at the user's discretion" -- that is good to know, and should be added to the text, IMHO. Thanks.
Ok so there are two sides to this:
a) incorporating content others have made available under CC-BY[-SA]
and
b) making our content available to others under CC-BY[-SA] for others to use
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 understand that you want to provide the user with more rights (more on that below). But what has attributions to do with licensing? By all means: contribuions need to be acknowledged - but either by co-authorship, or by explicit statements. Licensing does not really help here IMHO.
I also seek to avoid any possible barriers to entry - of which overly restrictive licensing is one (especially now people [2]are aware that it's an issue).
I still don't see what those barriers are. I don't think that not being able to change a spec has any impact on adoption. Like, OASIS has a very similar statement: "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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English." which is almost 1:1 the OGF statement. Well, OASIS standards get adopted. Docbook is a notable example ;-) Same for W3C: "No right to create modifications or derivatives of W3C documents is granted pursuant to this license. However, if additional requirements (documented in the Copyright FAQ) are satisfied, the right to create modifications or derivatives is sometimes granted by the W3C to individuals complying with those requirements" and others. Could you provide an example where such statements actually hinder standards adoption?
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).
The OGF copyright notice explicitely states: "The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees."
Basically we have three things that we're able to protect: - The actual API itself (which can be protected by patents) - References to the API (which can be protected by trademarks) - Documentation of the API (which is by default protected by copyright) FSF's "[3]Did You Say Intellectual Property? It's a Seductive Mirage" rant goes into more detail on this topic. We go to great lengths to ensure that the API itself, as in the specific version(s) approved by the OGF (but not necessarily derivatives of it), do not infringe patents held by working group participants in the process. We can't guarantee that others don't hold patents over it (nobody can) and we don't want to write a "blank cheque" to anyone who cares to modify the specification - so we specifically exclude patents from the copyright licensing provisions (in contrast with licenses like the [4]Apache 2.0 license which do include a patent grant). Creative Commons' [5]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 [...]
Uhm, I think the above is all correct, and important - but I am missing the bit where th OGF license gives you trouble. IANAL, so maybe I am misparsing things - sorry...
That's why all the news about cloud computing specifications being available under CC licenses is essentially non-news, while still being a big step forward in standards openness.
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".
Sorry, Sam, I think this is FUD - at least you should have left the 'barely' out ;-) As said above: the IPR works well for a waste set of standards very well, and I don't see complains like this for, fir example, DocBook...
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.
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.
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
See above: extenting is possible. Annotation: please read again: "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." "derivative works that comment on or otherwise explain it"!
* Correcting errors
OGF has an errata process for that.
* Deriving a new specification from it (be it for a similar or different application altogether)
See above.
* Including (parts of) the specification in documentation
See above
* Including other documentation (Wikipedia, standards, etc.) in the specification and/or association explanatory documents
See above
* Incorporating (parts of) the specification in (eg Wikipedia) articles
Again, see above. That is all covered nicely.
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?
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.
Yes, that makes sense I guess, but still does not explain the CC ;-) Thanks for your patience, Andre. -- Nothing is ever easy.
On Fri, Mar 5, 2010 at 1:32 PM, Andre Merzky <andre@merzky.net> wrote:
I understand that you want to provide the user with more rights (more on that below). But what has attributions to do with licensing? By all means: contribuions need to be acknowledged - but either by co-authorship, or by explicit statements. Licensing does not really help here IMHO.
We should acknowledge contributors not only for ethical reasons but because authors have certain inalienable rights in many jurisdictions. It is also a useful reward for those who have volunteered (or been paid for!) their time and encourages people to take ownership of the success of the specification. You'll also note the absence of CC licenses which lack the attribution clause (CC-0 et al excluded). Like, OASIS has a very similar statement: <snip>
which is almost 1:1 the OGF statement. Well, OASIS standards get adopted. Docbook is a notable example ;-)
Same for W3C:
<snip>
and others.
Could you provide an example where such statements actually hinder standards adoption?
For better or worse there is a [mis]conception that CC licensing is necessary/useful/positive and even sufficient for cloud APIs. For example, this press release<http://www.gogrid.com/company/press-releases/gogrid-moves-api-specification-to-creativecommons.php>regarding the GoGrid API which summarises nicely as follows: *This allows any Cloud Computing provider to build an API based on this OpenSpec, as well as to modify, share, and republish changes to the specification itself and profit from these efforts.*
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).
The OGF copyright notice explicitely states:
"The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees."
Sure, but then the standard is dead and needs to be rewritten/reverse engineered from scratch. Not so with a CC licensed specification which can be updated/expanded as needed.
[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 [...]
Uhm, I think the above is all correct, and important - but I am missing the bit where th OGF license gives you trouble. IANAL, so maybe I am misparsing things - sorry...
It is more restrictive than CC and our requirements (in terms of ensuring compliance with a static, normative specification) can be met with trademark law alone.
That's why all the news about cloud computing specifications being available under CC licenses is essentially non-news, while still being a big step forward in standards openness.
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".
Sorry, Sam, I think this is FUD - at least you should have left the 'barely' out ;-) As said above: the IPR works well for a waste set of standards very well, and I don't see complains like this for, fir example, DocBook...
Ok, so s/barely/precisely/.
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.
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.
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
See above: extenting is possible.
Annotation: please read again:
"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."
"derivative works that comment on or otherwise explain it"!
"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.
* Correcting errors
OGF has an errata process for that.
So long as OGF exists...
* Deriving a new specification from it (be it for a similar or different application altogether)
See above.
Ditto.
* Including (parts of) the specification in documentation
See above
Really? Including product documentation? I'm sufficiently unconvinced that I wouldn't do it myself...
* 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.
* 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).
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.
Yes, that makes sense I guess, but still does not explain the CC ;-)
No, but it does provide a simple, effective alternative to the copyright restrictions that are usually in place. Computing standards only get more open over time - cloud is a great opportunity to take the next step and one that I personally don't plan to miss. Perhaps it would be more insightful to turn this argument around and have you explain what benefit you think these additional restrictions provide? Sam
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.
participants (4)
-
Alexander Papaspyrou -
Alexis Richardson -
Andre Merzky -
Sam Johnston