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

Sam Johnston samj at samj.net
Sun Mar 28 11:03:41 CDT 2010


On Sun, Mar 28, 2010 at 5:39 PM, Alexis Richardson <
alexis.richardson at gmail.com> wrote:

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


Works for me - let's move on.

Sam


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


More information about the occi-wg mailing list