Oracle v. Google: Apocalyptic Subhead

Bringing you only the finest in topical writing, it’s your Soapbox contributors.

So, Oracle v. Google. First, some backstory. In 2009, Sun Microsystems, the creator of Java, was acquired by Oracle, Inc., Larry Ellison’s database outfit. At around the same time, Android was in the middle of taking off. (The HTC Dream/T-Mobile G1 was released in October, 2008.)

Android, of course, is the most widely-used mobile operating system in the world, and something your humble author works with on a daily basis. Developed by Google, Android has two parts: a low-level operating system, powered by Linux, and a framework running on top of it, written in Java. … but not exactly. Google re-implemented some of Java’s APIs, for reasons of developer familiarity. I’ll pause for a moment here and give you some metaphors for APIs, in case you aren’t also a developer.

At its most basic, an API (which stands for application programming interface) is a list of capabilities a certain piece of code exposes to the world. First consider a racing rowboat, with a team of oarsmen and a coxswain in the back. The rowers have a simple API: there is one function (sometimes called a method or a procedure) called ‘stroke’. The coxswain doesn’t necessarily need to know how the oarsmen row, but he does need to know that, when he says ‘stroke’, the oarsmen will all row at once.

Next, consider a car. It presents a slightly more complicated API: ‘go faster’, ‘go slower’, and ‘turn’. In modern cars, the API is implemented by the gas pedal, the brake pedal, and the steering wheel. In the early days of motoring, this wasn’t necessarily so: the Model T, for instance, used a very different control scheme. The important point is that both the Model T and a Tesla Model S implement the same API, no matter how different they may be in the details.

Finally, consider a dictionary. Say you invent a language and create a dictionary for it. Your dictionary is protected by copyright, but your language is not. US copyright law says that you can copyright expression, but not information or data. Your language is information, but the definitions in your dictionary are expressive, creative content. So, although your dictionary is copyrighted, someone can come along and rewrite all your definitions. By doing so, they have created a new work, and you have zero rights to it: they’re using the freely-usable data (the words which compose your language) that you have collated, and making new content where copyright would otherwise be an issue (the definitions).

So, what does an API entry look like in Java?

public String toString()

There are three parts here. ‘Public’ means that anyone who includes this piece of code in their own piece of code can ‘see’, and therefore use, the function. ‘String’ means that the function returns a value of type String. (A String is a piece of text.) toString() is the method name. (There is a fourth part; the parentheses enclose the arguments, the information which someone who wants to call the function must send to the function. In this case, there are no arguments.)

An API is something like a mixture of all of those metaphors1. It’s a way to lay out the functionality of a piece of software, and functional works are generally not subject to copyright. On the other hand, an API is also a description of the functionality of a piece of software, and descriptions (like dictionary definitions) can be copyrighted.

That brings us back to the matter at hand, re-implementations of Java. Two other projects with that aim predated Android: GNU Classpath and Apache Harmony. You’ll note that neither calls itself Java: Oracle, by way of Sun, owns the trademark for the term ‘Java’. Now, Java’s APIs are organized in groups called packages, which have names, for instance, like java.lang (core functionality in the Java language). Crucially, Sun never thought it could copyright those names. It could copyright the implementations: for instance, there’s a method called Math.max(number, number), which returns the larger of two numbers, belonging to the java.lang package. Its full address is java.lang.Math.max. Despite the occurrence of ‘java’ in the package name, Sun never asserted ownership over the structure of the API: it was broadly accepted in the software industry that API definitions were functional, not expressive, and therefore not subject to copyright.

In 2012, though, Oracle looked at Google and thought to itself, “Hmm. I want a piece of that sweet, sweet Android pie. How can I get my hands on that?” The answer? Assert copyright over the Java API. Oracle sued Google in the US District Court for the Northern District of California. The jury ruled that there was infringement, but hung on Google’s fair use defense. Rendering the jury’s verdict moot, Judge William Alsup4 additionally ruled that APIs aren’t copyrightable at all, under a certain clause in the Copyright Act5 which states that procedures, processes, systems, and methods of operation, among other things, are not subject to copyright. Oracle appealed to the Court of Appeals for the Federal Circuit, which overturned Alsup’s ruling that APIs are not copyrightable, and remanded the case back to Alsup’s court to hear arguments over fair use, which is where we are today.

Before I go on, I want to remind readers that, from a practical standpoint, I’m on Google’s side. I don’t think that APIs ought to be copyrightable, for reasons I’ll get into later. That said, having read Judge Alsup’s decision in the original case, and the CAFC’s decision overruling that decision, I think that the CAFC probably ruled correctly, exclusively as a matter of law, in Oracle’s favor. Oracle argued—convincingly—that, although a method like toString(), the example above, may not be copyrightable in itself, the arrangement of methods into classes and those classes into packages constitutes a taxonomy, which an earlier case found to be subject to copyright. In the same way that writing, “It was the best of times, it was the worst of times,” would not infringe on Charles Dickens’ copyright, but inserting the whole text of A Tale of Two Cities into this post would, copying a single method from an API is different than copying an entire API.

