This article raises a hot issue in IT circles: “Are API’s copyrightable?” This question is currently being played our in the current Google vs. Oracle slug-fest over Java. But this issue is far bigger than Google and Oracle’s current tussle, and it is unlikely to be definitively resolved by this one case.
The issue really goes to the essence of what is subject to copyright protections, what API’s truly are, and how does the way APIs are used impact the issue of copyright protection.
Ultimately, APIs are, at their core, software (or are at lease they constructed from software). As has been repeatedly recognized both in the US and internationally, software can be (and usually is) considered a work of creative authorship and, as such, it is subject to copyright protections.
APIs, however, are not typical software, in the same way that a word process program for a PC or a photography app for a smartphone are. In certain senses, APIs are more like an programing language of its own. It is in this context that the Google/Oracle struggle is being played out.
So far, European Union courts appear to moving towards a clear position that programming languages cannot be copyrighted. http://www.infoworld.com/d/application-development/programming-languages-not-copyrightable-rules-top-eu-court-192231 In taking this stance, the European Court of Justice clearly stakes out the position (correctly, I believe) that copyrights cannot protect functionality or concepts. The ECJ’s rationale behind this is that extending copyright protections to such lengths would amount to making it possible to monopolize ideas, to the detriment of technological progress and industrial development. The resulting finding of the ECJ is: ideas and principles which underlie any element of a computer program are not protected by copyright under the European copyright directive, only the expression of those ideas and principles.
The shortfall of the ECJ’s analysis, however, is that the very terms that make up that expression are themselves software. In many case individual operative terms and expressions in object-based languages are themselves their own pieces of software, containing unique expressions of underlying ideas and principals.
Clearly this kind of argument runs the risk of devolving into a never-ending exercise akin to reductio ad absurdum. Despite the reductionist nature of this argument, it still contains both a kernel of truth and the basis for a debate about where creative expression begins and and where concepts and functionality begin.
Clearly a significant tension exists here. The creators of APIs have an understand interest in both protecting the value of their creation and how it used. On the other hand, APIs are put out as a lingua franca to permit pieces of software to communicate and interact with one another. Placing arbitrary restrictions such means of common communication undermines the whole purpose of APIs and the levels of interconnectedness which they permit.
Regardless of the outcome of the Google/Oracle suits and the other lawsuits bound to follow, it is clear that this is a potentially pivotal issue in software world and one that bears close watching by companies whose products and/or services are either dependent upon or at least significantly impacted by the use of APIs. The final results could be a real game changer.