Part I: APIs and IP
The big Oracle v. Google order holding that the Java API is not copyrightable is now about two months old, but software developers are still talking about it because APIs (“application programming interfaces”) are so crucial to what developers do. I don’t think it’s an exaggeration to say that APIs are an integral part of the who technology ecosystem that we take for granted.
An API is a bit of software code that runs between the application you’re developing and another (usually larger) piece of software, such that your application may use one (of several) functions provided by that other piece of software. A familiar example would be a restaurant-review application or website (like this one) that shows the user a map of the restaurant in question. This is possible because Google (or MapQuest or whoever) made an API with that functionality and, just as important, released that API to the developer of the restaurant app.*
* I’m really stuck for a good metaphor here. In some ways, an API is like how Provence sells lots of nice products at its restaurants/stores, but you can buy Provence bread at the Green Hills Kroger. It’s as though that Kroger location used Provence’s “Bread API.” It didn’t bring an entire Provence store into itself, just the bread.
Now the Oracle v. Google case didn’t just involve any of API but one of the most important APIs: the Java API. Java is a computer language, but it’s also a “platform,” like a little operating system that serves as a foundation for other applications. What makes Java so special is that it can run on any machine that’s been Java-enabled—which, because Java was free and powerfully supported, means just about any machine you can think of: your computer, your smart phone, etc. Java is especially important for running applications through your web browser.
This flexibility made Java a great way for Google (and its predecessor) to develop a mobile operating system. It was also a tried, tested and stable. The Android operating system, therefore, adopted the Java language. For that to work, though, Google needed the Java API. Without the API, Java commands are just empty words. It is the API that gives the commands in Java meaning and functionality—that allow Java programs to execute.
Like other APIs, the Java API is like the reference room in a library. It consists of “packages,” which are like sets of encyclopedias that are logically organized by subject (rather than alphabetically). The “packages” are further divided into “classes,” which are like the subjects contained in our hypothetical encyclopedia. The “classes” are then divided into “methods,” which are like individual entries in the encyclopedia.*
* Imagine a gazetteer-like encylopedia that consisted of short, one- or two-sentence descriptions of persons, places and events of, say, Chinese history, which was divided into several sections, perhaps “Persons,” “Places” and “Events,” or perhaps by era. The book would be the package, the sections the classes, the entries the methods.
A “method” from the Java API acts like an entry in a dictionary. To use an example from the opinion itself, if you write in Java “int a = java.lang.Math.max (2,3),” you’ve told the Java platform to compare 2 and 3 and return the larger of the two. “max” is a method that goes to the Java platform and performs the function. The Java platform knows what to do because of the code that “max” contains. Thus, if you don’t have access to the Java API, you don’t have access to Java.
Now, the scuttlebutt among lawyers and non-lawyers is that Oracle v. Google means that APIs cannot be copyrighted and will be fair game to developers forever. The truth, of course, is more complex.
Intuitively, I think software developers understand that main issue. If Oracle could claim copyright protection over Java the API, it could essentially block all access to Java itself, and that intuitively seemed wrong.
In the run-up to the Oracle v. Google opinion, much of the discussion centered on the philosophical question of whether you could claim copyright ownership of a language (computer or otherwise). As it happens, Oracle wasn’t quite claiming such ownership. It was claiming copyright ownership of the APIs, which enable the Java language but aren’t (legally speaking, at least) the same as the Java language. Like any piece of code, APIs are at least potentially copyrightable. The question is whether the code in the Java APIs deserve copyright protection.
The reason using copyright to block access to Java seemed wrong was that Java is functional. The Java APIs aren’t just collections of words but words that describe (and, in a sense perform) certain functions. The Java API “max” is a function. And if you aren’t allowed to copy that API into your Java library, you can’t use that function in Java.
In point of fact, this intuitive understanding has a basis in law and leads us to one of the key principles underlying copyright law: copyright does not protect functionality. You’ll hear this a lot from copyright lawyers: copyright protects expression, not the underlying ideas or facts.
As it turns out, giving copyright protection to functionality is even more dangerous than giving it to ideas or facts because doing so would cause really awkward overlap with another major branch of intellectual-property law: patents.
If you think about it, functionality is the bread-and-butter of patent law. But patents are very different from copyrights and are meant to encourage different behaviors. Patents are meant to encourage research and development by giving a limited monopoly* over inventions. Copyright is meant to encourage creativity. You can see why software development gets hung up between the two.
* It’s not really a monopoly, but the truth is unnecessarily complex for our purposes.
To get a patent, you have to spend several years and quite a bit of money (and sweat). What’s more, you can only get a patent if your invention is absolutely novel—i.e., (simplifying somewhat) no one had ever thought of it before. On top of that, patents last only 20 years from the filing date, which is a long time but…
…not nearly as long as copyright, which lasts the life of the author plus 75 years (and will probably get longer and longer). More important, copyright arises automatically, with no additional work on the author’s part beyond, you know, creating the work.*
* Registering the copyright is another matter, but even that’s cheap and pretty easy.
Finally, copyright doesn’t demand novelty, only “originality”—i.e., it has to be original to you, the author. It will tolerate very similar works, so long as one wasn’t copied from the other. Thus, an infinite number of monkeys typing out an infinite number of the same work will have an infinite number of copyrights for essentially the same work (provided the monkeys weren’t looking over each other’s shoulders).
However, just because you got functionality in your expression (and expression in your functionality) doesn’t mean your, er, candy bar can’t get copyright protection. You just need to separate out the functionality (and other ideas and facts) from the expression. To take my miserable metaphor a bit further (did you click the link?*), you just need to focus on the chocolate and ignore the peanut butter.
* I love the comment: “Seriously, who struts down the street eating a jar of peanut butter?” Funny thing is that I never, never questioned it at the time.
I’ll explain what I mean, and discuss what happens when you can’t separate functionality from expression, next time.
Thanks for reading!
How is an API different from a key to a lock? It appears to serve the same function. You use (unknowingly, most of the time) the API to gain entry to Java, and its functionality. Personally, I don’t hand out keys to my office or my house or car to just anybody on the street. It’s not that I have a copyright to the office, house or car, but i sure do want to hold onto the particular shape of that key, as it protects what is otherwise MY stuff.
Thanks for the comment, and you raise a really good point–a point that isn’t addressed in Court’s opinion, because the issue was (more or less) addressed by the jury. Here are three things to keep in mind:
1. Yes, an API is very much like a key, with this major difference. If you happen to (legally) find a key laying about and use it, it’s still trespass. By contrast, if you legally acquire a copy of, or legally make a version of, an API, there’s no analogy to trespass.
2. APIs may be either public or private. If you want third-party developers to use your amazing software product, you need to develop and publish APIs. Otherwise, you keep them private. As it turns out, Java is a very, very public program, and its APIs were very, very public.
3. In fact, Google semi-successfully mounted an argument that, because Oracle’s predecessor, Sun Microsystems, (1) so freely published the Java APIs, and (2) talked A LOT about how everything in Java was open-source (slight exaggeration for effect), any infringement by Google of the copyright in the Java APIs was a fair use. (Personally, I would have described this as an implied license, but whatever.) The jury deadlocked on this very issue.
What’s this about a jury? Well, the judge asked the jury to determine a few things, on the ASSUMPTION that “structure, sequence & organization” of the APIs were copyrightable. Most notably, the jury was asked to determine whether Google infringed the “structure, sequence & organization” of the Java APIs. The jury found that it did, but then the judge, in the opinion I’m blogging about, held that the “structure, sequence & organization” of the Java APIs were NOT copyrightable, completely undercutting the jury’s verdict (which will be the subject of my next blog entry on this case). As mentioned, the jury was also asked to render a verdict on the fair use issue, and on that issue it deadlocked.
(There’s a good reason the judge did things this way. A jury verdict is harder to overturn on appeal than a judge’s decision. Thus, if the judge’s decision on copyrightability is reversed, we have a jury verdict that can be easily reinstated. Had the judge rendered his decision first, there would have been no jury verdict, and a reversal would have required a full retrial of the issues.)
Thanks for reading!