##### October 8, 2020

Disclaimer: I’m not a lawyer. This is not legal or professional advice. What I say below are my own views, some of it is inexact for the sake of concision, and some of it might just be plain old wrong. So don’t use this as the basis for deciding to engage in copyright infringement, stock market speculation, or anything else.

Over the past decade, Google and Oracle have been litigating a case about software and copyright that has garnered a lot of attention in the software industry, due to its potential to impact the legality of what many in the industry currently take to be commonplace daily practice. I recently listened to the oral arguments presented to the Supreme Court, and wrote this essay to dive into the technology aspects of the case. I’ll do so in three parts: background exposition about the technology being litigated, a look at the arguments each party made, and finally I’ll do some editorializing about the case.

# What’s An API? 🔗︎

In creating their Android smartphone platform, Google re-implemented the Java programming language (owned by Sun, which is owned by Oracle), and in the process copied the API declarations from 37 Java packages that form the Java standard library. If we want to debate whether this is copyright infringement, we’ll have to start by understanding what a programming language is.

Inside your computer, phone, or VR headset, you have a CPU chip. These are made by a variety of companies - Intel you’ve probably heard of, but there are others like AMD, as well as companies like Apple who make their own custom chips. These chips rely on something called an Instruction Set Architecture (ISA), which is essentially the set of commands that a particular chip supports and is capable of physically executing. These might look something like this:

ADD r0, r1
CMP r0, r1
MOV r0, r1
...


You can write a computer program as a sequence of these instructions. At a physical level, the CPU will read the opcodes (ADD, CMP, etc.) as different electrical signals that in turn cause electricity to be routed to different areas of the chip. The physical structure of these disparate areas is itself different and is what makes it possible to perform the various allowed operations (adding numbers, comparing, etc.). You can think of the ISA as the “language” that you need to speak for a physical CPU to understand you.

There are a few ISAs out there in the world: x86 is the one most likely to be powering your laptop, but arm is what’s now powering iPhones. When writing software for computers, it’s a huge pain to write a program at the level of individual CPU instructions (think of this like building a house without power tools). Additionally, writing software at this level means your program can only run on computers that understand the ISA you’ve chosen, which is a huge inconvenience.

High-level programming languages were developed in order to solve these problems. Code looks substantially more human-readable:

attemptCount = 1
while attemptCount < 60:
print("I am on attempt: " + attemptCount)
attemptCount = attemptCount + 1
is_successful = requestRaise()
if is_successful:
exit()


Conceptually, it’s a lot easier to understand the intent of this program when compared to pages of ADD, CMP, and MOV!

Now, in order for CPUs to actually run these programs, this “high-level” code is translated (the industry term would be compiled) into a functionally equivalent sequence of instructions (MOV, ADD, etc.) for your computer’s specific ISA, which is what is ultimately understood and run by your CPU. Programmers write their programs in one language, and compilers are these other programs that translate it into machine language to be run. The secret sauce, of course, is that the compiler has the capability to translate your high level language into any ISA, which makes it possible for you to write your program once and have it run on any physical CPU.

Oracle owns the rights to the Java programming language. What does this actually mean?

• A programming language will usually have a specification, which describes the rules for writing programs in that language.
• You’ll see a variety of things such as which words are reserved for use by the language.
• Typically speaking, this isn’t “code”, it’s usually just prose and some diagrams.
• A programming language will usually have one or more compilers, which can understand programs written to conform to the language specification and in turn translate them to machine instructions.
• Java has many different such compilers, only one of which (Hotspot) is owned and managed by Oracle.

So what happened is that Google built their own compiler for the Java language specification (Dalvik) in a “clean-room” implementation (which basically means they didn’t look at the source code of the original while doing so) that is perfectly capable of understanding the entire java language as specified. Interestingly, Oracle didn’t claim that this action was copyright infringement on either of the above components. What they’re going after instead is the fact that Google copied the APIs of 37 Java SE packages - approximately 11,000 lines of code. What does this mean?

A programming language by itself is usually not very useful. If you read the entire Java language specification, you won’t find anything about talking to the internet, processing videos, or sending emails. A programming language usually includes only the most primitive building blocks (such as basic arithmetic), and more advanced functionality is then built separately using that functionality. A reasonable analogy is how English defines the alphabet and syntactically significant words like “a” or “the”, but we’re then free to invent our own incredibly expressive words like “supercalifragilisticexpialidocious”.

We do this in programming languages with things called libraries. As an example, I might write some code that looks like this:

package justin.math; // Comment: This defines a package

public Integer addTwoNumbers(Integer a, Integer b) { // the function "declaration"
return a + b;                                      // the function "implementation"
}


and someone else could then write a program that looks like this:

import justin.math.*; // This *uses* a package someone else wrote

