On Friday, the Court of Appeals for the Federal Circuit released its decision in Oracle America Inc. v. Google Inc. The dispute concerned allegations that Google copied elements from Oracle’s Java software platform when it developed its Android platform for the mobile market. The Federal Circuit handed Oracle a solid victory, ignoring Google’s push for an interoperability exception to excuse copying that was not for the purpose of interoperability.
The facts of the dispute are essentially this: Sun Microsystems (which has since been acquired by Oracle) developed the Java platform in 1996 with the idea of creating a virtual machine that allowed software to run on any platform or operating system – allowing programmers to “write once, run anywhere.” In 2005, Google acquired mobile startup Android, Inc. with an eye toward entering the mobile market. It entered into negotiations with Sun to license and adapt the Java platform for its mobile devices. The negotiations were ultimately unsuccessful – Google refused to “make the implementation of its programs compatible with the Java virtual machine or interoperable with other Java programs”, which ran counter to Sun’s commitment to interoperability.
So Google began to develop its own virtual machine to interact with the Java platform. It also wanted to take advantage of the developer community that Sun had built up rather than spending the time and effort building its own, so it copied the declaring source code from 37 Java API packages verbatim, as well as the “taxonomy” of the packages – the structure, sequence, and organization (“SSO”) of the packages and their respective classes. That way, developers already familiar with Java could easily begin writing programs for Google’s mobile platform, increasing its value.
This case does require some understanding of the technology at issue. The court begins by noting, “This copyright dispute involves 37 packages of computer source code. The parties have often referred to these groups of computer programs, individually or collectively, as ‘application programming interfaces,’ or API packages, but it is their content, not their name, that matters.”
The Java platform in its entirety provides an environment for programmers to develop applications that can run on any device or hardware. It essentially consists of the Java development kit (JDK) that programmers use to create their apps and the Java virtual machine (JVM) that runs the code, translating the app source code into source code that the machine the app is running on can understand.
Included in the development kit are a number of “ready-to-use” Java programs available to programmers to perform common computer functions – these are the API packages involved in the case. They are, in the words of the court, “shortcuts” that allow programmers to execute certain functions rather than writing the function from scratch. Each function is referred to as a “method.” Related methods are grouped together into “classes.” Related classes, in turn, are organized into “packages.”
The source code that the packages are composed of can logically be divided into two types: (1) the “implementing code” is the guts of the methods, the individual steps that comprise a specific function, and (2) the “declaring code” is the “header” that identifies the method and tells the programmer what the method needs, like what inputs must be provided and what outputs can be expected.
Oracle licenses its Java platform and API packages in three different ways: an open source license on its declaring and implementing code that is free but requires licensees to offer any changes or additions they contribute through open source licensing as well; a Specification license that provides licensees with the declaring code but not the implementing code; and a Commercial license, which allows businesses to “use and customize the full Java code in their commercial products and keep their code secret” in exchange for royalties.
A quick discussion of the procedure in the litigation here is also helpful, as it is a bit unusual. The issue of copyrightability – whether the declaring code and SSO are protectable in the first instance – was given to the trial judge to decide. The issue of infringement – whether Google’s copying of these intruded onto Oracle’s exclusive rights – was given to the jury, along with Google’s affirmative fair use defense. Because the issues were being determined simultaneously, the jury was instructed to assume copyrightability when it determined infringement and fair use.
The jury found that, presuming the API packages were copyrightable, Google had infringed, but it was unable to reach a verdict on fair use. However, the trial judge would later determine that the declaring headers and SSO were not protected by copyright, and Oracle appealed.
On appeal, it was undisputed that Google had “copied 7,000 lines of declaring code and generally replicated the overall structure, sequence, and organization of Oracle’s 37 Java API packages.” The question was whether these elements are protected by copyright. The district court had determined they were not because “(1) there was only one way to write the Java method declarations and remain ‘interoperable’ with Java; and (2) the organization and structure of the 37 Java API packages is a ‘command structure’ excluded from copyright protection under Section 102(b).”
Oracle argued that the district court was wrong when it “(1) concluded that each line of declaring code is uncopyrightable because the idea and expression have merged; (2) found the declaring code uncopyrightable because it employs short phrases; (3) found all aspects of the SSO devoid of protection as a ‘method of operation’ under 17 U.S.C. § 102(b); and (4) invoked Google’s ‘interoperability’ concerns in the copyrightability analysis.” The Federal Circuit agreed with Oracle on all its points.
Essentially, said the Federal Circuit, the district court approached the issue from the wrong direction, using doctrines meant to determine the scope of conduct that constitutes infringing activity in order to analyze the threshold question of copyrightability. (Or, as Lee Gesmer states it, “Filtration for interoperability should be performed ex ante, not ex post.”) The Circuit also held that concerns about interoperability that the district court brought up should be reserved for a fair use analysis.
The Federal Circuit began its analysis by noting that “the application of copyright law in the computer context is often a difficult task” and then proceeded step-by-step through the question of copyrightability.
Computer programs can be protected by copyright as “literary works.” To be protected, a work must be “original” and possess “at least some minimal degree of creativity.” But protection extends only to the particular expression of an idea in a work, not to the idea itself. The Copyright Act refers to this distinction between ideas and expression in Section 102(b), which says:
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, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
The Circuit observes that among the principles incorporated into this section is the rule that “those elements of a computer program that are necessarily incidental to its function are … unprotectable.”
It goes on to state that copyright protection extends to both literal and non-literal elements of computer programs. The literal elements include the verbatim source code. Non-literal elements include such components as the program’s sequence, structure, and organization. Here, Oracle was claiming copyright protection to both: “(1) literal elements of its API packages—the 7,000 lines of declaring source code; and (2) non-literal elements—the structure, sequence, and organization of each of the 37 Java API packages.”
As the court points out, no one disputes that these elements are original. What is at dispute is whether these elements are copyrightable under Section 102(b), and both parties disagree over the Section’s interpretation and application. In the end, the Circuit rejected Google’s argument that copyrightability of software programs is a two-step process, “wherein Section 102(a) grants copyright protection to original works, while Section 102(b) takes it away if the work has a functional component.” The court explained that both sections must be considered in tandem.
In order do so, the Ninth Circuit endorses the Second Circuit’s three step “abstraction-filtration-comparison” test.
In the abstraction step, the court “first break[s] down the allegedly infringed program into its constituent structural parts.” In the filtration step, the court “sift[s] out all non-protectable material,” including ideas and “expression that is necessarily incidental to those ideas.” In the final step, the court compares the remaining creative expression with the allegedly infringing program.
As the Federal Circuit explains, the second step involves consideration of “traditional copyright principles of originality, merger, and scenes a faire” to determine first whether expression is original to the programmer and second whether a particular element was included because of efficiency considerations, requirements external to the program itself, or taken from the public domain.
The first step of the abstraction-filtration-comparison test is part of the copyrightability analysis. The last question goes to infringement. In the Ninth Circuit, the second step straddles the line; questions of originality go toward copyrightability, while “concepts of merger and scenes a faire are affirmative defenses to claims of infringement.” According to the Circuit, “While the trial court mentioned the abstraction-filtration-comparison test when describing the development of relevant law, it did not purport to actually apply that test. Instead, it moved directly to application of familiar principles of copyright law when assessing the copyrightability of the declaring code and interpreted Section 102(b) to preclude copyrightability for any functional element ‘essential for interoperability’ ‘regardless of its form.’” The Circuit next addresses each holding of the lower court in turn.
First, the district court held that the declaring code was not entitled to copyright protection under the merger and short phrase doctrines. The merger doctrine prevents infringement of expression when that expression is the only way an idea can be expressed. For software, that means merger allows copying of elements that “are the only and essential means of accomplishing a given task.”
As stated above, however, the merger doctrine is used to determine infringement, not copyrightability. In addition, the district court improperly looked at merger from Google’s perspective. Instead, the Circuit explains, “merger cannot bar copyright protection for any lines of declaring source code unless Sun/Oracle had only one way, or a limited number of ways, to write them.” And, as the evidence shows, Sun/Oracle had virtually unlimited ways to write its declaring code.
Short phrases, of course, are not protectable, but as the Circuit observes, that does not mean any work that contains short phrases is not copyrightable. The relevant question is “whether those phrases are creative.” The Circuit explains:
By analogy, the opening of Charles Dickens’ A Tale of Two Cities is nothing but a string of short phrases. Yet no one could contend that this portion of Dickens’ work is unworthy of copyright protection because it can be broken into those shorter constituent components. The question is not whether a short phrase or series of short phrases can be extracted from the work, but whether the manner in which they are used or strung together exhibits creativity.
The Circuit ultimately concludes that “Oracle ‘exercised creativity in the selection and arrangement’ of the method declarations when it created the API packages and wrote the relevant declaring code,” thus affording them copyright protection.
Next, the Circuit looks at the “scenes a faire doctrine,” which the trial court rejected but which Google raises on appeal. This doctrine bars from copyright protection “commonplace expressions” such as stock characters and scenes. For software, says the Circuit, “the scene a faire doctrine denies protection to program elements that are dictated by external factors such as ‘the mechanical specifications of the computer on which a particular program is intended to run’ or ‘widely accepted programming practices within the computer industry.’”
Google argued that “because programmers have become accustomed to and comfortable using the groupings in the Java API packages, those groupings are so commonplace as to be indispensable to the expression of an acceptable programming platform.” The Federal Circuit rejects this argument. As with the merger doctrine, the scenes a faire doctrine involves the question of infringement, not copyrightability. And also like the merger doctrine, “the focus of the scenes a faire doctrine is on the circumstances presented to the creator, not the copier. The court’s analytical focus must be upon the external factors that dictated Sun’s selection of classes, methods, and code—not upon what Google encountered at the time it chose to copy those groupings and that code.”
Structure, Sequence and Organization
The Federal Circuit next looks at the trial court’s conclusion that the structure, sequence, and organization (SSO) of the API packages is not copyrightable because it is a “system or method of operation.” The trial court appears, to the Federal Circuit, to have reached this conclusion by relying on the First Circuit’s Lotus Development Corp. v. Borland International, Inc. decision.
In Lotus, as the Federal Circuit explains, software developer Borland sought to develop a spreadsheet to compete with the popular Lotus 1-2-3. In doing so, it copied the menu command hierarchy of Lotus 1-2-3—where commands such as “Copy,” “Print,” and “Quit” are arranged into menus and submenus—in its entirety in order to make it easier for Lotus users to switch. The First Circuit held that this menu command hierarchy is not copyrightable subject matter. It is instead a “method of operation” which Section 102(b) bars from copyright protection. The First Circuit defined a “method of operation” as “the means by which a person operates something, whether it be a car, a food processor, or a computer” and held that the menu command hierarchy is the means by which a person operates Lotus 1-2-3.
The Circuit agreed with Oracle that it was incorrect to rely on Lotus because “it is distinguishable on its facts and is inconsistent with Ninth Circuit law.” The Circuit explain that, unlike here, Lotus did not involve any copying of the underlying code, the elements copied were not found creative by the Lotus court, and the elements copied were “essential to operating” the system.
“More importantly,” says the Circuit, “the Ninth Circuit has not adopted the court’s ‘method of operation’ reasoning in Lotus, and we conclude that it is inconsistent with binding precedent.” The Circuit sees Lotus’s rule that functional elements are never copyrightable as inconsistent with the abstraction-filtration-comparison analysis, a conclusion the Tenth Circuit had also come to when it rejected the adoption of Lotus. Indeed, notes the Federal Circuit, “no other circuit has adopted the First Circuit’s ‘method of operation’ analysis.”
The problem the Federal Circuit sees with the idea that functional elements can never be copyrightable is that it would mean no computer program is protectable—“computer programs are by definition functional.” The Circuit ultimately concludes “that a set of commands to instruct a computer to carry out desired operations may contain expression that is eligible for copyright protection.” The Circuit explains what this distinction looks like in the case here:
On appeal, Oracle does not—and concedes that it cannot—claim copyright in the idea of organizing functions of a computer program or in the “package-class-method” organizational structure in the abstract. Instead, Oracle claims copyright protection only in its particular way of naming and organizing each of the 37 Java API packages. Oracle recognizes, for example, that it “cannot copyright the idea of programs that open an internet connection,” but “it can copyright the precise strings of code used to do so, at least so long as ‘other language is available’ to achieve the same function.” Thus, Oracle concedes that Google and others could employ the Java language—much like anyone could employ the English language to write a paragraph without violating the copyrights of other English language writers. And, that Google may employ the “package-class-method” structure much like authors can employ the same rules of grammar chosen by other authors without fear of infringement. What Oracle contends is that, beyond that point, Google, like any author, is not permitted to employ the precise phrasing or precise structure chosen by Oracle to flesh out the substance of its packages—the details and arrangement of the prose.
The lower court based its decision in part on the conclusion that “Google replicated what was necessary to achieve a degree of interoperability—but no more, taking care, as said before, to provide its own implementations” and reached this conclusion by relying on the Ninth Circuit decisions in Sega Enterprises v. Accolade, Inc. and Sony Computer Entertainment, Inc. v. Connectix, Corp.
But as the Federal Circuit points out, both Sega and Sony are fair use cases, not copyrightability cases. In addition, they are distinguishable because “defendants in those cases made intermediate copies to understand the functional aspects of the copyrighted works and then created new products.” Here, however, Google copied literal and non-literal elements of Oracle’s software into its own product, not to reverse engineer Java “to figure out the ideas and functionality of the original” in order to create “its own structure and its own literal code.”
The Circuit rejects too Google’s suggestion of a broader “interoperability exception” to copyrightability as inconsistent with Ninth Circuit case law and the abstraction-filtration-comparison inquiry (which the Ninth Circuit endorsed in Sega itself). The Circuit once again reminds of the fact that copyrightability is focused on the choices available to the plaintiff when creating the original program. It notes “the relevant compatibility inquiry asks whether the plaintiff’s choices were dictated by a need to ensure that its program worked with existing third-party programs. Whether a defendant later seeks to make its program interoperable with the plaintiff’s program has no bearing on whether the software the plaintiff created had any design limitations dictated by external factors.”
The Federal Circuit reserves its strongest words against Google in its discussion of interoperability. “Indeed,” says the Circuit, “given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google’s interoperability argument confusing.” It goes on to point out, “The compatibility Google sought to foster was not with Oracle’s Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue.”
The Circuit ends by looking at Google’s assertion of a fair use defense, which the original jury was unable to reach a verdict on. Oracle argues on appeal that the Circuit should rule against fair use as a matter of law, saying “Google knowingly and illicitly copied a creative work to further its own commercial purposes, did so verbatim, and did so to the detriment of Oracle’s market position.” While the Circuit agrees that “Oracle’s position is not without force,” it ultimately holds that “due respect for the limit of our appellate function requires that we remand the fair use question for a new trial.” It does so because a number of material facts remain in dispute (fair use is a mixed question of fact and law).
First, disagreement remains over whether Google’s use is “transformative,” though the Circuit does point out that “Google overstates what activities can be deemed transformative under a correct application of the law.” Second, though it was error for the judge to consider interoperability in the copyrightability analysis, it may be relevant to a fair use inquiry. Finally, concerning market impact, the Circuit notes that Oracle disputes the district court’s finding that “Sun and Oracle never successfully developed its own smartphone platform using Java technology,” saying it had been licensing in the mobile and smartphone markets when Google copied its API packages, a move that harmed those commercial opportunities.
This decision is just shy of a complete victory for Oracle. The Federal Circuit rejected all of Google’s arguments unequivocally. It agreed with all of Oracle’s arguments except for its argument that it should reject Google’s fair use defense—though even then, it showed a good deal of skepticism toward the defense (and, on the market harm prong, moved the needle more in favor of Oracle). But while nothing has been publicly announced yet, I imagine Google will seek a rehearing in front of the entire Federal Circuit before going back to the district court (and there’s always the chance Supreme Court review will be sought at a later point before any return to the district court).
Within hours of the decision, tech advocates and the tech press were already predicting the utter destruction of innovation. It has been called “potentially disastrous” and “dangerous” (along with predictable assertions that the judges involved must not understand technology). I believe, even if you disagree with the outcome of the case, these charges are greatly exaggerated. It’s difficult to see how interoperability is jeopardized by a case where the defendant deliberately set out to create a program that was not interoperable. And the decision does not impact the ability of developers using third-party APIs. At issue was not a defendant interacting with or using a third party’s API, but rather a defendant who copied and replicated an API qua API to be incorporated into its own platform.
I tend to agree with Oracle’s attorney Rosenkranz, who said, “There’s nothing at all astounding in what the Federal Circuit did.” The decision is methodical and well-reasoned. It correctly applies core copyright doctrines and existing precedent. No doubt it will become a seminal case in software copyright law, due in no small part to its thorough discussion of relevant doctrines, unless and until a full panel or the Supreme Court weighs in.