On May 31, 2012, the U.S. District Court for the Northern District of California held as a matter of law that the “structure, sequence, and organization” of Oracle’s Java Application Programming Interface (“API”) was not copyrightable because it consisted of functional material and names. The court’s decision obviated a jury verdict that Google had infringed Oracle’s copyright and is significant for several reasons:
It demonstrates the court’s willingness to reign in software copyright cases in which the plaintiff alleges infringement of non-literal elements, i.e., without actual copying of lines of software code. These are the cases typically enforced under the “structure, sequence, and organization” theory of infringement.
It explains the evolution of software copyright law in a single decision, including a reconciliation of the court’s findings with purportedly contrary case law.
The decision articulates a clear framework for limiting the copyrightability of computer interfaces.
Although the court explicitly denied that the “structure, sequence, and organization” doctrine was dead, its case law summary shows that the doctrine has been diminishing for decades. The appeal of this decision could either strengthen or further diminish the doctrine.
The District Court’s Reasoning in Oracle v. Google
The Java API is a set of pre-written programs in the Java programming language for carrying out various commands, such as determining which of two numbers is larger. Anyone is free to use the Java language to write a program, but the API is protected by Oracle’s copyright. Thus, when Google began developing its Android operating system for smartphones, it tried to obtain a license to the API. But negotiations fell through, and no license issued. Instead, Google wrote its own source code to implement the same functions that 37 API packages performed. It gave the programs the same names, arranged them in the same packages, and had them take the same input and output. Due to the manner in which the Java language works, this required that 3% of Google’s implementation of these API packages be identical to the Java API code. The district court found that, despite this literal copying, Google had not infringed Oracle’s copyright.
The court’s decision articulated several key principles of copyright law in the context of software copyright cases:
The merger doctrine means that if something can only be expressed one way, the expression of it cannot be subject to copyright protection.
Ideas, procedures, processes, systems, methods of operation and concepts cannot be copyrighted.
Names and short phrases are not copyrightable.
The fact that effort or investment was required to produce something does not make that thing copyrightable.
The scenes a faire doctrine means that functional elements essential for interoperability are not copyrightable because such elements are dictated by external factors, e.g., they are provided merely to ensure functional compatibility.
The court found that the copied portions of the code were primarily functional. The nature of the Java language made it impossible to write a method that generated the same output from the same input without using the same or nearly the same expression. Of the copied portions, only the method and variable names could have been changed without affecting function. But because names are not copyrightable, the use of the names was not an infringement.
Certain Interfaces Are Not Copyrightable
The Oracle decision applies to a specific interface — the Java API. The court based its holding on a careful analysis of how that API worked and a factual determination that it could not accomplish the same function if it were expressed differently. Given the wide variety of interfaces that exist — from hardware buses to graphical user interfaces — this decision does not mean that interfaces are never copyrightable.
But importantly, Oracle shows that certain interfaces are not copyrightable, and it sets out a framework for deciding whether a particular interface is copyrightable. Courts should consider how an interface works to determine whether the same function can be accomplished in more than one way. If it can (and if the differences are not merely names or some other uncopyrightable element), the interface should be copyrightable. But if the only changes that can be made without harming functionality are to elements not subject to copyright, or if no changes can be made at all, then the interface is not subject to copyright.
Thus, software interfaces which can only function if the required inputs, outputs and keywords are put together in a particular way are much less likely to be found copyrightable. Similarly, an electronic interface, such as one that complies with a particular standard, is also less likely to be copyrightable, although nothing prevents a developer from copyrighting his version of software that implements a particular electronic interface. A user interface, in which a designer could choose, for instance, whether to have users click on buttons or type numbers to enter a PIN, is more likely to remain protectable by copyright.
An Appeal Is Likely, But Its Effects Are Uncertain
Oracle has announced that it intends to appeal, although as of press time it had not yet filed a notice of appeal. The deadline for Oracle to file will depend on when the district court decides a pending motion.
An appeal will most likely go to the Court of Appeals for the Federal Circuit, because Oracle’s complaint included claims for patent infringement as well as copyright. The Federal Circuit applies regional circuit law to non-patent issues, however, and therefore Ninth Circuit law will apply to the copyright issues. Regional circuit law, rather than Federal Circuit law, also becomes the binding authority for district courts on non-patent issues. And the Federal Circuit’s ruling will be merely persuasive, not binding, on the other circuits as well. This is not to say that a Federal Circuit opinion will carry no weight. As the first appellate court to address the issue on such a complete and articulate opinion, any Federal Circuit decision will likely be quite influential, particularly to courts in the Ninth Circuit and other circuits across the country.
The District Court Presented a Strong Case . . .
The district court opinion, authored by Judge William Alsup, is laudable for its exceptional clarity. Judge Alsup’s explanation of the technology at issue could be a model for introductory courses in computer science. He provides a detailed summary of the law of software copyright that belongs in every copyright casebook. His reasoning is clear and well-supported. In short, this opinion begs to be affirmed.
Appellate courts rule on orders, not the judges who write them, but Judge Alsup’s impressive track record is also worth noting: nearly 75% of his decisions that have been appealed in the last five years have been affirmed in full. To provide some perspective on this statistic, by contrast, in 2001 through 2010, the Federal Circuit’s rate of affirming patent infringement decisions in full was only around 55%. In addition, Judge Alsup has an unusually strong technical background for a federal district court judge, including coding experience.
It will be difficult to attack that aspect of the court’s opinion which rests on the doctrine that names and short phrases are never copyrightable. Under federal regulations, “[w]ords and short phrases such as names, titles, and slogans” are “not subject to copyright.” 37 C.F.R. § 202.1. And the Ninth Circuit — like most courts — acknowledges this limitation on the scope of copyright. Thus, while the Copyright Act itself is silent on the issue of whether words and short phrases may be protected, the Federal Circuit, applying Ninth Circuit law, would be hard-pressed to say they are.
. . . But There Is No Guarantee the Federal Circuit Will Affirm
The portion of the opinion resting on the functionality of the interface is on shakier ground for several reasons. First, the law is less clear. The opinion acknowledges tension between early software copyright cases, which more enthusiastically protected “structure, sequence, and organization,” and recent cases, which have not used the phrase. Yet, as this opinion notes, “structure, sequence, and organization” is not a dead doctrine.
Second, Oracle may argue that Google did not have to organize its methods in the same groups as the methods in the Java API. The district court’s answer to this argument was that programs written in Java use the hierarchical location of a method to call that method; thus, the hierarchical organization is necessary to ensure interoperability between Android and millions of existing lines of code in Java. Yet Java programs are not entirely compatible with Android, as Google used the interfaces from only 37 of the 168 Java API packages. The Federal Circuit might question the necessity of using the hierarchical organization in light of that choice.
The appellate court may also consider the issue of nonliteral infringement and feel compelled to rationalize this decision with other non-literal copyright doctrines. Courts have long held that a book, for example, need not be copied word-for-word to be infringed if the characters and plot are the same. Thus, while the district court opinion focused on the three percent of code that was literally the same, on appeal the Federal Circuit might focus on the code in its entirety to determine whether it was substantially similar, although not literally identical.
Of course, the Federal Circuit could avoid the issue entirely. In addition to arguing that the API was not copyrightable, Google raised equitable defenses such as laches and implied license. The Federal Circuit could apply any of these defenses and dismiss Oracle’s copyright claim without ever reaching the question of copyrightability.
What the Holding Is Not
Despite some commentary to the contrary, this decision is not an “open source” victory. From a legal standpoint, open source refers to a form of licensing. Open source software is not immune from copyright laws; rather, the owners of copyright for open source software choose to license it openly, albeit with certain conditions. Typically, the license grants rights to copy, modify and even sell the code but requires that the licensee grant the same rights to downstream users of the original code and make available any modified source code. In this case, licenses were not at issue. Thus, this is not a decision about whether open source software is per se subject to copyright.
This decision also does not give carte blanche to the public to copy Java API packages. Rather, it permits anyone who wishes to write an original implementation of the same functions to use the same section of code as Google did — specifically, the method headers.
Copyright does not provide complete protection for interfaces. Interface developers should explore patents or contractual agreements to protect against non-literal infringement.
If this decision is affirmed, organizations wishing to use or implement interfaces without permission of the developer should seek legal advice as to whether the type of interface at issue is copyrightable.
Software copyright owners will need to more carefully assess the risk of pursuing non-literal copying theories in software copyright enforcement actions.