First published in Redline on 31 July 18. Copyright 2018 Sean Hogle, licensed under CC-BY-2.0. This article is reposted here in light of the US Supreme Court’s decision (15 Nov 19) to grant certiorari (ie agree to hold a review) in the Oracle v. Google appeal, a surprising and welcome development.

The Court of Appeals for the Federal Circuit’s long-awaited ruling in the appeal of the Oracle v. Google fair use jury verdict has arrived. Oracle America Inc. v. Google LLC (Fed. Cir. 2018) (“Oracle II”).  The court’s second opinion in this legal clash of tech titans is the latest culmination of nine years of furiously fought litigation. Once again, Google lost this round; the Federal Circuit tossed out the jury’s verdict in favor of Google on its fair use defense to Oracle’s copyright infringement claim relating to Java application programming interfaces (APIs).

A detailed summary of the facts and procedural history of the case can be found here. In short, Google replicated 37 of Oracle’s Java APIs for use in Google’s Android operating system for smartphones, in order to enable easier and faster application development in a popular programming language, Java. By using the same declarations as are used in the Java programming language, Google made developing Android applications dramatically easier and faster, and in the process appreciably boosted the popularity of the Java programming language and unleashed a massive proliferation of Android applications in short order. Oracle didn’t see it that way, and since 2010 has been pursuing Google for patent and copyright infringement, resulting in two jury verdicts and two appeals.

This post analyzes the latest ruling of the Federal Circuit (CAFC) and offers a critique of its reasoning, focusing on whether Google’s use of the Java APIs was “transformative”, a crucial factor in the fair use inquiry. The inexorable logic of the CAFC’s decision is that the use of APIs for interoperability purposes can never be fair use as a matter of law. Such a ruling cannot be squared with the law of the Ninth Circuit, which the Federal Circuit was bound to apply, and threatens software competition and innovation.

This is the second appeal in the case. In the first round, the district court (Judge Alsup), ruled that the APIs at issue were not copyrightable. Oracle America Inc. v. Google Inc. (ND Cal. 2012). On appeal, the CAFC disagreed, overruling Judge Alsup in an opinion that was remarkable for its factual and legal flaws. The appellate court’s API copyrightability ruling was, essentially, that APIs are always copyrightable as a matter of law, so long as they are expressed in a “creative” and “original” manner. “[W]e conclude that a set of commands … may contain expression that is eligible for copyright protection,” the Federal Circuit proclaimed, “as long as the author had multiple ways to express the underlying idea.” In so deciding, the CAFC effectively nullified section 102(b)’s “process, system, or method of operation” copyrightability exclusion as it applies to software.

Congress added Section 102(b) to the US Copyright Act in 1976 specifically because of heightened concerns about extending copyright protection to software, a means of controlling computer functionality. The CAFC failed to acknowledge the historical context of Section 102(b), and failed to realize that Section 102(b) defines the scope of copyright protection for software.

In its 2014 decision reversing the copyrightability determination, Oracle America Inc. v. Google LLC (Fed. Cir. 2014) (“Oracle I”), the appellate court nevertheless recognized the potential viability of Google’s fair use defense on interoperability grounds, and consequently remanded the case to the district court for a new trial. “[W]hile we have concluded that it was error for the trial court to focus unduly on the functional aspects of the packages, and on Google’s competitive desire to achieve commercial ‘interoperability’ when deciding whether Oracle’s API packages are entitled to copyright protection, we expressly noted that these factors may be relevant to a fair use analysis.“ Oracle I (emphasis added).

On remand, a jury of ten people (eight women, two men) did in fact find these factors relevant, and ultimately ruled in Google’s favor after deliberating for three days and hearing two weeks’ worth of evidence. The jury heard extensive testimony concerning Google’s interoperability arguments, market impact, and developer reaction. The jury’s verdict was unanimous.

To grasp the significance of the verdict, it’s helpful to recite Judge Alsup in his opinion denying Oracle’s post-trial motion to set it aside:

