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

[Alexis Richardson]

A simple solution to 'the copyright issue' is to grant a shared
copyright to the OGF while keeping your own copyright as well.



On Sun, Mar 28, 2010 at 8:38 AM, Sam Johnston <samj at samj.net> wrote:
> Thijs,
> Haven't we got a spec to finish? I wasn't even able to sit through the last
> weekly call because it veered so far off course (granted I had a filthy
> headache at the time courtesy a nasty flu), but I see little value in
> wasting what little volunteer time we have when it seems pretty clear we're
> at an impasse on the copyright issue.
> Sam
>
> On Sun, Mar 28, 2010 at 11:29 AM, Thijs Metsch <Thijs.Metsch at sun.com> wrote:
>>
>> Dear group,
>>
>> To finally close this issue I wanna setup a concall to discuss this
>> matter. Please fill in the doodle so we can find the best time for this
>> discussion...
>>
>> http://doodle.com/irv86rayupyzfwe4
>>
>> Cheers,
>>
>> -Thijs
>>
>> -----Original Message-----
>> From: Andre Merzky <andre at merzky.net>
>> Reply-to: Andre Merzky <andre at merzky.net>
>> To: Pieter Hintjens <ph at imatix.com>
>> Cc: Richard Hughes-Jones <Richard.Hughes-Jones at dante.org.uk>, Steven
>> Newhouse <s.newhouse at omii.ac.uk>, occi-wg at ogf.org
>> Subject: Re: [occi-wg] OCCI Editor Getting Started Guide
>> (docs/README.txt)
>> Date: Fri, 26 Mar 2010 23:28:37 +0100
>>
>> Hi Pieter,
>>
>> its great to see some additional response, besides Sam :-)
>>
>>
>> Quoting [Pieter Hintjens] (Mar 25 2010):
>> >
>> > On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston <samj at samj.net>
>> > wrote:
>> >
>> > > Mine too - if you can't reuse/remix the work then it's not free
>> > > enough.
>> >
>> > The ability to remix a standard seems an essential freedom: if a
>> > standard becomes too complex or encumbered by patents then this is
>> > the only way to save parts of it.
>>
>> *sigh* my mail thread to that topic is counting well over 50 mails
>> by now, and I still did not understand why people think that to be
>> the case.  Would you or Sam please so kind and provide either an
>> explicit example for a spec which has successfully been forked, or
>> an explicit use case where that would be neccessary, and where the
>> same cannot be achieved by referencing or profiling the old (complex
>> or encumbered) standard?
>>
>> What I (naively) think is that I can always create a specification
>> like
>>
>>  "This specification defines an API API-B, which consists of the
>>  API defined in [orig], names API-A, with the call A removed, and
>>  the calls B added.  The call C changes its semantics to perform a
>>  nil operation.  Call D takes an additional parameter 'int size'
>>  which defaults to 1."
>>
>> Voila, new API specified.  Same for interfaces, protocols, etc etc.
>> Why do you need to fork a spec?  I don't get it, sorry...
>>
>> Yes, the new API is called differently.  This is a *good* thing - I
>> don't want to see two specs for API-A which define different syntax
>> and semantics!  Are there use cases where one wants to break
>> interoperability on purpose? *scratch*  I can't think of any.  At
>> least the version number of the spec needs to change, IMHO.
>>
>>
>> > That's why for Digistan we defined[1] the ability to fork a
>> > standard under a share-alike license as a necessary aspect.  We
>> > chose the GPLv3 mainly because it includes some safeguards against
>> > software patents, which CC does not.
>>
>> I understand the concerns about patents.  But I think we agreed that
>> this is out of scope for this specific discussion.  I am not sure if
>> you are on the OCCI mailing list, so you may have not seen that part
>> of our exchange.
>>
>> We basically agreed I think, and this is also what you say I guess,
>> that neither the OGF IPR nor CC-SA can provide any protection
>> against 3rd party patent claims on technology required to implement
>> a specification.  The best one can do is to obtain explicit patent
>> waivers from those parties known to have claims on the relevant
>> technology.  GPLv3 helps to some extent of course, but cannot
>> provide protection against 3rd party patent claims either.
>>
>> Thanks, Andre.
>>
>> > -Pieter
>> >
>> >
>> > [1] http://www.digistan.org/text:rationale#toc6
>>
>>
>>
>>
>>
>> --
>> Thijs Metsch                        Tel: +49 (0)941 3075-122 (x60122)
>> http://blogs.sun.com/intheclouds
>> http://www.twitter.com/befreax
>> Software Engineer Cloud, Grid and Virtualization
>> Sun Microsystems GmbH
>> Dr.-Leo-Ritter-Str. 7               mailto:thijs.metsch at sun.com
>> D-93049 Regensburg                  http://www.sun.com
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>