[occi-wg] Unlocking the formats deadlock

[Gary Mazz]

What is the definition "reasonable" in terms of licensing ? What are the 
hard costs ?

Patent licensing can be a significant obstacle to adoption.

Do you want students and universities sued for using OCCI technology ?  
Do you want to pay someone else for the work you did here ?  Does your 
companies want to pay a competitor for your contributions here ?

Look below to see what others considered "reasonable".

The OMA DRM (a standards like body) charged  $.35 per device with a 
$566,000 cap. Intertrust another DRM scheme is $3.5m annually and 
$325,000 per carrier. M$ graces us with only $2.9million and $625,000 
per year for carriers.

Look at MP3 licensing rates from Thompson:

BTW, this means EVERYONE providing an open source mp3 player can be 
prosecuted and sued for up to $15,000 and $5.00 per copy download plus 
damages.

In other places on their website, Thompson demands 3% of "associated" 
gross revenue from distributing content with an mp3 format.

Here is the web site for all of you that want to pay a fee for each mp3 
player you have: http://www.mp3licensing.com/royalty/

This is pricing from Thompson's public web site:
 


-gary

Andre Merzky wrote:
> Quoting [Sam Johnston] (May 25 2009):
>   
>>> 5. Sun Cloud API (CC licensed) ??? AE: Evaluate?
>>> 6. Amazon Web Services as ???de-facto??? (i.e. as Euc. and Nimbus have
>>> proceeded). ??? AE:public but closed API
>>>
>>> If we want to take the middle ground yet not sit on the fence it would be a
>>> useful exercise to see what 4 and 5 offer and do not offer? See where our
>>> efforts here could improve these published APIs and models?
>>>       
>> I've done that myself already but you're welcome to go through the
>> exercise yourself. By my clock you've got less than an hour until you
>> miss our first deadline.
>>
>> By the way, CC licenses are useless to us  without patent pledges.
>>     
>
> Please note that OGF sees it as its task to gain such
> pledges, if the group determines that this is required for
> the standard to be implementable under "Reasonable and
> Non-Discriminatory" license terms.
>
> For details, see http://www.ogf.org/About/abt_policies.php,
> and http://www.ogf.org/About/abt_policies_ipr.php for
> pledges covering OGSI and OGSA.
>
>   "Where the Open Grid Forum knows of rights, or claimed
>   rights, the Open Grid Forum Secretariat shall attempt to
>   obtain from the claimant of such rights, a written
>   assurance that upon approval by the Open Grid Forum of the
>   relevant Open Grid Forum document(s), any party will be
>   able to obtain the right to implement, use and distribute
>   the technology or works when implementing, using or
>   distributing technology based upon the specific
>   specification(s) under openly specified, reasonable,
>   non-discriminatory terms."
>
> Hth, Andre.
>
>
>   
>> Sam on iPhone
>>
>>     
>>> 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
>>     
>
>
>
>