Further Reflections on Oracle v. Google
1. The Federal Circuit’s decision is not binding precedent in any other case in any district court anywhere in the country. Because this case arose in the Ninth Circuit, the Federal Circuit was required to apply Ninth Circuit precedent. But its interpretation of Ninth Circuit precedent is not binding on district courts in the Ninth Circuit, or any other circuit. Thus, a district court in San Jose or Seattle is free to ignore the Federal Circuit’s misinterpretation of Sega v. Accolade and Sony v. Connectix.
To be sure, other district courts may find the Federal Circuit’s reasoning to be persuasive, but it is not binding. And as these district courts dig into the Federal Circuit’s reasoning, they quickly will conclude that it is not that persuasive. The Federal Circuit certainly undermined its credibility with its assertion that Google and its amici believe that software should not be protectable under copyright. The Federal Circuit itself flatly contradicts this assertion when it observed that
Google agrees with the district court that the implementing code is the expression entitled to protection…. Indeed, at oral argument counsel for Google explained that, “it is not our position that none of Java is copyrightable. Obviously, Google spent two and a half years…to write from scratch all the implementing code.”
The Federal Circuit noted that “of the 37 Java API packages at issue, ‘97 percent of the Android lines were new from Google.’”
2. The Federal Circuit’s statement that interoperability is irrelevant to determining protectability is dicta. In my previous blog post, I explained that the Ninth Circuit had determined that elements necessary for interoperability fell on the idea (and therefore unprotectable) side of the idea/expression dichotomy, but that the Federal Circuit had misinterpreted these precedents. The Federal Circuit, however, went even further than stating that interoperability was irrelevant to the determination of whether an element was protectable; it also disagreed with the district court’s finding that replication of the structure of the Java API was necessary to achieve a degree of interoperability between Java and Android. The district court found that in order for at least some of the existing Java apps to run on Android, Google had to provide the same command system using the same names with the same functional specifications. The Federal Circuit, in contrast, noted that there was “no evidence in the record that any such app exists.” Moreover, the Federal Circuit claimed that Google could “point to no Java apps that either pre-dated or post-dated Android that could run on the Android platform.” The Federal Circuit further stated that Google did not seek to foster compatibility “with Oracle’s Java platform or the [Java Virtual Machine] central to that platform.”
If, in fact, Java and Android are not compatible, then the Federal Circuit had no reason to reach the issue of the impact of interoperability on the protectability analysis. Any statements on that question are mere dicta.
3. The court’s explanation of what Java elements Google copied and why it copied them underscores that those elements are unprotectable under 17 U.S.C. 102(b), which withholds copyright protection from “any idea, procedure, process, system, method of operation, concept, principle, or discovery….” Section 102(b) is the codification of the long-standing idea/expression dichotomy that lies at the heart of copyright. The Second Circuit in Computer Associates v. Altai recognized that “drawing the line between idea and expression is a tricky business.”
The Federal Circuit found that Google’s real objective in replicating the structure of the Java API was
to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue. The district court agreed, finding that, as to the 37 API packages, “Google believed that Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as in Java.” Google’s interest was in accelerating its development process by “leverag[ing] Java for its existing base of developers.”
The Federal Circuit went on to say that
Google was free to develop its own API packages and to “lobby” programmers to adopt them. Instead, it chose to copy Oracle’s declaring code and the [structure, sequence and organization] to capitalize on the preexisting community of programmers who were accustomed to using the Java API packages.
The Federal Circuit opined that the desire to capitalize on the preexisting community of Java programmers “has nothing to do with copyrightability.” But this plainly is wrong. What could be better proof that something is a procedure, system, or method of operation than if a person can become “trained,” “experienced,” or “accustomed” to using it in the course of developing new works? Earlier in the opinion, the Federal Circuit described the API packages as “shortcuts” programmers can use when writing their own programs. While the detailed steps of each shortcut may be copyrightable, the structure of the entire set of shortcuts surely isn’t. If a framework of shortcuts used by programmers in their development process isn’t a procedure, system, or method of operation, what is?
Jonathan Band is a DC-based attorney whose clients include Internet companies, providers of information technology, universities, library associations, and CCIA. He previously guest-posted on DisCo about his initial thoughts about the Oracle v. Google opinion.