[occi-wg] Unlocking the formats deadlock

Tue May 26 03:52:58 CDT 2009

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<http://en.wikipedia.org/wiki/Inventive_step_and_non-obviousness>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 <http://code.google.com/apis/gdata/patent-license.html> 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<http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=77054011>for
same. There is some room to move here (for example, Audi referring to
BMW... only to result in a hilarious epic
fail<http://www.37signals.com/svn/posts/1675-santa-monica-bmws-checkmate>)
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
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090526/8e268a08/attachment.html 