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.
|API Copyright, API Evangelist, Eff, Legal|
blog comments powered by Disqus
Latest Blog Posts
- My First Keynote With The Infamous Audrey Watters
- Are You Going To Be At API Days in San Francisco? I Am!
- Updated API History White Paper
- History of APIs - Twilio
- API Providers Guide - API Design
- Box Opens Up Revenue Sharing For API Developers
- History of APIs - Mashery
- A Book API Platform
- History of APIs - del.icio.us
- API Management Using Github
- In The End API Providers Will Only Sell Bandwidth
- The Build-Up To #APIStrat in October
- APIdays Mediterranea Is A Wrap
- Helping EFF Urge The Courts to Block Copyright Claims in Oracle v. Google API Fight
- API Aggregation For Federal Government with FedAPI
- Have You Checked Out Webshell Lately?
- New Features From BaaS Provider AnyPresence
- Signals I Use To Monitor Companies In The API Space
- API Management Using APiphany
- Github Can Be More Than Code
- Quick Demonstration Showing The Benefits of The White House Digital Strategy
- IRS Needs To Use White House Open Data Policy For Guidance
- Dropbox As Your Apps Default File System
- DataSift's Open Source World
- Salesforce Adds Sandbox Templates