SCOTUS Asks Solicitor General’s Advice on Whether to Hear Google’s Java API Copyright Case

SCOTUS Asks Solicitor General’s Advice on Whether to Hear Google’s Java API Copyright Case

Google, Inc v Oracle America, Inc, 14-410, [Google’s Petition] [Oracle’s Opposition] [Google’s Reply] [CAFC Decision]

On January 12th 2015, the U.S. Supreme Court asked for the Solicitor General’s advice on whether it should hear Google, Inc v Oracle America, Inc, 14-410, a case which would put directly at issue whether Java’s method headers are subject to copyright protection, or whether they are excluded by Section 102(b) of the Copyright Act for being a system or method of operation. Google’s petition comes after a loss in the Court of Appeals for the Federal Circuit (CAFC) where that Court held that Section 102(b) was not an absolute bar for systems or methods of operations, but rather a codification of the idea-expression dichotomy. [12, Petition] The CAFC found Oracle’s Java method headers to be creative and original, and on the right side of the idea-expression dichotomy since the code could have been written in many different ways. [12, Petition] Google’s principal argument in its petition is that the lower courts are deeply divided on the application of Section 102(b) and on how compatibility arguments and merger apply to software, and that its interpretation of Section 102(b) should be favoured. [1, Petition] Oracle opposes the petition, denying that there is division amongst the lower courts, and reiterates that Section 102(b) is rightly understood as the codification of the idea-expression dichotomy. [18, 24, Opposition] Both parties argue that their interpretation of the law would better foster growth and innovation in the software industry. [33, Petition; 32, Opposition]

Factual Background

At issue is not whether code in general can be subject to copyright protection. It is agreed by the parties that it can be. [7, Opposition; 1, Reply] What is in dispute is a particular kind of Java code, known as method headers. The Java programming language contains within it a number of pre-written programs, known as methods, for carrying out various computing tasks. Programmers call these methods using the method headers and the method’s implementation code carries out the task. [7, Reply] The methods are sometimes referred to as being organized into an API (Application Program Interface) Package. [5, Petition]

Google had copied Java’s method headers for 37 Java methods into its Android software for compatibility reasons – so that programmers could write code for Android applications using these familiar methods. [7, Reply] Although Google did not copy every method header available in Java, the amount of copying totaled 7000 lines of code copied verbatim. [8, Opposition] Google argues that it was necessary to replicate the method headers precisely, rather than rewrite them differently, so that programmers who were familiar with Java would be able to write code using the methods. Google calls this the “lock-in” effect. [31, Petition]

Google rewrote the entire implementing code for these methods on its own. [7, Petition]

Oracle writes that it offered to license the use of its code to Google on numerous occasions, but Google had rejected the offers. [33, Opposition]

Lower Court Decisions

The District Court for Northern California found in favour of Google, holding that although the code was creative and original, it was nevertheless barred from copyright protection. As Google puts it, the Java method headers were excluded from copyright protection under section 102(b) of the Copyright Act as a system or method of operation. [9, Petition] Oracle puts it differently, writing that the CAFC’s reasoning was that the ideas in the code merged with its expression. [9, Opposition]

The CAFC reversed the decision. As Google writes, the CAFC interpreted Section 102(b) to be a codification of the idea-expression dichotomy. Thus, since Google could have written its own API packages with method headers that could have been written and organized in any number of ways while still achieving the same function, Section 102(b) does not bar the packages from copyright protection. [12, Petition] Oracle disputes Google’s interpretation of the CAFC decision in some respects, [25, Opposition] but a common thread can be found. As interpreted by Oracle, the CAFC found that Oracle has copyright over the “particular way of naming and organizing each of the 37 Java API packages,” [26, Opposition] as a matter of the Section 102(b) codification of the idea-expression dichotomy. [27, Opposition]

Google’s Arguments on Petition

Google opens with the statement that this very question has been before the Supreme Court before, but remains unresolved, after Lotus Development Corp v Borland International, Inc, 516 US 233 (1996), and the division among the lower courts on this point has deepened ever since. [1, Petition] Central to Google’s argument is that appellate and lower courts around the United States are deeply divided on the function of Section 102(b), particularly with respect to its application to software. [13, Petition] Google claims the lower courts also differ on how they view copying for the sake of compatibility [18, Petition] and how the merger argument is to be applied to software. [19, Petition]

Google argues that the function of Section 102(b) is to exclude certain subject matter from copyright protection: “we do not think that [original expression] is alone sufficient. Courts must still inquire whether original expression falls within one of the categories foreclosed from copyright protection by § 102(b), such as being a ‘method of operation.’” [3, Reply] Google argues this interpretation is in accordance with the statute’s plain meaning. [14, Petition] Google argues that the Java method headers are a system or method of operation, and thus must be excluded from copyright protection. [29, Petition]

Google finds support for its interpretation of Section 102(b) from the classic copyright case of Feist Publications, Inc v Rural Telephone Service Co, 499 US 340 (1991), which it reads as holding that Section 102(b) “identifies specifically those elements of a work for which copyright is not available.” [21, Petition] Google cites Baker v Seldon, 101 (11 Otto) US 99 (1880) as excluding a method of accounting from copyright protection for being a method of operation, and for the proposition that the Patent Act, rather than the Copyright Act, governs protectability of methods and systems. [23-24, Petition]

Google supports its interpretation of the law on the policy argument that the ability of programmers to build on existing interfaces to create new products is a critical driver of innovation in the software field. [33, Petition]