Oracle has portrayed the Java programming language as distinct from the Java API library, insisting that only the language itself was free for all to use. Turns out, however, that in order to write at all in the Java programming language, 62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise, the language itself will fail. The 62 “necessary” classes are mixed with “unnecessary” ones in the Java API library and it takes experts to comb them out. As a result, Oracle has now stipulated before the jury that it was fair to use the 62 “necessary” classes given that the Java programming language itself was free and open to use without a license ….

Oracle America Inc. v. Google Inc., Order Denying Rule 50 Motions (June 2016) (“Order”) (emphasis added).

Oracle’s appeal of the pro-Google fair use jury verdict was heard by the same three-judge panel that heard the 2014 reversal of the district court’s decision that copyright protection does not extend to the Java APIs in question. In a ruling that surprised many, the Federal Circuit completely disregarded the jury’s verdict, flatly contradicted its 2014 ruling, and held that Google’s use of the Java APIs was not fair as a matter of law.

The Federal Circuit’s fair use decision is flawed and harmful in many respects. Others have already ably addressed the shocking repudiation of a Silicon Valley-sophisticated jury’s well-supported evidentiary findings, and the rather obvious results-oriented nature of the court’s decision. Here’s an illustrative example, from the TechDirt blog, of the reaction the court’s decision engendered, particularly its complete 180-degree reversal from its earlier 2014 opinion:

In 2014, [the CAFC] … made it clear that a new trial was necessary on fair use because of “the limit of our appellate function” (to make determinations on matters of fact). But here, once the jury came back with a result that the same judges disliked, it miraculously started arguing that, well, really, we can review the jury’s decision because we can and because juries are “advisory only.” …

This clearly is the same three judge panel completely moving the goalposts from their earlier decision in the same case because they don’t like the outcome.

CAFC in Oracle v. Google, 2014
“We cannot say that there are no material facts in dispute on the question of whether Google’s use is “transformative,” even under a correct reading of the law.”

CAFC in Oracle v. Google, 2018
“Google’s use of the API packages is not transformative as a matter of law…”

….

CAFC in Oracle v. Google, 2014
“[R]easonable jurors might find that [the functional aspects of an API] are relevant to Google’s fair use defense under the second and third factors of the inquiry.”

CAFC in Oracle v. Google, 2018
“Although it is clear that the 37 API packages at issue involved some level of creativity–and no reasonable jury could disagree with that conclusion–reasonable jurors could have concluded that functional considerations were both substantial and important…. The Ninth Circuit has recognized, however, that this second factor ‘typically has not been terribly significant in the overall fair use balancing.’”

Another fun one. In 2014, the court pointed out that perhaps the 2nd factor (the nature of the work — in this case, the fact that it’s an API that is functional rather than expressive) could weigh heavily on the fair use analysis. In 2018 when the jury did exactly what the CAFC suggested it might, but which the CAFC obviously hoped it would not, it suddenly poo-poos the idea that the 2nd factor really matters at all.

Mike Masnik, TechDirt, The Federal Circuit’s Judicial Hypocrisy In Overturning Jury Concerning Java API Fair Use Question (emphasis in original).

As egregious as that was, by far the worst aspect of the court’s ruling is that its opinion and its logic lead regrettably to the conclusion that replicating APIs for interoperability purposes can never be fair use, as a matter of law.

For use to be considered fair, the most significant factor is whether the use in question is “transformative”, meaning that it “added something new, with a further purpose or character, altering the first with new expression, meaning, or message.” In the words of the US Supreme Court, transformative works “lie at the heart of the fair use doctrine’s guarantee of breathing space within the confines of copyright, and the more transformative the new work, the less will be the significance of other factors, like commercialism, that may weigh against a finding of fair use.” Campbell v. Acuff-Rose Music Inc. (US S Ct 1994).

The Federal Circuit held that Google’s use of the Java APIs was not transformative as a matter of law for the following four reasons:

Google’s use of the API packages is not transformative as a matter of law because: (1) it does not fit within the uses listed in the preamble to § 107; (2) the purpose of the API packages in Android is the same as the purpose of the packages in the Java platform; (3) Google made no alteration to the expressive content or message of the copyrighted material; and (4) smartphones were not a new context.

Each reason will be addressed in turn.

“Not in the preambles list”

