“We thus decline any invitation to declare the protection of software programs should be the domain of patent law, and only patent law.”
-- Oracle America, Inc. v. Google Inc. (Fed. Cir. May 9, 2014)
The intersection of copyright and patent law is of great interest to anyone who seeks to develop or use creative works that are also functional, in particular developers of software, which by its very nature is functional. In Oracle v. Google, the overlap in protection between these two intellectual property regimes is squarely at issue. Oracle, owner of the Java software platform, alleges that Google infringed Oracle’s copyright interests in its application programming interfaces (“APIs”) when Google developed its Android mobile platform. Google argues that the APIs are functional and not entitled to copyright protection. The Federal Circuit has now rejected Google’s arguments, leading to the pronouncement above.
Written by Judge Kathleen O’Malley and reversing the decision of the U.S. District Court for the Northern District of California, the Federal Circuit held that the structure, sequence and organization (“SSO”) of Oracle’s Java programming interfaces are protected by copyright law, and remanded to the district court to determine whether or not Google’s copying of those interfaces was a fair use. The Court held that not only the literal line-by-line software code of the APIs was protectable, but also its SSO, rejecting Google’s arguments that it had to copy the Java SSO in order to ensure interoperability. The Court remanded on fair use because it believed there were material issues of fact as to whether Google’s use was transformative, whether its use had any negative market impact on Oracle, and whether “interoperability” might be relevant to the second and third fair use factors.
Perhaps the most interesting—and unusual—aspect of the decision is its final section, in which the Court directly addresses Google’s sweeping policy arguments about the proper scope of intellectual property protection for software. Noting that Google had cited scholars advocating that software should only be protected by patent law, or that an entirely new type of protection should be created for software, the Court pointed out that there are also advocates that press for protection of software under copyright law instead of patent law, especially given the rise of patent trolls (although the Court does not use that term). Pointing to the Supreme Court’s language in Mazer v. Stein, 347 U.S. 201 (1954) that no federal statute “says that because a thing is patentable it may not be copyrighted,” the Court stated that until the Supreme Court or Congress instructs otherwise, it was “bound to respect the 9th Circuit’s decision to afford software programs protection under the copyright laws.”
Surely the Court’s mind, at least in part, was on its prior decision in Alice Corporation Pty. Ltd. v. CLS Bank International, now pending review before the Supreme Court. That case involves the availability of patent protection for a computerized trading platform, and observers had hoped that the Federal Circuit would bring some clarity to the scope of software patentability, in particular when software or business-method patents should be disqualified as mere abstract ideas. However, the Court splintered and seven separate opinions were issued, with the 10 judges on the panel taking very different approaches, leaving it up to the Supreme Court to (possibly) bring clarity to the issue. Interestingly, Judge O’Malley authored a dissent in Alice Corporation that would have held all of the patents eligible for protection, perhaps suggesting a somewhat expansionist approach to the scope of both patent and copyright law.
The case
In Oracle v. Google, Oracle alleged that Google first approached it and asked to license the Java software, but when license negotiations broke down, Google simply copied 37 packages of computer source code, in the form of the Java APIs, and used that code to build out Android. Google did not copy the entirety of the Java software by any means, but Oracle argued that it duplicated verbatim 7,000 lines of “declaring code” and the structure and organizations of the APIs, and then developed its own implementing code (the bulk of the Android platform). It argued that because the APIs were functional, they were not copyrightable, and that it was required to copy them to ensure interoperability.
Oracle brought suit against Google in the Northern District of California, alleging that Google’s Android mobile operating system infringed Oracle’s patents and copyrights. A jury found that Google had not infringed Oracle’s patents. Then, having been told by the judge to assume that Oracle’s APIs were protectable under copyright, the jury found that Google had infringed Oracle’s copyrights in the 37 Java packages and a specific computer routine; that Google had not infringed eight decompiled security files; and it deadlocked on Google’s fair use defense.
After the jury verdict, Judge Alsup issued a decision on copyrightability, finding that the 37 APIs were not protected by copyright (he did find that Google had infringed with respect to the eight decompiled surety files). By determining that Oracle’s APIs were not entitled to copyright protection in the first instance, he mooted the question of whether Google’s Android software infringed Oracle’s APIs, and thus also mooted the fair use question.
Both parties appealed to the Federal Circuit. Oracle argued that Google was free to recreate the Java functionality, but could not do so by copying the literal code itself, or its non-literal structure, sequence and organization (“SSO”). Google countered that the “interoperability” of the Java APIs was key to the entire software ecosystem that had later developed around Java, and this interoperability considerations rendered the APIs wholly functional and therefore not entitled to protection. Oracle argued that questions of interoperability with other, later-developed software are not properly part of the copyrightability analysis because they do not constrain the author’s choices when the author is creating the work. Rather, those are questions, if at all, for the fair use analysis.
The Federal Circuit reversed Judge Alsup and held that the 7,000 lines of Java code, as well as the non-literal aspects of that code (the SSO), are protected by copyright. In reaching its decision, the Federal Circuit first restated two long-standing principles of copyright law: That copyright protection extends only to the creative expression in a work of authorship, not the functionality or idea of the work; and that protection extends not just to the literal aspects of the work, but also to “non-literal” aspects. Courts look at the “levels of abstraction” in a work to determine what aspects beyond the literal text are protected—essentially this can be thought of as a sliding scale that extends from concrete expression up to the level of pure concept. Courts are tasked with drawing the sometimes difficult line where a non-literal aspect of the work is sufficiently original to be protected, versus only an “idea.”
As the Court also noted, the Copyright Act expressly mandates that software is a “work of authorship” covered by copyright law, so there was no real dispute that the “literal” aspects of Oracle’s software, here the source and object code of the API’s, were protected by copyright law. The Court also cited cases finding that protection for “non-literal” aspects of software, defined in those cases as the “sequence, structure and organization” (“SSO”) of the software, can also be protected so long as it “qualifies as an expression of an idea [rather than] in idea itself.” See Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2df 1173 (9th Cir. 1989). Thus the question for the Oracle APIs was, in the Federal Circuit’s view, whether the software’s SSO was just an idea, or contained separable, protectable expression.
In order to “ferret out apparent expressive aspects of a work and then separate protectable expression from ‘unprotectable ideas, facts, processes, and methods of operation,” the Court turned to the “abstraction-filtration-comparison” test created by the 2nd Circuit but adopted by the 9th Circuit. Notably, that test “rejects the notion that anything that performs a function is necessarily uncopyrightable,” a notion that Judge Alsup’s decision appeared to adopt. Rather than adopting a bright line, the test is a “more nuanced assessment” that examines each program on a case-by-case basis, first breaking it down into its structural constituents, then filtering out unprotectable material, and comparing the remaining “nugget” with the allegedly infringing software.
Backing up a step, it is worth noting that generally speaking, copyright suits ask two basic questions: First, is the plaintiff’s work subject to copyright protection in the first instance, and second, has the defendant infringed that work? The correct sequencing of analyses in each part of this relatively straightforward two-step process assumed primary importance in the case, with the court taking great pains to lay out which tests are applied during each phase. The result is a clear, reasoned opinion on all fours with applicable precedent in the 9th Circuit, that confirms that copyright protects non-literal aspects of software even if those elements could be described as functional, so long as there are other ways to express the same functionality.
The Court explained that in all circuits, the abstraction step is a part of the threshold question of whether the plaintiff’s work is protected by copyright, and the comparison step is clearly part of the analysis of whether the defendant’s work infringes plaintiff’s work. However, for the middle step that requires filtering out unprotectable elements, including application of the doctrines of merger and scenes a faire, the circuits differ as to when this examination occurs. The Court did not pass judgment on which of these views is correct (although it seemed to hint that this step logically belongs under the copyrightability analysis), as it was required to apply 9th Circuit law and the 9th Circuit clearly places the filtration step in the infringement analysis.
One thing the Court made crystal clear, and that is essential to understanding the result in this case, is that any limitations on the copyrightability or scope of protection of a work must be considered as of the time of creation of the work by the original author. For instance, the merger doctrine recognizes that if an idea or function can only be expressed in one way, the idea/function and the expression merge and the expression cannot be protected because to do so would rob the public of access to the idea or functionality. The Court explained that the question of whether there are multiple ways of expression an idea or function, such that the merger doctrine would not apply, must take into account the options at the time of authorship.
Applying this analysis, the Court first found that the 7,000 literal lines of the Java declaring code were protectable, and turned quickly to the question of whether Google infringed that code. Google argued that there was a “merger” of the functional aspects of the declaring code with the expressive aspects of the code, but the Court held that the record showed that at the time Oracle’s programmers were developing the Java APIs, there were “unlimited options” as to how to structure it. Therefore, the Court found that the copying of the literal code constituted infringement unless Google could assert a valid fair use defense (see below).
The heart of the case came next: Whether Android infringed the non-literal SSO of the Oracle APIs. This is the issue which so disturbs some members of the software industry, because (as everyone agrees) the structure and organization of APIs serves a functional purpose, and if new software developers who are building out applications that need to interact with the original software cannot copy that structure, they will be forced to pay license fees in order for their software to function. The question was essentially a reprise of the merger argument: Did the functionality merge with the expressive aspects of the software’s structure?
Google pointed first to a 1995 case from the 1st Circuit, affirmed without an opinion by the Supreme Court, that held that a “method of operation” (in that case, a menu command hierarchy) could not be protected. That decision appears to leave no room for any software that qualifies as a method of operation can be protected, regardless of whether there were multiple ways to express the method. The Federal Circuit in this case rejected that all-or-nothing approach, finding it inconsistent with 9th Circuit law, and not logical. Rather, all software likely constitutes a method of operation, and yet if there are multiple ways to structure software to produce the same functionality, by protecting one expression of those multiple ways, the law does not preclude the public from replicating the functionality itself.
Crucially, Google also raised the question of “interoperability” of the Java APIs as a rationale for denying protection to the SSO of those APIs. According to the district court, “Google replicated what was necessary to achieve a degree of interoperability” with Java, and this demonstrated that these aspects of the Java APIs were not protectable. The Federal Circuit strongly disagreed, finding that while externalities that limit a software creator’s choices in the first instance may indeed limit the scope of protection, the fact that later developers want to develop compatible software does not somehow retroactively affect the copyrightability of the work. In other words, if the creators of Java had needed to make it interact with some other application at the time Java was being created, and could only structure their code in a particular way in order to do so, then the structure would not be protectable. But when faced with a wide range of possibilities, the fact that they chose a particular structure that the market then came to accept as a preferred structure, does not preclude copyrightability.
Google relied on two 9th Circuit fair use cases (Sony and Sega) that discussed interoperability in the fair use context but used language that appeared to conflate the fair use question with the copyrightability question; the Federal Circuit rejected the suggestion that these cases created a sui generis “interoperability exception” to copyrightability.
Critical to the Court’s approach was the notion that nothing in its ruling prevents parties in Google’s position from accessing and duplicating the functionality of APIs—such parties are only barred from duplicating the precise structure of those APIs where there are multiple options for recreating the functionality using different structures. Because Google focused its argument and evidence on its need to create duplicate the Java structure so that Java programmers to be able to easily migrate to Android (which the Court said might be relevant for fair use, but not copyrightability), Google effectively conceded that it could have duplicated the functionality of the APIs by other “expression.” If that functionality could not be duplicated in other ways, then the result might have been different.
Ultimately, the Court remanded to the district court on the fair use question, leaving unresolved the issues of whether Android constitutes a transformative use of the Java APIs (although the Court chided Google for “overstating” what activities can be considered transformative); whether Google’s “competitive desire to achieve commercial interoperability” might be relevant to a fair use analysis; and how substantial any market impact was on Oracle, given Google’s allegations that Oracle had never developed its own mobile platform but Oracle’s response that it was already licensing in the mobile space when Google began developing Android. While the cards appear stacked against Google on remand, there is still a window of opportunity for it to prove that—despite its admitted copying of protected software—it was entitled under the law to make use of it in the way that it did here.
