Author(s): Pamela Samuelson
Year: 2013
Abstract:
Three
fundamental errors undergird Oracle’s legal position on this appeal of a
District Court ruling that the Java Application Programming Interfaces
(APIs) at issue in this case are unprotectable by U.S. copyright law.
First, Oracle takes an unduly narrow view of 17 U.S.C. § 102(b), which
provides that “[i]n no case does copyright protection…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 a protected work.
Oracle tries to read the procedure/process/system/method of operation
exclusions out of the statute by asserting that to take these exclusions
seriously would undermine copyright protection for computer programs.
But the legislative history of the Copyright Act of 1976 indicates that
Congress was well aware that computer programs would instantiate
numerous types of unprotectable processes and methods of operation. It
added the § 102(b) exclusions to the statute with the specific intent of
ensuring that copyright protection for programs would not be
interpreted too broadly. It is a basic canon of statutory interpretation
that courts must endeavor to give all words in a statute appropriate
meaning. If Congress has decided that computer programs are
copyrightable, but processes and methods they embody are not, then it is
incumbent on courts to determine which processes and methods embodied
in programs are outside the scope of copyright protection. After a full
trial on the merits and consideration of numerous briefs, the District
Court determined that the command structures of the Java APIs at issue
in this case were methods that enabled program interoperability, and
consistent with controlling Ninth Circuit decisions, ruled that these
APIs were unprotectable methods under § 102(b).
A second
fundamental error in Oracle’s legal position in this appeal is its
overbroad understanding about the protectability of “structure, sequence
and organization” (SSO) of computer programs. While some case law
endorses the view that program SSO may in appropriate cases be within
the scope of protection that copyright provides to programmers, courts
and commentators have recognized that the SSO concept is too imprecise
to be useful in software copyright cases. The main reason is because
this concept does not help courts to make appropriate distinctions
between protectable and unprotectable structural elements of programs.
Procedures, processes, systems, and methods of operation, almost by
definition, contribute to the structure and organization of works of
authorship that may describe or embody them. But this does not make
those elements protectable by copyright.
A third fundamental
error in Oracle’s legal position lies in its mistaken understanding of
the merger doctrine as applied to elements of computer programs that are
essential to interoperability. Oracle wants to believe that as long as
its engineers exhibited creativity in the design of the Java APIs and
those engineers were not constrained in their choices about how to
construct the APIs, the APIs are ab initio copyright-protectable
expression. However, the case law is clear that when the design choices
of subsequent programmers are constrained by the interface designs
embodied in earlier programs, the merger doctrine applies to the reuse
of elements necessary to achieving interoperability. All that subsequent
programmers must do is to reimplement those elements in independently
created code, as the District Court found that Google had done in this
case.
Keywords: Oracle v. Google appeal, antitrust, copyright
Link: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2272272