[occi-wg] Unlocking the formats deadlock

Tue May 26 04:01:36 CDT 2009

Sam,

If the IETF are happy with it, then I am.

a

On Tue, May 26, 2009 at 9:52 AM, Sam Johnston <samj at samj.net> wrote:
> On Tue, May 26, 2009 at 9:37 AM, Alexis Richardson
> <alexis.richardson at gmail.com> wrote:
>>
>> On Tue, May 26, 2009 at 2:38 AM, Sam Johnston <samj at samj.net> wrote:
>> >>> By the way, CC licenses are useless to us without patent pledges.
>> >>
>> >> Please can you explain this statement.  Not all CC licenses are the
>> >> same.
>> >
>> > In so far as patents go they are... I can release a spec into the
>> > public domain and still charge you royalties when you implement it,
>>
>> Inasmuch as this is an issue, it is not unique to CC.  IETF is open to
>> the same commentary.
>>
>> For example TCP has no explicit patent grants afaik.  Indeed TCP is
>> IETF licensed, and the IETF license makes no explicit patent grants.
>
> I assure you that it is not possible/interesting/sensible for us to
> incorporate non-obvious content and/or concepts from existing standards
> without explicit patent waivers/grants/pledges. In fact even a patent pledge
> may not go far enough if it is tied to a particular standard (as is often
> the case - including for GData as it turns out). Even things like function
> names can end up in patents so we owe it to our users to tread very
> carefully here.
>
>>
>> > and if you use my trademarked name to describe your implementation
>> > then you're in trouble again.
>>
>> I don't think this is an issue qua licenses such as CC-BY-SA which
>> require attribution.  If a license *requires* attribution (or similar)
>> then attribution won't suffice to constitute trademark infringement.
>> Note that this is a different case from that where attribution is not
>> required.
>
> Attribution is something else again - I'm talking about things like
> Eucalyptus claiming to support the Amazon EC2 API despite the existence of
> at least one registered trademark for same. There is some room to move here
> (for example, Audi referring to BMW... only to result in a hilarious epic
> fail) and we have our own name (OCCI) but if I were a competitor to Sun or
> Amazon I'd be very careful about including their names in my product
> marketing material.
>
> Sam
>
>>
>> >>>> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On
>> >>>> Behalf
>> >>>> Of
>> >>>> Sam Johnston
>> >>>> Sent: 25 May 2009 17:07
>> >>>> To: occi-wg at ogf.org
>> >>>> Subject: [occi-wg] Unlocking the formats deadlock
>> >>>>
>> >>>> Afternoon all,
>> >>>>
>> >>>> As you know I spent last week evangelising OCCI at the Cloud
>> >>>> Computing
>> >>>> Expo
>> >>>> in Prague (Monday/Tuesday) and Cloud Computing Expo in London
>> >>>> (Wednesday/Thursday), presenting the Introduction to the Open Cloud
>> >>>> Computing
>> >>>> Interface<http://docs.google.com/Present?docid=ddqm27m2_298fsf9mqdg>
>> >>>> presentation at both. I was only scheduled for Prague but the
>> >>>> organisers
>> >>>> found a spot on the technical track in London too. I also ended up on
>> >>>> the
>> >>>> panels at both which was even more opportunities to talk about cloud
>> >>>> interop. I'll be in Portugal for Cloud Views from Wednesday and will
>> >>>> try
>> >>>> to
>> >>>> get involved in OGF 26 time permitting as well. By now people
>> >>>> certainly
>> >>>> know
>> >>>> we exist and that we're doing real (hopefully good) work.
>> >>>>
>> >>>> Unfortunately we're somewhat stuck on the formats decision despite
>> >>>> hours
>> >>>> of
>> >>>> face to face discussion with 1/2 a dozen of the more active working
>> >>>> group
>> >>>> members (myself, Alexis, Chris & Richard from ElasticHosts and the
>> >>>> Fujitsu
>> >>>> guys). While this is not at all unusual for technical discussions we
>> >>>> do
>> >>>> need
>> >>>> to fairly urgently find a solution before people (myself included)
>> >>>> lose
>> >>>> interest and wander off. I can't overstate how important this working
>> >>>> group
>> >>>> is to the future of cloud computing and both of the alternatives are
>> >>>> rather
>> >>>> unpalatable:
>> >>>>
>> >>>>  *   On one side we have Amazon EC2 APIs which are not only
>> >>>> encumbered
>> >>>> but
>> >>>> inelegant and inflexible (at least in the context of the enterprise
>> >>>> use
>> >>>> cases I spend most of my time thinking about - no offense intended).
>> >>>> Other
>> >>>> APIs designed to expose the functionality of a single implementation
>> >>>> fall
>> >>>> into the same category and while they meet their specific needs well,
>> >>>> we
>> >>>> need to expose the current and future functionality of all current
>> >>>> and
>> >>>> future implementations, not just one today. At the extreme end of the
>> >>>> simplicity scale you have text-based APIs which we all now agree
>> >>>> won't
>> >>>> meet
>> >>>> our needs.
>> >>>>  *   At the other end of the scale we have VMware's vCloud API which
>> >>>> has
>> >>>> been injected into the DMTF process, following in the footsteps of
>> >>>> OVF. I
>> >>>> fully expect the resulting "open API" to be almost word-for-word
>> >>>> identical
>> >>>> to the new VMware APIs which is something the
>> >>>> DIGISTAN<http://www.digistan.org/> guys call "vendor
>> >>>> capture<http://www.digistan.org/open-standard:definition>". Unlike
>> >>>> the
>> >>>> public cloud APIs, this will be well-suited for enterprise and you
>> >>>> can be
>> >>>> sure that service providers will deploy VMware en masse to provide it
>> >>>> as
>> >>>> part of their [semi-]private "I can't believe it's not cloud"
>> >>>> offerings.
>> >>>> Good on them for being first and forcing the rest of the industry to
>> >>>> follow
>> >>>> their lead.
>> >>>> This working group's job is to find the middle ground - something
>> >>>> which
>> >>>> is
>> >>>> simple enough to be useful for public cloud offerings but extensible
>> >>>> enough
>> >>>> to be useful for more challenging tasks (e.g. enterprise). This is
>> >>>> also
>> >>>> critical for hybrid clouds (unless you're all happy to implement
>> >>>> DMTF's
>> >>>> APIs
>> >>>> in addition to your own). The business case is easily justified even
>> >>>> if
>> >>>> only
>> >>>> on the basis of getting access to customers who are currently kicking
>> >>>> the
>> >>>> tyres with tactical deployments but unable to deploy strategically.
>> >>>>
>> >>>> As you know I have been pushing Atom[Pub] hard, perhaps too hard, and
>> >>>> the
>> >>>> XML-xenophobes have dug their heels in as a result. It was made
>> >>>> painfully
>> >>>> obvious in London that blanket application of AtomPub to the problem
>> >>>> isn't
>> >>>> going to fly with at least one of them and to that end I've spent the
>> >>>> weekend working on paring it back where it's not absolutely
>> >>>> necessary.
>> >>>> I've
>> >>>> also purchased and read O'Reilly's RESTful Web
>> >>>> Services<http://oreilly.com/catalog/9780596529260/> book by Leonard
>> >>>> Richardson<http://www.crummy.com/> and Sam Ruby from cover to cover
>> >>>> and
>> >>>> am
>> >>>> largely sold on their concept of a Resource Oriented Architecture
>> >>>>
>> >>>> (ROA)<http://www.infoq.com/resource/articles/richardson-ruby-restful-ws/en/resources/04.pdf>
>> >>>> - do read this sample chapter if you have time.
>> >>>>
>> >>>> Fortunately I think I've found a simple, elegant solution which
>> >>>> obviates
>> >>>> the
>> >>>> need for Atom (at least where collections are not required). I've
>> >>>> captured
>> >>>> it in a series of 3 blog posts which I'll forward to the list for the
>> >>>> sake
>> >>>> of convenience and the archives.
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Sam
>> >>>> -------------------------------------------------------------
>> >>>> Intel Ireland Limited (Branch)
>> >>>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>> >>>> Registered Number: E902934
>> >>>>
>> >>>> This e-mail and any attachments may contain confidential material for
>> >>>> the sole use of the intended recipient(s). Any review or distribution
>> >>>> by others is strictly prohibited. If you are not the intended
>> >>>> recipient, please contact the sender and delete all copies.
>> >>>>
>> >>> _______________________________________________
>> >>> occi-wg mailing list
>> >>> occi-wg at ogf.org
>> >>> http://www.ogf.org/mailman/listinfo/occi-wg
>> >>>
>> >>
>> >
>
>