Guest Post by Pamela Samuelson, Richard M. Sherman Distinguished Professor of Law at Berkeley Law School. I asked Professor Samuelson to provide a discussion of the recent Federal Circuit decision in Oracle v. Google. DC.
Application programming interfaces (APIs) are informational equivalents of the familiar plug and socket design through which appliances, such as lamps, interoperate with the electrical grid. Just as a plug must conform precisely to the contours of the socket in order for electricity to flow to enable the appliance to operate, a computer program designed to be compatible with another program must conform precisely to the API of the first program which establishes rules about how other programs must send and receive information so that the two programs can work together to execute specific tasks.
No matter how much creativity might have gone into the design of the existing program’s interfaces and no matter how many choices the first programmer had when creating this design, once that the API exists, it becomes a constraint on the design of follow-on programs developed to interoperate with it. Anyone who develops an API is, in a very real sense, designing that aspect of the program for itself and for others.
One of the many errors in Judge O’Malley’s decision in the Oracle v. Google case was her insistence that the merger of idea and expression in computer program copyright cases can only be found when the developer of an API had no choice except to design the interface in a particular way. If there is any creativity in the design of the API and if its designer had choices among different ways to accomplish the objective, then copyright’s originality standard has been satisfied and not just the program code in which the API is embodied, but the SSO of the API, becomes copyrightable. Indeed, harkening back to an earlier era, Judge O’Malley repeated the unfortunate dicta from the Apple v. Franklin case about compatibility being a “commercial and competitive objective” which is irrelevant to whether program ideas and expressions have merged.
The Ninth Circuit in the Sega v. Accolade case, as well as the Second Circuit in Computer Associates v. Altai, have rejected this hostility toward achieving software compatibility and toward reuse of the APIs in subsequent programs.
Although purporting to follow Ninth Circuit caselaw, Judge O’Malley in Oracle v. Google ignored some key aspects of the holding in Sega. Accolade reverse-engineered Sega programs in order to discern the SSO of the Sega interface so that it could adapt its videogames to run on the Sega platform. The principal reason that the Ninth Circuit upheld Accolade’s fair use defense as to copies made in the reverse engineering process was because “[i]f disassembly of copyrighted object code is per se an unfair use, 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,” citing § 102(b). To get the kind of protection Sega was seeking, the Ninth Circuit said it “must satisfy the more stringent standards imposed by the patent laws.”
Judge O’Malley in Oracle also ignored the Ninth Circuit rejection of Sega’s claim that Accolade infringed based on the literal copying of some Sega code insofar as that code was essential to enabling the Accolade program to run on the Sega platform. That Sega code might have been original in the sense of being creative when first written in source code form, but by making that code essential to interoperability, the expression in that program merged with its function, and hence Accolade’s reproduction of it was not an infringement.
The SSO of the Sega interface was almost certainly creative initially as well. Yet, once that interface was developed, it was a constraint on the design choices that Accolade and other software developers faced when trying to make videogames to run on Sega platforms. The Second Circuit similarly rejected Computer Associates’ claim that Altai had infringed the SSO of its program interface and suggested that patents might be a more suitable form of legal protection for many innovations embodied in software.
Under Sega and Altai, the SSO of APIs are not within the scope of copyright protection for computer programs. Subsequent cases—at least until the Federal Circuit decision in Oracle v. Google—have overwhelmingly endorsed this approach to compatibility issues in software cases.
Perhaps Judge O’Malley was worried that if she did not extend copyright protection to the Java APIs in Oracle v. Google, there would be too little intellectual property protection available to computer programs. After all, she was one of the Federal Circuit judges who would have upheld all of the patent claims for computer-implemented inventions in the CLS Bank v. Alice Corp. case that is now pending before the U.S. Supreme Court. She joined an opinion that warned that if courts struck down the claims in CLS Bank, this mean that hundreds of thousands of software and business method patents would be invalidated. Given the Supreme Court’s skepticism about the Federal Circuit’s rulings on patentable subject matter, there is reason to think that at least some software patents may indeed fall when the Court issues its opinion in Alice. Would such invalidations affect the scope of copyright protection for software?
In the most expansive interpretation of software copyright law since Whelan v. Jaslow, Judge O’Malley in Oracle v. Google endorsed dual protection for APIs from both copyright and patent law. This ignored an important statement from that court’s earlier ruling in Atari Games v. Nintendo that “patent and copyright laws protect distinct aspects of a computer program.” The Oracle opinion instead invoked the dicta from Mazer v. Stein that “[n]either the Copyright Statute nor any other says that because a thing is patentable it may not be copyrighted.”
While it may have been true that the statuette of a Balinese dancer in Mazer was eligible for both copyright as a sculpture and a design patent for an ornamental design of an article of manufacture (as a lamp base), nothing in that decision or any other has upheld utility patent and copyright protection in the same aspect of the same creation, and it seems unlikely that the Supreme Court would abrogate the longstanding tradition tracing back to Baker v. Selden that copyrights protects expression in works of authorship and patents protect utilitarian designs.
In “The Strange Odyssey of Software Interfaces as Intellectual Property,” http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1323818, I traced the tortuous evolution of the law in relation to the protection of software interfaces. At first, they were not treated as intellectual property at all. Firms published APIs so that others would make programs to run on their computing systems. As firms recognized that they could license interface information to generate revenues, APIs were protected as trade secrets. In the mid- to late 1980s, some argued that the “structure, sequence, and organization” (SSO) of APIs should be protected by copyright law, but by the early 1990s, courts decided they were unprotectable elements of programs, more suited to patent than to copyright protection. And so firms began patenting interface designs, as well as continuing to license them as trade secrets.
If Judge O’Malley’s opinion in the Oracle v. Google case is to be believed, APIs have migrated back into copyright’s realm big time. Unless overturned by the Supreme Court or repudiated or distinguished in subsequent cases, the Oracle decision may well reignite the software copyright wars that so many of us thought had died out after the Sega, Altai, and their progeny.