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
- Thank You For Your API Evangelist Blog(s)
- Video From The Hypermedia Panel At API-Craft In Detroit Last Month
- Please Open Source Your API Before Shutting It Down
- Explaining My Work Around APIs In Higher Education To Institutions
- You Can Have An API Just By Choosing Products And Services That Have APIs
- Using Excel As An API Datasource And An API Client For The Masses
- Brewing Up Something Awesome With The Jive Software API
- Relationship Between APIs And Containers
- Real-time and Visualizations Will Be Key in Financial API Deployments
- Notification Focused Startups Within Leading API Ecosystems
- APIs That Do One Thing And Do It Well Like ZipLocate
- Which API Do I Need?
- The Expanding API Conference Landscape
- Ocotoparts Open Source Google Spreadsheet
- Andrew Nacin Of WordPress @APIStrat Chicago
- Push Button API Deployment With The Heroku Button
- WordPress Style API Modules For Government
- The Heroku HTTP API Design Guide
- What I Have Been Calling API Trends, Are Slowly Being Baked Into API Operations
- FDA Finding Their API Mojo With A New Drug Label API
- Adding PokitDok To Healthcare Research And The API Stack (Well They Did)
- Why I Am Continuing To Integrate Zapier In My Business Workflow
- Who Is Going To Build The Uber API Platform For The Sharing Economy?
- The API Focused Dev Shop
- Route SMS Messages To Google Spreadsheets Via Twilio API With TwilioSheet