The software industry issued a collective sigh of relief after this week’s Supreme Court decision in Google v. Oracle finding that fair use allowed Google’s reimplementation in Android of Java declaring code. The Supreme Court’s first fair use decision in over 25 years and first software copyright opinion ever no doubt will be carefully studied by law professors and copyright practitioners alike. Nonetheless, a few preliminary observations about the decision can be made. (See here for an overview of the case and here for the implications of the decision.)
1. The Supreme Court has the capacity to decide complex cases involving technology. When the Supreme Court agreed to hear Google’s petition, some questioned whether the Supreme Court would be able to comprehend the complicated computer programming questions at issue in this case. Would the Justices understand the difference between the implementing code and the declaring code in the Java application programming interface (“API”)? Would they appreciate the imperative Google felt for reimplementing the Java declaring code in Android? And could they anticipate the impact of their decision on competition in highly dynamic technology industries?
The majority opinion written by Justice Breyer reflects a mastery of the technical details. Any concerns about the Court’s ability to handle a case involving cutting-edge technology was misplaced. Moreover, two of the Justices appointed by President Trump had no difficulty rendering impartial justice by ruling against Oracle even though it was perhaps the highest-profile pro-Trump technology company. (Justice Barrett, appointed to the Court after the oral argument took place, did not participate in consideration of the case.)
2. The majority’s decision to “assume for argument’s sake” the protectability of the declaring code copied by Google and reach only the fair use of that copying probably reflected a compromise among six of the Justices to reach a consensus position. The majority justified passing over one of the two questions presented by Google by stating that under “the rapidly changing technological, economic, and business-related circumstances” of the case, it believed it “should not answer more than is necessary to resolve the parties’ dispute.”
Justice Thomas’ dissent, however, sharply criticized the Court for “inexplicably” and “wrongly sidestep[ing] the principal question that we were asked to answer: ‘Is declaring code protected by copyright?’” Indeed, it is somewhat odd that the majority would bypass this critical issue by assuming, “purely for argument’s sake, that the entire Sun Java API falls within the definition of what can be copyrighted.” The “rapidly changing technology” justification rings hollow. As Justice Thomas noted, rapid change is “a constant where computers are concerned.” A more likely explanation for this unusual choice is that the six Justices in the majority did not all agree that the declaring code was unprotectable. To avoid a fractured decision that could cause unnecessary confusion, the majority jumped over the protectability question and instead resolved the case on a theory they all could support: fair use.
3. The structure of the fair use decision reinforces the sense that at least some of the Justices thought that the declaring code fell outside the scope of copyright protection. Judicial opinions in fair use cases typically consider the four fair use factors in the order they appear in 17 U.S.C. §107: (1) the purpose and character of the use; (2) the nature of the copyrighted work; (3) the amount and substantiality of the portion used; (4) and the effect of the use on the market for or value of the copyrighted work. In the majority opinion, however, the second factor, the nature of the copyrighted work, appears first. This signals that the majority believes that the nature of the work is of heightened significance in this case.
Justice Thomas in his dissent remarked on this reordering, explaining that the majority “proceeds in this manner in order to create a distinction between declaring and implementing code that renders the former less worthy of protection than the latter.” And he was exactly right. Although the majority did discuss the nature of the copyrighted work—the Java API—it devoted much of its attention to distinguishing the declaring code from the implementing code.
Tellingly, its description of the declaring code strongly suggests that the declaring code is not protectable under copyright. “Like other computer programs,” the declaring code “is functional in nature.” But unlike other programs, “its use is inherently bound together with uncopyrightable ideas…” That sounds a lot like “merger” of idea and expression. Further, the declaring code’s “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 API’s system.” (Emphasis supplied.) Furthermore, the declaring code’s “value lies in its efforts to encourage programmers to learn and to use that system so that they will use (and continue to use) Sun-related implementing programs that Google did not copy.” (Emphasis supplied.) The use of the word “system” twice in two consecutive sentences is no accident. The opinion implies that the declaring code is an essential element of a system unprotected under 17 U.S.C. § 102(b). If that wasn’t clear enough, the opinion adds, “the declaring code is, if copyrightable at all, further than are most computer programs (such as implementing code) from the core of copyright.” (Emphasis supplied.)
4. The decision prevents the use of copyright to hinder interoperability, even though the decision addresses interoperability only indirectly. A recurring theme throughout the decade-long litigation has been the impact the case would have on software interoperability. Oracle, the Solicitor General, and the Federal Circuit argued that the case had nothing to do with interoperability because the Java and Android platforms were incompatible; an app written for the Java platform could not run on Android, and vice-versa. Google, the district court, and Google’s amici in the software industry, by contrast, argued that the declaring code was a form of interface between software elements: between the method calls familiar to Java programmers and implementing code that actually instructed the computer to perform the function. Reuse of the declaring code in Android made it easier for Java programmers to migrate their apps from the Java platform to Android. In other words, reuse of the declaring code enabled a degree of interoperability between the Java and Android platforms. If reuse of the declaring code infringed copyright, then established firms could use copyright to prevent new entrants from interoperating with their products.
The majority opinion carefully threaded its way between these two positions by centering its analysis on the Java programmer’s ability to use her skills in the new Android environment, rather than on the ability of Java apps to run in Android. In other words, the decision focused on the “interoperability” of computer programmers rather than computer programs.
The clearest indication of this focus on programmers, not programs, is when the majority called the Sun Java API a “user interface” because “it provides a way through which users (here the programmers) can ‘manipulate and control’ task performing computer programs ‘via a series of menu commands.’” The majority stated that the declaring code was “part of a user interface” and that Google “reimplemented a user interface.” Conversely, Google in its briefs referred to the declaring code as a “software interface.”
When explaining why Google’s use was transformative under the first fair use factor, the purpose and character of the use, the majority stressed that Google copied the Java API “only insofar as needed to allow programmers to call upon those tasks” that would be useful in smartphone programs “without discarding a portion of the familiar programming language and learning a new one.” The Court referred to evidence that “reimplementation of interfaces is necessary if programmers are to be able to use their acquired skills.” When discussing the third fair use factor, the amount and substantiality of the portion used, the Court explained that Google’s objective “was to permit programmers to make use of their knowledge and experience using the Sun Java API when they wrote new programs for smartphones with the Android platform.” The Court described the declaring code as “the key” Google needed “to unlock the programmers’ creative energies.” When examining the fourth fair use factor, the market effects of the use, the Court referred to the “programmers’ investment in learning the Sun Java API.” And in its conclusion, the majority held that Google’s copying of the declaring code was a fair use as a matter of law because it took “only what was needed to allow users to put their accrued talents to work in a new and transformative program.”
The decision reached its fair use conclusion without considering what the district court called the “degree of interoperability” between the Android and Java platforms. This may be because the record on this issue was insufficiently developed in the district court. Nonetheless, it is clear that the fair use argument would be at least as strong, if not stronger, if a firm sought to reimplement an interface for the purpose of achieving interoperability. The majority’s reasoning concerning the benefits of enabling programmers to transfer their skills to a new environment would also apply if the firm created an interoperable platform. Moreover, the programmers would be able to reuse significant amounts of code they had already written, thereby enabling them to generate additional revenue from a new market while freeing them to create entirely new programs rather than rewrite existing ones.
Furthermore, the majority’s fourth factor analysis would weigh heavily in favor of an interoperable product. The Court discounted Oracle’s potential loss of revenue deriving from users being locked into the Java SE environment. The Court observed that “when a new interface, like an API or a spreadsheet program, first comes on the market, it may attract new users because of its expressive qualities.” However, as time passes, “it may be valuable for a different reason, namely, because users, including programmers, are just used to it. They have already learned how to work with it.” The Court added that “we have no reason to believe that the Copyright Act seeks to protect third parties’ investment in learning how to operate the created work.” The Court went on to explain that enforcing a copyright in an interface “would risk harm to the public.” The majority acknowledged that lock-in could “prove highly profitable” to “firms holding a copyright in computer interfaces” but “those profits could well flow from creative improvements, new applications, and new uses developed by users who have learned to work with that interface.” The Court concluded that a lock created by copyright protection for interfaces “would interfere with, not further, copyright’s basic creativity objectives.”
Importantly, in this discussion, the Court referred to the adverse consequences of copyright protection for computer interfaces generally, not just user interfaces such as the Java API. Additionally, the majority cited with approval four circuit court decisions where the courts held that copyright did not extend to elements necessary for interoperability: Lotus v. Borland, Sony v. Connectix, Sega v. Accolade, and Lexmark v. Static Control Components. The Court thus suggested not only that fair use permitted the reuse of program elements essential to achieving interoperability, but that such elements might not be protectable in the first place.
5. The majority’s opinion included explanations of copyright and fair use that will guide decisions unrelated to software. It acknowledged that “copyright has negative features. Protection can raise costs to consumers…. And the exclusive rights it awards can sometimes stand in the way of others exercising their own creative powers.”
In a similar vein, the Court quoted Thomas Macaulay’s statement that copyright is a “tax on readers for the purpose of giving a bounty to writers.” The Court added that “Congress, weighing advantages and disadvantages, will determine the more specific nature of the tax, its boundaries and conditions, the existence of exceptions and exemptions.”
The Court quoted Judge Boudin’s statement in his concurring opinion in Lotus v. Borland that “applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.” At the same time, it interpreted the CONTU Report as concluding that “copyright’s existing doctrines (e.g., fair use), applied by courts on a case-by-case basis, could prevent holders from using copyright to stifle innovation.” The Court observed that
fair use can play an important role in determining the lawful scope of a computer program copyright, such as the copyright at issue here. It can help to distinguish among technologies. It can distinguish between expressive and functional features of computer code where those features are mixed. It can focus on the legitimate need to provide incentives to produce copyrighted material while examining the extent to which yet further protection creates unrelated or illegitimate harms in other markets or to the development of other products. In a word, it can carry out its basic purpose of providing a context-based check that can help to keep a copyright monopoly within its lawful bounds.