print(addTwoNumbers(1, 2)); // "3" would appear onscreen


The first file is what programmers would generally describe as a “library”. Real libraries generally exist for more complex tasks (such as rotating an image), but the point is that the implementations are often complex, and they are hidden behind relatively simple declarations or interfaces precisely so that it’s as easy as possible to very concisely perform complex tasks. With the use of many libraries, you could imagine code that looks like:

searchResults = searchGoogle("How many people are there?");
sendEmail("mom@justinyan.com", "See? I told you: " + searchResults);
adjustThermostat("living_room", "65F"); // I need to cool off!


In addition to the Java Language Specification and Hotspot JVM (Oracle’s compiler), Oracle maintains a variety of “standard libraries” called Java SE which provide functionality including things like more complex math, cryptography, and the ability to communicate with the internet. In the process of writing their own compiler for the Java Language, Google also copied the declarations for around 6000 functions, though they re-implemented each function themselves. This process might look something like this:

// Original
package java.lang.math;
public Integer max(Integer a, Integer b) {
if (a > b) {
return a;
} else {
return b;
}
}

// Re-implemented - notice the first two lines are identical.
package java.lang.math;
public Integer max(Integer a, Integer b) {
if (a - b > 0) {
return a;
}
return b;
}


A collection of these declarations is colloquially known as an “API”, and because they exist in the source code file alongside the implementation, the question at stake right now is whether they are protected under copyright. This is the avenue through which Oracle has chosen to go after Google.

# The Arguments 🔗︎

This is where I remind you that I’m not a lawyer. I’ve spent a while listening to the arguments, reading the US code, and reading about relevant case law, but I’m just a layman forming a layman’s impression on the topic.

Computer programs are considered “literary works” and are therefore covered under copyright law as stated in 17 Section 102. For me, the intuition of a copyright is most easily divined by thinking about books: copyright is intended to protect an author from someone else simply making copies and selling the book without compensating the author. Of course, as the world has changed, similar concepts have made their way into the scope of copyright protection - music, pictures, movies, and now computer programs.

Of course, there are a variety of principles the courts have developed to restrain the obvious edge cases when it comes to copyright. For example, I cannot copyright a “book” with the single word “the” and then sue the world into oblivion. There are heuristics such as “Sweat of the Brow” (how much effort went into the work) and “Threshold of Originality” (is the work sufficiently novel/creative?) that govern whether something is even copyrightable to begin with (and yes, these are pretty subjective, but that’s the cost of trying to protect creative works).

Another set of limitations comes from section 102b, which states “In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.” This subsection was written to distinguish copyright protections from patent protections and is in essence a codification of the classic Idea-Expression distinction, first articulated in Baker v. Selden, in which it was found that someone who wrote a book about a bookkeeping system had copyright protection for his book, but not for the bookkeeping system he had described in the book. Protection for the latter would require him to file for a patent.

Now, even if you have a copyright, in order to win an infringement case, you also have to show that your work was copied and that the level of copying is misappropriation. Here, there is a heuristic called “substantial similarity” which is used to determine whether the copying was wrongful in some way. Of course, there is no clear rule, and though a variety of tests exist - such as the Filtration Test, there’s really no clear definition the software industry can use.

Even after all of this, section 107 carves out the “Fair Use” safe harbor, which makes it possible to use copyrighted work as long as it satisfies one of four possible factors (which I won’t reproduce here). Classical examples of fair use include things like literary criticism, education, etc.

So with all of that legal background out of the way, Google has presented two main arguments:

1. Non-copyrightability of APIs: Yes, we copied the declarations, but we did not copy the implementations, and we are arguing that the function declarations aren’t protected by copyright to begin with.
2. Fair Use: Yes, we copied the declarations, and even though those are covered by copyright, our specific usage should be considered Fair Use.

Interestingly, each of these arguments was found in favor of Google at a district court, and was then reversed in favor of Oracle upon appeal - which leaves us here, at the Supreme Court, to adjudicate on both counts. I’m only going to explore the first argument, because as presented to the Supreme Court, the second argument seems to mostly be a procedural question: Google won the jury trial, an appeals judge overturned this, and they are arguing that the appeals judge should not have done this.

If computer programs fall under copyright protection via section 102a, and function declarations are in the same file as the implementations which are undoubtedly computer programs, how could Google possibly argue that the declarations are not copyrightable? Google’s argument revolves around the “Merger Doctrine”, which argues that if an idea can be intelligibly expressed in only one or a limited number of ways, then the particular expression “merges” with the idea, and is not considered protected (which section 102b explicitly states).

Consider one of the examples used in the case:

// Comment: Call this snippet "mathlib"
package java.lang.math;

public static double max(double a, double b)
public static double min(double a, double b)
public static double absolutevalue(double a, double b)


