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

[Sam Johnston]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100328/0d16f8dd/attachment.html