Asymmetric contract of APIs

A tweet about APIs that referenced this blog post really raised some interesting thoughts around APIs for me.

The short of the blog post is that it describes how a lone-wolf entrepreneur apparently got screwed over by Google changing their terms-of-service midstream on their YouTube API. The timeline is suggestive of the idea that they might have changed it, in fact, directly because of the work this guy was doing.

This raises big questions on the eco-system around creating products that leverage the API to services that other products provide. This is a big question because use of APIs has proliferated recently, and is clearly a powerful force for innovation and growth.

The APIs provided by Twitter, Facebook, and Google and the services that make use of them are high-profile examples, but of course there are plenty of others.

If you were building a bricks-and-mortar business you'd be able to enter into a contract with a supplier of some service such that it was clear what both of your responsibilities were. Even in the legacy software business, if you buy software from a vendor you can do things like get source code in escrow to protect against them going out of business and that sort of thing.

But in a world where one party makes available some access to a service, provides rules (rightly) against what you can do with that service, and then is able to change that service - the ground could get shaky.

I think what we need is the ability to "lock-in" some terms of service when using an API. The problem currently is that the relationship is completely asymmetric. Company A makes available an API and then can change the legal rules on you at their whim. If you built a business plan around being able to use that API in the way that you used to be able to - you're screwed.

Something like a "Terms of Use" would be useful - as in: "here are the terms under which I am willing to use your API". As I mentioned above, this could be as simple declaring that the Terms of Service for the API user is locked in at some specific time (presumably when the dependent party starts working with it - but there would need to be a formal commitment point).

Things as they are now are too one-sided, and you basically have to cross your fingers that the platform won't change out from under you. To keep driving innovation, I think that needs to change.