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!

Rick Sanders

Rick is an intellectual-property litigator. He handles lawsuits, arbitrations, emergency injunctions and temporary restraining orders, opposition and cancellation proceedings, uniform dispute resolution proceedings (UDRPs), pre-litigation counseling, litigation avoidance, and other disputes, relating to copyrights, trademarks, trade secrets, domain names, technology and intellectual-property licenses, and various privacy rights. He has taught Copyright Law at Vanderbilt University Law School. He co-founded Aaron | Sanders with Tara Aaron-Stelluto in 2011.