Google v. Oracle - The Final Shoe Drops

The Supreme Court ruled yesterday in Google v. Oracle that Google did not infringe Oracle's copyright in its APIs by virtue of fair use. The vote was 6-2, with Justice Breyer writing for the Court, and Justices Thomas and Alito dissenting. 

The opinion was straightforward and went to great lengths to attempt to explain the technology at issue. I thought it did a decent job of it (definitely more Godot than Guffman), even as the opinion continued to struggle for a good analogy. The Court adopted the file cabinet/drawer/folder analogy presented in Google's brief, which I thought was a terrible analogy...so I guess there's no accounting for taste (or winning advocacy). The court's fair use analysis was influenced by Judge Boudin's concurrence in Lotus v. Borland, though that concurrence didn't actually call it fair use, but instead "privileged use."

Others have and will surely write about the fair use aspects and what this means for software APIs. Contrary to Oracle's ridiculous and vitriolic press statement yesterday, this case will likely not change the way anyone in the industry behaves in the least. APIs have been used and reused for decades, and will continue to be. And contrary to being a barrier to entry, reuse of APIs allows for competitive inroads and entry, including by Oracle, in its mimicry of Amazon's AWS API. (Indeed, the hubris of Oracle's statement in light of its implementation of another company's API is stunning, assuming it was unlicensed-I've been unable to verify one way or the other.)  

The opinion also has some nuggets for other fair use - discussion of transformation and art, definition of markets for determining harm, another reaffirmation of Campbell v. Acuff-Rose Music, fair use as a mixed question of law and fact (something I discussed in a prior blog post), and so forth.

Instead, I will focus on my hobby horse-whether the APIs are copyrighted, and if so how we get to non-infringement. The Supreme Court explicitly decided that the copyrightability of APIs is a third-rail and did not attempt to touch the issue. There are two ways to read the tea leaves. First, perhaps a majority of the court thought they were uncopyrightable, but feared the effects of saying so. Second (and my guess), perhaps a majority of the court (or a 4-4 split) thought that they were copyrightable, but fair use was an acceptable compromise. The second possibility is why I wrote and submitted my amicus brief, which was intended to give a path to non-infringement even if the APIs were copyrightable.

Alas, the court did not buy into the abstraction/filtration argument I made, which I believe was doctrinally appropriate, nor did the brief get a cite, as many that discussed the importance of APIs did. However, in a sense, the court adopted the methodology I suggested. From my brief:

But the copyrightability of an entire work does not answer the question of whether any particular portion of it, if used by another, is infringing. That analysis requires determining whether the defendant has taken too much expression and not ideas, systems, methods of operation, or the like. And such a determination cannot be made outside of the infringement analysis. Any functionally required aspects—including any expression necessary to practice the idea—should be removed from the comparison. 

What remains should then be compared. The advantage of this approach is that it recognizes that while entire software programs may be copyrightable in some contexts, their pieces might not be infringed in others. There need be no zero-sum game, but only a recognition that the scope of copyright depends, as it always has, on the accused’s use of the copyrighted work. 

...

[T]he Court need not decide whether any part of Oracle’s code is copyrightable standing alone. It should only determine that the scope of its copyright in the Java source code cannot extend to infringement through the reuse of declaring functions necessary to create a compiler or interpreter that accepts the same commands and parameter names to allow programmers to use the Java programming language.

The primary pushback on this argument that I received from smart colleagues asked this question: why should context matter in the infringement analysis? Justice Thomas's dissent is replete with this same concern. My answer was always the same - because use in a functional context may be a use of the idea/method, whereas use in a different context might not be.

But Justice Breyer has sidestepped this question to essentially reach the same result using fair use. The one place where we can be sure that context matters is fair use. The nature and character of the use is one of the factors, after all. The Court's analysis tracks many of the same issues in my brief - the functionality of the APIs, their use as a de facto standard, switching costs, etc.

And so the Court's final resolution is not that far off from what I had asked. Rather than excluding the APIs from infringement by filtering them out, the Court would instead exclude them from infringement under a fair use analysis that considers many of the same factors. I can live with this solution--way back in 1999, I published a paper that argued that "courts have been able to determine efficient economic outcomes based on the cases before them, but they have been unable to settle on a rule that definitely determines how much reuse to allow in each case." The article lays out a variety of economic factors that predict how cases come out, and you'll be shocked to find out that they favor Google in this case (e.g. switching costs, de facto standards, lack of slavish copying of the implementation, no breach of an underlying economic duty, public benefits of compatibility). Perhaps that's a reason this case has stuck in my craw for so long: it's about the only one that didn't fit with my 20+ year old model.

Despite my doctrinal sanguinity, the downside of the court's approach is that it might still lead to framing issues in the future. Litigants might still be subjected to juries asked to simply decide whether the APIs were used (for infringement) and then hope to rely on fair use as a defense. Then again, a judicial fair use inquiry might keep the question from ever getting to a jury, which is basically the same result I've advocated. But this case went to a jury, by appellate order, and it's unclear that it should have. It was certainly costly. However, the strong language of this opinion may apply the next time, as in the case I recently blogged about with control codes.

The end is near for my Oracle and Google blogging, a 9 year expedition. But I do have one more in me, a more technical post in a week or so about the so-called 170 lines of code that supposedly all that are necessary to implement Java.