Unfortunately for the world of software, Oracle’s argument—that the organization of the API is expressive, and therefore subject to copyright—seems correct to me. There are infinite ways to organize an API, and deciding on one of those is an expressive process which takes creativity. Certainly, there are well-structured APIs and poorly-structured APIs, and there are no hard and fast, mechanical rules for how to design the former as opposed to the latter. An API is not like a general-purpose English dictionary, where there is only one reasonable arrangement for the words and definitions, the alphabetic and that arrangement is therefore purely functional. It’s more like a Chinese dictionary, where there is no purely alphabetical arrangement for the words. To arrange words in a Chinese dictionary, the dictionary author has to design a taxonomy or an arrangement, and that, again, is a creative process6.

Up until now, I’ve spoken of the law as it stands. How the law stands is, in this case, different from how the law ought to be. Although the organization of an API is taxonomic, and therefore subject to copyright, APIs need a special exemption. I’ll provide a few examples of products which, under the case law established by the CAFC, would be infringing.

First, and most ironic, we have… Oracle’s flagship database product. Almost every database in wide use today uses a programming language called SQL to manage and query the database. Oracle DB is no exception. Oracle did not, however, invent SQL: that honor falls to IBM, which created the language in the early 1970s. Oracle re-implemented it, evidently without obtaining a license, in the late 1970s, and SQL was not released as an ISO standard until 1986. Since Oracle was founded, and went through its initial growth, by infringing IBM’s copyright on the SQL API, IBM has plausible grounds to literally sue Oracle out of existence7.

Second, we have Linux, as well as all the GNU utilities. In the 1980s, Unix was an AT&T product, and antitrust judgements had forced AT&T to license Unix freely. When AT&T spun off Bell Labs, those judgements no longer applied, and Bell Labs began to sell Unix as a commercial product. The GNU project, and eventually Linus Torvalds, wrote clean-room implementations of the Unix kernel, which became Linux, which now powers the larger part of the Internet. Nokia, the owner of Bell Labs, can now hold the whole Internet hostage. (Fortunately, I doubt they will. Nokia tends to be pretty chill.)

Third, and most compelling, we have literally every non-Apple computer in existence today8. In the 1980s, IBM released the IBM Personal Computer, from which we get ‘PC’. Almost immediately after that, dozens of competitors released IBM PC-Compatible computers, which re-implemented the low-level API by which programs written for the IBM PC interacted with the operating system and the computer hardware. The presence of a de-facto standard allowed competitors to enter the marketplace, and as the PC market grew, Microsoft released MS-DOS and Intel figured out its own expansion card standard. When IBM tried to go proprietary, the consumer PC market—now almost entirely independent from IBM—moved to the Windows/Intel standard that has persisted to this day. Without IBM’s initial innovation, and the freedom of other manufacturers to re-implement IBM’s standard, we wouldn’t have the vibrant personal computer market we have today.

So, the law is wrong. We can’t fix that in this case. What can we do? Google is trying to claim a fair use defense, and may yet prevail, but I don’t want to speculate on the odds. Provided that APIs are copyrightable (and, right now, as a matter of law, they are), Google’s use was probably not protected by fair use. My read of the trial suggests that, in general, Google argued well and Oracle argued poorly. With any luck, the jury will agree.

What if they don’t? The result is bad for the software industry, but not as apocalyptic as some might claim. There is no copyright concern as far as using an API goes: that isn’t the issue at hand here. The issue is reimplementation, which is a driver of innovation and market expansion. We will likely see fewer products which are designed to take the place of other products, because such projects are now risky on copyright grounds, and depend on the good will (or free licensing) of the copyright holder.

We’ll also probably see a return to ‘not invented here’ as an objection to using open products—unless they were designed from the ground up to be different from other, existing products covered by copyright, the risk, for corporate entities, is too great.

Finally, it’s also bad for Java. Closing a platform tends to kill it; see the IBM example above. Even if that doesn’t happen, Oracle’s behavior here will undoubtedly have a chilling effect. Although I just said that this suit doesn’t have a major impact on day-to-day usage of Java, what it does do is demonstrate that Oracle is willing to push the boundaries of IP law in pursuit of a quick buck. If that’s the way they want to behave, they’ll have to deal with the consequences: people are going to run away from Java.

Fortunately, Google appears to have won, according to the news today. More on what that might mean after I read enough to synthesize an opinion.

1. My wife, who holds a seminary degree, often talks about heresies2 as regard the Trinity, and how most common metaphors for the Trinity end up espousing one of those heresies. My usual response is, “Yes, but there’s no such thing as a perfect metaphor; a perfect metaphor is just the thing you’re trying to describe.”
2. In the technical sense; that is, beliefs incompatible with lower-case orthodox Christian doctrine.
3. (There is no third footnote. I forgot to update the numbering when I removed it, and can’t be bothered to change it now.)
4. His middle name is ‘Haskell’, which the programmers and computer scientists in the audience will find amusing.
5. See here for more; you’re looking at section b.
6. To my knowledge, which is very limited, because I am not a lawyer, this has never been tested in a US court, but my feeling is that the arrangement of a Chinese dictionary would also be copyrightable. See this article and point 5 in this blog post for more on Chinese dictionaries.
7. Your author would watch that case.
8. I don’t know if Apple computers count here, so I’ll leave them out.

Leave a Reply

Your email address will not be published. Required fields are marked *