On Tue, May 26, 2009 at 5:59 AM, Gary Mazz
<garymazzaferro@gmail.com> wrote:
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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of
Sam Johnston
Sent: 25 May 2009 17:07
To: occi-wg@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@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg