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

Mon Mar 29 05:27:38 CDT 2010

I know that some people can't make that timeslot...who I would like to
have on the concall...

-Thijs

-----Original Message-----
From: Edmonds, AndrewX <andrewx.edmonds at intel.com>
To: Thijs Metsch <Thijs.Metsch at Sun.COM>, occi-wg <occi-wg at ogf.org>
Subject: RE: [occi-wg] OCCI Editor Getting Started Guide
(docs/README.txt)
Date: Mon, 29 Mar 2010 11:21:02 +0100

Perhaps we can discuss this on Weds confcall?

-----Original Message-----
From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Thijs Metsch
Sent: Sunday, March 28, 2010 5:40 PM
To: occi-wg
Subject: Re: [occi-wg] OCCI Editor Getting Started Guide (docs/README.txt)

How do you wanna finish a spec without this issue fixed? I wanna finish
it now...We can leave the conall. But I have the feeling that not
everything is settled/cleared out yet. So we need to discuss it and if
we do that by mail it's gonna take ages...

-Thijs

-----Original Message-----
From: Sam Johnston <samj at samj.net>
To: Thijs Metsch <Thijs.Metsch at Sun.COM>
Cc: Steven Newhouse <s.newhouse at omii.ac.uk>, occi-wg <occi-wg at ogf.org>,
Richard Hughes-Jones <Richard.Hughes-Jones at dante.org.uk>
Subject: Re: [occi-wg] OCCI Editor Getting Started Guide
(docs/README.txt)
Date: Sun, 28 Mar 2010 17:38:31 +0200

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

-- 
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