What is an API?
In simple terms, an API (Application Programming Interface) is a software intermediary that allows applications to talk to each other. For example, when you see a snippet with the weather forecast on the home screen of your mobile phone, this happens through an API which facilitates sourcing the weather data from a third party before it is displayed on your screen. In the same way, when you are booking a flight with an online travel service APIs again come into play as they facilitate the communication between the travel application you use and the database with flight information managed on the relevant airline website – this is how the online travel service can show you in real time the availability and prices even though this is third party data.
So in a way, the API specifies how one software system should be accessed from the outer world, what inputs it will need and what outputs it will return.
Is an API subject to copyright protection?
The question whether an API is copyrightable is a complex one and at this point is subject to ongoing litigation between Oracle and Google that has reached the US Supreme Court. Interestingly, prior to reaching the Supreme Court the case had been decided differently by different courts first in favor of Google and later Oracle. At first instance, the US District Court for the Northern District of California ruled in favor of Google and subsequently in 2018 the US Court of Appeals for the Federal Circuit ruled in favor of Oracle.
Back in the autumn of 2007 Google was in a rush to release Android as Apple had just released the first iPhone and the competition for the emerging smartphone market was fiery. To facilitate the adoption of Android by developers Google decided to copy parts of Java SE into Android, thus making it easier for those developers to create Android apps. Java was developed by Sun Microsystems in the early 1990s but eventually Sun was bought by Oracle in 2010. Shortly afterwards, Oracle initiated a lawsuit against Google alleging that Google had infringed the copyright in the Java API packages.
It is a well-known principle that copyright protects only the expression of an idea but not the idea itself. To do the contrary would result in building monopolies on ideas. Hence, copyright protection does not extend to ideas, functionalities, processes, methods of operation. From a technical perspective, it could be argued that an API in a way resembles a method of operation. On the other hand, the API is expressed in code through the use of a programming language and in this sense it is clearly an expression which if original, should be protected. Therefore, the function of an API is not copyrightable but its expression in code may very well be.
The key requirement for a work to be protected under copyright is originality – i.e. the author has made free and creative choices and the work is his own intellectual creation. Therefore, if an API is original – a situation where there are many different ways to structure and express the functionality of the API in source code and the author has creatively chosen and expressed just one of those – then the API should be protected under copyright. However, if technical constraints dictate that an API can only be expressed in a very limited number of ways and there is no room for any creative choices, then based on the “merger doctrine” (idea and expression merge) the expression of the API in code will not be original and no copyright will subsist. Consequently, in the second scenario anyone should be able to freely use and copy such an API.
Therefore, a case-by-case analysis is inevitably required in order to determine whether creative choices were employed in designing an API and hence it can be protected under copyright. Despite being utilitarian in their nature, APIs could very well involve various architectural design and implementation decisions that could easily give rise to originality in the work. In this sense, in the Oracle v Google case the US Court of Appeals for the Federal Circuit postulated that designing the Java API packages was a creative process and as none of the creative choices were dictated by function, they qualify as original works that are subject to copyright protection.
What about fair use?
A second important question that can be raised is then the issue of fair use. And this is exactly the second line of legal defense employed by Google – in case that APIs are found to be copyrightable they claim that their copying into Android resembled fair use.
There are 4 statutory factors relevant for assessing fair use established under §107 of the US Copyright Act – (i) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes; (ii) the nature of the copyrighted work; (iii) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and (iv) the effect of the use upon the potential market for or value of the copyrighted work.
The first factor involves two components – i) whether the use is commercial in nature, or alternatively pursues educational or public interest purposes and ii) whether the new work is transformative or simply replaces the original creation. It is interesting to note here that a potential finding that the new work is highly transformative may decrease the importance of the commercial use factor. In order for the secondary work to be transformative it must either alter the original with a new expression or meaning or serve a new purpose distinct from the original work. The finding of the US Court of Appeals on this factor was that Google’s use of the APIs was highly commercial in nature and not transformative which weighs against a finding of fair use.
The second factor is premised on the question whether the nature of the work is highly creative or not. Works that are highly creative are deemed closer to the core of intended copyright protection than others and it is more difficult to establish fair use when such works are copied. Alternatively, if mere functional considerations dictate the expression of the work then it would be less creative and it would be easier to establish fair use. Here it is interesting to note that the US Court of Appeals found that while creative enough to be protected under copyright the expression of the APIs was significantly driven by functional considerations and thus the second factor was found to weigh for a finding of fair use.
The third statutory factor revolves around the amount and substantiality of the portion used in relation to the copyrighted work. The inquiry under the third factor takes into account both the quantitative amount and importantly the qualitative value of the portion of the original work used. Here the US Court of Appeals found that only 170 lines of code were necessary for Google to make it feasible for Android developers to write in Java language. Instead Google copied 11 500 lines of code of all roughly 2.86 million lines of code in the Java SE libraries and copied the structure, sequence and organization for the 37 API packages in its entirety. The third factor was found by the court to be at best neutral and arguably to weigh against a finding of fair use.
The fourth factor focuses on the principle that fair use is limited to copying done by others which does not materially hinder the marketability of the copied work. In assessing the fourth factor, courts have to consider not only the harm to the actual or potential market for the copyrighted work, but also any harm to the market for potential derivative uses. Here the US Court of Appeals found that even if there was no harm to the current market, the evidence before the court showed that Oracle intended to license Java SE in smartphones and therefore Google’s actions had a substantial impact on the potential market of the copyrighted product and its derivatives. Therefore, the fourth statutory factor weighed heavily against a finding of fair use.
Doing a balancing exercise on the four factors the US Court of Appeals summarized that factors 1 and 4 weigh heavily against a finding of fair use, factor 2 weighs in favor of fair use and factor 3 was, at best, neutral. Weighing the factors together the conclusion was that Google’s use of the declaring code and structure, sequence and organization of the 37 API packages was not fair use.
An important takeaway from the decision of the US Court of Appeals for the Federal Circuit is that despite potentially being creative enough to warrant copyright protection, APIs still have a utilitarian nature and are driven by certain functional considerations. Therefore, it is likely that factor 2 from the fair use statutory requirements would usually more often weigh in favor of a fair use finding when APIs are copied. This is important as APIs play a key role in solving the interoperability challenges in data exchanges. Of course, satisfying only the requirement under factor 2 is certainly not enough for a fair use finding as can be seen by the decision of the US Court of Appeals.