[openstack-dev] [openstack-tc] Motion to validate Heat's application as incubated project

Monty Taylor mordred at inaugust.com
Fri Oct 26 16:31:31 UTC 2012


IANAL

On 10/26/2012 08:16 AM, Thierry Carrez wrote:
> Christopher B Ferris wrote:
>> Thanks for your thoughts. As for the EC2 v OpenStack APis, the EC2 API can be stripped out, leaving all functionality of nova
>> unimpaired. If the same could be true of the AWS Cloud Formation structures, it would make the project easier to consume 
>> for those with persnickety legal departments.
> 
> Indeed, Heat would basically be the first OpenStack project to adopt a
> third-party API as its main API (rather than introducing an
> OpenStack-specific API that lets us in control of the features we can
> expose).
> 
> The arguments of why we need an OpenStack Compute API rather than just
> adopting the AWS EC2 API can probably be made just the same for Heat...
> 
> I expect this to become a critical point in the discussion.

I do too. I do think however that our initial concerns over license/use
of the API (I was one of the vocal advocates of not touching Amazon APIs
for fear of a crazy Bezos running amok - you can go find my blog
argument with Shuttleworth on the subject) have been mitigated by recent
court cases that found APIs are not copyrightable (thanks for stupidly
suing Google, Oracle!)

The concern about being able to deviate from the API is a good one, but
honestly deviating from an API which already has tooling is the same
question whether it's deciding that the Amazon API is deficient and we
need to make changes or whether we're just revving our API ... both
would result in client-side tool issues, and both would have to have the
benefit of the API changes weighed against the cost of client disruption.

In this case, since the desire to do something different from what's
there is only theoretical, and this code is there, I would say that,
sans legal concerns over Bezos and court cases, ANY api that comes in on
version 1 of heat is going to be completely arbitrary and at some point
in the future we might want to change it... so this one is no worse than
any other.

Please, everyone mark this down as the first time I have not argued
_against_ using an Amazon API.

Monty



More information about the OpenStack-dev mailing list