The Supreme Court has now come out with its decision in the long-running Google v. Oracle case. To take a deeper dive, we’ve invited David O’Neill, CEO of APIMetrics to help us analyze the true impact of the decision.
First, some background: Oracle owns the copyright in Java SE, a computer program that uses the Java computer programming language, which is used by millions of computer programmers around the world. Google developed the Android platform specifically for smartphones. To make that platform more easily usable by programmers already familiar with Java, Google copied roughly 11,500 lines of code from the Java SE program that are part of a tool called the Application Programming Interface (API). In 2010, Oracle sued Google for copying Oracle’s APIs.
And what are APIs? An API is a standard package of computer code that lets one program interface with another program or hardware. It is essentially a documented definition on how you do a thing…think of it like a recipe. The API could be a recipe for a particular dish—let’s say it’s French fries. Programmers use APIs to call up that particular recipe—a dozen kitchens could take a potato, cut it into strips and fry it, and end up with a dozen different end products. The “magic” for want of a better word isn’t in the concept behind cutting a potato up and frying it; it’s how you cut it, how you treat it after cutting, what you fry it in and for how long, and how you season and present it. So if you want saltier fries, you use one API; if you want crisper fries, you use a different API. But the API is only making it easier to add fries to the plate by instructing the chef what you want; it is not a restaurant by itself.
The concept of using APIs has been around for over half a century in computer programming, and is now ubiquitous. It is hard to overstate how APIs have changed modern software development, especially around Cloud APIs—there essentially isn’t a single solution people consume over the internet that doesn’t, at some stage, have APIs in the process. If we look at some of the major sectors like healthcare and banking, process transformation is all being driven by APIs. The development of the ubiquitous API has meant that engineers can quickly build apps, websites, in-car services, and a host of other products from the same set of APIs without having to write something new every time.
Turning back to the litigation between Oracle and Google, in the first trial, a jury found that Google infringed Oracle’s code, but the trial court judge held that APIs constitute a “system or method of operation” that could not be copyrighted, and so vacated the verdict. The Federal Circuit reversed, finding that the declaring code and the structure, sequence, and organization of the Java API packages were entitled to copyright protection. Google petitioned for Supreme Court review then, but the Supreme Court declined to review that decision.
The next trial decided whether Google’s use of Oracle’s APIs was nonetheless “fair use.” A jury found that Google’s use was protected fair use, and Oracle again appealed to the Federal Circuit. As we reported on this blog previously, the Federal Circuit held that Google’s use was not fair and vacated the jury’s verdict. We predicted then that the Supreme Court would take review of that decision, and it did.
The Supreme Court avoided tackling the issue of whether APIs are properly subject to copyright at all (i.e., the conclusion in the Federal Circuit’s first decision). Instead, the majority assumed (without deciding) that APIs can be copyrighted, and focused instead on whether Google’s admitted wholesale copying of Oracle’s API’s was “fair use.” But in getting to that question, the Court noted that Congress thought “long and hard” about whether to grant copyright protection to computer programs because it did not want to grant anyone more economic power than was necessary to incentivize creation of such programs so as not to stifle later innovation. The Court found that Congress intended fair use to provide that balance, and to provide a “context-based check that can help keep a copyright monopoly within its lawful bounds.”
Although the Supreme Court affirmed the Federal Circuit’s holding that “fair use,” as an equitable doctrine, must ultimately be decided by a judge (not a jury), it reversed the Federal Circuit’s conclusion that Google’s use here was not fair. The Court’s decision emphasized that the nature of the APIs copied were far from copyright’s core protections, as the value of the APIs stems from their wide acceptance in the programming community (not on their unique originality). But in context, the Court seems to be saying (repeatedly) that as copyrighted software becomes more popular with programmers, it will become less protectable.
Similarly, the Court’s decision transforms and expands the “transformative” test for analyzing the “purpose and character of the use” in determining fair use. The Court adopts the concept of “reimplementation,” which it defines as building a new system by repurposing the same words and syntax of an existing system. Indeed, the Court cites with approval a 1992 Ninth Circuit decision (Sega Enterprises v. Accolade) that found reverse engineering a computer program was fair use, because any attempt to use copyright to monopolize a market by making it impossible for others to compete runs counter to copyright’s central purpose of promoting more expression, not less.
Overall, the Court’s opinion shows that a six-vote majority is concerned about monopoly power in technological platforms. Although its decision centered on “fair use,” its language will breathe new life into the affirmative defense of copyright misuse. Ironically, now the more successful a technology company may be in making its platform dominant, the less protection its code may now get from courts. Developers who have relied on using APIs and possibly other code (think open source packages) without licensing or other restrictions will breathe a sigh of relief. On the other hand, platforms that count on licensing revenue may find it harder to negotiate licenses. This decision could also potentially have significant implications for companies that have grown up as an API-first business and then moved away from APIs—Twitter, for example. As more and more products are run by software (think about any new car), this decision will make it easier for adjacent add-on and service providers (think about your neighborhood mechanic) to compete. The Court used this case to make a policy statement that the need for interoperability can trump copyright protection; how that tilt away from strong copyright protection for computer code will affect future innovation remains to be seen.
David O’Neill is founder and CEO of API governance and monitoring service APIMetrics. He is a 20 year mobile and API industry veteran with a track record of creating test and monitoring solutions. His current focus is on the challenges posed by API regulation and providing ways to automate governance, compliance and performance monitoring for the entire API ecosystem.
