Dear Oracle: The Java APIs Are Not a Work of Art

Oracle said the Java APIs were like a beautiful painting. Google said they were more like a file cabinet. And in the end, Judge William Alsup came closest to agreeing with Google, comparing an API to a library that organizes the Java programming language.
Image may contain Indoors Room Library Book Furniture and Shelf

Oracle said the Java APIs were like a beautiful painting. Google said they were more like a file cabinet. And in the end, Judge William Alsup came closest to agreeing with Google, comparing an API to a library that organizes the Java programming language.

"Each package is like a bookshelf in the library," Alsup wrote with last week's much-anticipated ruling in the epic legal battle between Google and Oracle. "Each class is like a book on the shelf. Each method is like a how-to-do-it chapter in a book. Go to the right shelf, select the right book, and open it to the chapter that covers the work you need."

His ultimate point was that the organization of a library is not subject to copyright. Yes, he said, the books are copyrightable, but not the way the books are organized.

In other words, Google did not infringe on Oracle's copyright when it cloned 37 Java APIs in building its Android mobile operating system. Though Google copied the organization of the APIs, it built the code behind them on its own -- or at least mostly on its own. "The Java and Android libraries are organized in the same basic way but all of the chapters in Android have been written with implementations different from Java but solving the same problems and providing the same functions."

With his ruling, Judge Alsup effectively brought an end to the six-week trial over Google's use of Java in Android. After suing Google in 2010, claiming both copyright and patent infringement, Oracle had sought a portion of Google's Android revenues, but in the wake of Alsup's ruling, it's entitled to almost nothing -- though the database giant has already said it will appeal.

>"This reaffirms our longstanding understanding of the law: that these APIs were free for anyone to use as we did, taking just the declarations and doing our own independent implementations. That's the way developers use Java. You can't say a language is free for everyone to use and then hold back the nouns and the verbs." – Google

If Alsup had ruled otherwise, says Bret Bocchieri, an intellectual property lawyer with the international law firm Seyfarth Shaw LLP, Oracle could have potentially reaped a "mind-staggering amount" of damages. But he didn't.

What's more, Alsup's ruling allows a world of software companies and individual developers to breathe a sigh of relief. In the software world, cloning APIs is a common practice. Several cloud platforms, for instance, mimic the APIs of Amazon's massively popular Elastic Compute Cloud. An API is an application programming interface, a way for two pieces of software to talk together, and the general assumption has always been that these interfaces are not subject to copyright. When Oracle tried to argue otherwise, it caused at least a little hand-wringing among software outfits across the industry. But on Thursday, Alsup put an end to all that.

"To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands," read his 41-page brief. "No holding has ever endorsed such a sweeping proposition."

Ed Walsh, an attorney with the law firm Wolf Greenfield, isn't surprised by the ruling. But he also says that we shouldn't necessarily view the ruling as a decision that frees all APIs from copyright. He believes that the judge may have ruled in favor of Google at least in part because Sun, the original maker of Java, allowed Google to clone the APIs. Oracle sued Google after acquiring Sun.

"I think some element of the influence [for the ruling] was the view that Sun allowed people to use Java," Walsh said. "So that expanded the range of things [Oracle] could not protect by copyright."

Catherine Lacavera, Google's director of litigation, says much the same thing. "This reaffirms our longstanding understanding of the law: that these APIs were free for anyone to use as we did, taking just the declarations and doing our own independent implementations," she told Wired. "That's the way developers use Java. You can't say a language is free for everyone to use and then hold back the nouns and the verbs."

But Alsup goes much further, using great detail in describing what the Java APIs are and how they should be treated under the law. His library metaphor is an apt one. But he doesn't stop at metaphors. He seems to truly understand APIs. He realizes there's a difference between copying an interface and copying the code behind an interface.

"Every method and class is specified to carry out precise desired functions and, thus, the 'declaration' (or 'header') line of code stating the specifications must be identical to carry out the given function," he says, after laying down his library metaphor.

As of 2008, Java included 166 APIs, spanning more than six hundred classes, broken into more than six thousand methods. Google replicated the names and the operation of 37 API packages, but it used its own code to implement the methods and classes.

During the trial, Oracle counsel Mike Jacobs often said that building an API was akin to writing a great symphony or, yes, painting a beautiful painting. And Judge Alsup did acknowledge that developing an API is a creative endeavor. But he added that at the conceptual level, such inventions can only be protected by patents. Oracle also tried the patent argument, but that didn't work either.

Java relies on a particular vocabulary called "method specifications" that allow humans to tell the computer exactly what they want it to do. Alsup said that under the U.S. Copyright Act, no matter how creative a method specification may be, anyone -- including Google -- is entitled to use the same specifications as long as the line-by-line implementations are different. "The method specification is the idea. The method implementation is the expression. No one may monopolize the idea," Alsup wrote.

The judge said that no court of appeals or district court has addressed whether APIs are subject to copyright. But he did point to other precedent, including the 1879 Supreme Court ruling in Baker v. Seldon -- a case that examined whether accounting techniques are copyrightable. The court ruled that bookkeeping methodology could only be protected by patents and that protection under copyright law would "frustrate the very purpose of publication."

"It is true that Baker is aged but it is not passé. To the contrary, even in our modern era, Baker continues to be followed in the appellate courts."

He also cited 1994's Apple Computer, Inc. v. Microsoft Corp., 1992's Computer Associates International, Inc. v. Altai, and 1986's Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc. -- all of which examined whether various aspects of computing are subject to copyright. For Alsup, the upshot is this: If there are only a few ways to express an idea, then no one can claim copyright.

Names and short phrases are not copyrightable, he said, and copyright protection never extends to any idea, procedure, process, system, method of operation, or concept -- regardless of its form. He also said that functional elements essential for interoperability are not copyrightable. And that includes the Java APIs.

In many ways, the Google-Oracle battle was a letdown. But in some cases, it rose above the usual monotony. The highlight came when Alsup told the court he had learned to code in Java -- a way of showing Oracle that he wouldn't let the company pull the wool over his eyes. It was quite a performance, and after looking back on six weeks in his courtroom, where he hit both the attorneys and expert witnesses with the sharpest of questions, we take him at his word. In his ruling, he went so far as to write out lines of code that illustrate methods, classes, and packages. And, well, he got the ruling right.