No Copyrights on APIs: Help Us Make The Case

I don't buy the SAMBA example in the original article. As I understand it they reverse engineered the API/protocol from the on the wire network traffic. This would to me make it not a case of literal copying and therefore not infringing a copyright in the API (if it exists).<p>The equivalent for a general API would be avoiding the documentation and the actual API files (headers etc.) and developing an alternative implementation from examples of client code and the behaviour observed of the library when tested with inputs.<p>This may be the answer, allow APIs to be copyrighted (in general - some may be too trivial to be copyrightable where there are limited sensible approaches) but allow the reverse engineering of behaviour.<p>Of course it would be possible to grant licenses to the the API and it may be sensible to consider the flexibility of the API license when choosing to use a library, webservice or framework and the difficulty of transferring away from it to an alternative supplier.

I thought APIs had been established as non-copyrightable by numerous precedents, e.g. Lotus v. Borland, Apple v. Microsoft. Why do we need to go through this again?<p>The US Copyright Law Chapter 12 provides for reverse engineering, for the purpose of interoperability. So that would seem to negate any defense of copyright of an API, whose sole purpose is interoperability.

Honestly if something is silly as several musical notes can be copyrighted, I don't see how you could argue something as complicated and full of creative work as an API can't be. Instead, I think we need something more like the reverse-engineering or parody laws. Allow them to be reimplemented as long as it is clearly called out that they are not the original creative work of the reimplementing party. It would lead to effectively the same thing and would give the original creator credit.

Any creative content or writing can be copyrightable. But in the case of <i>Oracle vs Google</i>, the end of the case was that an API is just no more than a list of rules and URLs, nothing "creative".<p>And a list is not copyrightable.<p>Think to the Yellow Pages for examples. No Copyright on name, address and numbers (hopefully) , because no specific form or shape to these writings.<p>The case is to define if design an API is more than listing URLs. I don't think so, and the Judge Alsup of <i>Oracle vs Google</i> who was developer too, said the same thing.<p>But API providers will try to not accept this. Do you remeber Twitter's message to developers<p><a href="http://apijoy.tumblr.com/post/34350096121/twitter-api-teams-message-to-developers" rel="nofollow">http://apijoy.tumblr.com/post/34350096121/twitter-api-teams-...</a><p>?<p>IFTTT, Zapier, Webshell.io, Webscript.io, Elasctic.io, Apiary.io, Opalang.org, Rules.io etc...we have something to bring to api@eff.org

<i>2. 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><p>Would this cover a language-specific wrapper around an HTTP API? For example, I wrote a Python library for the iHackerNews API[0]. Would something like that count as a reimplementation for the purposes of their request?<p>[0] <a href="https://github.com/dmpayton/python-ihackernews" rel="nofollow">https://github.com/dmpayton/python-ihackernews</a>

Some thoughts on why a legal precedent probably isn't enough: <a href="http://www.3scale.net/2012/11/the-case-against-api-copyright-and-the-need-for-an-interface-commons/" rel="nofollow">http://www.3scale.net/2012/11/the-case-against-api-copyright...</a>

this would be a stepping stone to copyrighting design patterns ... <i>shrug</i>