In a surprising decision that should terrify software developers, the Federal Circuit held today that Google’s use in its Android mobile operating system of Java API labels infringed Oracle’s copyright. Rejecting the jury verdict, the district court’s holding, and established law, the appellate court held that Google’s use was not a fair use.
This case should never have reached this stage. The works at the heart of the case are Java API labels that, as Google (and EFF) argued, should not even be eligible for copyright protection. Judge Alsup, who demonstrated some proficiency with programming Java in the first leg of the case, came to the same conclusion. But then it went to the Federal Circuit on appeal. The Federal Circuit, which usually focuses on patent issues, had jurisdiction because Oracle’s lawsuit originally contained a patent claim. Because the case was litigated in the Northern District of California, however, the Federal Circuit was supposed to apply Ninth Circuit law. Instead, it misread that law, reversed Judge Alsup’s ruling, and sent everyone back to San Francisco to litigate the question of whether Google’s use was a fair use.
Here, again, the Ninth Circuit generally protects innovation by recognizing that copying of a functional work, like an API, is often necessary and appropriate in order to make something new. Consistent with that longstanding principle, when the jury was asked to evaluate the facts and apply the applicable legal standard, it found that Google’s use was fair.
Having gone to the trouble of sending this case to a jury, you might think the Federal Circuit would respect the jury’s decision. It did not. In the court’s view, the jury’s finding was simply advisory and incorrect as a matter of law.
The Federal Circuit has upended decades of software industry practice and created legal uncertainty that will chill innovation.
Turning to the first fair use factor, the purpose and character of the use, the court found that Google’s use was commercial (true) but also that it was not transformative. Google argued that it took select bits of API code and then wrote its own implementation, putting the code into a new and different context—smartphones—and creating new functionality. Not good enough, said the Federal Circuit: Google was using the APIs as APIs, so its purpose was the same as Oracle’s. On this theory, few if any uses of functional works could ever be found to be transformative—the whole purpose of using them is for their functionality.
Not surprisingly, the court held that factor two, the nature of the work, favored Google. Where, as here, the “works” in question are more functional than expressive, they should receive only the thinnest copyright protection. What was surprising, though, is that the court gave short shrift to this factor. In many cases, the nature of the work does not weigh heavily one way or the other, but here the functionality of the works was a core issue in the case and a major focus of the trial.
On the third factor, the amount used, the court held that Google copied far more lines of code than necessary, that the amount copied was “qualitatively []significant,” and that no jury could have reasonably found otherwise, “particularly when the material copied was important to the creation of the Android platform.” Here, the court is pursuing a species of the “heart of the work” doctrine, which says that even a small taking may be unfair if it is the most important aspect of the original work (e.g., the part of a memoir where a president admits he lied under oath). But the analysis doesn’t work well here, where we are talking about a functional work and the central purpose of the fair use was to deploy that functionality.
Finally, the court held that any reasonable jury would have concluded that Google had harmed the potential smartphone market for the APIs given the evidence that such a market existed and the Oracle might have wanted to enter it. The jury heard conflicting evidence about Oracle’s efforts to enter this market, but the Federal Circuit now insists that only one conclusion about market harm can be drawn—and that the jury, which actually heard the evidence, got it wrong.
Attempting to soften the blow, the court finally observes that copying code could be a fair use—just not here. That will be cold comfort to the millions of software developers who just entered a whole new world of dramatic legal uncertainty.
Part of the problem is an artifact of court procedure. The Ninth Circuit could, and hopefully will, reiterate its longstanding opinions protecting innovative fair uses if the opportunity arises. But a plaintiff can ensure they wind up before the Federal Circuit instead by simply tacking on a patent claim. Even if the claim is weak and easily disposed of, as it was in this case, it is enough to give the Federal Circuit appellate jurisdiction. What plaintiff wouldn’t prefer a playing field slanted so dramatically in their favor?
This case has already cast a long legal shadow over the entire world of software development. Defending fair use takes time, money, and lawyers. Thanks to the outrageous penalties associated with copyright infringement, it comes with substantial risk. Wedging a layer of copyright permissions culture into API compatibility comes with unknowable costs, too: how many developers will abandon ideas for competitive software because the legal risks are too great? How many investors will fear to support them?
Today’s decision takes that bad situation and makes it much, much worse. The Federal Circuit has upended decades of software industry practice and created legal uncertainty that will chill innovation. We hope Google takes this to the Supreme Court so that the justices can clean up yet another Federal Circuit mess.
