BTLJ Blog

Oracle v. Google – or How a File Cabinet beat Harry Potter

The Oracle v. Google case, currently on appeal before the Court of Appeals for the Federal Circuit, will decide whether APIs (Application Programming Interfaces) are copyrightable subject matter under section 102(a) and 102(b) of the Copyright Act. But it is also about Harry Potter and a file cabinet – the metaphors Oracle and Google used to explain the character of APIs to the court, Oracle referring to Harry Potter, and Google literally wheeling a file cabinet into the court room to make a point.

So sticking to the metaphors used by the parties, this post is about how Oracle’s Harry Potter got knocked off his broomstick in mid-air by the file cabinet Google hurled at him. It provides an overview of the history leading to the Oracle v. Google case, the technical and legal background, and the reasoning Judge William Alsup used in his order in favor of Google.

The Story Behind the Case

Sun Microsystems developed the Java programming framework, comprising, inter alia, a system of interfaces (APIs) and an implementation of a functions library based thereon, both being commonly referred to as “Java API”. In 2010, Oracle acquired Sun and merged it with Oracle USA, to become Oracle America. The distinctive feature of the Java programming framework is that it allows programs written in Java to run on many different platforms, without the developer having to rewrite the program for all the different operating systems. For that feature, Sun used the catchphrase “Write once, run anywhere” to promote Java.

Google had been developing Android, an operating system aimed at portable devices, since 2005 and released it in 2007. Google first tried to negotiate a license with Sun to use and adapt the Java platform for mobile devices, but the negotiations failed. So Google came up with its own implementation of the Java environment in Android, in order to allow programs that had been written by third party developers in Java to run on Android as well.

Oracle brought suit against Google in August 2010, claiming patent and copyright infringement. Procedurally, Judge Alsup split the case into three different phases covering issues of copyright, patents, and (if necessary) damages. The focus of this post is on the copyright prong only.

The Technical Background in a Nutshell

For a better understanding of the copyright law issues brought up by this case, it is necessary to take a look at some of the underlying technical facts. Allegedly, Judge Alsup even learned to code in Java for the trial, and he presents an extensive introduction into the Java programming framework (p. 4-13 of the order).

In a nutshell, the technical background can be distilled into the following five technical terms:

  • API,
  • function,
  • method,
  • declaration/header, and
  • (method) body.

The API (Application Programming Interface) is the definition of the interface, the abstract specification of how different programs interact with each other (e.g. like the reference system used in a library to help users locate books).

A function is a specific subroutine of a computer program. It is a sub-program that has been sourced out of the program code for efficiency reasons (e.g. like the print-function of an operating system that allows different applications to use that function). In the library-metaphor, this would be the story that a specific book tells.

A method is the concrete implementation of such a function, consisting of a declaration/header and the body of the method. In the library-metaphor, this would be the actual book that contains the specific story.

The declaration/header of the method tells the programs what the function of that method is and how it can be invoked. In the library-metaphor, this would be the title and reference code for a book that one looks up in the library reference system in order to find it in the library.

The body of the method contains the code implementing the function of that method. In the library-metaphor, this would be the actual text of a book in which the story is told (as distinguished from its title and reference number).

Where’s the Infringement?

Google wrote most part of Android’s Java environment itself, in particular the implementations of the functions in the Java libraries (the body of the methods). However, Google used in part exactly the same interface definitions (APIs) as in Oracle’s Java version. By using the same APIs, Google enabled application programmers to call certain functions by the same names in Android’s Java version as in Oracle’s Java version. This made it easier for application programmers to develop compatible programs and, to a certain extent, allowed programs already written in Java to run on Android without the programmer having to rewrite it.

In the copyright prong of the Oracle v. Google case, there was agreement that Google had not literally copied the libraries (i.e. the collections of methods), but created its own implementations (i.e. Google had written its own code in the body of the methods to achieve the same function). The issue at hand was rather whether Google had violated copyright law by its verbatim use of the the declarations/headers, thus replicating the interfaces (APIs) and the structure, sequence and organization (SSO) of the libraries in question.

