Back in May, the appeals court for the Federal Circuit (CAFC) enhanced its reputation of consistently getting basic patent law wrong by deciding to get copyright law wrong
too, in declaring that APIs were copyrightable subject matter, in the Oracle v. Google lawsuit. As we explained at the time, the court appeared to make some rather serious fundamental errors, not understanding the difference between software and interfaces (and worse, totally misquoting some experts). Last month, Google asked
the Supreme Court to review the case. On Friday, a bunch of interesting amicus briefs were filed, asking the Supreme Court to fix the CAFC's big mistakes.
Perhaps the most interesting was put together by the EFF, and was signed by 77 computer scientists
, including many of the most well-known and most respected computer scientists around, including Hal Abelson, Brian Behlendorf, Ward Cunningham, Peter Deutsch, David Dill, Dave Farber, Ed Felten, Mitch Kapor, Alan Kay, Brian Kernighan, Guido van Rossum, Avi Rubin, Bruce Schneier and Bjarne Stroustrup among others. There are a lot more, obviously, but those were just a few of the names that stood out.
The key point made in the filing
is that this upsets decades of what was considered a settled matter in computer science, while highlighting how much of computer history was built off of the recognition of non-copyrightable APIs, allowing for the creation of interoperable systems, much of which drove the early computer revolution. Here's the summary from the brief:
For decades, computer scientists have relied on
the open nature of APIs to enable rapid innovation in
computer technology. For decades, circuit courts have
supported that reliance, concluding that Section 102(b) of
the Copyright Act protects a programmer’s source code
as creative expression, but does not cover the processes,
systems, and methods of operation that code may employ
to interface with other software. The district court
correctly followed that precedent and rejected Oracle’s
claim that the Java APIs could be copyrightable. Sadly, the
Federal Circuit chose to split with the other circuits and
reverse the district court. That decision upended decades
of industry practice and threatens the basic principles
upon which our technology sector was built.
Not surprisingly, the Federal Circuit’s decision has
been harshly criticized. As many commentators have
noted, if the Federal Circuit’s view had been accepted
at the birth of modern computing, many important
technologies would never have existed, and/or succeeded.
For example, the widespread availability of diverse, cheap,
and customizable personal computers owes its existence to
the lack of copyright on the specification for IBM’s Basic
Input/Output System (BIOS) for the PC. And open APIs
were essential to many modern computing developments,
including those of operating systems such as UNIX,
programming languages such as “C,” the Internet’s
network protocols, and cloud computing.
Today, open, uncopyrightable APIs continue to spur
the creation and adoption of new technologies. When
programmers can freely reimplement or reverse engineer
an API without obtaining a costly license or risking a
lawsuit, they can create compatible software that the
interface’s original creator might never have envisioned
or had the resources to develop. Moreover, compatible
APIs help enable people to switch platforms and services
freely, and to find software that meets their needs
regardless of what browser or operating system they use.
Without the compatibility enabled by the open nature of
APIs, consumers could be forced to leave their data and
programs behind when they switch to a new service.
The freedom to reimplement APIs also helps
developers rescue “orphan” software or data—systems
that are no longer supported by their creators. When
a company stops supporting a computer platform or
service, the ability to freely reimplement APIs protects
the communities that rely on that software. Government
entities and non-profi ts are especially susceptible to the
orphan programs problem as they often cannot afford to
upgrade and are left using legacy technologies for years
Next up, is a filing from CCIA
written in part by Jonathan Band, which is noteworthy in part because Band co-wrote the book on copyright and interfaces
(first published nearly 20 years ago), explaining how interfaces aren't copyrightable and
why that simple fact was responsible for so much of the computer revolution. This filing similarly notes how much of history was driven by interoperability, but also digs deeper into what a mess it would be if the CAFC's view was determined to be correct:
If a company could exercise proprietary
control over the interface specifications implemented
by its products, that company could determine which
products made by other firms – if any – would be
compatible with its software. And should that company
have a dominant position in a particular market, it
could use its control over compatibility to expand its
dominant position into adjacent markets. Moreover,
such authority would extend the rights under copyright
beyond what is necessary to protect the original
expressive elements that have traditionally been
offered protection under American copyright law, and
it would override limitations on copyright crafted to
protect the public good.
Such a broad monopoly would have serious
implications for consumer welfare. In the absence of
competition during the effective lifespan of the product,
the first developer would have little incentive to
develop more innovative and less costly products.
These negative consequences would be compounded
by the fact that the personal computer revolution and
the emergence of the Internet have produced an
overwhelming need for interconnection between
different elements of computer systems. Prohibiting
competitors from accessing de facto standard interface
specifications would lock users into a particular
operating system or network software environment,
and would inhibit the transfer of data between users
with different computing environments....
shows a host of real-world problems and economic
harms that would result if API copyright could foreclose
compatibility, including the cost of rewriting
interface code formerly understood to be unprotected,
and lock-in costs resulting from consumers’ inability
to switch operating systems or cloud computing
providers.... Lock-in would deter competition, investment, and innovation in the
burgeoning cloud computing industry, which is known
to be sensitive to policy changes in copyright.
In short, in the computer industry, overly broad
intellectual property protection directly restricts
competition and innovation. This was the status quo
in the computing environment in the 1970s. Once a
buyer purchased a computer system, the buyer was
essentially locked-in to that system: the system was
incompatible with products manufactured by other
companies, and conversion costs were high. Although
“locking in” was extremely profitable for dominant
vendors such as IBM, competitors and users suffered
from high prices, indifferent service, limited choice,
and slow innovation.
CCIA also reminds the Supreme Court that Oracle (and Sun) not to long ago were among those who fought strongly for the position that interfaces were not copyrightable and that interoperability should be allowed. The filing notes that Sun and Oracle fought hard against parts of the DMCA when it was introduced that would have blocked interoperability. For example:
In a 1998 press release, Michael Morris, then Vice
President and General Counsel of Sun Microsystems, argued
that the DMCA as introduced would “impose[ ] a new and
unnecessary layer of restraint on lawful access to those unprotected
elements of computer programs that are necessary to
achieve interoperability, thus placing developers of interoperable
products at the mercy of proprietary vendors.”
That resulted in changes to the DMCA to make sure that interoperability was allowed. And yet, now, Oracle (via its Sun acquisition) is trying to argue that the exact opposite is true.
Finally, Public Knowledge also submitted an interesting brief
which lays out the ridiculous situation we're in today with an analogy using amusingly named stand-ins and products:
Say that Delphi Corporation manufactures screws. It
hits upon a new design for a screw socket—the interface
between screw and screwdriver—that is more efficient
than the prevailing Phillips and flathead insertions. Capitalizing
on this novel idea, Delphi manufactures a line of
screws using this socket, which it calls Sumatra.
The Sumatra socket is wildly popular. New lines of
screwdrivers are made for the Sumatra socket. Engineering textbooks praise the Sumatra design. Wood-workers teach their sons and daughters to use it. And
competing screw manufacturer Zillion decides to make
its own screws compatible with the Sumatra socket. The
screws otherwise differ, but use the Sumatra socket so
that woodworkers need not purchase new tools.
Only then does Delphi declare the Sumatra socket a
sculptural work, suing Zillion for copyright infringement.
Rather than focusing on more recent rulings concerning software, the Public Knowledge brief goes all the way back to Baker v. Selden
from 1879, which found that you couldn't copyright a set of blank ledger forms.
Oracle repeatedly points to the “intricate web of connections" of the Java API, in an effort to suggest that
its structure, sequence and organization of the API is
copyrightable. Oracle Brief, supra, at 26. But so too
can uncopyrightable blank forms constitute an intricate
web of connections. Selden’s book included 19 forms and
24 pages of demonstrative explanation designed “to compress almost innumerable accounts under a few specific,
intelligible heads.” .... For either blank forms or APIs, intricacy does not confer copyrightability.
Given that an API is factually on par with a blank
form, it is unsurprising that the reasoning of Baker directly applies to the copyrightability of APIs. Baker held
that blank ledger forms, including the “ruled lines and
headings,” could not properly be the subject of copyright.... The Court said that copyright cannot
cover “systems” or an “art”; the Java API is certainly a
system, one that teaches the “art” of using the Java system....
The Java API is on all fours with the blank forms
of Baker, both factually and legally. Since copying of
the blank forms in Baker was permissible, copying of
the Java API is too.
It's also nice to see the Public Knowledge brief call out the simple factual errors
in the CAFC ruling (some of which we pointed out in our post at the time):
... the Federal Circuit misunderstands arguments that interfaces
are more properly protected by patent law than copyright law... Google,
several amici below, and the district court merely proffered the unremarkable argument that functional elements should be excluded from copyright law by § 102(b) and the idea/expression dichotomy... But the Federal Circuit mistook them to mean that software may only be
patentable or copyrightable, but not both. The Federal Circuit further assumed that criticisms of
software patents equate to suggestions to expand copyrightable subject matter to cover interfaces.
These propositions are flawed. First, the Federal Circuit t neglects that there is matter outside the realm of both
copyright and patent; the court apparently supposed that
every element of a software program must fit into one or
the other. Second, the Federal Circuit fails to differentiate the discrete elements of a given software product that
may be copyrightable and those that may be patentable,
instead lumping those elements together into a single entity. Third, the Federal Circuit conflates programming
interfaces with computer programs generally.
Hopefully, these and other arguments convince the Supreme Court of just how wrong the CAFC was in its ruling. Recently, the Supreme Court has been pretty bad on copyright cases, while generally good on patent cases, so it's always a little nerve-wracking when copyright cases get there. The one bit of good news is that the Supreme Court has clearly found itself regularly questioning CAFC's interpretation of laws, since most of those patent cases come up via CAFC. The only reason this copyright case went to CAFC was because it started out as a patent case, though the patent issues got tossed out early on.