Posted on 11-02-2012
The Electronic Frontier Foundation (EFF) needs our help to explain to the Federal Circuit Court on why there should NOT be copyrights on APIs. As EFF published today:
Earlier this year, we applauded District Court Judge Alsup for getting it right and holding that, as a matter of law, one could not copyright APIs. The case, Oracle v. Google, is now on appeal to the Federal Circuit, where a three-judge panel is going to revisit Judge Alsup’s ruling.
The EFF is soliciting the our assistance in how to help build the case, asking for feedback on two example areas:
- Software reimplementing someone else’s API, calling someone else’s API, or any other uses of third-party APIs for interoperability, competition, or innovation.
- Reimplementation of an API, where the resulting software benefitted the original API creator, perhaps by increasing the creator’s user base or otherwise benefitted the developer community
I think we are in the infancy of API deployment, so it’s going to be tough to find many solid examples. But I think the two areas we can demonstrate the importance of no copyright on APIs, is within two business sectors that evolved on the web, using APIs and are critical to business and government today:
- Cloud - As EFF said, Eucalyptus reimplemented the Amazon API to offer a competing cloud storage service. You also saw the same with first implementation of Google Developer Storage and up to & other providers: Dunkel Cloud Storage, Host Europe Cloud Storage, GreenQloud Storage Qloud, ScaleUp Technologies, Connectria Cloud Storage, Lunacloud, and DreamObjects Cloud Storage providing unprecedented interoperability for cloud computing.
- Social - Same as with cloud you have seen competition pop up for both Twitter and Facebook, mimicking their platform and APIs. Platforms like App.net have copied Twitter’s social network providing competition, and potential value to Twitter users by allowing developers to use App.net for things they can't use Twitter for.
I think another clear example of open API design being used to help users is Pinboard’s implementation of the Delicious API:
|Pinboard - Wherever possible the Pinboard API uses the same syntax and method names as the Delicious V1 API. This implementation allowed users to seamlessly export Delicious bookmarks accumulated over several years to Pinboard when Delicious was sold by Yahoo. If Yahoo had copyrighted their API design, Pinboard could never have done this.|
A slightly different approach to offering benefit to users via an open API design is surrounding the Instagram API:
|Instagram API - In 2010, before Instagram itself launched an API, a passionate developer launched a rogue API for the popular photo sharing platform based upon Instagram's own internal API design they used to drive the popular iPhone application. The move showed Instagram the demand for an API, and after designing and launching their own asked the rogue API to shut down. A slightly different scenario, but if API design was copyright this may not have been possible. We’ve seen the same approach with a rogue Pinterest API, but it hasn’t resulted in the same response from Pinterest unfortunately. But community driven API design has a lot of potential for opening up companies and encouraging API innovation.|
I strongly believe that APIs have massive potential for innovation across many business sectors. The copyright of API design would eliminate much of this potential. Open API design allows for healthy competition, interoperability and innovation as we’ve seen with cloud and social. But open API design can also augment the lack of standards through market leadership, helping grow healthy industries and essential online utilities. Amazon EC2 and S3 design standards are clear examples of this in the wild.
Cloud and social are fast become essential components in our everyday lives, but open API have the potential to become mission critical with implementations like Open311. Some API designs are just too important to be proprietary. I would argue Twitter, Amazon S3 and Amazon EC2 also fall into this category and need to remain open for the greater good.
Without the ability to copy, mimic, mashup, translate, emulate and re-define API design we won’t be able to become more fluent in communicating via web and mobile apps using APIs. We are just beginning to understand online communication via the power of mobile apps. As we still grunt and groan while communicating via APIs--let’s not stunt our growth and development with allowing API design to be copyrighted.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Will You Add Me To API Evangelist And How To Spot The Cool Kids
- When I Remix APIs Using Swagger How Do I Deal With Authentication Across Multiple APIs
- It Takes A Team Of Evangelists To Raise An API
- Support For Only Two Creative Commons Licenses In The API Commons
- Machine Readable Terms of Service Didn't Read Applied To APIs Via APIs.json
- API Deployment For Non-Developers Using Zapier, Google Docs, and APISpark
- State of Hypermedia Today @ API Craft In Detroit
- Need A Formal API Standard For Your Government Agency? Fork 18Fs, And Make It Your Own!
- CORS Makes Your API Portable And Remix-able
- Chief Data Officer Needs To Make The Department Of Commerce Developer Portal The Center Of API Economy
- An API Definition As The Truth In The API Contract
- Look At Existing APIs In The Space Before Designing Your Own
- Libraries Hacked: UK Library API, Data And Technology Hacks
- Financial Data Aggregator Yodlee Looking For A Director of Developer Evangelism
- AutoDevBot Open Sources Their API Monitor
- Low Hanging Fruit For API Discovery In The Federal Government
- Looking At 77 Federal Government API Developer Portals And 190 APIs
- Applying APIs.json To API Discovery In The Federal Government
- The Power In API Discovery For APIs.json Will Be In The API URL Type
- Fixing The Machine Readability in API Commons
- Evolving How We Approach The API Lifecycle With APIMatic
- APIs Can Open Up Your Company To Outside Ideas
- APIs Are Often Just A Facade That Is Covering Up The Legacy View Of World
- A Mobile Developer Toolkit With The University Of Michigan APIs
- Kicking Off Image Manipulation API Work