The Federal Circuit’s Poorly Reasoned Decision in Oracle v. Google

by on

As Matt reported earlier, the Federal Circuit issued a very disappointing decision today in the litigation between Google and Oracle that has the potential to upset well-established practices in the computer industry that encourage interoperability and competition.

The case is complex factually and procedurally. The main issue before the Federal Circuit was the protectability under copyright of elements of the Java Application Program Interface (API), which Google incorporated into the Android API. The lower court had ruled that the method headers (a line or two of code at the beginning of each subroutine) and the organization of the 37 Java API packages were not protected by copyright under 17 U.S.C. 102(b).

Following a lengthy oral argument last year, the Federal Circuit reversed, finding that these elements were protectable. The Federal Circuit remanded the case back to the trial court to determine whether Google’s copying was permitted under the fair use doctrine (17 U.S.C. 107).

The opinion written by Judge O’Malley reflects a fundamental misunderstanding of the controlling precedent. On non-patent matters, the Federal Circuit must apply the law of the circuit from which the case arose. Here, because the case was decided by a court in the Ninth Circuit, the Federal Circuit is required to apply Ninth Circuit law.

The law in the Ninth Circuit could not be more clear: program elements necessary for interoperability are not protectable under copyright. In Sega v. Accolade, the Ninth Circuit found that the 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).”

Nonetheless, because the Sega court issued this ruling in the context of determining whether Accolade’s reverse engineering was a fair use, Judge O’Malley incorrectly held that the permissibility of copying interface information was a fair use question. She failed to appreciate that 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). The Ninth Circuit explained in Sega 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 Ninth Circuit’s decision in Sony v. Connectix that fair use permitted the reverse engineering by Connectix likewise was predicated on the unprotectability of the interface information Connectix was seeking.

Additionally, Judge O’Malley brushed aside the First Circuit’s ruling in Lotus v. Borland, which found that the Lotus 1-2-3 command structure was an unprotectable method of operation. Instead, Judge O’Malley relied upon the long discredited Third Circuit decision in Apple v. Franklin that compatibility is “a commercial and competitive objective which does not enter into the … issue of whether particular ideas and expressions have merged.” She further mischaracterized Borland as suggesting that computer programs could not receive copyright protection because they were functional works.

Judge O’Malley also completely distorted the policy arguments made by Google and its amici. She said that the arguments “appear premised on the belief that copyright is not the correct legal grounds upon which to protect the intellectual property rights of software programs.” Nothing could be further from the truth. Google and its amici made clear that they completely agreed that copyright protected software. The question before the court was whether copyright protected these specific program elements necessary for interoperability.

For the past 20 years, since decisions such as Sega v. Accolade, Computer Associates v. Altai, and Lotus v. Borland, computer programmers in the United States have understood that copyright does not protect program elements necessary for interoperability. Based on this understanding, programmers have freely copied these elements, which has encouraged enormous creativity, innovation, and competition in the digital environment. Judge O’Malley’s decision casts doubt on this understanding. By ruling that interoperability is relevant only to fair use, and not to protectability, Judge O’Malley would require every developer to perform a fair use analysis before developing an interoperable product. This would place U.S. programmers at a competitive disadvantage to developers in other jurisdictions that recognized that copyright does not protect program elements necessary for interoperability. The Court of Justice of the European Union, for example, in the 2012 decision in SAS Institute v. World Programming Ltd., ruled that program functionality, programming languages, and data formats were not protectable under copyright.

One possible light at the end of the tunnel is that on remand, the lower court could rule that the copying of program elements necessary for interoperability is a fair use as a matter of law. After all, the Ninth Circuit in Sega held that “where disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access, disassembly is a fair use of the copyrighted work, as a matter of law.” Such a ruling would restore the legal certainty that Judge O’Malley has upended.

