The Oracle v. Google decision came down Friday. Talk about a shocker.
Let’s look at what that case was all about.
In 2010 Oracle sued Google in the U.S. District Court of Northern California for copyright and patent infringement. The case centered mostly on several Application Programming Interfaces (APIs). The APIs were used to write applications for Android. The jury returned a verdict of no patent infringement of the APIs but did find copyright infringement and came back deadlocked on if Google’s use of the APIs constituted fair use.
However, the Judge in this case was not just any Judge. As the trial dragged on he revealed he was….a software developer!
Here is how that played out.
Oracle argued Google’s use of rangeCheck (unrelated to the API) was used to save time:
“They wanted it faster, faster, faster. This copying allowed them to use fewer resources and accelerate that. Suppose they accelerated it two days. They’re making $3 million a day now, activating 700k or 800k phones….”
In response to a reminder from Judge Alsop about causal nexus, Oracle’s attorney replied:
“I still think it’s possible to demonstrate a nexus by showing that speed was very important to Google in getting Android out, and by copying they accelerated that.”
To which Judge Alsop responded with his big announcement:
“I have done, and still do, a significant amount of programming in other languages. I’ve written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There’s no way you could say that was speeding them along to the marketplace. You’re one of the best lawyers in America, how could you even make that kind of argument?”
The best lawyer in America was on the ropes:
“I want to come back to rangeCheck.”
To which Judge Alsop makes it clear that he is knowledgeable about rangeCheck:
“rangeCheck! All it does is make sure the numbers you’re inputting are within a range, and gives them some sort of exceptional treatment. That witness, when he said a high school student could do it—“
And the lawyer is less so:
“I’m not an expert on Java — this is my second case on Java, but I’m not an expert, and I probably couldn’t program that in six months.”
With this discovery of Judge Alsop’s software development background it came as no surprise when in response to a request for Judgment as a Matter of Law Judge Alsop found that the API itself was not able to be copyrighted. Judge Alsop broke it down in plain English for the appellate court he surely knew would become involved later on and explained that the API was not copyrightable because it was a “system or method of operation.” He went on to say that 102(b) of the Copyright Act precluded “copyrightability for any functional element ‘essential for interoperability’ regardless of its form.” Right on.
102 (b) says
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.
Oracle appealed Judge Alsop’s ruling to the Circuit Court. This past May 10th Judge O’Malley reversed holding that an API is copyrightable and remanded back for a decision on fair use.
Before we move on I don’t disagree software is copyrightable. That is well established. Software is protected as a literary work under the Copyright Act. As it should be. No argument there.
But an API is a set of rules on how software components interact with each other. It is purely functional. You shouldn’t be able to copyright the rules on how software interacts. Think of it this way. You know the movie ticket dispensers? I don’t disagree at all that the software running on the ticket dispenser is able to be copyrighted. But how you interact with the ticket dispenser, how you punch the button to indicate the movie and times you want to see, these interactions should not be copyrighted. Those interactions between you and the machine are methods of operation to get your ticket. The API enables those interactions between you and the ticket machine. This is what was held to be copyrighted. The interaction between you and the ticket machine.
How did this happen? Look at this excerpt of some of the reasoning from Judge O’Malley while discussing the names of the APIs (such as java.lang.ref and java.lang.reflect).
“By analogy, the opening of Charles Dickens’ A Tale of Two Cities is nothing but a string of short phrases. Yet no one could contend that this portion of Dickens’ work is unworthy of copyright protection because it can be broken into those shorter constituent components. The question is not whether a short phrase or series of short phrases can be extracted from the work, but whether the manner in which they are used or strung together exhibits creativity.”
Yep. By analogy the API names were elevated as great literary works of art, equivalent to the work of Charles Dickens. Literary works of art that deserved to be copyrighted. Come on. As one ReadWrite commentator said “Google basically thought Java sucked for its purposes and so it copied the ‘table of contents’ and wrote the book to ‘be better’.”
So what happens next?
Well of course Google will appeal. No doubt about that.
But pretend for a minute this ruling stands. And ignore for the moment whether Google’s use is held to be fair use.
APIs are important. It is an API that literally gets me where I’m going. When I use my smartphone to click on an address so it displays on a map an API what accomplishes that. There is no getting away from APIs and no getting away from this ruling if you are in software development.
If this ruling is upheld it means that anytime a developer copies an API the developer has to determine if that copy qualifies as fair use. Cue the high corporate legal bills and convoluted APIs developed just to avoid copyright infringement. Consider the ticket machine example. There are only so many ways a person can interact with that machine to get the tickets. Not much room for creativity. But guess what. It is either get creative, probably at the expense of efficiency, and/or consult an IP lawyer to verify that your use is fair use.
This case is by no means over and it should be interesting to watch what happens.