What the heck does the Google vs. Oracle decision mean?

Few of the Supreme Court Justices seemed to understand what an API is or does, but their decision was a victory shout for software developers of all kinds, including open source developers.

What the heck does the Google vs. Oracle decision mean?
Getty Images

You can be forgiven if you’re not 100 percent certain what the US Supreme Court ruled in its Google vs. Oracle decision. Yes, we know that “Google won” — or, as Justice Stephen Breyer wrote, “Google’s copying [of the Java API] did not violate the copyright law.” This is true, but goes only so far. Google, after all, had gone to court with two big arguments: one, that APIs aren’t copyrightable and, two, that even if APIs are copyrightable, Google’s use of the Java API to develop Android constituted fair use.

The US Supreme Court sidestepped the first question, arguably the more important of the two, with Breyer writing, “Given the rapidly changing technological, economic, and business-related circumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute.” That’s better than what the world would have looked like had the Court sided with Oracle, which would have “threaten[ed] disastrous consequences for innovation,” as Microsoft offered in its amicus brief.

Still, we’re left with an industry where APIs might or might not be copyrightable. The considerable solace, however, is that courts have been given the nod to take a generous view on fair use as related to APIs and interoperability, one that makes developer utility central to the doctrine of fair use.

A world of copyrightable APIs...

Last year Hannu Valtonen outlined all that could go wrong if APIs were deemed to be copyrightable. Developers, quite simply, would have to unlearn decades of common development practices, while business interests could set up toll gates on their APIs to monetize them. It would also become dramatically harder to achieve compatibility across products, entrenching big, corporate interests.

In a word, it would be terrible.

Yet we’re not actually any farther away from this potential future today than we were before the US Supreme Court ruled, because they ducked the issue, as Justice Clarence Thomas fired off in his dissent. (“By skipping over the copyrightability question, the majority disregards half the relevant statutory text and distorts its fair-use analysis.”) I don’t blame the Justices for skipping that question, because based on the questions they’d been asking the counsel for both parties, it seems likely that few of them (Justice Breyer excepted) seemed to really understand what an API is or does. Digging into the copyrightability question would perhaps have required them to understand the function of APIs better than they were capable of.

So we’re left with the same uncertainty about copyright and APIs as before, though with the silver lining that the Court expressly did not say that APIs can be copyrighted. This might give support to previous appellate rulings that skewed against copyrightability, as Timothy Lee points out.

It also made it clear that copying APIs for the purpose of interoperability is pretty clearly fair use, even while leaving murky just how “fair” that use would be if the product making the API calls is directly competitive... or an open source version of the proprietary product.

Wither open source?

This is an area where some confusion persists, at least over at The Wall Street Journal. “A Supreme Court ruling that sided with Alphabet Inc.’s Google in its 10-year legal battle with Oracle Corp. reaffirms the business model behind open source software—sharing bits of computer code for free, experts said,” wrote Angus Loten. I’m not sure the Court’s decision did anything of the sort, and I’m very much in favor of anything that furthers the cause of open source software.

Loten, for example, cites Forrester analyst David Mooter, who argues that “a decision in Oracle’s favor would have exposed open source software makers to copyright trolls threatening lawsuits over similarities between competing software codes.” This is true of all developers, not just open source developers. And, in fact, it might be less true of open source developers these days, who have tended to be the real innovators over the last decade, not imitators. Open source software as varied as Kubernetes, PyTorch, Apache Kafka, and Redis isn’t at serious risk of being faulted for copyright infringement. This is all state-of-the-art stuff, not copycat code.

If anything, however, the Court’s decision did center on the importance of developers of all kinds, open source or otherwise. Instead of focusing on the owner of the code that a developer calls through an API, the Court chose to focus on the value of those developers. This is a big deal. The Court reached its decision by holding “Google’s limited copying of the API is a transformative use” because “Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language.”

More bluntly, the majority opinion went on, “Google wanted millions of programmers, familiar with Java, to be able easily to work with its new Android platform, [so] it also copied roughly 11,500 lines of code from the Java SE program.”

This is a victory shout for developers of all kinds, including open source developers. While it would have been great for the Court to stamp out the silly notion that APIs can be copyrighted, at least the Court expanded the definition of fair use in a way to take into account what is good for developers to build great software. This will help all developers, including those that choose to apply open source licenses to their code.

Copyright © 2021 IDG Communications, Inc.