Back in January we published a ‘Trends in IT Law: looking ahead to 2020’ post on the Kemp IT Law blog. In that piece we billed Google v Oracle as the biggest item on the software legal agenda for 2020. The impact of COVID-19 on the US Supreme Court’s March session means there is a chance the case will figure prominently in our 2021 update too. Few doubt the significance of Google v Oracle. For Google, a judgment in Oracle’s favour would throw “a devastating one-two punch at the software industry” and “wreak havoc on copyright law”.1 For Oracle, if the decision goes the other way, the Supreme Court will have sanctioned “an egregious act of plagiarism” and “rewritten” copyright law2. In this broad update on the case we briefly recap the story so far; look in a bit more detail at a short computer program called the ‘compareTo’ method which illustrates what Google copied from Java (and what it did not); and then consider the questions put to the Supreme Court.
The battle between Google and Oracle has been running for so long3 that substantial historical accounts are now beginning to emerge.4 But it can be summarised in a few sentences:
- The key events took place amid the blistering competition for the world’s booming smartphone market in the mid-2000s.
- Apple released the first iPhone in January 2007 but Google was late – it was still developing Android which it would not release until that November.
- To spur the adoption of Android by developers, Google copied parts of Java into Android. This meant that developers already using Java would not need to learn another language to write Android apps.
- Java was well-established. It had been written by Sun Microsystems in the mid-1990s. Sun was an easy target after the 2008 financial crisis and was bought by Oracle in 2010.
- Oracle sued Google for infringing copyright in the Java API a short time later. The litigation has been progressing up (and down) the US courts system since.
In articulating the technical aspects of what Google copied from the Java API, the key point is that Google copied the ‘declarations’ (and the broader organisational structure) of parts of the Java API but wrote its own ‘implementing code’. We give a technical explanation of this below, and then go on to consider the legal questions.
Java APIs – methods, declarations and implementations
Figure 1 is the centrepiece of our explanation. It is a cutting from a slide deck shown by Google’s lawyers at the first instance trial in 2012. It shows two versions of a short computer program known as a ‘method’ – one from Java (left-hand side), the other from Android (right). The things to note are that the first lines of each are identical and that the highlighted code differs.
Methods are shortcuts that allow developers to use pre-written code to carry out specific, commonly performed tasks. The method in Figure 1 is called ‘compareTo’. ‘compareTo’ enables a computer to calculate the alphabetical order of different sequences of text. The functionality is like the ‘Sort A to Z’ button you might use when filtering search results on an online shopping website. Even though the code in the different versions of ‘compareTo’ is different, the output is identical – alphabetical order.
Figure 1: the ‘compareTo’ method
The first line of a method is known as the ‘declaration’. This is because it identifies (‘declares’) the method by citing its name and identifying some of its functionality. A developer can use the functionality of compareTo in the program they are writing by ‘calling’ it using a shorthand command derived from compareTo’s declaration: “public int compareTo(String anotherString)”.
The highlighted code in the main body of compareTo is the ‘implementing code’. This is the code that gives a computer the step-by-step instructions how to execute (‘implement’) compareTo. Clearly there are differences between the implementing code in the Java and Android versions of compareTo. This is because Google rewrote5 the implementing code for the Java methods it used in Android, fearing that copying them would be an infringement of Oracle’s copyright. Google was also keen that Android was optimised for smaller smartphone processors – hence the implementing code it wrote is shorter than the Java version.
Stepping back, in simple terms the Java API is a collection of methods which are carefully organised into a logical hierarchy. There are organisational units above methods: classes and packages. The first instance judge described this as “like a library. Each package is like a bookshelf in the library. Each class is like a book on the shelf. Each method is like a how-to-do-it chapter in a book.”6 As well as the method declarations, Google replicated the functionality and organisational structure of parts of this library in Android. Google argues that to preserve the functionality of Java in Android (thereby helping developers already familiar with Java) the rules of Java required these aspects to be identical: “to work on the Android platform, Google had to replicate the syntax and structure of the Java API declarations exactly”7 The copyright issue at the heart of Google v Oracle lies in the tension between Google’s literal copying on the one hand, and the prescriptive rules of Java on the other.
Are Java APIs copyrightable and if so does Google’s use constitute ‘fair use’?
Google has put two copyright questions to the Supreme Court: One – does copyright protection extend to a software interface? Two – does Google’s use of the Java API constitute “fair use”?
The statutory provision at play is Section 102(b) of the 1976 Copyright Act, which sets the boundary for copyright protection in the US. While s.102(a) provides that “original works of authorship” are generally copyrightable, s.102(b) k
