On Friday, the EFF issued a request for input on arguing making the case that API Interfaces should not be subject to copyright, following Judge Alsup’s landmark ruling against Oracle. The request is also covered on Techcrunch.
While the ruling itself applied to the Java programming language, the problem is widespread and applies to Web APIs also. We feel much the same way as the EFF, a future of copyright lawsuits on API Interfaces:
A profound negative impact on interoperability, and, therefore, innovation. APIs are ubiquitous and fundamental to all kinds of program development. It is safe to say that all software developers use APIs to make their software work with other software.
We certainly support that stance, and API copyright would be extremely damaging. However, we also believe it is unrealistic (maybe even undesirable) to expect rulings which de-facto declare all API copyrights unenforceable, so fighting the legal fight is not the only thing that is needed – the evolution of a kind of “interface commons” much like creative commons or open source licenses today would seem to be another important pilar to keeping Web APIs free and open.
The Case Against API Copyright
Copyrighting an API essentially “protects” the means to address a specific functionality, which is fundamentally different from protecting the functionality itself. The simpler the API interface, the more it looks like basic speech and the wider the impact of copyright would be. To illustrate the problem, take the example of copyrighting a REST pattern for accessing a hotel database and making reservation:
Claiming copyright may be a logical step for a company launching a Hotel API.
However, running a hotel reservation service per-se is not in and of itself unique or protectable – the free market allows many such services to arise.
Copyrighting the API Interface, if this were enforcable, would mean this particular structure of the interface is off limits to anybody else.
The next company may work around this, copyright also and so forth.
As more companies launch APIs, these workarounds become more and more complex.
The more companies launch APIs in the space, the more impossible it becomes to launch a new API and for existing API owners to revise their own. In other words, gridlock occurs in the field because small adjustments inevitably infringe something. This gridlock will very quickly even affect the original company that launched the API. Further, developers wishing to use these APIs have to deal with a proliferation of different interfaces for much the same function – a tremendous overhead for innovation.
While there are certainly arguments to say that a well designed API takes considerable effort and should be rewarded, the danger of wide enforcement of copyright is extremely high. This is especially where API building blocks are simple – it becomes akin to copyrighting words and short phrases.
Applying such copyright, is really analogous to copyrighting the structure of a web site (the items in the menu, number of pages etc.) – which is generally not copyrightable on the Web, rather than the long form text and images on the site (which rightly is). If copyrighting standard navigation patterns on the web were allowed the Web as we know it today simply could not exist.
(Note that we are not talking about passing off one API as another or Trademark infringement which are different serious issues – but purely about the ability to copyright the structure of the interface.)
API Interfaces are different to speech
One might argue, that APIs are a work of creativity – and in many cases designs are excellent and require a great deal hard work. Further, long form human readable text is copyrightable – so why not APIs by the same reasoning? In human speech however:
What is copyrighted is a very specific, in tact, sequence of long form prose.
For another human being to communicate the same ideas and concepts, there are many other ways they could choose which – even if they are not quite as good / effective – clearly convey the same message and are understandable to other humans in an instant.
In other words, in human speech, not being able to reproduce the exact same sequence does not remove the ability to quickly communicate the same message (even if a little less elegantly). This is because human listeners have the ability to understand the message quickly in multiple ways.
For APIs this is not the case – no software exists today that can dynamically understand and interoperate with APIs, thus new programming effort is required every time there are subtle changes in the way the API works. Delivering the same message multiplies in cost with every new variant of the API. Copyrighting the API thus becomes much closer to hindering freedom to communicate than copyright in human speech does.
From Techcrunch’s coverage:
While I think that APIs are creative efforts, they are merely components of the bigger picture. On their own, they don’t do much. If one were to make an analogy to cooking, the ingredients to a recipe would be APIs, and the dish would be the application.
This is a good analogy, the simpler the building blocks that can be copyrighted, the more restrictive the world is for innovators.
This is particularly true in APIs since very often the best designed APIs do what the best programming languages do – adopt common conventions and patterns. If this ability is blocked, learnability goes down and friction goes up. Precisely the thing which makes one API great, is the fact that it was able to rely on non-copyrighted shared conventions of other APIs that went before. Programmers have always been naturally collaborative and simply want to solve problems – killing this ability to share is a loss for everybody.
REST, SOAP, ebXML
One piece of good news is that architectural patterns such as REST and standards such as SOAP, ebXML and many others have long established patterns that effectively in the public domain. This means that for many obvious interfaces there is plenty of precedent to reject copyright claims and to dissuade people from enforcing frivolous lawsuits.
On the other hand just because precendent exists, it may not stop lawsuits – and tremendous cost in fighting them.
Beyond Copyright and the need for an Interface Commons
Copyrighting APIs would have great negative impact on the evolution of the Web. However, having said this, believing in a world in which blanket re-use of APIs is always permitted is likely to be rather naive.
It seems likely that some specific combinations will always end up being copyrightable and enforceable in certain courts – specifically those for which a company manages to argue (rightly or wrongly) that it is so specific and elaborate that the obviousness test fails. Wether these cases are right or wrong will not matter a great deal since legal action and the possibility of its success will have a potential chilling effect on certain innovations.
As a result, it seems imperative that there need to be mechanisms for API creators to explicitly label API interfaces as re-usable and as the number of APIs grows, ideally collaboratively design interfaces as shared standards. This is exactly the model that has been successful in Open Source Software and Creative Commons:
There is no assumption that an arbitrary piece of code is reusable.
People explicitly label and share re-usable code.
Since it is unlikely there will ever be a blanket law guaranteeing all APIs can be copied, explicit labeling is powerful process by which the commons can grow. It would seem that parallel licenses similar to open-source licenses would be needed to make this happen.
It is hard to imagine a future with 500 different types of “content read/write” Web API interfaces (or hotel APIs) – the overhead in implementation would be enormously costly. It seems obvious that “open” versions of such interfaces would gain traction – further the existence of such open interfaces would increase the sphere of building block interfaces which cannot be copyrighted by others.
The copyrighting of API interfaces creates a major chilling effect on innovation – and the simpler the building blocks of a copyrighted API, the closer it is to copyrighting individual elements (words / short phrases) of speech. As the number of Web APIs swells to the many 100′s of thousands and millions, this would add an unimaginable burden to implementation and innovation. So we are certainly hopefully that this practice is recognized as not permitted / admissible by law.
On the other hand it seems unlikely that a complete de-facto, blanket ban on all copyright claims on any type of API Interface is possible or even desirable (there may be cases of genuine claims). As a result it seems that something like an interface commons effort would be of extreme high value for the future in order to ensure a growing corpus of genuinely clear interface specifications.
The EFF in particular is seeking inputs from users and reimplimentors fo APIs – see their page here.