This morning, the Supreme Court heard oral arguments in Google v. Oracle. The practical implications of this case and the copyrightability of application programming interfaces (APIs) are significant because of the effects on competition and barriers to entry in the tech industry, as written by Pamela Samuelson and Charles Duan.
The policy implications of the case merit an entirely separate discussion, but based on the arguments, here are the three different bases for a ruling in this case and my impressions of each of them.
One: Standard of Review
This May, the Supreme Court surprised many followers of this case by requesting supplemental briefs on the issue of the Court of Appeals for the Federal Circuit’s (CAFC) use of de novo review in overturning the 2016 jury verdict that Google’s use of the APIs was fair. In doing so, CAFC decided to overturn the jury’s finding of fair use because a jury “is limited to determining disputed ‘historical facts,’ not inferences or conclusions to be drawn from those facts [therefore] all jury findings relating to fair use other than its implied findings of historical fact must, under governing Supreme Court and Ninth Circuit case law, be viewed as advisory only.” From this, CAFC ruled it should “assess all inferences to be drawn from the historical facts found by the jury and the ultimate question of fair use de novo.” Google of course disputes this, arguing that the jury verdict is a mix of fact and law and should have had more weight in CAFC’s decision.
Given the Court’s request, I was surprised that the standard of review and civil procedure played a minor role in the oral arguments, with only Gorsuch and Alito spending significant time discussing it.
While the relatively small amount of time spent discussing it doesn’t mean much in oral arguments, ruling on the standard of review issue gives the Supreme Court the ability to avoid some of the thornier issues of copyright law while falling back on established precedent. In Feltner v. Columbia Pictures Television, the Supreme Court ruled that the Seventh Amendment guaranteed a right to trial by jury in cases of copyright infringement. This was a unanimous decision written by Clarence Thomas and, oddly enough, argued by John Roberts before he was appointed to the court.
Based on my impression of the oral arguments, ruling based on standard of review will depend entirely on how comfortable the justices are with ruling on the idea that APIs and the declaring code are different from implementing code. If they are uncomfortable ruling on these grounds, then CAFC allows them to avoid this issue. If, on the other hand, the justices are comfortable with this differentiation (or lack thereof), then this leads to the second possible outcome…
Two: Eligibility for Copyright Protection
Should the Supreme Court decide not to kick the case back to the CAFC, then it would have to determine if the APIs are eligible for copyright protection in the first place. In an amicus brief, Niskanen Center joined Public Knowledge and R Street Institute in arguing that APIs specifically aren’t eligible for copyright protection. This is because unlike traditional pieces of computer code, the APIs are shorthand commands designed to ensure interoperability and familiarity for coders:
[R]eimplementation [of the kind Google engaged in] is ubiquitous, predates this case (and computing in general) by centuries, and is beneficial for the free flow of information. Naval flag signals, floriography, telegraphic codes, hospital codes, and countless other systems that translate ideas, phrases, and commands into symbols have been reimplemented throughout history to the benefit of communication. Progress would be severely limited if such reimplementation were restricted or not possible.
APIs are designed to be “shortcuts” that could, in fact, be re-written by any programmer in a different language. Avoiding the shortcut by using different names to perform the same functions–as Oracle has argued–would allow Google to escape any claims of infringement. But it would also break compatibility for millions of lines of existing Java software and thousands of skilled Java programmers. Writ large across the many industries that depend on APIs in the form of Internet standards and communications technology, it cannot be the case that copyright serves its constitutional purpose by eradicating the tremendous economic value of compatibility and interoperability, as Oracle would have copyright law do. [Emphasis added].
I want to point out the bolded section, as the fact that you could rewrite an API in a different language is important evidence for copyright eligibility. One of the most common arguments against Google’s reimplementation, is, in the words of Steven Tepp of George Washington University Law School, that “Google could have written its own declaring code in the Java programming language to perform the same functions without copying Sun and Oracle’s code.”
Sounds reasonable, but there’s a problem: Under current law, an unauthorized translation of a work is considered to be copyright infringement. But if translating is acceptable for the purposes of an API, the same way I could translate the Copyright Act into Spanish if I were so inclined, this implies that they are not protected by copyright. As Charles Duan wrote in Ars Technica, “implementing an API in another computer language is simply an act of translation, and translating a copyrighted work into another language is specifically known to be a copyright infringement.”
There is, however, a difference between the full text of the Copyright Act and the APIs. While a translation of the former isn’t infringement because laws aren’t eligible for copyright protection, a translation of the latter not being infringement would rely on the fact that the specific expressions embodied in the APIs are so tightly linked to the “idea…system [or] method of operation” that exclusive control of them would give exclusive control of the idea. Under past legal precedent and the current text of the Copyright Act, one cannot have control over an idea.
Similarly, when “compatibility [the basis of Google’s argument for reimplementation] requires that a particular code sequence be included in the component device to permit its use, the merger and scènes à faire doctrines generally preclude the code sequence from obtaining copyright protection.” The merger doctrine applies when an expression covers all of the ways it’s possible to express an idea, making the expression in question ineligible for copyright protection. Though related to the 102(b) issue, these are distinct legal questions and there was some confusion over which argument Google was making. Its arguments relied on both, even if merger was the one with the greatest focus.
However, there’s more than one way to write a given computer function and not every piece of code is a method of operation. The question at hand is whether APIs specifically should be treated like any other piece of code, and a great deal of the oral argument was spent searching for a metaphor that would adequately describe the difference. Justice Breyer found one that stuck, by analogizing the declaring code to the QWERTY keyboard. If the inventor of the QWERTY keyboard could claim copyright that layout, they would effectively have a monopoly on the typewriter market.
As Google’s attorney Thomas Goldstein pointed out, there is only one way to use the declaring code that is at issue to ensure the interoperability of the system for outside developers. It has been established that the developers have the right to use the declarations. For the declarations to work as developers expect them, Google’s Android has to use them as they exist, and writing new declarations would undermine this goal. It would be as difficult as someone writing a novel using a non-QWERTY keyboard. Possible? Of course. But that would be a significant barrier to entry created by control over a purely functional design.
Declaring codes are distinct in that “it tells [an] outside developer what to do…how to operate the computer program [which is] unlike any other code.” While Justice Kavanaugh compared the APIs to a song–which can only be expressed one way–using declaring code isn’t like copying a song because you like the one way the song expresses it. As we argued in our amicus brief, it’s a series of signals and commands which can be part of a larger work.
Oracle’s attorney Josh Rosenkranz and Deputy Solicitor General Malcolm Stewart, for their part, focused on the idea that the APIs in question are no different than any other computer code, which is obviously eligible for copyright protection. While one could fairly criticize the interoperability arguments as a policy argument (despite legal precedent to the contrary), arguments made about the need for copyright protection in general in the software industry run into not only that exact same problem, but also fly in the face of a rich history of reimplementation in the industry.
However, even if the Supreme Court finds that APIs are eligible for copyright protection, this still leaves one unanswered question…
Three: Fair Use
In its de novo review, CAFC determined that Google’s use of the APIs was not fair. In response to the four factors, the court found:
- On the purpose and character of the use: “the highly commercial and non-transformative nature of the use strongly support the conclusion that the first factor weighs against a finding of fair use.”
- On the nature of the copyrighted work: “Although it is clear that the 37 API packages at issue involved some level of creativity…reasonable jurors could have concluded that functional considerations were both substantial and important. Based on that assumed factual finding, we conclude that factor two favors a finding of fair use.”
- On the amount and substantiality of the work used: “Even assuming the jury accepted Google’s argument that it copied only a small portion of Java, no reasonable jury could conclude that what was copied was qualitatively insignificant, particularly when the material copied was important to the creation of the Android platform…the third factor is, at best, neutral in the fair use inquiry, and arguably weighs against such a finding.”
- On the effect of the use upon the potential market: “[U]nrestricted and widespread conduct of the sort engaged in by” Google would result in “a substantially adverse impact on the potential market for the original” and its derivatives…Accordingly, the fourth factor weighs heavily in favor of Oracle.”
CAFC found that only the second factor (the nature of the work) ruled in favor of fair use.
There is no set number of boxes to be ticked to find fair use (it’s a weighing test), but there are a few ways the Supreme Court could find in favor of fair use. For example, the Court could find that with respect to factor one, the reimplementation of the APIs into a different work for the sake of interoperability is transformative, even if the language of the APIs itself remains unchanged. The Court may also find that the number of packages and amount of code reimplemented (11,500 lines out of millions) is so small that it weighs in favor of fair use, rather than just being neutral.
For example, Thomas asked what a transformative use of code would look like, to which Oracle responded that use for the purposes of study would be acceptable.
Oracle instead analogized what Google did (taking a code used for desktop and adapting it to a smartphone) to taking a book and adapting it to a movie, an irrelevant comparison in this case. But, curiously, Stewart argued that interoperability was a relevant factor in determining fair use, something which–if true–bodes well for Google.
———
These are my initial impressions of the case. I don’t want to hazard a guess on the outcome, mostly because of how disparate the concerns of the justices are. Breyer, Kagan, and Sotomayor seem keen to rule in favor of Google on copyrightability, Alito and Thomas against on fair use and copyrightability grounds, but the rest are up in the air. (For excellent summaries via Twitter, I strongly recommend looking at the feeds of Sarah Burstein, Charles Duan, and Sarah Jeong.)
Loading...