Google’s argument starts by saying that the scope of copyright protection clearly gives software engineers who have learned Java the freedom to use the language, and more importantly, the library functions as they wish. That is, I, as a developer, am perfectly within my rights to write a program that looks like this:

// Comment: Call this snippet "justinsprogram"
import java.lang.math;
java.lang.math.max(1.2d, 2.3d)


The crux of the argument is that given how the java language is specified, which Oracle has not chosen to litigate, there is only one way for Google to write their own libraries that respond to these specific commands. That is, if in my program I write import java.lang.math; and then java.lang.math.max(1.2d, 2.3d), there must be a library file that contains the lines in the mathlib snippet above (this is what the java language specification sets in stone). You cannot capitalize Max, you cannot call it Maximum, you cannot change the first line to java.lang.mathematics - the definition of how Java works enforces a single way to write the API that will respond to that specific Java program that has been written. Because this is the only way it can be expressed, then idea merges with expression, and the merger doctrine prevents the copyrightability of API declarations.

Oracle’s argument is that this is ridiculous. There are many different programming languages, and they point out how Apple built their own language (Swift) and wrote their own libraries, which includes a max function. Their point is that if we consider the “idea” in question to be “how do we express a group of related mathematical functionality”, there are obviously many different ways to express such a concept - you could call it maximum, you could have max and min inside of different files, so on and so forth. The merger doctrine applies only because Google is taking a deliberately narrow view of what the “idea” is.

# Editorializing 🔗︎

After listening to the arguments and doing some research, a few things jump out to me.

## Who Is Right? 🔗︎

Under the letter of how the law is currently written, I personally think that Oracle should probably win on the non-copyrightability portion of the case.

In the oral arguments, we heard the Google lawyer say “There was only one way for us to implement this” while the Oracle lawyer argued “There were clearly many ways to implement this”. Is one of them lying? The reality is that they are both telling the truth, and the sleight of hand is happening with the word “this”. The Google lawyer means “the Java SE API” when he says “this”, and the Oracle lawyer means “math-related (and other) functionality”.

As we explored above, Google’s argument revolves around the fact that there is only one way for them to build a library that would respond correctly to the programs written by a developer who used Java and the Java SE functions. Therefore, the real question they are posing is: given the expression that is the 6000 function declarations that look like public static double max(double a, double b), what is the idea being expressed?

Google posits that the “idea” is the “Java SE API” itself, and if you accept this premise, it would then follow from the Java Language Specification that there is only one way to declare such functions, and therefore the Merger Doctrine would preclude the function declarations from copyright protection. As far as I can tell, they are predicating this argument on the idea that software engineers learn these functions and then have the right to use them to write programs, which constitutes them as an idea.

For me, I think the most interesting question that Google’s argument presents is simply: “For the purposes of copyright, what qualifies as an idea in terms of non-copyrightability?” For Google’s argument to not immediately succumb to a slippery slope of defining anything as an idea, I think they would have to posit that “any interface is an idea”, no matter how concretely it is described. This argument is actually reasonably plausible, but given that other programming languages have clearly managed to express “math-related” content in a way that allows them to compete (very successfully) with Java, I think a dispassionate comparison would lead one to conclude that Oracle’s interpretation is the more natural and intuitive one, and that ruling for Google under this argument might be a case of “right ends, wrong means”.

## Consequences 🔗︎

Both Google and Oracle make the argument that the world would collapse if the other side were to win. Most of the industry seems to be on Google’s side, while the US Government and a range of copyright defenders are on Oracle’s side.

Let’s address the industry worries first:

• Even if Oracle wins, an interface like max(a,b) would probably not be in danger of copyright. Similar to a “book” that just contains the word “the”, this would probably not pass the Threshold of Originality. Even more so, Google’s argument would be substantially more likely to apply in this case: there are only so many ways to express the idea of “taking a maximum of two numbers”.
• Compatibility layers should probably be more worried than before. As an example, many video games can only be played on Windows PCs. I use Linux and therefore have to use software called WINE, which translates programs written for Windows into programs capable of running on Linux. The original game programs that run on Windows use Windows-specific functions such as GetFileAttributesW, and it’s hard to imagine how WINE could work without at least one copy of that function in its code (so that it knows what to recognize and then translate).

This kind of cross-compatibility and cross-pollination is extremely common in the industry. When programming languages develop new APIs and capabilities, these often rapidly make their way to other languages - which is a very good thing, otherwise, we’d be using languages that are each good at one very narrow thing, instead of having a plethora of choices that are each good at many different things. Indeed, Oracle got their start in the industry by letting people who used the SQL language with IBM databases on Oracle databases, and even now are in the business of maintaining compatibility with dominant APIs. The ability to introduce competing implementations is a great way to stimulate competition on what would otherwise be a potentially stagnant platform.