Update:  Further reflections on this subject here.

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 the Oracle v. Google oral argument.

  • Alexander Gödde

    This is in no way a comment on the validity of the CAFC decision – and personally, I’m trying to get my head around what this means for programmers out there.

    So just a couple of comments about your remarks regarding the decision:

    The CAFC decision does not protect ideas or functionality.

    The fact that Google may not
    copy the Java API does not prevent it in any way from using the idea
    expressed therein, i.e. to have an API structured into packages, classes
    and methods, nor does it prevent it from employing the principles used in organizing these in organizing an API of its own.

    The API copyrightability also
    does not prevent Google from offering identical functionality to the Java
    API packages in question. It is just that they have to find their own way
    of structuring this functionality.

    Additionally (based what is quoted here from the case, I have not read the decision), SEGA seems to have no relevance to the present case:

    Google did not disassemble Oracle code to get access to ideas and functional elements. The Java API is necessarily public and well documented. The ideas at question are wholly expressed in the API declarations (and further explained by the documentation). The functionality is similarly defined by the API definitions. Implementations of the functionality were possible, and done, without reference to the Oracle implementations, and required no disassembly.

    It is not disassembly or reverse engineering that is at question here, but direct, outright copying of the API declaration code.

    • J. S. Greenfield

      The point of the reference to Sega isn’t to claim that this was reverse engineering. The point of Sega is that the court held that the aspect of Sega’s programs that are “functional requirements for compatibility with the Genesis console” — i.e., the external interfaces — “are not protected by copyright” under 17 USC 102(b).

      That this determination was made in the context of a case where reverse engineering was at issue doesn’t limit the holding to cases of reverse engineering.

      Your observation that Google could offer identical functionality using a different interface is irrelevant. They could offer identical functionality in a completely different language, also. But that wouldn’t enable developers to reuse code that they had already developed on Android, or to develop common code for use on Android and on other systems (that support Java). Rather, it would force developers to (effectively) completely rewrite all their existing code libraries to run on Android, and dual-develop future code.

      If Oracle believes that interfaces are properly copyrightable, then I hope that they are preparing to negotiate licenses and pay hefty royalties to Alcatel-Lucent and Bjarne Stroustrup, given that the vast majority of Java’s core language interface is lifted directly from C and C++.

      And I hope that they are similarly preparing to negotiate a license and pay hefty royalties to IBM for their adoption and use of SQL in their database products.

      (Somehow, however, I suspect that they would be singing a very different tune if any of those parties came a-calling, looking for decades worth of back royalties, and/or an injunction against continuing use.)

      • Alexander Gödde

        Had a look at Sega: It does support Google, but doesn’t give any reasons to why the court did not consider interfaces to be copyrightable.
        The statement(s) to this effect are clearly necessary for the decision (not orbiter dicta). Seeing that the CAFC considered the question at great length, it is somewhat surprising though that the Sega court did not even offer any discussion of it.

        Regarding the protected functionality question:

        There is a difference between functionality in principle (“and API which offers X, Y and Z”) and specific implementations of this functionality.
        The former neither falls in the realm of copyright, nor should it (that’s a matter for patent law, if anything).
        I think there are good arguments, based on the current laws, why the latter does.

        The question whether this should be, and what the consequences of this are in practice, is separate from applying the law as is. You listed some practical examples there which show how problematic copyrightability here is.

        • J. S. Greenfield

          That the Sega court didn’t discuss it at length is presumably an indication that they didn’t perceive it to be a controversial conclusion (and likely, an indication that even Sega didn’t argue that the interfaces, themselves, were protected by copyright).

          You’re correct that functionality is a matter for patent law (and I’m sure we can agree that cases where an API would qualify for patent protection are either non-existent, or nearly non-existent), but that would seem to be precisely the point of 102(b) — i.e., prohibiting the use of copyright to achieve patent-like protection of functionality.

          To illustrate this point, consider a non-software example. Apple comes out with a new device — e.g., the iphone 5, and they use a new power/data connector for it. The connector is not sufficiently original from a functionality standpoint to be eligible for patent protection. So anybody could create a functionally similar connector. The shape and configuration of the connector was a creative choice, but once Apple has selected it, only that particular shape and configuration can be used to interoperate with Apple devices, so it becomes functional.

          If Apple possesses a copyright on such, then they possess a right to prohibit anybody else from making a compatible device — e.g., a power adaptor, a music amplifier, etc.

          Now perhaps Apple decides that a robust third-party market for such items benefits them, so they let anybody create such devices, freely.

          After some time, a lot of these third-party devices have proliferated. Apple customers have spent a lot of money buying these various devices.

          A third party comes along with their own phone, and they want to enable users to re-use all these accessory devices they have invested in. So the third-party implements a compatible connector. There’s only one way to implement a compatible connector: using the same interface.

          Yet Apple asserts that its copyright is infringed by such.

          Apple has effectively granted themselves something that functions very similar to patent protection — for something that didn’t qualify for patent protection in the first place, and for a term lasting ~5x normal patent terms.

          The “creative” aspects of the connector were secondary to its functional purpose, and once chosen, they become 100% functional when it comes to interoperation. Yet Apple is allowed to elevate those secondary, and minor, creative aspects to outweigh the primary functional purpose, and grant themselves exclusive rights to the functional use of the connector.

          This would seem to be precisely the sort of thing that 102(b) was intended to prevent.

          And certainly there is a substantial history of jurisprudence predicated on the notion that interoperating doesn’t infringe. Furthermore, Congress was explicit in DMCA in carving out a specific exemption for reverse engineering for the purpose of interoperability (see 17 USC 1201(f)) — which strongly indicates that Congress was endorsing that jurisprudence and confirming that implementing interoperability is a non-infringing act that is to be encouraged — and accordingly, that interfaces are not copyrightable under 102(b).

          The Federal Circuit holding turns this entirely on its head.

        • wizardwerdna

          Review the 1st Circuit Opinion in Lotus v. Borland, where Lotus claimed that the API for its macro language (the tree of “/” commands) were protectible “look and feel” and expressive. Of course, one cannot write a compatible macro set without duplicating it, directly or indirectly. To grant copyright protection to that API is to functionally DENY Borland the right to execute Lotus 1-2-3 Macros. This merger of expression and function resulted in a technical inability to duplicate the functionality of 1-2-3, even though not a line of 1-2-3 code appeared in Quattro.

          This concept was never controversial before today, at least not since the 80s. Had APIs been protectible expression, the Phoenix BIOS that made PC clones possible would have been infringing, and only IBM could make PCs. Our world would have been quite different today. And our world is about to be. As lawyers, the litigation this new patent-like protection (without requirements of novelty and nonobviousness, and with virtually unlimited terms) will educate our grandchildren. It will, however, chill innovation. Its bad policy, and bad law.

  • Bruce Hayden

    Instead of jumping into an ongoing thread, I am going to start afresh.

    The basic problem here is that the CAFC has in essence provided copyright protection for functionality, in the guise of interoperability. While it is conceivable that the courts could have accepted copyrightability in the interoperability (similar to early look-and-feel), but for the most part they haven’t. Rather, the majority rule seems to be (or have been) that functionality is filtered out before looking at what is left to determine whether a work is protected by copyright. In the expression/functionality dichotomy, copyright is designed to protect original expression and patents to protect functionality.

    The difference between this and Fair Use, is that in the case of filtration of functional elements, you never get to the question of Fair Use, because there is no copyright. In the case of Fair Use, you have a copyright on original expression that would be otherwise infringed, absent Fair Use. Often, the result is the same. But not always. One difference is that some defendants may be able to excuse their actions through Fair Use, while others would not be able to. And, that may prove critical here, since the first of the four factors for Fair Use is the “The purpose and character of the use, including whether such use is of
    commercial nature or is for nonprofit educational purposes”. Google is a very large company, and its use is most assuredly commercial.

  • Tom Byron

    The author of this article has a tenuous grasp on the implications of the Sega case, the viability of Lotus v. Borland, and the import of Altai. Sega v. Accolade was a fair use case; nowhere did it say that APIs are not copyrightable under all circumstances. Sure, certain aspects of any computer program are not copyrightable under 102(b); and the Sega case was no different in this respect. But fair use PRESUMES copyrightability of the work used.

    Lotus is an unprincipled decision in its abject failure to propose a standard by which method of operation is to be distinguished from copyrightable content in the software context. Taken to an extreme, that court’s decision would not stop at a command or menu structure in undermining software copyright. It’s little surprise district courts within the First Circuit have fought not to apply its aimless methodology to other software copyright cases (on a literal/non-literal distinction in the methodology’s scope).

    Altai is almost certainly inconsistent with Lotus, as the former prescribes a more granular abstraction-filtration-comparison test for determining copyrightable “nuggets” within a program, and it does not limit that test to non-APIs. Altai certainly doesn’t take a wild hack at a huge command structure and call it uncopyrightable. In fact, an application of Altai to the facts in Lotus probably would have led to a contrary result.

    So far, the established principle the author points to does not exist. But he suggests that it might be restored at the fair use retrial. Does the author have any knowledge of fair use jurisprudence? (I’d like to think I do – see ). First of all, a fair use finding here isn’t even likely here for the simple fact that Google used a lot more than the “nothing” that was necessary to create a system that isn’t actually interoperable with Java. But even if fair use is found on remand, do you expect the court to say “this was an interoperable use, and all interoperable uses are fair”? That isn’t how a fact-sensitive, case-by-case test like fair use works. The court will go through the four factors and reach a conclusion – the last thing it wants to do is screw up again by overstating its holding.

    At bottom, this decision is entirely consistent with all precedent and statutory law – software is copyrightable to the extent it embodies an original/slightly creative work of authorship fixed in a tangible medium of expression. That was present here – nowhere is interoperability to be considered at the copyrightability stage. The court rightly pushes such concerns to a fair use analysis where they belong.
    Needless to say, I think this article is way off the mark.