I recently had the privilege of making a presentation on the Oracle v. Google copyright case at the Boston Bar Association (slides here), and although how Google could lose on appeal wasn’t the focus of the talk, that’s what I found myself thinking about after the program. Argument before the Court of Appeals for the Federal Circuit (CAFC) in Washington, D.C. is scheduled for December 4, 2013, and a decision is likely by late summer or early fall, 2014.
I view the core issues that threaten Judge William Alsup’s order holding that the structure of the Java API “declaring code” (but not the “implementing code”) is not copyrightable to be the following.
1. Was Judge Alsup Wrong to Include “Interoperability” In His Analysis of Copyrightability?
The heart of the court’s decision that the structure of the Java declaring code (7,000 lines of code) is not copyrightable centers around the conclusion that Google’s use of this code in Android is necessary for third-party partial interoperability with Java. As the judge stated in his order, “Millions of line of code had been written in Java before Android arrived … Such code was owned by the developers, not by Oracle. In order for at least some of this code to run on Android, Google was required to provide the same command system.” The judge went on to state that “Google was free to duplicate the command structure for [the Java API] in Android in order to accommodate third-party source code relying on the [API] (taking care to write its own implementations).”*
*Note: Java was developed by Sun Microsystems beginning in the mid-1990’s. Oracle acquired Sun, and Java along with it, in 2010. For convenience, references are to Oracle, even when referring to time periods before Oracle acquired Sun.
However, Oracle has a good argument that interoperability is properly raised in connection with a copyright fair use defense, not to determine whether the plaintiff’s work is copyright-protected in the first instance. In fact, the two key cases relied on by Judge Alsup, Sega v. Accolade (9th Cir. 1992) and Sony v. Connectix (9th Cir. 2000), point strongly in this direction.
Judge Alsup relied on the first of these cases, Sega, for the proposition that a software company may copy functional aspects of an existing program to the extent that copying is necessary for compatibility. While Judge Alsup described Sega as a “close analogy” to Oracle/Google, it is difficult to see how this is the case.
Sega involved intermediate copying* of computer code as an initial step in the development of a competing product, and the court analyzed the defendant’s conduct under principles of copyright fair use, not copyrightability.
*Note: “Intermediate copying” describes a process of reverse engineering a program (typically by decompiling object code), and using the knowledge gained to create a compatible, non-infringing program.
Sega held that the defendant’s reverse-engineering and copying of a computer game’s short “lock out” code was fair use where it was necessary to bypass the lock out code to develop compatible game cartridges. The lock out code was 20 bytes long, which the Sega court described as de minimis, and the use of the code was the only way that the defendant could enable its game cartridges to operate on the plaintiff’s game machine.
Importantly, whether Sega’s code was copyrightable was not the focus in Sega v. Accolade. The issue in that case was whether Accolade’s intermediate copying was protected as fair use. The Ninth Circuit never focused on whether the plaintiff’s (Sega) code was protectible, although it did observe, in passing, that the 20 byte code was “functional,” and that no creativity and originality went into its design.
By contrast, in Oracle v. Google it is undisputed that the structure of the Java API is creative and original, that it does not fall under the de minimis doctrine (7,000 lines of code vs. 20 bytes), and that it was not implemented for purposes of compatibility, but rather for the more general purpose of making Google’s Android OS more easily adaptable to programmers who already were familiar with Java.
The second case relied on by Judge Alsup, Sony v. Connectix (also described by him as a “close analogy”), seems even more remote to the issues in Oracle/Google. Judge Alsup held that Sony (like Sega) stands for the proposition that “interface procedures” required for compatibility are not copyrightable.
However, in the Sony case, while Connectix reverse-engineered the Sony basic input-output system (BIOS) in order to duplicate the “interface procedures” of the Sony PlayStation, there is no indication that the resulting Connectix program was an infringement of the Sony program, and therefore the coyrightability of the Sony system was not at issue. The case involved a fair use analysis of reverse engineering, which is not relevant to the issue decided by Judge Alsup: whether the structure of the 7,000 lines of Java code copied by Google is protected by copyright law in the first instance.
Oracle v. Google is not an “intermediate copying” case, and Oracle has a strong argument that both Sega and Sony are weak authority (if they are authority at all), upon which to support the conclusion of the Java API’s non-copyrightability reached by Judge Alsup. If the CAFC agrees, this could serve as the basis for reversal and remand either to reconsider the issue based on the correct principles of law, or to proceed directly to the damages phase of the copyright case, along with a retrial of Google’s fair use defense.
2. Under Computer Associates v. Altai, Does Filtration Based on Interoperability Apply “Ex Post” to the First Author’s Work?
A closely related issue arises under Computer Associates v. Altai, decided by the Second Circuit in 1992. This case established the “abstraction – filtration – comparison” test, which remains the gold standard in software copyright law. The key component of this test is filtration, according to which the court “filters out” non-copyrightable components of the first author’s (typically the plaintiff) computer program. One factor identified by the court in Altai was “compatibility requirements or other programs with which a program is designed to operate.”
Although Judge Alsup did not explain how Altai supported his conclusion in Oracle/Google, he discussed the decision at length, Google relies on it implicitly in its appeal brief, and the CAFC is free to use it to uphold Judge Alsup’s decision.
However, under Altai it is the first programmer’s work (in this case Oracle) that is filtered, not the alleged infringer’s work (in this case Google), and the filtration is performed as of the time the first work is created (ex ante) not as of the date of infringement (ex post). When Oracle created the Java API it did not do so to meet compatibility requirements of other programs. Thus, copyright protection of the Java API was not invalidated by compatibility requirements at the time it was created.
In order to uphold judge Alsup’s ruling that the Java API declaring code’s later-acquired popularity caused it to lose copyright protection, the CAFC would have to conclude that while Oracle may have owned a copyright-protected program when it developed Java in 1995 (and subsequent versions in later years), it lost that copyright protection based on the subsequent popularity of Java. This is analogous to a trademark losing protection when it becomes generic, an extension of Altai that no court has adopted.
Oracle’s argument may be made stronger by the fact that Google’s Android OS is only partially compatible with Java. In fact, Google does not market Android as Java-compatible. As Oracle argued, Google did not create the Android OS so that it could market it as compatible with Java, it was “just trying to make Android more attractive to programmers who know the Java API conventions.” This may make it more likely that the CAFC will conclude that interoperability goes to the issue of fair use, not the copyrightability of the Java API in the first instance.
Again, the CAFC may conclude that this argument could serve as a defense for Google under the fair use doctrine, but that it does not go to the issue of whether the Java API is copyright-protected in the first instance. This would result in the CAFC issuing an order that includes some combination of the following: reversing Judge Alsup’s order on copyrightability (with instructions to either reconsider the issue or to reinstate the jury verdict of liability), and remanding the case for a retrial on fair use.
3. Will the CAFC Reject the District Court’s Reliance on Lotus v. Borland?
Finally, Judge Alsup gave heavy weight to the First Circuit’s 1995 decision in Lotus v. Borland. This important and controversial case held that a menu command hierarchy that serves as the method by which a program is operated is an uncopyrightable “method of operation” under 17 U.S.C. §102(b).* Lotus has never been applied by the Ninth Circuit (whose copyright law is controlling in this case). However, Judge Alsup concluded that while the Java API may resemble a “creative … original taxonomy … it is nevertheless a command structure, a system of method of operation … of over six thousand commands to carry out pre-assigned functions. For that reason it cannot receive copyright protection ….” In fact, a close reading of Judge Alsup’s decision in Oracle/Google could lead one to conclude that this was the sole basis on which Judge Alsup found the structure of the Java API declaring code to be uncopyrightable, and therefore affirmance or reversal may depend on whether the CAFC concludes that Judge Alsup properly applied Lotus in Oracle/Google.
*Note: 17 U.S.C. §102(b) provides that “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 ….”
The CAFC may be unpersuaded by Judge Alsup’s decision to apply Lotus, based either on its limitation to First Circuit law, or based on facts that could serve to distinguish it in this case. It is not a stretch to think that the CAFC could hold that while Java’s system of commands may embody a method of operation that falls under §102(b), under Ninth Circuit law the court is required to determine whether any separable expression is entitled to copyright protection, an analysis that Judge Alsup did not perform.
The CAFC could even reject Lotus outright, and hold that a system of commands is not a “method of operation” under §102(b). Both the Third and Tenth Circuits have indicated that the fact that the words of a program are used in the implementation of a process should not affect their copyrightability, and the CAFC could conclude that this is the appropriate approach under Ninth Circuit law.
Bottom line: Google has its work cut out for it to persuade the CAFC to uphold Judge Alsup’s ruling on the copyrightability of the Java API declaring code. The judge’s decision does not give Google a lot to work with, and leaves some gaping holes for Oracle to aim for. The outcome is far from certain, and the resulting decision has the potential to be a watershed event in the development of software copyright law.