Now, let’s consider the concerns that Oracle poses:

• The core of their argument is that removing copyright protection would remove the incentive for people to innovate and develop better APIs - why invest if a competitor can just copy? Indeed, this is the entire point of intellectual property: some forms of creative work need to be protected or else no one would bother to invest in them. People outside of the industry probably don’t think of the “APIs” as very creative - after all, it’s the implementations that do things, right? Shouldn’t that be where all the work is?

Indeed, in the district-level fair use trial, the jury concluded that the entire Java SE API was barely above the creativity threshold for copyright, and I’m pretty sympathetic to the argument that API designers deserve more credit than this. Google engineers have given hour-long talks about writing just these interfaces. Stripe, a company valued at tens of billions of dollars, is famous for how much better its APIs are than its competitors. Customers paid them more money because of how much easier it was to use their API. If this wasn’t creative and hard, how could a company derive a competitive advantage worth billions of dollars?

Consider a house. In modern times, a typical home is nicely subdivided into areas like the “kitchen”, “bedroom”, “living room”, and so on. Designing a modern home is substantially easier because these conceptual guidelines already exist - “I need two bedrooms, a bathroom, and a kitchen”. Designing a brand-new API is similar to trying to create these guidelines before anyone has ever built a home. You’ll regularly do things that would be analogous to “I think people will want dogrooms” and then discover years down the line that everyone finds this useless.

Let’s go back to Stripe, a company that helps other businesses accept credit card and other digital payments. If you pay for something online, there’s a good chance Stripe is what made that possible. When a customer wants to pay for something, how should the business inform Stripe of this fact? Should they say charge_credit_card? Should charge_bank_account be a different function or should there be a generic charge? It actually takes a lot of experience, judgment, and trial-and-error to discover the best way to express these concepts.

Despite arguing that writing APIs is actually hard work and has a lot of value, I don’t think Oracle’s argument holds much water. The truth is that we don’t need more incentives to get people to build great APIs. Amazon knew that people were going to copy its S3 API. Stripe will absolutely have copycats. They built these APIs anyway. There are a few reasons for this:

1. The business model behind software has moved away from selling software to selling services. Originally, we thought that because software could be copied for free, the best business model would be to sell it (it’s pure profit!), but we’ve discovered that the best feature of software is that you can automate tasks and provide services for minimal marginal cost. Someone can copy your API, but if they can’t figure out how to perform the implementation that makes that API possible, then it just doesn’t matter. For example, someone can copy Stripe’s API, but if they can’t figure out how to treat credit cards and bank accounts the same internally, it won’t do them any good.
2. When competitors copy your API, you then force them to react to your changes. Competitors making proactive changes puts them at risk that it conflicts with a change you might make, breaking compatibility.
3. Having a great API is a great initial differentiator, helping you build up market share before your competitors are able to react. As it turns out, copying is not a trivial undertaking and parity generally can’t be achieved in a day.
4. Competitors copying your API consolidates the entire industry around a standard that you effectively define, and your organization will generally have the most experience and knowledge with it, which is a major first-position experience and branding advantage. When choosing between options that have the exact same API, why wouldn’t you pick the company that was the one to design it to begin with?

Indeed, huge amounts of code, including the implementations, are increasingly being developed in public and are free to use, with minimal effect on the desire to innovate and invest. This is precisely because the network, standards, and systems effects are so strong - the true long-term competitive advantages lie in the operational know-how of your employees, your userbase, etc. The industry has already organically moved away from business models that would be incentivized by copyright litigation, and therefore, despite all of the hard work that truly goes into designing wonderful APIs, it just doesn’t seem necessary for them to be copyrightable.

Given that I think the court should probably rule in favor of Oracle given how the law is written, I think we’ll find an interesting grey area because many modern APIs that exist on the internet are not actually really even “code”. Consider Twilio’s API - the description of which is mostly just prose:

This just says: send an HTTP POST request to this URL in this format. While copyright law clearly protects Twilio from having their documentation copied, it would be extremely easy to implement a service that could respond to this description using a different programming language, and providing documentation that looked entirely dissimilar. At a glance, this looks almost entirely analogous to Baker v. Selden - which raises the question: should APIs that exist on the web have a different level of protection from those written in code?

The best fix for this mess would probably be to simply write some better legislation: the way software is treated as part of the copyright act (as a literary work) has served us for 40 years, but it’s time for some updates. To me, the simplest solution would simply be to separate software out from the other copyrightable entities (why should the music industry worry about their business model when two software giants litigate?), and then to simply explicitly create a carve-out excluding APIs from being copyrightable. This would avoid the risks that arise from adding new rules for software that have unintended consequences for things like books, while having a stable foundation for the policy that probably encourages the most innovation in industry.