With respect to the first reason given, the list of permissible purposes in the preamble to the fair use section of the Copyright Act (17 USC § 107) consists of “criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research.” Interoperability is not mentioned here, admittedly; but it’s a non-exhaustive list (the list is prefaced with, “the fair use of a copyrighted work … for purposes such as ….”). Under such logic, Ninth Circuit precedent (which the Federal Circuit was bound to apply in this case) would be otherwise. See Sega Enterprises Ltd. v. Accolade, Inc. (9th Cir. 1992) (intermediate copying as an integral part of reverse engineering is fair use if the point of that effort is to discover the unprotected interfaces needed for compatibility); Sony Computer Entertainment, Inc. v. Connectix Corp. (9th Cir. 2000) (“Connectix’s intermediate copying and use of Sony’s copyrighted BIOS was a fair use for the purpose of gaining access to the unprotected elements of Sony’s software.”).

The CAFC did not, in fairness, rely solely on the fact that Google’s use failed to fit neatly in the section 107 list. In rejecting Google’s arguments on the transformative nature of Android, the court sniffed that Google’s achievement was not even “modestly” transformative, and dismissively characterized Google’s actions as, simply, “copy code verbatim to attract programmers to Google’s new and incompatible platform.” (quotations omitted).

As noted by others, the CAFC seems unable to distinguish between code and APIs. See Mike Masnik, TechDirt, Insanity Wins As Appeals Court Overturns Google’s Fair Use Victory For Java APIs (“CAFC once again shows that it still doesn’t understand why APIs and code are not the same thing ….”). Undisputedly, the Android platform’s use of the Java APIs was sufficient to enable a non-trivial degree of cross-platform compatibility at the developer level. Java applications can easily be migrated to Android, and vice versa.

This fact however was lost on the court. As was evident in the 2014 decision as well, the CAFC’s apparent interoperability demands are absurd; they expected Google to magically render applications written for a platform originally developed for desktop computers (Java) to run perfectly without alteration on a platform for mobile devices (Android). Because Google couldn’t achieve the impossible, interoperability imperatives fell on deaf ears in both section 102(b) and fair use CAFC analyses. What’s more, in neither the 2014 or the 2018 opinion does the Federal Circuit deign to hint as to what its decision would have been if perfect compatibility had in fact been achieved. The bar is left guessing as to how or to what extent compatibility is required or even relevant.

“Purposes are the same in both Android and Java”

Regarding the second reason, the Federal Circuit ruled that Google’s use of the APIs mirrored that of Oracle’s use, in that both are used as declarations for software functionality. Where the use “is for the same intrinsic purpose as [the original copyright holder’s],” the court noted, ”such use seriously weakens a claimed fair use,” citing for this proposition cases that had nothing to do with software, APIs, or compatibility.

Of course, the entire point of the exercise for Google was to use the identical declarations as Oracle used to mitigate development incompatibilities. As Judge Alsup wrote in his opinion denying Oracle’s motion to set aside the jury verdict:

It should go without saying (but it must be said anyway) that, of course, the words copied will always be the same (or virtually so) in a copyright case — otherwise there can be no copyright problem in the first place. And, of course, the copied declarations serve the same function in both works, for by definition, declaring code in the Java programming language serves the specific definitional purposes explained above. If this were enough to defeat fair use, it would be impossible ever to duplicate declaring code as fair use and presumably the Federal Circuit would have disallowed this factor on the first appeal rather than remanding for a jury trial.

Order (emphasis added).

“Google made no alteration to Oracle’s APIs”

The court’s third rationale for overruling the jury’s transformation verdict is that Google made no alteration to the APIs, leaving intact the APIs’ “expressive content or message”. In the words of the CAFC: “While Google’s use could have been transformative if it had copied the APIs for some other purpose—such as teaching how to design an API—merely copying the material and moving it from one platform to another without alteration is not transformative.”

Google adopted the Java APIs in order to maintain a target level of compatibility between the Android development platform and the Java development platform, a move that has boosted the popularity of the Java programming language more than anything Oracle has ever done. Google was required to use the 37 Java APIs in question verbatim in order fulfill the entire purpose of the enterprise. The declarations must be the same to achieve the same functionality.

