A significant statement of software copyright law has come in a very high-profile case: Java API packages were held not protectable under U.S. copyright law in Oracle America, Inc. v. Google, Inc., No. C 10-03561 WHA (N.D. Ca. May 31, 2012). The jury, having been told to “take for granted that the structure, sequence and organization of the 37 API packages as a whole was copyrightable,” found that Google had indeed copied the Java API packages, and therefore infringed, although the jury deadlocked on the merits of Google’s fair use defense. Following the jury’s finding, the court, having deferred the question, considered whether “the elements replicated by Google from the Java system were protectable by copyright in the first place.” The court found that they were not.
The court helpfully provided a very clear and succinct summary of its ruling:
So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.
Continuing its summary, the court acknowledged that Google could have avoided duplicating Java’s exact command structure in Android by “re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used).” However, considering the Java commands taking the form “java.package.Class.method(),” the court noted that this name tree was a utilitarian structure for carrying out a precise method. Thus, the “command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted.” To further bolster this point, the court added that “[d]uplication of the command structure is necessary for interoperability.”
The court’s decision was supported by lengthy findings of fact, including a detailed description of the organization and implementation of the Java API. The court found that “Google wrote or acquired its own source code to implement virtually all the functions of the 37 API packages in question.” Everyone agreed that Google’s implementations were “different from the Java implementations.” However, concerning “the 37 packages at issue, Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.” Further, “Code already written in the Java language would, to this extent, run on Android and thus achieve a degree of interoperability.” A comparison of “the 37 Java and Android packages side by side” yielded the conclusion that “only three percent of the lines of code are the same.”
The court then it began its legal analysis by noting that the Copyright Office does not extend registrations to names and short phrases. Delving into the case law, the court noted that the venerable case of Baker v. Seldon, 101 U.S. 99 (1879), holding that an accounting system could not obtain copyright protection, continued to be followed by modern courts. As the copyright law has developed to cover computer programs, no one disagrees that line-by-line copying is copyright infringement. The question is what to do with claims such as the one here, where the alleged infringer is accused of stealing the “structure, sequence and organization” of the copyrighted work.
Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222 (3d Cir. 1986), which found a software structure copyrightable because it could be separated from the utilitarian purpose of the work, has been oft-criticized. More courts have followed the approach of Computer Associates International, Inc. v. Altai, 982 F.2d 693 (2d Cir. 1992), which adopted the “abstract-filtration-comparison” test. The present court provided a detailed summary of the law following these two cases; anyone needing to research the law governing copyright protection extended to computer software structures should give attention to this opinion.
After providing its detailed summary of the law, the court set forth “principles of copyright law” by which it concluded that the present case was controlled:
- Under the merger doctrine, when there is only one (or only a few) ways to express something, then no one can claim ownership of such expression by copyright.
- Under the names doctrine, names and short phrases are not copyrightable.
- Under Section 102(b), copyright protection never extends to any idea, procedure, process, system, method of operation or concept regardless of its form. Functional elements essential for interoperability are not copyrightable.
- Under Feist, we should not yield to the temptation to find copyrightability merely to reward an investment made in a body of intellectual property.
Applying these conclusions to the present facts, while there was a creative element in how the command taxonomy of Java was organized, it was also true that commands had to be of a certain form, and each command called on a pre-assigned function. Further, the need for interoperability, and the fact that interoperability was at the heart of the command structure, additionally weighed in favor of the command structure being a functional requirement, and not protectable by copyright.
The court stated “in closing” that it was
important to step back and take in the breadth of Oracle’s claim. Of the 166 Java packages, 129 were not violated in any way. Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines. Oracle must resort, therefore, to claiming that it owns, by copyright, the exclusive right to any and all possible implementations of the taxonomy-like command structure for the 166 packages and/or any subpart thereof — even though it copyrighted only one implementation. 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. No holding has ever endorsed such a sweeping proposition.
This was the second significant software copyright case decided by a U.S. District Court in as many days, the court in Tetris Holding, LLC v. Xio Interactive, Inc., having found that the look and feel of the Tetris video game did merit copyright protection. It does not seem to me at first blush that these decisions are difficult to reconcile, although scholars will probably be comparing and contrasting them for some time to come. This court held that the Java APIs were not protectable by copyright essentially because form could not be separated from function, whereas the Tetris court held that the look and feel of the Tetris videogame, i.e., its form, could be separated from its functional requirements. Thus, different factual findings supported different legal conclusions, and do not necessarily suggest different legal analyses. I will not venture to say how the European Court of Justice’s recent ruling that European copyright protection does not extend to computer programs fits into the mix.