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.