“Smartphones are not a new context”

The fourth factor relates to Google’s use of the Java APIs for Android-based smartphones as a new context. The court simply noted that the Java platform had already been implemented in smartphones, and that a “mere change in format (e.g., from desktop and laptop computers to smartphones and tablets)” is not transformative.

In so holding, the court casually tossed aside the considerable evidence the jury relied on in support of its verdict; namely, that previous efforts at porting Java to mobile operating systems had not proven particularly attractive to application developers, and that Google had overcome many previously daunting technical hurdles to enable widespread Java application development on a mobile device platform.

As one prominent practitioner observed, “The court overlooked the evidence that Android, unlike Java, was designed to operate on smartphones, and its features were optimized to function in that confined environment. When dealing with functional works, a court should treat optimization to function in a different environment as a new context.” Jonathan Band, Project Disco, The Federal Circuit Blows it Again in Oracle v. Google.

Ninth Circuit Precedent

The facts of Sega Enterprises Ltd. v. Accolade, Inc. (9th Cir. 1992) should be familiar to followers of the Oracle v. Google proceedings. In the early nineties, Sega manufactured video game consoles and game cartridges that could be used only with the Sega console. Sega licensed the code necessary to produce Sega-compatible game cartridges to game publishers. Accolade, an independent game publisher, attempted to negotiate a license with Sega, but could not accept Sega’s demand that Sega be the exclusive manufacturer of all games produced by Accolade. Accolade therefore reverse engineered the Sega console and game cartridges in order to discover the “interface specifications”—that is, the APIs or, in the terminology of the Ninth Circuit’s opinion, “header files”—that enabled Accolade’s Mac and PC games to run on—that is, interoperate with—the Sega console platform. Intermediate copying as an integral part of reverse engineering, the Sega court held, is not actionable and is fair use if the point of that effort is to discover the interfaces needed for compatibility. (The more recent Sony Computer Entertainment, Inc. v. Connectix Corp. (9th Cir. 2000)  decision is in accord. “Connectix’s intermediate copying and use of Sony’s copyrighted BIOS was a fair use for the purpose of gaining access to the unprotected elements of Sony’s software.” Notably, the fact that Connectix failed to achieve perfect compatibility was not material.)

One would have expected that the CAFC would attempt to distinguish or at least explain away the Sega decision, given that the court was bound to apply Ninth Circuit law. Accolade’s actions were quite similar to those of Google: both companies replicated interfaces—ie APIs—in order to achieve some level of interoperability: between the Mac/PC platform and the Sega platform, in the case of Accolade, and between the Java platform and the Android platform, in the case of Google. In both cases, a target level of compatibility was achieved. Accolade copied the Sega APIs in the same way that Google has copied the Java APIs, and that use was held to be fair under binding Ninth Circuit precedent. Charitably, it’s difficult to square the CAFC’s holding with Sega.

And yet, in its opinion, the Federal Circuit cited the Sega decision only twice; once for the proposition that, “[T]he 1980 amendments to the Copyright Act unambiguously extended copyright protection to computer programs,” and again for the proposition that, “some uses can be fair.”

___

Just as with its 2014 decision, the CAFC failed to understand the implications of Google’s conduct and the extent of compatibility achieved at the developer level, and as a result, use of interfaces can never be held to be fair use—unless the Ninth Circuit steps in. Copyright protection for APIs, even for content that is expressive, original or creative, must be denied if that same content constitutes nothing more than a description and classification of functionality.

The software industry, and indeed every industry that relies on software, has thrived for decades without the encumbrances of proprietary claims over APIs. Because the Federal Circuit’s decision destroys the balance between copyrightable expression and uncopyrightable ideas in software, it threatens competition and innovation. The Ninth Circuit [OR THE US SUPREME COURT: CERT GRANTED 15 NOV 19.] should repudiate it at the earliest opportunity.

______________________________________

Sean spent part of his career as Assistant General Counsel at Sun Microsystems, responsible for Java platform licensing and alliances in the Asia-Pacific region as an expat in Tokyo. The views expressed in this article are Sean’s alone and do not necessarily represent the positions of Sean’s former employers, law firm or clients.