Google vs. Oracle: The Importance of the Supreme Court API Copyright Decision
On April 5, 2021, the Supreme Court of the United States of America issued its decision in the Google vs. Oracle API copyright case with two crucial outcomes:
- The Supreme Court adhered to the lower court decision and operated under the assumption that APIs are copyrightable.
- Google’s copying of 11,500 lines of code from Java was indeed “fair use.”
As Postman Chief Evangelist, I signed the Supreme Court amicus API brief along with 82 other computer scientists stating our opposition to the assertion that APIs were copyrightable, while also supporting Google’s right to fair use under the current legal definition.
APIs are not just fundamental to the Postman API Platform; they play a central role in virtually every enterprise organization and every industry all across the globe. APIs are the pipes behind every desktop, web, mobile, and device application you see connected to the internet today. Because of that ubiquity, the Supreme Court decision is something that impacts us all. To shine a light on this important ruling, we wanted to help break down the decision to help everyone understand the business impact of what the Supreme Court has handed down.
Some background on Google vs. Oracle
Just seven months after acquiring Sun Microsystems in 2010, Oracle sued Google for copyright and patent infringement in the District Court for the Northern District of California. This saga began as two separate cases, one on patent infringement, and another on the copyright related to the Java API in 2012. They were eventually merged into a single case, with a jury finding that Google had infringed on the copyright, but found non-infringement on all patent claims—with the judge issuing a final verdict that declared APIs were not copyrightable in the first place. Oracle appealed the decision and was able to overturn the case on the basis that the Copyright Act of 1976 (part of the Copyright Law of the United States) provides protection to “original works of authorship fixed in any tangible medium of expression,” and that Oracle’s APIs were indeed “creative, original, and resembl[ing] a taxonomy.” This outcome led Google to file a petition with the Supreme Court in 2019, receiving a hearing date in early 2020. However, due to COVID-19, the oral arguments were postponed until October 2020—leading us finally to the Supreme Court decision this month.
During the 2020 oral arguments, the Supreme Court examined the Google vs. Oracle case on four guiding factors set forth in the Copyright Act’s fair use provision:
- The purpose and character of the use
- The nature of the copyrighted work
- The amount and substantiality of the portion used in relation to the copyrighted work as a whole
- The effect of the use upon the potential market value of the copyrighted work
The court operated under the assumption that the 11,500 copied lines can indeed be copyrighted, and only focused on whether Google’s use of those lines was actually fair use. Ultimately, the Supreme Court felt that Google’s use of Oracle’s APIs was creative and enough of an advancement in the area of mobile application development to justify fair use. Google did not copy all of the Java APIs; they copied just enough to meet their needs for the mobile operating system, while also ensuring their APIs were familiar enough for existing Java developers to understand how to use them—this point was a key argument for why Google asserted fair use.
From Postman’s point of view regarding this ruling, we would prefer that APIs are not copyrightable in the first place, but we are inspired by the portion of the Supreme Court ruling that widens the definition of fair use, and we also feel the positioning and attention of this case will deter other organizations from asserting copyright in the same way that Oracle did.
As part of this case discussion, we’d like to share our thinking on how we came to our view of API copyrighting.
APIs should be free of copyright
APIs are very abstract and can be difficult to “see” even for developers, which is why our industry often applies various analogies to help everyone better understand what is an API and what isn’t. One of our favorite analogies for helping make APIs more relatable—while also helping us make the argument for why APIs should not be copyrightable—is the restaurant menu. APIs are like restaurant menus in that they provide “structure, sequence, and organization” for your digital resources in the same way that a restaurant menu does for all the food items being served up at a restaurant. Imagine if restaurant A that serves up burgers, fries, and shakes couldn’t use the same words, as well as the ordering and organization of the words on their menu as restaurant B.
Menus are not copyrightable, and like APIs, can have dramatically different ingredients and processes behind each expression of the ideas behind a restaurant. The structure, sequence, and organization of burgers, fries, and shakes on your menu are not what create a novel expression of an idea; rather, it is the ingredients, processes, and services behind them. Both burger restaurants benefit from the shared concept of a menu, and a shared knowledge among their consumers of what burgers, fries, and shakes are. It is the execution of it that ultimately will set one restaurant apart from another. Likewise, APIs are not intellectual property; they are the part of your operations that are common, reusable, remixable, and able to be put into use in as many applications, by as many developers, as possible.
With copyright applying to APIs, all API developers must now consider licensing with each API they are looking to reimplement or reuse as any part of a workflow—if a developer is crafting a workflow with 5-10 different APIs, they potentially have 5-10 individual licenses they need to navigate.
To explore the friction which copyright imposes, let’s consider one potential use case where a developer is making an API call to Amazon Web Services (AWS) Simple Storage (S3) APIs, where with each individual API call our developer literally navigates and receives the “structure, sequence, and organization” of an API. This use case actually shows why 17 million developers are using Postman today: It allows them to make a request to an API, receive, and then even save the (now) copyrighted “structure, sequence, and organization” of an API. This, in turn, enables them to then easily mock the API and iterate upon the design of a new API, improvising upon the expression of an idea in a collaborative and iterative way, making incremental changes as often as necessary or desired.
This is how business gets done in 2021, and is something that provides the velocity our economy needs to continue growing. The licensing of interfaces for desktop, web, mobile, and device applications is a business model from the previous century. Today, the companies you see leading the conversation in any industry (or creating entirely new industries) realize that they must reduce as much friction as possible at the interface layer of operations, encouraging consumers—or even competitors—to build on top of their APIs. This is the present and the future of doing business in the digital world.
An API economy without copyright friction
While APIs have been copyrightable for a couple of years now, it isn’t something that has fully set in with API providers and service providers. To use the AWS S3 API use case again, but this time elevating beyond the individual use case to a real-world business use case, let’s consider the reuse of the S3 API in its entirety by storage provider Min.io, who augments AWS S3 storage APIs with valuable scaling, redundancy, and other useful capabilities. Min.io uses the same “structure, sequence and organization” of the AWS S3 API as their own API. While Min.io could easily be seen as a competitor of AWS S3, they are actually adding value for AWS S3 users while also generating revenue for AWS.
This pattern plays out over and over across many different sectors of our economy, where APIs are being used, reused, and remixed to generate new types of applications, integrations, or entirely new companies and products or services. Our economy is increasingly powered by publicly available API resources and capabilities like this, and this layer of our economy is too fast-moving, ever-changing, and perpetually building upon itself in a machine-readable way for it to be licensed and slowed. More value is generated by the free and open evolution of APIs done in a collective and collaborative way (across enterprise organizations and within industries) than when applying legacy approaches to licensing the interface that puts the code to work.
The Supreme Court fair use ruling in Google vs. Oracle significantly leaned on the separation between the declaring code and the implementation code that make up the Java API, in that developers can’t even see the implementation code, and the declaring code is by design the fair use portion of an API. This separation increases when you move from programming-language APIs like Java to web APIs, and increases even further as these APIs evolve from being deployed using language frameworks to commoditized API gateways that are ubiquitous across every cloud platform and a fixture in any modern enterprise. This is one reason we at Postman are so accepting of the Supreme Court’s new fair use definition: This further separation of the API from its backend code and systems, as well as the usage of API specification formats like OpenAPI and AsyncAPI, provides us with a human- and machine-readable contract that we need to quantify the surface area of our API—or, more specifically, the fair use portion of our APIs, which is something that can easily be “diffed” or compared between two different APIs to quantify the scope, difference, and reuse across any API. The new fair use definition will help the entire developer community automate how we collectively design, operate, communicate, iterate, collaborate, and reuse the APIs that are powering the economy today and into tomorrow.
What’s next for API copyright?
The Google vs. Oracle API case centers around language libraries (the Java API), but the precedent of copyright applying to APIs also transfers to the web APIs that are powering the desktop, web, mobile, and device applications we all depend on today. With the precedent in the United States being that APIs are copyrightable, we at Postman recommend that everyone license their APIs using the widest possible license, applying a Creative Commons CC0 or CCY-BY to your Swagger, OpenAPI, or AsyncAPI definitions. We are fairly confident that the Supreme Court’s fair use precedent will provide the scope needed to take us into the future without too much friction.
While APIs are copyrightable, most API providers will understand the importance of APIs being free of licensing friction, and see the business opportunities involved at the API gateway layer using modern API management, rate limiting, and service composition. The next generation’s digital products and services won’t be designed to generate revenue from licensing and restriction on APIs; instead, they will be centered around evolving rapidly and competing on access to the latest digital resources and capabilities.
Even when companies do opt to take a more restrictive copyright stance on their APIs, we believe they will be further dissuaded from enforcing and engaging in litigation involving API copyright. Ultimately, the decade-long Google vs. Oracle copyright case has had a significant impact on Oracle’s image and brand when it comes to the fast-growing API sector, and it has sent a message to other companies who might consider taking to court companies that re-implement their APIs.
The Supreme Court ruling in the Google vs. Oracle API copyright case puts an exceedingly prolonged battle to rest, removing a lot of uncertainty from the sector. The ruling also coincides with a maturing of the API landscape, the increasing presence of machine-readable API specifications like OpenAPI and AsyncAPI, and a renewal of venture capital investment. All of this sets the stage for a pretty compelling future for the API sector, making for an optimal mix of technological, business, and political momentum that will help us sustain and iterate upon our legacy technological infrastructure, while also ensuring that we move fast enough to lead when it comes to the future of artificial intelligence, cybersecurity, and other emerging innovations of the tech sector.
In celebration of the Supreme Court ruling (yes, we definitely think the broader definition of “fair use” is worth celebrating), we invite you to join us in discovering, implementing, and remixing APIs using Postman’s Public API Network to innovate and evolve existing APIs in new ways. The time is right for you to help deliver the next big shift in the API landscape, or design the perfect orchestration or workflow using just the right combination of APIs—and Postman and the Supreme Court are right behind you all the way.
The supreme court did not rule that APIs are copyrightable. Instead,they assumed for argument’s sake that they were, just to show that fair use applies
The ruling states:
To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”
SCOTUS did not rule that APIs are copyrightable. The declined to rule on that, because it wasn’t necessary to decide this case.
Agreed on the “SCOTUS did not rule that APIs are copyrightable”, but they deferred to the lower court decision and operated under the assumption that APIs are copyrightable.
With all due respect, I think you’re assumption is wrong. If I understand what you’re saying, you believe that innovation is more important than legally protecting my intellectual work. That’s nonsense. By this argument I could take your Postman API (or pick parts of it) and start my own business and not only will you not get credit, I’ll also make money off of it. Is that really fair use, and does it seem legal? The developers at Google are just lazy. Instead of creating their own work they take from others. Don’t just look at this one moment, look ahead and think of the problems this policy will create. I’m all for collaboration and innovation but I don’t believe in stealing. Isn’t it really just modern day plagiarism?