The Copyright Question at Hand – and its Relevance

The copyright law question at the heart of the Oracle v. Google case is thus whether the APIs and their implementation used by Google in their own Android Java version are copyrightable subject matter under section 102(a) and 102(b) of the Copyright Act.

The answer to this question is of great relevance to the software industry, as in today’s interconnected world, no computer program works as a standalone application, but communicates and interrelates with various other computer programs (e.g. operating systems or other application programs). But in order for programs to communicate, they need to be interoperable. And Interoperability is achieved by means of interfaces, by standardized processes of exchanging and receiving data – by APIs.

Thus if such APIs are found to be copyrightable subject matter, copyright law might confer a monopoly right and thus enable a copyright holder to preclude (or at least control and financially benefit from) any future development – which might impede innovation. On the other hand, developers might argue that such a grant of a monopoly right will offer them a valuable incentive – leading to more and faster innovation.

The Copyright Law Background

Section 102(a) and 102(b) of the Copyright Act define copyrightable subject matter as “original works of authorship fixed in any tangible medium of expression”, 102(a), with the exception of “any idea, procedure, process, system, method of operation, concept, [or] principle […],” 102(b).

While the requirements of authorship and fixation did not raise any issues in Oracle v. Google, the requirements of originality and expression did.

Originality and the Words and Short Phrases Doctrine

The threshold to meet the originality requirement is rather low and easily met: “Original, as the term is used in copyright, means only that the work was independently created by the author (as opposed to copied from other works), and that it possesses at least some minimal degree of creativity.” Feist Publ’ns, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 345 (U.S. 1991).

Nevertheless, certain categories of works may lack the required degree of originality if they are so blunt, short, or obvious that the in fact lack even the slightest “spark of creativity”: This “de minimis” standard excludes words and short phrases from copyright protection, or as the U.S. Copyright Office states: “Copyright law does not protect names, titles, or short phrases or expressions. Even if a name, title, or short phrase is novel or distinctive or lends itself to a play on words, it cannot be protected by copyright.” The courts refer to this principle as the “words and short phrases doctrine” (cf. Sega Enters. v. Accolade, Inc., 977 F.2d 1510, 1524 Fn 7 (9th Cir. Cal. 1992)).

Expression and its Nemeses

Section 102(b) of the Copyright Act contains carve outs from copyrightability, by defining what is not considered “expression” as per section 102(a). The courts have come up with several doctrines and tests to apply section 102(b) in practice:

  • the Altai test;
  • the idea/expression respectively process/expression dichotomy;
  • the merger doctrine, and
  • the scènes à faire doctrine.

The Altai test (also Abstraction-Filtration-Comparison or AFC-test), defines a three-step procedure in order to determine whether the non-literal elements of two computer programs are substantially similar, in order to ascertain whether a computer programs non-literal – but nevertheless copyrightable – “structure, sequence and organization” (SSO) have been infringed upon. The Altai test was formulated in Computer Assocs. Int’l v. Altai, 982 F.2d 693 (2d Cir. N.Y. 1992), based on ideas first expressed by Judge Learned Hand in Nichols v. Universal Pictures Corp., 45 F.2d 119 (2d Cir. N.Y. 1930).

The idea/expression dichotomy (or distinction) stands for the basic understanding in copyright law that the pure ideas understood as abstract principles or fundamental truths are not protectable, only their concrete expression. The process/expression dichotomy (or distinction) stands for the notion closely related to the idea/expression dichotomy that not just ideas (including concepts, principles and discoveries), but also procedures, processes, systems or methods of operation need to be distinguished from their concrete expression, as only the latter (expression), but not the former are protectable by copyright. There is no clear agreement among scholars as to where these concepts were derived from, but most commonly reference is made to Baker v. Selden, 101 U.S. 99, 102 (1880) (for a more extensive analysis cf. Pamela Samuelson, Why Copyright Law Excludes Systems and Processes from the Scope of its Protection, 85 Tex. L. Rev. 1921 (2007)).

