Google v. Oracle: What the Supreme Court Did (And Did Not Do)
In what commentators have called “The Copyright Case of the Century,”1 the Supreme Court ruled earlier this year in favor of Google in their long-running battle with Oracle over Google’s use of Java’s API in their development of the Android operating system. In a 6-2 majority written by Justice Breyer, the Court held that Google’s use of Java’s API constituted fair use, but did not answer the more fundamental question of whether API code is protected by copyright. I argue that while the Court’s ruling may be sufficient to uphold the status quo, it does not resolve the fundamental tension at issue in this case: that Congress chose to protect functional computer code under copyright, which is usually meant for expressive works and does not perfectly fit the needs of protecting code while promoting ease of use and development. The decision the Court reached may be the best of a few bad options, but it is likely to create significant uncertainty until the question of how code should be protected is solved.
In 1990, engineers at Sun Microsystems began developing a programming language that would become known as Java. The language was released in 1996. Initially, it was designed to write programs for the emerging World Wide Web. However, it had many uses, and due to its flexibility and portability, many programmers adopted it to use for their own programs.
Alongside the programming language itself, Sun developed an Application Programming Interface, or API. An API is an interface that defines certain functions known as ‘methods’ within the programming language for ease of use by creating specific functions that a programmer can use, thus simplifying the process of writing complex code. For instance, an API might contain a function to find the hypotenuse of a right triangle, which the programmer can then utilize by typing a specified set of words or letters along with the lengths of the sides.2 To use a legal analogy, an API is like the United States Code; a lawyer writing a brief about novelty in patent law can write, for instance, 35 U.S.C. § 102 (a)(1) rather than type out the entire statute repeatedly, similar to how a programmer writing a particular program can use a method in an API rather than reproduce the entire task.
Because of Java’s popularity, programmers became used to Java’s API, as many programming students learned primarily to code Java. Sun did good business out of licensing Java’s API to other developers to design their software. Many companies used Java for a wide variety of applications, and one such application was the burgeoning market for smartphones.
2. Google’s Development of Android
In 2005, Google acquired Android, Inc., a Palo Alto startup focused on making smarter software for mobile phones. Google planned to enter the telecommunications market and wanted to use Android to create a mobile operating system for smartphones. As part of this plan, it wanted to entice developers to create apps for its new operating system, and because of Java’s popularity, it would be easier for developers to write those apps in a language similar to Java. Google entered into talks with Sun to license Java for use in developing Android, but the talks fell through.3 Instead of licensing Java itself, Google developed its own software, known as Dalvik. Dalvik allowed developers to use the Java programming language to write apps for Android, which would then be converted to Dalvik when the code was compiled (translated from the easier-to-read programming language to machine code).
Crucially, however, they included certain parts of Java’s API: about 11,500 lines of code containing some of Java’s essential methods. Google copied what is known as the 'declaring code' of the APIs, or the line of code that 'declares' the name of the particular method. However, they rewrote from scratch the 'implementing code,' the code that actually performs the method's function. Android was launched and became an incredible success, with over 2.5 billion users worldwide.4
3. Legal Twists and Turns
In 2010, Oracle Inc. purchased Sun. Oracle filed suit against Google for copyright and patent violations. The case took a complex path to get to the Supreme Court. Initially, Judge William Alsup of the Northern District of California oversaw a three-phase trial: One phase for the copyright claims, one for the patent claims, and one phase for damages, if necessary. The jury found for Google on the patent claims, but for Oracle on the copyright claims.5 Judge Alsup, however, ruled that APIs were not copyrightable.6 Oracle appealed the ruling to the Federal Circuit, which reversed the ruling, holding that APIs were copyrightable, and remanded the case to the district court for fair use analysis.7 The Supreme Court denied certiorari. In the fair use trial, the jury found in favor of Google.8 Oracle again appealed to the Federal Circuit, where the decision was reversed, with the Federal Circuit again holding in favor of Oracle that Google’s use was not fair as a matter of law.9 Google again appealed for a writ of certiorari, and this time the Supreme Court agreed to hear the case.
From the start of the litigation, the case was watched closely by the tech industry.10 For the most part, industry actors favored Google, with even business rival Microsoft submitting an amicus brief supporting Google.11 Tech industry experts argued that the reuse of APIs is widespread in software development and is crucial to allow programmers to create interoperable programs or work with a wide variety of devices and other programs.12 Amici argued that reimplementation was extremely common in the industry and argued that treating APIs as copyrightable would undermine development in a wide variety of areas.13 Not all commentators favored Google: A few argued that a ruling favoring Google would remove protection from smaller innovative software developers, allowing large companies with vast resources to utilize the innovations of smaller developers.14
Google advanced two arguments for why their use of Java API was acceptable. The first—and, according to the majority, more provocative—is that APIs are not copyrightable.15 It argued that while Congress included computer code in the 1980 amendment to the copyright law, APIs in particular, especially the declaring code they used, are essentially “processes” or “methods of operation” that cannot be copyrighted.16 Google’s other argument was that even if the APIs could be copyrighted, its use of Java’s API was protected by fair use, a doctrine that protects the use of copyrighted material under particular circumstances. If either of the arguments were accepted, Google would not be liable.17
Justice Breyer, writing for the majority, focused almost exclusively on the fair use argument. The majority, not wanting to “answer more than is necessary to resolve the parties’ dispute,” assumed arguendo that APIs could be copyrighted, but held that Google’s use of Java’s API was covered under fair use.18 The majority analyzed Google’s use of Java’s API under the traditional fair use test. The test is flexible and fact-specific, with four statutory factors that the majority argued applied flexibly to help the analysis: (1) the purpose and character of the use, (2) the nature of the copyrighted work, (3) the amount and substantiality of the portion used, and (4) the effect of the copying on the market value of the copyrighted work.19 The majority held that all four factors favored Google and thus that its particular use of Java’s API was protected under fair use.20
1. The Nature of Declaring Code
The main factor utilized by the majority was the second factor, and it was in that analysis that the majority made what is likely to be the main takeaway of importance from this case: the distinction between declaring code and implementing code. The majority nearly goes so far as to hold that declaring code is per se uncopyrightable, and does clearly hold that declaring code deserves less copyright protection than implementing code.21 As Google used only Java’s declaring code and wrote its own implementing code, the nature of the work used was, in the court’s eyes, less deserving of copyright protection.
This distinction will undoubtedly have effects on the programming industry. After all, the main reason Google wanted to use Java’s API was so that programmers developing apps for Android could use the same methods they were used to in other Java programming, and it is the declaring code that determines method names. While not every user who wants to do what Google did will have the capability to rewrite the methods themselves as easily as Google could, giving declaring code significant protection serves the purpose many in the industry desired: it prevents programmers from having to re-learn method names when they are programming in Java but on a new platform.
2. The Other Fair Use Factors
The majority’s analysis of the first, third, and fourth factors focuses on the particular facts of Google’s use of Java’s API. Google only copied Java’s API as much as necessary to allow programmers to use familiar method names, thus tilting the first factor in their favor.22 It only copied 11,500 lines out of the 2.86 million of Java’s full API, tilting the third factor their way.23 As for the fourth factor, Google did not seek to set up a competitor to the Java programming language or API, but to develop its own set of products in a completely different market, meaning that while Google clearly wanted to make money off of their use, it did not harm the value of Java’s API.24 With all the fair use analysis factors favoring Google, the majority ruled that Google’s use was protected by fair use.
The dissent, written by Justice Thomas, took issue with the decision not to answer the first question, arguing that “the majority gets the methodology backward” by answering the fair use question without answering the copyrightability question.25 In a sense, answering the copyrightability question is necessary to answer the fair use question. Indeed, if APIs were not copyrightable, there would be no need for fair use analysis, as Google would not have infringed a non-existent copyright. However, the copyrightability question, if answered in Google’s favor, would have created a much stronger rule. If APIs are not copyrightable, there is no need for users of APIs to use them only when fair use protects them. Anyone could copy an API and use it for their own purposes unless some other form of IP protected it. If the majority’s desired outcome was to maintain the status quo, where APIs could largely be protected under copyright but allow for traditional fair use, the path it chose was reasonable.
The dissent’s analysis focuses mainly on Congress’s mandate that computer code is protected by copyright, relying on Congressional purpose in both its copyrightability and fair use analyses even though it recognizes that “computer code occupies a unique space in intellectual property.”26 The dissent argues that Congress made computer code copyrightable without making the majority’s distinction between declaring and implementing code.27 If Congress did not distinguish between declaring and implementing code and implementing code is copyrightable, it seems like declaring code should also be copyrightable.28 The dissent’s argument can be viewed as an argument by contradiction: If declaring code is not copyrightable, then implementing code, and most computer code in general, cannot be copyrightable, and most computer code, based on Congress’s mandate, must be copyrightable.29
2. The Dissent on Fair Use
In its fair use analysis, the dissent emphasizes Congress’s decision to make computer code copyrightable, holding that three of the fair use factors favor Oracle.30 It admits that the second factor, which the majority emphasizes, is the most favorable to Google. Declaring code is functional, and the second factor favors fair use when a work is more functional than creative.31 However, the dissent argues that declaring code is actually closer to the core of copyright than implementing code; after all, developers cannott even see implementing code, while declaring code is more like an expression used to represent a process.32 The dissent then analyzes each of the remaining factors in Oracle’s favor, beginning with the market factor. It recognizes that Oracle’s market for Java’s API was significantly harmed, as other companies, including Amazon and Samsung, negotiated significant discounts in their contract with Oracle.33 The dissent makes similar arguments in its analysis of the purpose factor, holding that the use of the API was inherently commercial and that Google’s intended purpose was supplanting Java’s API.34 Finally, it argues that while Google only used a small amount of Java’s API, what should be measured is how much of the declaring code Google used rather than the entire implementing code.35
A large part of the Court’s trouble with the copyrightability question is that while Congress chose to make computer code copyrightable, it is an odd fit for copyright protection. The reason for this is simple and obvious: while copyright protection is meant primarily for creative and artistic works, computer programs “almost always serve functional purposes.”36 Certainly, there is significant creativity that goes into programming in much the same way as someone can be a creative lawyer, doctor, or chef. Many programmers even refer to elegant implementations and functions as “beautiful.” The desire for elegant, concise code, however, is not based on any inherent aesthetic value it possesses, but on that code’s efficiency and efficacy at achieving its intended result. Shorter, simpler code is more efficient and requires less computing resources, which can then be devoted to other functions. Computer code may be used to produce works of expression. It is undoubtedly used extensively to generate imagery in modern blockbusters, not to mention underpinning the cameras that shoot the movie and the word processors used by the scriptwriters. Ultimately, though, the code is not a creative work in and of itself.37
This observation is in tension with the direct mandate of Congress that computer code is protected by copyright.38 The majority and the dissent approach this fundamental tension in different ways. The majority notes this tension multiple times but seems unwilling to go against what it views as a congressional mandate. While the majority does not explicitly rule on the question, it seems to acknowledge that computer programs that are functional in nature can be copyrighted, at least given its assumption that APIs are copyrightable.39 Instead, it looks at the purpose of the code, distinguishing between declaring code that “is bound together with uncopyrightable ideas (general task division and organization)” and implementing code, which is more directly creative.40 Because the purpose of declaring code is essentially to organize methods and allow programmers to call them up more efficiently, it seems to argue, it is too much like the exceptions listed in 17 U.S.C § 102(b). While the use of particular language may embody a certain kind of creativity, in choosing words that will be easy to remember and read, it is bound up with uncopyrightable ideas, and thus deserves little or no protection itself.
Meanwhile, the dissent bases its holding mainly on Congress’s mandate.41 While this rule would, at least, provide a brighter rule about when computer code is protectable, it still upholds the problems caused by Congress’s mandate in the first place.
2. The Uncertain Path Forward
It is hard, however, to say what a better route would be, and I will not attempt it in this piece. Computer code is a unique form of idea—especially given the norms and practices of the software industry—and none of the traditional forms of intellectual property protection perfectly fit the needs of software engineers. While particularly novel and innovative code may be patented, the long process of applying for the patent compared with the lightspeed rate of change in the software industry means that most code will be obsolete by the time a patent is obtained, and the patent monopoly will extend long past the code’s useful lifespan, disincentivizing sharing. As for trade secret protection, if interoperability is the goal, a form of protection that uses secrecy as its watchword will certainly be a poor fit, especially for programming languages and APIs themselves which must be widely known.
Perhaps the middle road the majority chose, upholding the general copyrightability standard but allowing some copying under fair use, is a good compromise position. However, the fair use quesation is, as the court itself emphasizes, the opposite of a clear, bright-line rule.42 While the majority opinion offers some guidelines on how the fair use analysis should play out—most crucially, that declaring code has less protection than implementing code, but also that a fair use argument is more likely to succeed if the product being developed is not a competitor with the API itself—it is still likely that the decision will lead to further uncertainty (and further litigation). The uncertainty is especially present for developers without the resources to rewrite implementing code from scratch, as Google did. Until the Court clarifies its position, or Congress steps in to clarify how computer code, in general, is protected by providing a brighter line rule, the “Copyright Case of the Century” will be all sound and fury, signifying nothing.
1. See Devin Dwyer, Google Wins Big in Supreme Court Clash With Oracle, Abc News (Apr. 5, 2021) https://abcnews.go.com/Politics/google-wins-big-supreme-court-clash-oracle/story?id=76878814. Return
2. In this example, for instance, a programmer would type java.lang.Math.hypot(3,4), and code in the API would calculate and return the hypotenuse of a right triangle with lengths 3 and 4, which is 5. Return
3. Multiple reasons have been given for the failure to reach a deal. Google wished to make their development language open source, to encourage widespread development. If such a deal had gone through, developers would have written code that would work on Android devices but nowhere else, going against Sun’s “write once, use anywhere” philosophy which emphasized inter-usability between platforms. Return
4. Russel Brandom, There Are Now 2.5 Billion Active Android Devices, The Verge (May 7, 2019) https://www.theverge.com/2019/5/7/18528297/google-io-2019-android-devices-play-store-total-number-statistic-keynote. Return
5. Oracle America, Inc. v. Google Inc., 872 F. Supp.2d 974, 976 (N.D. Cal. 2012). Return
6. Id. at 1002. Return
7. Oracle America, Inc. v. Google Inc., 750 F.3d 1339, 1381 (Fed. Cir. 2014). Return
8. Oracle America, Inc. v. Google Inc., 886 F.3d 1179, 1185 (Fed. Cir. 2018). Return
9. Id. at 1211. Return
10. See, e.g., Cari Tuna and Don Clark, Oracle’s Java Suit Gives Jolt, The Wall Street Journal (Aug. 14, 2010), https://www.wsj.com/articles/SB10001424052748703321004575427710931993950. Return
11. Brief for Microsoft Corporation as Amicus Curiae in Support of Petitioner, Google LLC v. Oracle Am., Inc. No. 18-956, 2021 WL 1240906 (U.S. Apr. 5, 2021), 2020 WL 224318. See, e.g., Brief for Amici Cuirae Small, Medium, and Open Source Technology Organizations in Support of Petitioner, Google LLC v. Oracle Am., Inc. No. 18-956, 2021 WL 1240906 (U.S. Apr. 5, 2021), 2020 WL 242508. See also Klint Finley, The Oracle-Google Case Will Decide the Future of Software, Wired (May 23, 2016) https://www.wired.com/2016/05/oracle-google-case-will-decide-future-software/; Timothy B. Lee, The Supreme Court Hears Oracle v. Google Tomorrow-Here’s What’s at Stake, Ars Technica (Oct. 6, 2020) https://arstechnica.com/tech-policy/2020/10/google-asks-supreme-court-to-overrule-disastrous-ruling-on-api-copyrights/. Return
12. See Rina Diane Caballar, Google v. Oracle Explained: The Fight for Interoperable Software, Ieee Spectrum (Feb. 19, 2020) https://spectrum.ieee.org/tech-talk/computing/software/google-v-oracle-explained-supreme-court-news-apis-software. Return
13. See, e.g., Brief for R Street Institute, et al. as Amici Curiae in Support of Petitioner, Google LLC v. Oracle Am., Inc. No. 18-956, 2021 WL 1240906 (U.S. Apr. 5, 2021), 2020 WL 242502, at 15-20. Return
14. See Sue Ghosh Stricklett, Google v. Oracle: An Expansive Fair Use Defense Deters Investment In Original Content, IP Watchdog (Jan. 19, 2020) https://www.ipwatchdog.com/2020/01/19/google-v-oracle-expansive-fair-use-defense-deters-investment-original-content/id=117951/. Return
15. Google LLC v. Oracle Am., Inc. 141 S. Ct. 1183, 1196, 209 L. Ed. 2d 311 (2021). Return
16. Id. Return
17. Id. Return
18. Id. at 1197. Return
19. Id. at 1196-97. Return
20. Id. at 1201-08. Return
21. Id. at 1202 (“In our view […] the declaring code is, if copyrightable at all, further than are most computer programs (such as implementing code) from the core of copyright.”). Return
22. Id. at 1204. Return
23. Id. at 1206. Return
24. Id. at 1208. The dissent most strenuously disagreed with this point: See infra note 33. Return
25. Id. at 1214. (Thomas, J., dissenting). Return
26. Id. at 1212. Return
27. Id. Return
28. Id. Return
29. The majority rejects the first premise of the argument, allowing a distinction between declaring and implementing code. Return
30. The dissent also argues that the majority misconstrues its fair use analysis by using the factors more-or-less equally, rather than the market and purpose factors being the most important. Google, 141 S. Ct. at 1214-15 (Thomas, J., dissenting). However, as the majority finds all four factors favorable to Google and the dissent finds three factors favorable to Oracle and one close factor, this argument is not important to the case’s resolution. Return
31. Google, 141 S. Ct. at 1215 (Thomas, J., dissenting). Return
32. Id. Return
33. Id. at 1216. Return
34. Id. at 1218. Return
35. Id. at 1220. Return
36. Id. at 1198. As Justice Breyer notes, citing the First Circuit Court of Appeals, “applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.” Id. (citing Lotus Development Corp. v. Borland Int’l., 49 F.3d 807, 830 (1st Cir. 1995) (Boudin, J., concurring)). Justice Thomas recognizes the tension too, but argues that Congress’s choice on how to resolve it is controlling. Google, 141 S. Ct. at 1212. Return
37. There is nothing theoretically preventing computer code from being a creative work - for instance, a particularly self-referential piece of code could have aesthetic value, or a show about a hacker could make a piece of code significant to the plot into a t-shirt design. However, such uses of code are more rare, and clearly not at issue in the controversy between Google and Oracle, so while they might need a carve-out if there was a general rule that code is not copyrightable, such works do not change the larger question of this case. Return
38. See Google, 141 S. Ct. at 1198. Return
39. Id. at 1202 (“Like other computer programs, it is functional in nature. But […] its use is inherently bound together with uncopyrightable ideas […]”). Return
40. Id. Return
41. See supra pages 7-8. Return
42. See Google, 141 S. Ct. at 1197 (“[W]e have understood the provision to set forth general principles, the application of which requires judicial balancing, depending on relevant circumstances, including “significant changes in technology[…]” [internal citations omitted]). Return