On 5th of April 2021 the US Supreme Court handed down its decision on the decade long legal battle between Oracle and Google regarding the copying of code from the Java API. This article will present a summary of the case as well as an analysis of its outcome and some additional thoughts on the copyrightability of APIs from an EU law perspective. But first of all, let’s see how it all began.
Back in 2005 Google acquired Android Inc. which was then a startup company. The aim of Google was to develop a platform for mobile applications as this was shaping to be a new promising market niche. The concept of a “platform” can be defined as the infrastructure that is used by computer programmers when they develop new applications. In its decision the US Supreme Court likens the concept to a factory floor where workers come, use the available tools and realize their creations.
At that time many programmers were using the popular Java programming language which was invented by Sun Microsystems. Many of them were also using the popular Java SE platform when developing new programs. After acquiring Android, Google began negotiations with Sun Microsystems about the licensing of the Java SE platform as it wanted to use it for its own new smartphone platform. Nevertheless, there were disagreements between the two parties and the negotiations fell apart. Ultimately, Google proceeded with developing its own platform which was to be tailored for smartphone technology. The Google engineers wrote millions lines of new code. However, as Google wanted all the programmers, who were already familiar with Java, to be able to easily work with the new Android platform, it copied roughly 11,500 lines of code from the Java SE program.
The copied lines of code were part of the Java SE API. In simple terms, an API (application programming interface) is a software intermediary that allows applications to talk to each other. It specifies how one software system should be accessed from the outer world, what inputs it will need and what outputs it will return.
The Java API can be viewed as a collection of individual tasks, known as “methods”. A method is a shortcut that allows programmers to use prewritten code to add certain functions into their own programs, rather than having to write code to perform those functions. The Java API groups together similar methods into larger “classes” and furthermore groups together similar classes into larger “packages”. This whole organizational structure of methods-classes-packages is referred to by the US Supreme Court as the structure, sequence and organization (SSO) of the Java API.
Each task (method) within the Java API consists of two types of source code – “implementing code” and “declaring code”. It is the implementing code that in effect instructs the computer how exactly to execute a particular task – such as for example putting a sequence of text in alphabetical order. But before the computer performs the function it should know which one of the many tasks within the Java API it should carry out, i.e. which exact implementing code it should choose. This is where the declaring code comes into play. The declaring code is the first line of code within a method and it identifies the method by name and functionality. Thus, the declaring code provides both the name for each task and the location of each task within the API’s overall organizational structure. The declaring code and a method call entered by the programmer allow him to draw upon the thousands of prewritten tasks, written in implementing code. The logic is such that without the declaring code, the method calls entered by the programmer would not call up the implementing code.
When developing Android, Google did not copy the implementing code from the Java SE API. In fact, it wrote its own task-implementing programs. For most of the packages in its new API, Google also wrote its own declaring code. However, for 37 packages Google copied the declaring code from the Java SE API. Effectively, for those 37 packages, Google copied the names given to particular tasks and the grouping of those tasks into classes and packages – the SSO.
In the aftermath of the global financial crisis Sun Microsystems was bought by Oracle in 2010. Shortly afterwards, Oracle initiated a lawsuit against Google alleging that Google had infringed the copyright in the Java SE API packages. Before reaching the Supreme Court diverging rulings were handed down by the lower instance courts. At first instance, the US District Court for the Northern District of California ruled in favor of Google and postulated that the copied code from the Java API was not copyrightable. However, at second instance the US Court of Appeals for the Federal Circuit reversed the earlier decision by postulating that the declaring code and its SSO were entitled to copyright protection. This is how the case reached the Supreme Court. Two main questions were directed at the US Supreme Court: i) whether the portion of the Java API that Google copied was protected by copyright and ii) whether Google’s copying constituted fair use, thereby absolving it from liability for copyright infringement.
Surprisingly, the US Supreme Court did not answer the first question at all. Instead, it chose to rely on a presumption, but strictly for argument’s sake, that the copied material was copyrightable – “In reviewing that decision, we assume, for argument’s sake, that the material was copyrightable”. Accordingly, the analysis of the court moved directly to the second question of fair use.
There are 4 statutory factors relevant for assessing fair use as established under §107 of the US Copyright Act:
- the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes
- the nature of the copyrighted work
- the amount and substantiality of the portion used in relation to the copyrighted work as a whole
- 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 Supreme Court was that Google’s limited copying of the Java API was a transformative use. The position of the court is that Google copied only what was needed to allow programmers to work in a different computing environment. Google’s purpose was to create a different system for a different computing environment (smartphones) and to create a platform that would help achieve and popularize that objective. According to the court, Google’s purpose was consistent with the broader notion of creative progress which is the basic constitutional objective of copyright.
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 deemed less creative and it would be easier to establish fair use. Here the finding of the Supreme Court was based on the nature of the declaring code. As established, the copied lines of code were part of an API that provides a way for programmers to access prewritten computer code through the use of simple commands. Therefore, the nature of such code is quite different from the code that actually instructs the computer to perform a task (such as the implementing code). The value of the copied lines of declaring code was primarily derived from the efforts of computer programmers who have already learned the API system. Consequently, the nature of the declaring code favors a finding for fair use according to the Supreme Court.
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 the qualitative value of the portion of the original work used. The finding of the Supreme Court was that Google copied 11,500 lines of code which represent 0.4 percent of the entire API, consisting of 2.86 million lines of code. The view of the Court was that the 11,500 lines of code should be seen as a small part of the considerably greater whole. Moreover, the reason Google copied those lines was not their creative nature or value but the utilitarian fact that they would allow programmers to bring their skills to a new environment tailored for smartphone applications. Therefore, according to the Supreme Court, the third factor weighs in favor 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 finding of the Court was that Google’s Android is not a market substitute for Java SE. Furthermore, the Supreme Court claimed that the copyright holder of Java SE would benefit from the reimplementation of its interface into a different market. Finally, the Court added that enforcing copyright on these facts would risk resulting in creativity-related harms to the general public. Accordingly, the fourth factor also weighed in favor of fair use.
Based on the assessment of the four factors, the Supreme Court ultimately concluded that Google’s copying of the Java SE API was aimed at reimplementing a user interface. It took only what was needed to allow programmers to put their talents to work in a new and transformative environment, and as such it constituted a fair use of the copied material.
From my perspective, an important factor for Google’s success in this legal battle was also the clever way their argument was framed before the Supreme Court. In addition to their purely legal arguments, Google’s stance was that a ruling against their use of the Java SE API would be heavily detrimental when it comes to independent developers as they would not be able to transfer their skills from one platform to another and would suffer the effects of vendor lock-in.
On the question of copyrightability, the expressed position by the Court was that given the rapidly changing technological, economic, and business-related circumstances, it should not answer more than what is necessary in order to resolve the parties’ dispute. Therefore, it assumes, but purely for argument’s sake, that the entire Java SE API falls within the definition of that which can be copyrighted.
Without a doubt, it would have been far more helpful if the Supreme Court at least had provided certain guidance on the factors to be taken into account when assessing the copyrightability of APIs. At the same time, it is understandable that the question of API’s copyrightability has to be ultimately decided on a case by case basis.
It must be mentioned that within the software industry there is an underlying understanding that the implementing code could be original and benefit from copyright protection but the declaring code is heavily dictated by functional considerations and as such would most likely not involve any creative choices. Quite often an analogy to a restaurant menu is used that likens the declaring code of an API to the names of the sections within a menu. No restaurant owner would be able to obtain copyright protection for the names of the sections of their menu – such as the headings – “salads”, “starters”, “main dishes”, “desserts”. Otherwise, its competitors would be prevented from using those words in their own menus.
In my view, based on its analysis of the differences between declaring and implementing code, the Supreme Court should have taken the next step and at least distinguished between the likelihood of copyrightability of the two types of code in an API. Furthermore, it could have provided guidance on the steps to be taken and the relevant copyright doctrines to be factored in when such an assessment is performed by the courts.
It is a well-known principle that copyright protects only the expression of an idea but not the idea itself. 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 and this was exactly Google’s argument before the US courts. 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. Obviously, the functionality of an API is not copyrightable but its expression in code may be.
Under EU law, the key requirement for a work to be protected under copyright is originality – i.e. that the author has made free and creative choices and the work is his or her own intellectual creation. Therefore, if an API is original – a situation where there are many different ways to structure and express 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 or in only one way and therefore, there is no room for creative choices, then based on the “merger doctrine” the expression of the API in code will not be original and no copyright will subsist. Consequently, in such a scenario anyone should be able to freely use and copy such an API. /The merger doctrine is a principle in copyright law dictating that when there is only one or a limited number of ways to express an idea, then the boundary between idea and expression disappears and they merge. Accordingly, the result is that the merged idea-expression is not protected under copyright/
A similar approach was prescribed by the Court of Justice of the European Union (CJEU) in its decision on Case C‑393/09 (Bezpečnostní softwarová asociace). While the judgment formally deals with the copyright protection of a graphical user interface, in my view the conclusion would be equally applicable also for APIs. As established in the EU Software Directive (Directive 2009/24/EC), interfaces are parts of a program which allow for interoperability – interconnection and interaction that allows all elements of software and hardware to work with other software and hardware and with end users. In particular, the CJEU provides the following guidance to national courts in paragraphs 45-51 of the decision on Case C-393/09:
“The Court has held that copyright within the meaning of Directive 2001/29 is liable to apply only in relation to a subject-matter which is original in the sense that it is its author’s own intellectual creation …
Consequently, the graphic user interface can, as a work, be protected by copyright if it is its author’s own intellectual creation …
When making that assessment, the national court must take account, inter alia, of the specific arrangement or configuration of all the components which form part of the graphic user interface in order to determine which meet the criterion of originality. In that regard, that criterion cannot be met by components of the graphic user interface which are differentiated only by their technical function.
As the Advocate General states in Points 75 and 76 of his Opinion, where the expression of those components is dictated by their technical function, the criterion of originality is not met, since the different methods of implementing an idea are so limited that the idea and the expression become indissociable …”
Therefore, under EU law, a case-by-case analysis is inevitably required in order to determine whether creative choices are employed in designing an API and whether it can be protected under copyright. Despite being utilitarian in their nature, it is still possible that APIs might involve various architectural design and implementation decisions that could give rise to originality in the work. However, when it comes to declaring code that merely represents the name of a task and its position within a larger structure (i.e. an expression dictated by a technical function), it is highly likely that no originality will be found and no copyright would subsist.
You must be logged in to post a comment.