The merger doctrine is the exact antipode of the idea/expression respectively process/expression dichotomy in the case where the idea or the process is so inextricably intertwined with the expression that they cannot be separated or distinguished. As Samuelson puts it: “The merger doctrine holds that if there is only one or a very small numer of ways to express an idea, copyright protection will generally be unavailable to that way or those few ways in order to avoid protecting the idea.” Pamela Samuelson, Questioning Copyrights in Standards, Boston College Law Review, Vol. 48:193, 215 (2007).

The scènes à faire doctrine refers to “must do” elements necessary to certain works, to “stock ideas”: “The French use a very expressive phrase in dramatic literature: ‘scenes a faire’ that is, scenes which ‘must’ be done.” Schwarz v. Universal Pictures Co., 85 F. Supp. 270, 275 (D. Cal. 1945). Although this doctrine was first developed in regard to literary works, it became to be understood in a more general manner, not just regarding standard literary works, but also in regard to computer programs, and not just in regard to certain “stock ideas”, but to various external factors constraining an author’s creative choices: “The scenes a faire doctrine, originally developed to recognize that certain plot structures are to be expected from works exploring certain literary or dramatic themes, has been adapted, especially in the software copyright case law, to recognize that epressive choices of subsequent authors may become constrained over time by the emergence of industry standards.” Pamela Samuelson, Questioning Copyrights in Standards, Boston College Law Review, Vol. 48:193, 215 (2007).

The Metaphors used by Oracle and Google

In order to explain to the court how best to apply these principles, tests and doctrines to the APIs at the heart of the case, both Oracle and Google used metaphors. They both tried to present their point of view regarding copyrightability of APIs by choosing a metaphor that would, once the court applied the above mentioned doctrines, lead either to a finding of copyrightability (Oracle) respectively non-copyrightability (Google).

Oracle made its point for copyrightability by comparing the affected method libraries to a Harry Potter novel:

“Ann Droid wants to publish a bestseller. So she sits down with an advance copy of Harry Potter and the Order of the Phoenix – the fifth book – and proceeds to transcribe. She verbatim copies all the chapter titles – from Chapter 1 (‘Dudley Demented’) to Chapter 38 (‘The Second War Begins’). She copies verbatim the topic sentences of each paragraph, starting from the first (highly descriptive) one and continuing, in order, to the last, simple one (‘Harry nodded.’). She then paraphrases the rest of each paragraph.”

(Oracle Opening Brief and Addendum of Plaintiff-Appellant, 1, February 11, 2013).

Google, on the other hand, referred to Section 102(b) of the Copyright Act and used a file cabinet to point out that APIs and their SSO are just a system of organization, a method of operation that allows to call up specific functions in a structured way:

“So just by writing the API, Java.lang.Math.Max(), that source code appears and comes into the program.

And now I actually created — excuse me, your Honor. I’m going to approach the cabinet. I actually created a cabinet to illustrate this because, again, I think it’s important for everybody to understand what we’re talking about when we say structure and organization of an API.

This is a cabinet. This is the Java language package. It happens to be a file cabinet. There are 37 of these that they are complaining about. They are not complaining about using the language, because that’s free. The names were all free. The complaint is about the system of organization. But you need that in order to program in Java.

So if I want to find this max() function. I write java.lang.Math.max() and the system knows I go to the java.lang package. I open the Math drawer.

Now, in the Math drawer are all the methods that are in the math class in Java. And by the way, they are typically organized alphabetically. Nothing too magic about that. They are organized alphabetically. But one of them would be my max() folder. And I take my max() folder out and inside it is the source code. That’s the original source code that Google wrote. […]

And what we’re talking about here is nothing more than this system of organization that has been around for years and programmers had been using whenever they program in Java. That’s what is at issue in this case.”

(Transcript of Jury Trial Proceedings, 263:2-264:6, April 17, 2012, Case 10-cv-03561, Doc. 943 (emphasis added))