Oracle’s Arguments in Opposition

Oracle favours the CAFC’s interpretation of Section 102(b) as codifying the idea-expression dichotomy, and rejects the argument that there is any division among the lower courts on its function, [14-16, Opposition] or any division on the issue of compatibility or merger. [23, Opposition] Oracle also turns the cases that Google relies upon on their heads. For example, Oracle reads Feist as explaining that Section 102(b) restates the idea-expression dichotomy, [27, Opposition]argues that Baker is a merger case, [25, Opposition] and writes that Lotus did not even involve computer code. [19, Opposition]

Oracle attacks Google’s argument on Section 102(b) as leading to an absurd result. In its view, all code amounts to a system or method of operation (rather than just the method headers). Therefore, if Section 102(b) precludes the Java method headers from copyright protection, then it precludes all code from copyright protection – which we know cannot be the case. [16, 26, Opposition] Instead, Oracle supports the view that Section 102(b) is a codification of the idea-expression dichotomy. [25, Opposition] Oracle argues that it is on the right side of the idea-expression dichotomy since the method header code could have been written in any number of different ways, and Oracle is claiming only its particular expression of the method headers, not the idea. [22, Opposition]

Oracle has a different view on how copyright of code can spur innovation. It claims it never would have invested millions in developing the Java language if it knew its investment would not be subject to copyright protection. [32, Opposition]

Fair Use Defence Remanded for Trial & the Compatibility Issue

Google’s fair use defence was not adjudicated before the CAFC. The CAFC remanded for a new trial on that defence. [12, Petition] Therefore, even if Google’s petition is denied, or if the case is heard and is again decided in Oracle’s favour, there is still a chance that Google’s copying could be deemed lawful if it is found to have been in accordance with the fair use doctrine.

The new trial might also serve as a forum for discussing Google’s compatibility (or interoperability) defence. The District Court, finding for Google, endorsed Google’s argument that replicating the method headers precisely was necessary to achieve a degree of interoperability with Java to allow programmers to write applications for Android using familiar Java methods. [10, Petition] When the CAFC reversed, it held that interoperability was irrelevant to copyrightability (an argument with which Oracle agrees), [29, Opposition] but noted that such an argument may be relevant to a fair use defence. [12, Petition]

In its opposition, Oracle uses the fair use trial to argue that Google’s petition is interlocutory since the Supreme Court would benefit from its conclusion. [37, Opposition] Google, however, sees the fair use trial as being entirely unnecessary if the dispute can be resolved on the copyright issue. [12, Reply]


Copying for the purpose of compatibility or interoperability is central to this case. As Google writes, it needed to copy the exact method headers so that programmers could make use of the methods when coding apps for Android. [31, Petition] Oracle acknowledges that Google’s use of the Java language itself is free of copyright issues, [App 108, Petition] but contends that the API packages are not a part of the Java language, [16, Opposition], and that Google should have written entirely different method headers itself. [19, Opposition] One can see a distinction between the API packages and the language itself, and that Google may be conflating the two for the purpose of its interoperability argument. However, if programmers also conflate the two, and rely on familiar Java methods with familiar syntax to the extent that they would not feel that they were writing in Java if they could not use them, it seems an empty statement to claim that the Java language is free to use.

If it is a persuasive argument that Google needed to copy the method header code for compatibility reasons, Google would then seem to have two chances to come out of this dispute victoriously: (1) if the Supreme Court considers that such code amounts to a system or method of operation which is excluded from copyright protection under Section 102(b), or (2) if the remanded trial concludes that Google’s copying was fair use. That is, if the Supreme Court takes the case and decides to interpret Section 102(b) the way Google suggests, as excluding certain subject matter from copyright protection. If the Supreme Court favours the CAFC interpretation and poses the question as whether Section 102(b) prohibits copyright to extend “beyond the original” expression to the idea embodied by the method header code, we may simply have a repeat of the CAFC decision which found that since the method headers could have been written in many different ways, the expression did not merge with the idea. If the Supreme Court adopts the CAFC’s interpretation it would not bode well for Google’s case, but Google’s compatibility argument may still become persuasive here: would programmers consider being able to use familiar Java method headers with familiar syntax as the “idea” that is being merged with Java’s expression?

It is also interesting to note that the parties appear to be approaching the compatibility argument from different angles. Google seems to view the compatibility issue from the perspective of the programmer writing applications. It needed to copy the Java method header code so that programmers could write with it. [31, Petition] However, Oracle points out that applications written in Java may not even run on Android devices, which it says is by Google’s design. [23, Opposition] Thus, Oracle says, Google’s compatibility argument is irrelevant. [23, Opposition] Oracle’s view focuses on compatibility from the perspective of the user running applications. It is difficult to see, in fairness, how Google’s compatibility argument is irrelevant unless Java is completely compatible with Android. And it is also odd to see Oracle criticizing Google for not making Java completely compatible with Android, because it would seem the only way to do that would be for Google to have copied every Java API package and all of its implementing code, when in reality Google had copied a lesser amount.

The outcome of this decision, should the Supreme Court choose to take the case, could be particularly important given the great deal of curtailing of software patent protection that has been occurring in the United States. The Supreme Court would be presented again with the chance to tweak the amount of copyright protection afforded to software, and to wrestle with the argument of whether software is properly protectable by copyright law, patent law, both, or neither.