We billed Google v Oracle as the biggest item on the software legal agenda for 2020 in our ‘Trends in IT Law: looking ahead to 2020’ blog post back in January. 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 law.[2] In a broad update on the case this blog briefly recaps the story so far; looks in a bit more detail at a short computer program called the ‘compareTo’ method, which illustrates what Google copied from Java (and what it didn’t); and then considers the questions put to the Supreme Court.
The battle between Google and Oracle has been running for so long[3] 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
- To spur the adoption of Android by developers, Google copied parts of Java into Android. This meant that developers already using Java wouldn’t need to learn another language to write Android
- 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
- 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
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 thing to note is that the first lines of each are identical, and 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.
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 rewrote[5] 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 why 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) keeps this in check:
“In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.”
Part of the answer to question one lies in whether the aspects of the Java API Google copied (the declarations and the organisational structure mentioned above) fall within one of these categories. If they do, they aren’t copyrightable in the first place. The likely candidate is “method of operation”.
But the boundary set by s.102(b) is a fraught one, particularly as it relates to copyright in software. This is because the utilitarian nature of software treads a fine line between the creative expression of original ideas (which copyright can protect) and the ideas themselves (which it cannot) – the so-called ‘idea-expression dichotomy’. In simple terms, it is eminently arguable which is which.
For this reason, courts in the US (and the UK and elsewhere) have been reluctant to draw broad conclusions about which bits of software are copyrightable, preferring to reach narrow conclusions on a case-by-case basis. The US Court of Appeals for the Second Circuit neatly captured this perennial uncertainty in a software copyright case from the early 1990s: “… compared to aesthetic works, computer programs hover even more closely to the elusive boundary line described in s 102(b)”.[8]
It will be interesting to see if the US Supreme Court is influenced by the view of the Court of Justice of the European Union that “copyright in a computer program does not protect either the programming language in which it is written or its interfaces (specifically, its data file formats) or its functionality from being copied.”[9]
The merger doctrine is a related aspect of Google’s copyrightability argument. In short, the merger doctrine means that if you can only express an idea or some functionality in one way, that expression is not copyrightable if it would have the effect of extending copyright protection to the idea or functionality itself. The question is whether merger doctrine applies to the declarations and organisational structure (which can only be expressed in one way under the rules of Java – see above) that Google copied.
Google’s view is that the copied parts of the Java API “easily fit” within s.102(b): “they are a method of operation because they are for developers to use.” On the merger doctrine, Google’s position is that “the dispositive, undisputed fact” is that the copied parts of the Java API “cannot be written in any other way”, and that the merger doctrine therefore applies.[10]
Unsurprisingly, Oracle argues the opposite: it “does not seek to protect the ideas embodied in Java”.
Instead, it “claims rights only in its particular expression of those ideas.” On the question of merger: “The merger doctrine applies only in the narrow situation where there are very few ways to express an idea. That is not this case.”[11]
If the Supreme Court finds that the Java APIs are copyrightable, Google will not have infringed Oracle’s copyright if it can prove fair use. Again, the statutory position is codified in the 1976 Copyright Act, at s.107: “the fair use of a copyrighted work… is not an infringement of copyright”. In determining fair use, s.107 provides that four equally weighted “fair use factors” must be used to guide the analysis. These factors include whether the use is “of a commercial nature” and “the nature of the copyrighted work”. Fair use has been described as “the most troublesome [doctrine] in the whole law of copyright.”[12]
In the US, a jury decides fair use. There are constitutional reasons for this, but it is also because “juries are simply better positioned than judges to decide the sort of issues that arise in fair use cases”[13] – which is to say that fair use cases require a complex set of subjective judgments that turn on cultural understandings and norms that are better suited to a diverse jury. One of the reasons Google v Oracle is so remarkable from a procedural perspective is that the US Court of Appeals for the Federal Circuit, in finding that Google’s use was not fair in 2018, reversed a jury’s earlier decision that it was – an almost unprecedented step in US judicial history.
In Google’s view, the appeals court’s finding that its use of the Java APIs was not fair use “is a dangerous misapplication of the fair-use doctrine with breathtakingly broad implications”. Notwithstanding the reversal of the jury decision, Google argues that the appeals court failed to factor the functional nature of the copied Java APIs into its fair use analysis. This will hand Oracle a “government-granted monopoly” over the functional elements of the Java APIs.[14]
Oracle’s argument is that the scale and purpose of Google’s copying precludes a finding of fair use: “No court has found fair use where, as here, someone copied so much valuable expression into a competing product to serve the same purpose as the original in the marketplace.”[15]
In Google’s characterisation, the global software industry relies on a settled assumption that an API’s implementation benefits from copyright protection but the declarations and organisational structure do not. Upsetting this apple cart will, in Google’s words, “impose debilitating retroactive liability” on software developers who reuse aspects of other APIs in this way: they will suddenly find that there is copyright in these declarations and structures, and it belongs to someone else.[16]
This blog was first published as part of the white paper which you can read in full here: Algo IP: Rights in Code – 2020 Update
[1] Petition for a Writ of Certiorari, Google LLC v Oracle America, Inc. (24 Jan 2019): https://www.supremecourt.gov/DocketPDF/18/18-956/81532/20190124110509177_Google%20cert%20petition.pdf.
[2] Brief in Opposition, Google LLC v Oracle America, Inc., No. 18-956 (27 Mar 2019): https://www.supremecourt.gov/DocketPDF/18/18-956/93436/20190327160337558_190311%20for%20E-Filing.pdf.
[3] Ten years in August 2020.
[4] For a masterly example, see: Menell, Peter S., ‘Rise of the API Copyright Dead?: An Updated Epitaph for Copyright Protection of Network and Functional Features of Computer Software’ Harvard Journal of Law & Technology (2018), Vol. 31, pp. 307-490: https://jolt.law.harvard.edu/assets/articlePDFs/v31/31HarvJLTech305.pdf.
[5] In fact, Google’s implementing code pointedly refers to a precedent that pre-dates Java entirely. The first line of the Android implementation of ‘compareTo’ reads: “// Code adapted from K&R, pg 101”. The double forward slashes indicate that this line is a coding note left by the Google developers. “K&R” refers to a book (first published in 1978) called ‘The C Programming Language’ by Brian Kernighan and Dennis Ritchie.
[6] Oracle America, Inc. v Google Inc. (N.D. Cal. 2012): http://www.groklaw.net/pdf3/OraGoogle-1202.pdf.
[7] Petition for a Writ of Certiorari, Google LLC.
[8] Computer Associates International, Inc. v Altai, Inc. (2d Cir. 1992): https://cyber.harvard.edu/people/tfisher/IP/1992%20Altai.pdf.
[9] Per SAS Institute Inc v World Programming Limited [2013] EWHC 69 (Ch), following C-406/10 SAS Institute Inc v World Programming Limited, ECLI:EU:C:2012:259).
[10] Reply Brief for the Petitioner, Google LLC v Oracle America, Inc. (11 Mar 2020): https://www.supremecourt.gov/DocketPDF/18/18-956/137903/20200311194254554_18-956%20rb.pdf.
[11] Brief for Respondent, Google LLC.
[12] Oracle America, Inc. v Google Inc. (Fed. Cir. 2014): https://cases.justia.com/federal/appellate-courts/cafc/13- 1021/13-1021-2014-05-09.pdf?ts=1411173375.
[13] Snow, Ned, ‘Who Decides Fair Use – Judge or Jury?’ Washington Law Review (2019), Vol. 94, pp. 275-332: https:// digitalcommons.law.uw.edu/cgi/viewcontent.cgi?article=5058&context=wlr.
[14] Petition for a Writ of Certiorari, Google LLC.
[15] Brief for Respondent, Google LLC.
[16] Reply Brief for the Petitioner, Google LLC.