Judge Alsup’s Metaphor and His View on Copyrightability of APIs

In his order of May 31, 2012, Judge Alsup also uses an analogy and characterizes APIs by using the picture of a library:

“An API is like a library. Each package is like a bookshelf in the library. 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.”

(Order re Copyrightability of certain replicated elements of the Java application programming interfac, 5:16-5:18, Case 10-cv-03561-WHA, Doc. 1202, May 31, 2012).

In the first pages of his order, Judge Alsup gives a detailed introduction into the technical intricacies of the Java programming framework (p. 4-13), which allows him to clearly distinguish what exactly Oracle accused Google of having replicated:

“All agree that Google was and remains free to use the Java language itself. […] All agree that the six-thousand-plus method implementations by Google are free of copyright issues. The copyright issue, rather, is whether Google was and remains free to replicate the names, organization of those names, and functionality of 37 out of 166 packages in the Java API, which has sometimes been referred to in this litigation as the “structure, sequence and organization” of the 37 packages.”

(Order re Copyrightability of certain replicated elements of the Java application programming interfac, 6:25-7:03, Case 10-cv-03561-WHA, Doc. 1202, May 31, 2012).

Judge Alsup then traces the development of copyright law through the following cases and materials:

Based on that extensive review, Judge Alsup concludes that the issue at hand in the Oracle v. Google case is controlled by (a) the merger doctrine, (b) the words and short phrases doctrine, (c) the idea/expression respectively the process/expression dichotomy/distinction, and (d) the “no sweat of the brow” doctrine according to Feist (33:13-34:05 of the order).

In application of these doctrines, Judge Alsup concludes that “[f]unctional elements essential for interoperability are not copyrightable” (34:01-34:02 of the order) and that even though there might be creativity in the definition and creation of APIs, they are nevertheless a system or method of operation and as such not copyrightable subject matter:

“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”

(37:15-38:02 of the order)

In conclusion, Judge Alsup thus followed the argument made by Google in its file cabinet analogy (for which Judge Alsup substituted his library metaphor) and held the APIs and the SSO of their implementation in the method libraries to be unprotectable under Section 102(b) of the Copyright Act.

The Pending Appeal

Both parties have appealed Judge Alsup’s order, and the appeal is currently pending before the U.S. Court of Appeals for the Federal Circuit (due to the fact that the original case contained patent law questions). The oral arguments have been held on December 4, 2013, and as of today, April 2014, an appellate decision could be expected anytime soon.

Florian Mueller, author of the FOSS PATENTS blog, interprets the proceedings of the oral arguments as a sign that Judge Alsup’s order will be reversed (Florian Mueller, Oracle apparently winning Android-Java appeal against Google — API declaring code copyrightable, December 04, 2013, and Forian Mueller, Detailed analysis of Federal Circuit hearing in Oracle v. Google: copyrightability is certain, December 06, 2013).

However, other sources have questioned Mueller’s neutrality by pointing at preexisting relationships between Oracle and Mueller (Charles Cooper, Oracle names bloggers, others it paid to comment on Google trial, August 17, 2012), as disclosed by Oracle according to a court order.

Outlook

It is far from clear how the Court of Appeals will decide. Based on the thorough technical and copyright law analysis by Judge Alsup, the court might affirm the district court’s decision. But based on the inquisitive proceedings of the oral arguments, one should not be too surprised if Judge Alsup’s order were to be reversed.

In either case, the question at the heart of the Oracle v. Google case has the potential to go all the way to the Supreme Court and to set a new landmark case in the field of software copyright law.

To sum it up using the parties’ metaphors, Oracle’s Harry Potter has been hit by Google’s file cabinet and knocked off his broomstick in the district court. But the day isn’t over yet, and with a helping hand of the Court of Appeals, Harry Potter might just get back up on his broomstick yet again – for his final battle against the file cabinet to be fought before the Supreme Court.

  • Share