Communications of the ACM
Home/Magazine Archive/May 2015 (Vol. 58, No. 5)/Oracle v. Google: A High-Stakes Legal Fight For the.../Full Text
Law and technology
Oracle v. Google: A High-Stakes Legal Fight For the Software Industry
Credit: Andrij Borys Associates / Shutterstock
Recently, the U.S. Supreme Court has been hearing an unusually large number of intellectual property cases. And it has issued opinions, in cases like Alice v. CLS Bank and ABC v. Aereo, that have made important changes to the patent and copyright laws. But now the Supreme Court may wade into a case that could prove far more important than any of the Court's recent forays into intellectual property. That case, Oracle v. Google, involves a foundational question about the copyrightability of software. As I write this column, the Court has not yet decided whether to take the case, but that decision will almost certainly be made by the time this column appears. I will try to explain here why it is important the Court take this case, and, even more importantly, that it overturn the lower court's ruling holding that software APIs are copyrightable. If the Court leaves the lower court's ruling in place, both the software industry and consumers are very likely to pay a steep price. (Communications columnist Pamela Samuelson wrote expertly about this case in her March 2015 Legally Speaking column—take a look back at her column if you want the complete picture).
The Origins of Java
Back in the mid-1990s, Sun Microsystems and a group of collaborators—including, importantly, Oracle—developed the Java programming language. Sun's goal in developing Java was clear—to overcome Microsoft's Windows monopoly.
How? By adopting a strategy of openness. Windows is a proprietary, closed platform. Sun recognized that it could not displace Windows with another platform that worked in the same way. Instead, Sun made Java open and free for anyone to use.
Sun's strategy was to create a "Java community," and to declare all specifications would be decided in the open and all players would have equal access. The foundation of this strategy was a promise that the Java applications programming interface (API) would be open, so anyone could use Java to create cross-platform software. APIs are the parts of a computer program that other programs interact with. If you want programmers to write programs that are compatible with your software, you ensure they have access to your program's APIs.
Having open and attractive APIs was a particular priority for Java. As Sun's then-CEO Jonathan Schwartz explained, "[w]e wanted to basically build the biggest tent and invite as many people as possible." That way, "when [programmers] at Oracle or SAP write an application, it can run on an IBM computer ... It can run on a Sun computer. It can run on any computer that runs Java. And that was our way of bypassing the monopoly."
How things have changed. Oracle acquired Sun in 2010. Following the acquisition, Oracle has taken a very different path. It has taken steps to close the Java API that Sun formerly evangelized as open. And Oracle is relying on copyright law to do the job.
Oracle's Copyright Strategy to Close the Java API
The focus of Oracle's effort is a lawsuit the company filed against Google. In the lawsuit, which was filed shortly after Oracle's acquisition of Sun, Oracle charges Google violated Oracle's copyrights in Java when it included certain Oracle code in the implementation of Java the Internet search giant uses in its Android mobile operating system.
It is important to understand what code Google copied from Oracle, and what Google did not copy. Java is composed of a set of pre-written programs that allow programmers to efficiently build software by assembling pieces of code that execute commonly used core operations. These chunks of code are called "methods," and each method performs a function. The methods are grouped into "classes," and classes are further grouped into "packages."
The computer code for each method consists of "declaring code" and "implementing code." The declaring code attached to any method is, in reality, nothing more than a name for that method. These names are structured in a particular format: java.package.Class.method(input). An example would be java.lang.Math.max (1,2). This bit of declaring code refers to a particular method (max), situated within the Math class and the lang package, that, when executed, returns the greater of two numbers.
The actual operation is executed by the method's implementing code—the declaring code performs no function other than to instruct the computer to execute the implementing code for the method it names.
And yet the declaring code is key to the utility of Java. Programmers working in Java do not need to know the implementing code for any particular method they wish to use in software they are authoring. Instead, programmers simply input the declaring code. Using the name within software written in Java results in the software performing the function. In this way, a programmer uses declaring code to operate the methods.
What is the business motivation behind Oracle's claim? The entire thing boils down to money.
Java is an efficient way to build software, and over the years it has attracted a large community of developers who have become fluent in Java's declaring code—that is, they have learned the names for many of the hundreds of methods available in the Java library. Which is why Google decided to use Java as the platform upon which developers build Android apps.
Google's Android software contains 168 packages of methods. But Google did not copy any of Oracle's implementing code. Instead, Google wrote or acquired its own implementing code for all the Java methods employed in Android. Oracle's lawsuit focuses on declaring code. Google used the same names for the methods contained in 37 of the Java packages used in Android. Oracle says using the same names is copyright infringement.
What is the business motivation behind Oracle's claim? The entire thing boils down to money. Oracle wants Google to pay to license Java rather than allow Google to author its own version of the implementing code. But Oracle cannot stop Google from writing its own implementing code, so they are using an indirect strategy. Oracle is trying to use copyright law to block Google's ability to use the Java declaring code. If they succeed, Google will be in a very tight spot. Java developers know the declaring code—that is, the names—for the Java methods. If Oracle can force Google to use different names, it will, at a stroke, make thousands of developers suddenly illiterate in Google's implementation of Java.
Or, to put it another way, think of the declaring code as a language—say, Spanish. Oracle wants to force developers to write for Android to learn to speak Portuguese. Which will make it much more difficult and expensive for developers to write apps for the Android platform. And that will give Oracle leverage to get millions in licensing fees from Google.
Oracle's Copyright Claims Fail Their First Test
In the beginning, Oracle's copyright claim did not fare so well. Federal District Judge John Alsup—a coder himself—dismissed Oracle's suit. Judge Alsup found that programmers used Oracle's declaring code to operate the Java methods. And, as a consequence, Oracle's declaring code was an uncopyrightable "method of operation."
As Judge Alsup noted, "methods of operation" are uncopyrightable under the section of the copyright law that distinguishes between copyrightable expression and uncopyrightable ideas. Methods of operation can sometimes be patented. But they are outside the jurisdiction of the copyright laws.
Oracle argued the declaring code was not a method of operation, but rather a "taxonomy"—that is, system for naming things. In Oracle's view, taxonomies may be copyrighted if they are creative. And Java's declaring code, Oracle argued, is creative. There is nothing inevitable, Oracle asserted, about the java.package.Class.method (input) structure of Java declaring code. Oracle could have chosen some other structure for declaring code. And because Oracle had choice in how to structure declaring code, its decisions regarding that structure were necessarily creative.
Judge Alsup accepted Oracle's arguments, but held they did not matter—the Java declaring code was nonetheless an uncopyrightable method of operation. Here is the key piece of Judge Alsup's opinion: "That a system or method of operation has thousands of commands arranged in a creative taxonomy does not change its character as a method of operation. Yes, it is creative. Yes, it is original. Yes, it resembles a taxonomy. But it is nevertheless a command structure, a system or method of operation—a long hierarchy of over six thousand commands to carry out pre-assigned functions. For that reason, it cannot receive copyright protection—patent protection perhaps—but not copyright protection."
The Federal Circuit Rules for Oracle
Oracle appealed to the U.S. Court of Appeals for the Federal Circuit. The Federal Circuit has jurisdiction over patent, not copyright. But the case ended up before the Federal Circuit because in the beginning it included patent claims.
Keeping copyright away from APIs will help keep the software industry healthy and competitive.
The Court acknowledged that Java declaring code was a method of operation, but held that "the [copyright] protection accorded a particular expression of an idea" is not extinguished "merely because that expression is embodied in a method of operation." In other words, in the Federal Circuit's view, if the construction of a particular method of operation involves some creative choice, then it will be copyrightable.
Which, to put it bluntly, simply cannot be right. Not least because the Copyright Act makes clear that methods of operation are uncopyrightable "regardless of the form in which [they are] described, explained, illustrated, or embodied ..." Which means Java's methods of operation are uncopyrightable even if the description of a particular method in declaring code involves creativity.
More generally, the construction of every method of operation involves some choice. But if every API involves creative choice, then every API would be, in the Federal Circuit's view, copyrightable. And that would simply erase the copyright law's exclusion of methods of operation. That is something no court has the power to do.
Will the Supreme Court Intervene?
Google has asked the Supreme Court to review the Federal Circuit's decision. In a sign that Google's request is being examined closely, the Court has asked the Department of Justice to weigh in on whether the Court should take the case. Regardless of what the DOJ says, the Court should go ahead and grant Google's petition for certiorari. And they should reverse the Federal Circuit and declare software APIs uncopyrightable. Copyrighting APIs threatens serious harm to both the software industry and consumers.
To see this, think for a moment of the competition that open software APIs have encouraged. Open interfaces are the foundation of the Internet—nobody has to ask for permission or pay a license fee to transmit a message according to the Internet Protocol, or to build a server adhering to the Hypertext Transfer Protocol.
Similarly, the continuing vitality of Unix-style operating systems was made possible the fact that although much of the source code for AT&T's Unix was copyrighted, the APIs were not. This allowed open source systems like Linux to use Unix interfaces, which made it easier for programs built on top of Unix to interact with Linux. The increased software compatibility that open interfaces provided paved the way for open source operating system competition with established proprietary platforms.
Keeping copyright away from APIs will help keep the software industry healthy and competitive. On the other hand, allowing companies like Oracle to use copyright to close APIs will block a lot of future software development. It will limit competition, and give big companies like Oracle the power to pick favorites and squash upstarts.
In view of the critical role open APIs play in ensuring software markets are competitive, the best outcome would be a Supreme Court holding that APIs, as methods of operation, are simply uncopyrightable. Note that such a holding would not be the end of intellectual property protection for APIs. Elements of APIs that are novel and meet the other criteria of patentability would still be eligible for patent protection. But Oracle and other software firms would be prevented from using the comparatively blunt instrument of copyright law to deny their competitors access to APIs wholesale.
Footnotes
The author has licensed non-commercial reproduction and distribution of this work on terms that can be found at https://creativecommons.org/licenses/by-nc-nd/4.0/.
©2015 ACM 0001-0782/15/05
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from [email protected] or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2015 ACM, Inc.
No entries found