The Solicitor General’s Peculiar Brief in Google v. Oracle
Last week, the Solicitor General of the United States filed a very peculiar brief advising the Supreme Court not to hear Google’s appeal from the Federal Circuit’s decision last year that the Android application program interface (API) infringed Oracle’s copyright in the Java API. We previously discussed the Federal Circuit’s May 2014 decision here, here, here, and here; and the significance of the Court’s call for the views of the Solicitor General here.
The SG’s brief is peculiar in several ways. First, it reflects a profound misunderstanding of the Copyright Act subsection that codifies copyright’s “idea-expression dichotomy” by prohibiting protection for ideas, systems, and methods: 17 U.S.C. § 102(b). Second, it completely ignores the obvious “circuit split” between the federal courts of appeal, which has been exacerbated by the Federal Circuit’s decision. Third, it mistakenly concludes that Google’s “substantial and important” concerns about the impact of the Federal Circuit’s decision on “interoperability and lock-in effects” are better addressed through the fair use doctrine than the idea/expression dichotomy.
Section 102(b)
The brief makes the bizarre argument that Section 102(b) can never exclude computer code within a copyrightable computer program from copyright protection.
The SG correctly notes that Google wrote its own “implementing code” (the code that performs the function) for the 6000 methods or subprograms at issue in this case. However, for each of the methods, Google copied the “declaring code,” a line or two at the beginning of the method that declares the name of the program and what it does. Additionally, Google replicated Java’s arrangement of the 6000 methods into 37 packages and 600 classes. (The Java API contained 129 other packages not involved in this litigation.)
The SG appears to have at least a basic understanding of what the Java API is and why Google copied some of its declaring code and the arrangement of some of its the methods. The SG understands that the Java API provides programmers with a library of standard subprograms that programmers can use as “building blocks” for larger programs. The SG also recognizes that Google “copied the declaring code so that programmers familiar with the Java platform would be able to switch over to the Android platform without having to learn entirely new commands for invoking commonly used methods.”
The Federal Circuit ruled that copyright protected both the declaring code and the organization of the methods, and that Google had infringed the copyright in these “literal” and “non-literal” elements. Oddly, the SG focuses only on the first holding: that Google infringed the copyright in the declaring code. The SG reasons as follows: copyright protects lines of computer code; declaring code is a kind of computer code; therefore, copyright protects the declaring code.
In its cert. petition, Google argued that the declaring code had a fundamentally different function from the implementing code, and this difference limited its protectability. The declaring code enabled a programmer to use a shorthand command to call a method’s implementing code. The declaring code thus was part of the method of operating the pre-written programs of the Java language and platform. Accordingly, the declaring code was unprotectable under 17 U.S.C. § 102(b).
The SG rejects this argument, finding no basis for distinguishing the declaring code from the implementing code; code is code. Yet, the SG acknowledges that “verbatim copying of [Java’s] declaring code was necessary for familiar commands to work on the Android platform.” In contrast, differences in implementing code have absolutely no impact on the ability of programmers to move between the Java and Android environments. Thus, declaring code is qualitatively different from implementing code.
It is worth noting that the declaring code and the implementing code are also referred to by programmers—and the district court–as the method header and the method body, respectively, further emphasizing the differences between these two types of code.
In rejecting the applicability of Section 102(b) to the declaring code, the SG articulates an exceedingly narrow interpretation of this foundational principle of copyright law. The SG states that “the basic purpose of Section 102(b)…is not to distinguish between copyrightable and uncopyrightable portions of a larger work of authorship, but rather to distinguish between the work of authorship and something else—be it an idea, a process, or a method of operation that the work of authorship describes or explains.” This is plainly wrong. Section 102(b) does far more than differentiate between a work of authorship and the underlying idea the work describes or explains. It also excludes from protection certain elements of a work, such as facts and aspects of the work’s structure. Judge Learned Hand famously noted that within every work there were “a great number of patterns of increasing generality,” and “there is a point in this series of abstractions where they no longer are protected….”
Moreover, contrary to the SG’s suggestion, the merger doctrine is an application of Section 102(b), and not a distinct concept. Additionally, the SG’s discussion of the merger doctrine is flawed. The SG attempts to distinguish this case from the Supreme Court’s decision in Baker v. Selden, where the Court found that the copyright in a book that explained an accounting system could not prevent others from copying the forms necessary to practice the accounting system. The SG notes that critical to the Court’s analysis “was that the accounting method could not be practiced other than through forms like the ones reprinted in the book.” The SG claims that in contrast to Baker v. Selden, there were an unlimited number of ways that Java API methods could have been named and structured, and nothing required Google to copy Java’s declaring code when it created the Android platform. But the SG overlooks the fact that Selden could have designed his accounting system in many different ways, and nothing required Baker to use Selden’s system. The point is that the Java API is a system for enabling programmers to use standard subprograms as building blocks for writing new programs. The system could have been designed in many different ways, but it was designed in a particular way, and the declaring code was necessary to practice the system in that way.
The fallacy underlying the SG’s bizarre notion that declaring code cannot be unprotectable under Section 102(b) is demonstrated by the following analogy. Imagine an American History study guide that contains a separate chapter for each decade from 1492 until the present. Each chapter starts with a topic sentence with this format: “This chapter covers the decade from x to x+9.” While the study guide as a whole is copyrightable, and many of its passages contain protectable expression, the 53 topic sentences are not protectable. The topic sentences only recite the fact that the chapter covers a particular decade. Moreover, any expression in the topic sentences has merged with the study guide’s system of devoting a chapter to each decade.
Circuit Split
The SG completely ignored the circuit split exacerbated by the Federal Circuit’s decision.
The Third Circuit has long been an outlier on software copyright issues, according computer programs a “thick” scope of protection more appropriate for artistic works than functional works. The other circuits have largely ignored the Third Circuit, and have applied Section 102(b) to computer programs in a manner that encouraged legitimate competition. In particular, numerous circuits have found that copyright did not protect command structures and other program elements necessary for interoperability.
The Federal Circuit’s decision, however, relied on the Third Circuit’s jurisprudence. In rejecting the district court’s finding that copyright does not protect program elements necessary for interoperability, the Federal Circuit cited the Third Circuit’s statement in Apple v. Franklin that compatibility is “a commercial and competitive objective which does not enter into the somewhat metaphysical issue of whether particular ideas and expressions have merged.” By endorsing the Third Circuit’s approach to software copyright, the Federal Circuit magnified the circuit split.
The SG makes no mention of this split. Indeed, it does not reference Apple v. Franklin or the other aberrant Third Circuit decisions.
Further, the SG misconstrues the most persuasive case law on the non-protectability of interface information: the Ninth Circuit’s decision Sega v. Accolade. Ninth Circuit case law is particularly relevant because this appeal arose from a district court within the Ninth Circuit. In Sega v. Accolade, the Ninth Circuit found that Accolade reverse engineered “Sega’s software solely to discover the functional requirements for compatibility with the Genesis console – aspects of Sega’s programs that are not protected by copyright. 17 U.S.C. § 102(b).” The Ninth Circuit explained that if reverse engineering were not permitted,
the owner of the copyright gains a de facto monopoly over the functional aspects of his work – aspects that were expressly denied copyright protection by Congress. 17 U.S.C. §102(b). In order to enjoy a lawful monopoly over the idea or functional principle underlying a work, the creator must satisfy the more stringent standards imposed by the patent laws.
The Sega court’s repeated citation to Section 102(b) leaves no doubt that the Ninth Circuit believed that elements necessary for interoperability were unprotectable under section 102(b).
The Federal Circuit misconstrued Sega. Because it was a fair use case, the Federal Circuit concluded that interoperability was relevant only to the question of the applicability of the fair use defense. The SG makes the same error. To be sure, the Sega court issued its ruling on interface information in the context of determining whether Accolade’s reverse engineering was a fair use. But the Ninth Circuit’s conclusion that Accolade’s disassembly was a fair use was predicated on its holding that the interface information Accolade sought – “the functional requirements for Genesis compatibility” – was not protectable per Section 102(b).
Finally, the SG minimizes the Federal Circuit’s conflict with the First Circuit’s decision in Lotus v. Borland. The SG attempts to trivialize Lotus by stating that “the precise rationale of Lotus is not clear.” The SG’s confusion appears to arise from its erroneous belief that Section 102(b) and the merger doctrine are distinct. The SG also tries to distinguish Lotus on the basis that Borland did not copy code.
Contrary to the SG’s assertions, Lotus is directly on point. The Lotus court’s conclusion that the Lotus command structure was an unprotected method of operation was based on the court’s concern about preserving the ability of users and programmers to switch products. The court viewed as “absurd” Lotus’s theory that “if a user uses several different programs, he or she must learn how to perform the same operations in a different way for each program used.” Likewise, the court rejected Lotus’s view that a user should be unable to employ a macro he wrote with the Lotus commands on a competing program, but instead should “have to rewrite his or her macros using that other program’s menu command hierarchy.”
Fair Use
The SG recognizes that Google “has raised important concerns about the effects that enforcing [Oracle’s] copyright could have on software development.” Nonetheless, the SG believes that these concerns are better addressed in the context of fair use on remand.
This belief is premised in part on the misunderstanding of Sega, discussed above. The SG also believes that fair use is the more appropriate theory for considering the protectability of interface information because it would “allow courts to consider the full range of competing equities” in each case.
This approach would significantly interfere with competition in the software industry. A developer would have to perform a fair use analysis before developing a compatible product. In a concurring opinion in the Lotus case, Judge Boudin observed that the widespread application of the fair use doctrine for purposes of achieving compatibility “would entail a host of administrative problems that would cause cost and delay, and would also reduce the ability of the industry to predict outcomes.”
Although the views of the SG can be influential, the Supreme Court has ignored the SG’s opinions on a number of copyright matters recently, and therefore may nevertheless grant Google’s petition for a writ of certiorari.
