Breaking News
Opinion Analysis

Justices validate Google’s use of Java platform in Android software code

Monday’s decision in Google v. Oracle reminds us that occasionally the Supreme Court can take a big case and actually decide it! So many of the intellectual-property cases that reach the justices reflect minor circuit conflicts of largely technical interest or end up with a decision so narrow as to contribute little to the development of the law. Google is not that kind of decision. Justice Stephen Breyer’s opinion for a 6-2 majority decisively rejects Oracle’s challenge to Google’s use of computer code from the Java SE platform in its Android operating system, and the reasons he offers to justify that decision will have ramifications echoing into the future for the owners, developers and users of commercial software.

The case arose from the Android operating system designed by Google for smartphones, which is now used in a variety of other devices (such as the Kindle Fire). When Google designed Android, it wanted to make it readily accessible to developers familiar with the Java programming language, so it included in the Android operating system about 11,500 lines of code from Java SE, a platform that allows developers to write programs in Java that can run on various devices. Some aspects of the decision involve technical aspects of software design and organization that I do not undertake to explain, hoping that I can summarize the crucial aspects of the court’s reasoning in relatively accessible terms. To understand why the court permitted Google to copy that code, though, it is necessary to understand a little bit about the organization of Oracle’s Java SE platform (originally created by Sun Microsystems). An important part of that platform is a set of thousands of methods developers might want their software programs to use; Breyer’s opinion uses the example of a method called “max,” which returns the larger of any two listed numbers.

Java SE uses three different kinds of code to implement the methods that it includes. The first is the “call,” which programmers type when they want to use a method. Breyer’s opinion, for example, refers to the “max” function, which would return the maximum of two numbers if the programmer typed the call java.lang.Math.max(4, 10). The second is the declaring code, which Java SE uses in response to a call to find the method identified by the call. The third is the implementing code, which is the code that actually solves the problem (in this case, figuring out whether 4 is greater than 10). When it created Android, Google wrote fresh implementing code for all of the methods that it included, but for many of the methods included in Java SE, it copied both the call and the declaring code. (You might imagine that it reused phrases like “Open Sesame,” but created anew the mechanisms to cause doors to open and shut.) Although a jury thought this was a “fair use” of the Java SE code, the U.S. Court of Appeals for the Federal Circuit disagreed, holding both that the copied code was protected by copyright and that it was not fair for Google to copy it.

A major part of the dispute considered Google’s argument that the calls and the declaring code are not even copyrightable. Generally, Google argued that those portions of the code are so functional that they are insufficiently expressive to warrant copyright protection, emphasizing provisions of the Copyright Act that forbid protection for any process, system, or method of operation. Breyer’s opinion is quite clear in declining to address that question, but rather assuming “purely for argument’s sake” that the code in question is copyrightable. For the majority, the case turns entirely on a conclusion that what Google did with the Java SE code is a “fair use” permitted by the Copyright Act despite any copyright protection for the code in question. The fair use provision is notoriously vague, calling for an unspecified balance of four relatively indeterminate factors that the statute specifies. The strategy of the majority opinion is to explain that each of those four factors weighs in favor of a finding of fair use, thus compelling a holding that Google’s conduct was fair. To put it another way, the court holds that the circumstances make Google’s conduct so clearly a fair use that the jury’s finding of fair use is largely irrelevant.

The first factor that the court considers is the “nature of the copyrighted work.” On that point, it is crucial that the code Google copied is a “user interface,” which (in Breyer’s words) is code “through which users (here the programmers) … manipulate and control task-performing computer programs.” Breyer explains that the user interface is different, for fair use purposes, from the “uncopied implementing programs,” because they embody “different kinds of capabilities.” On the one hand, “writ[ing] implementing programs … requires balancing such considerations as how quickly a computer can execute a task or the likely size of the computer’s memory, …. the very creativity that was needed to develop the Android software for use not in laptops or desktops but in the very different context of smartphones.” On the other hand, Breyer describes the user interface as “inherently bound together with uncopyrightable ideas (general task division and organization)” and something for which the “value in significant part derives from the value that those who do not hold copyrights, namely, computer programmers, invest of their own time and effort to learn the [interface].” Based largely on that distinction – tied to the “capabilities” of the different types of code – Breyer reasons that “the declaring code is, if copyrightable at all, further than are most computer programs (such as the implementing code) from the core of copyright.”

The second factor the court considers is the “purpose and character of the use,” specifically the extent to which the copier “adds something new, with a further purpose or different character” that can be regarded as “transformative.” For example, the most famous of the court’s opinions on that question held that a parody of a Roy Orbison song was fair use because it “need[ed] to mimic an original to make its point.” The court emphasizes two points on that factor. The first is “Google’s use of the Sun Java [interface] … to expand the use and usefulness of Android-based smartphones,” which Breyer characterizes as “creat[ing] a new platform that could be readily used by programmers,” an activity he regards as “consistent with that creative ‘progress’ that is the basic constitutional objective of copyright itself.” The second is that Google “limited its use” of Java SE code to copying “only … as needed to include tasks that would be useful in smartphone programs,” and “as needed to allow programmers to call upon those tasks without discarding … a familiar programming language.” For the court, it is largely dispositive on that factor that Google “provided a new collection of tasks operating in a distinct and different computing environment.”  

The court next considers the “amount and substantiality” of the copied material. That factor largely involves a baseline problem. Eleven thousand lines of code is quite a bit of code, “virtually all the declaring code needed to call up hundreds of different tasks.” But it is only a tiny fraction (about 0.4%) of the 2.86 million lines of code in the relevant Java program. The court’s prior decisions emphasize the subjectivity of the substantiality determination, including a memorable case in which it was held unfair to “scoop” the publication of a tiny portion of Gerald Ford’s memoir because the copied portion included the “heart” of Ford’s “creative expression” (Ford’s explanation of why he pardoned President Richard Nixon). Here, the court concludes that “the better way to look at the numbers is to take into account the several million lines that Google did not copy,” largely because the Java SE interface “is inseparably bound to th[e] task-implementing lines” that Google did not copy. Waxing more abstract, Breyer emphasizes that “Google copied those lines not because of their creativity, their beauty, or even (in a sense) because of their purpose. It copied them because programmers had already learned to work with [Java SE], and it would have been difficult … to attract programmers to … Android … without them.” Because “the amount of copying was tethered to a valid, and transformative, purpose,” the “substantiality” factor should “weigh in favor of fair use” in this case.

The fourth and final factor is the most difficult one, the market effect of the copying. Breyer makes two general points. First, it is not at all clear that Java SE ever would have been successful in the smartphone market. Breyer suggests that Java software originally was suited to simpler products like the original Kindle and “feature” phones, but could not be adapted readily for touchscreen devices like modern smartphones and the Kindle Fire. From that perspective, Android should not be regarded as “a market substitute for Java’s software,” but rather as a “mobile operating stack [that is] a very different type of product.” Suggesting that Java-based “mobile phone business was declining, while the market increasingly demanded a new form of smartphone technology,” Breyer concludes that Google (and Android) are not responsible for that decline. Perhaps more importantly, the court worries that “to allow enforcement of Oracle’s copyright here would risk harm to the public,” because it “would make of the … declaring code a lock limiting the future creativity of new programs [to which] Oracle alone would hold the key.” Ultimately, for the court, that “lock would interfere with, not further, copyright’s basic creativity objectives.” Accordingly, the court is “convince[d]” that the last factor “weighs in favor of fair use.”

This brief post passes over much of Breyer’s opinion, and tells you nothing at all about the critique of Breyer’s analysis in the dissent of Justice Clarence Thomas (joined by Justice Samuel Alito), which Breyer graciously describes as “thoughtful.” Scholars and lower courts doubtless will mull its implications as they apply it to the never-ceasing tide of disputes over the limits on the reuse and redeployment of software code. I hope this brief description gives a flavor of what surely will be a landmark in copyright law for decades to come.

[Disclosure: Goldstein & Russell, P.C., whose attorneys contribute to SCOTUSblog in various capacities, is among counsel for Google in this case. The author of this article is not affiliated with the firm.]

Recommended Citation: Ronald Mann, Justices validate Google’s use of Java platform in Android software code, SCOTUSblog (Apr. 6, 2021, 2:09 PM), https://www.scotusblog.com/2021/04/justices-validate-googles-use-of-java-platform-in-android-software-code/