Band paper

The Protectability of Application Program Interfaces:
Oracle America v. Google
Jonathan Band
policybandwidth
Contents
I. Facts...................................................................................................................................................................2
II. The Trial........................................................................................................................................................3
III. The Copyrightability Order............................................................................................................4
IV. The CAFC’s Holding...............................................................................................................................6
A. The Ninth Circuit Case Law Regarding Interoperability...............................................8
B. APIs and Interoperability...............................................................................................................9
C. The First Circuit’s Decision in Lotus v. Borland................................................................11
D. The CAFC’s Decision in Chamberlain v. Skylink...............................................................12
E. Policy Considerations....................................................................................................................13
V. The Cert. Petition..................................................................................................................................15
A. Section 102(b)..................................................................................................................................17
B. Circuit Split.........................................................................................................................................19
C. Fair Use.................................................................................................................................................21
VI. Next Steps….............................................................................................................................................21
In May 2014, the U.S. Court of Appeals for the Federal Circuit (CAFC) in
Oracle America v. Google ruled that Google infringed Oracle’s copyright when
Google replicated the Java application program interface in the Android
application program interface. In July 2015, the Supreme Court rejected Google’s
petition for a writ of certiorari, and the case was remanded to the district court,
which now will determine whether Google’s actions were permitted under the
fair use doctrine.
The case is complicated in terms of the facts and the applicable legal
doctrines. A final determination that Google infringed Oracle’s copyrights could
have a negative impact on the development of interoperable systems. It could
signal the extension of copyright protection to program elements necessary for
interoperability. This would allow a company that develops a platform that
becomes an industry standard to use copyright law to control the ability of other
companies to develop their own programs that attach to or compete with that
platform. At the same time, Oracle and other large software companies have
argued that the decision ensures that software companies receive a return on
their investment in the development of software, which in turn will incentivize
further innovative activity.

The Protectability of Application Program Interfaces: Oracle America v. Google
Jonathan Band, policybandwith 2
This article describes the facts and the holdings of the trial court in favor
of Google. It then reviews the CAFC decision reversing the trial court. The article
analyzes the decision, identifying several troubling legal conclusions. Finally, the
article explores the arguments made before the Supreme Court.
I. Facts
The Java programming environment, originally developed by Sun
Microsystems and now owned by Oracle, enables software developers to write
programs that can run on different types of computer hardware. Sun used the
phrase “write once, run everywhere,” to express the cross-platform benefits of
Java. The Java language consists of keywords and other symbols and a set of pre-
written programs to carry out various commands. The pre-written programs are
called libraries, which programmers access using the libraries’ application
programming interface (API). In 2008, the Java libraries had 166 packages broken
into thousands of classes, which in turn contained tens of thousands of methods.
Stated differently, the Java API had 166 folders including thousands of programs
to carry out tens of thousands of subroutines.
Each method consists of the method header and method body. The
method header contains the name of the method; the number, order and type of
the parameters used by the method; the type of value returned by the method;
and additional information about the method.
The method body is a block of code that implements the method. Under
the Java system, a method could be implemented (i.e., coded) in a different
manner, but the header must be the same for the method to interoperate
properly with other methods in the system. “[S]ince there is only one way to
declare a given method functionality, everyone using that function must write
that specific line of code in the same way. The same is true of the ‘calls,’ the
commands that invoke the methods.”1
After Google acquired Android in 2005 as part of a plan to develop a
smart phone platform, Google decided to use Java as the programming
environment for Android. Google entered into negotiations with Sun about
taking a license to use the entire Java platform, but the parties could not reach an
agreement. Thus, Google decided to create its own libraries, which ultimately
included 168 packages. At the same time, Google believed that Java application
programmers would want to find a core set of functionalities in the new Android
system that would be callable by the same names used in Java. Moreover, these
1 Oracle America, Inc. v. Google Inc., 872 F.Supp.2d 974, 979 (N.D. Cal. 2012)(Oracle
America I).

programmers would want code written in Java to run on Android. Accordingly,
the APIs for 37 of the Android packages have the same structure as 37 packages
in the Java libraries, but Google wrote its own implementation of the
approximately 600 classes and 6000 methods in the 37 packages – that is, it wrote
its own source code. 97% of the lines of code in these 37 packages are different
from the Sun implementation. The 3% of the lines that are identical consist of the
headers, which specify the names, parameters, and functionality of the classes
and methods.2 Moreover, the structure, headers, and millions of lines of code of
131 Android packages are completely different from the 129 Java packages not at
issue in this litigation.
Since 2007, Android software has been distributed through the Open
Handset Alliance, a consortium of more than 80 hardware, software, and
telecommunications companies. The first mobile phone using Android reached
the market in 2008, and by the end of 2010 Android was the world’s most widely
adopted smart phone platform. In June 2012, more than 600,000 apps could run
on Android.
II. The Trial
In January 2010, Oracle purchased Sun Microsystems, thereby acquiring
the intellectual property rights in Java. In August 2010, Oracle sued Google for
patent and copyright infringement in the federal court for the Northern District
of California, within the Ninth Circuit. During the course of the litigation, Oracle
claimed that Google’s actions threatened to “fracture” the Java environment.
Additionally, the development of Android prevented Oracle from entering the
lucrative mobile market. Oracle sought injunctive relief and potentially billions
of dollars in damages, including the disgorgement of Google’s profits relating to
Android.
The jury trial in the spring of 2012 was conducted in a copyright phase
and a patent phase. (The damages phase was obviated by the jury verdicts and
stipulations by the parties.) The copyright phase of the trial included high
profile witnesses such as Google CEO Larry Page, Google Chairman Eric
Schmidt, and Oracle CEO Larry Ellison.
2 To be precise, the Android version of these packages contained 677 classes and 6508
methods, while the Java version had 616 classes and 6088 methods. The one exception
to Google’s independent implementation of code involved nine lines of code for a
function called “rangeCheck.” Google was found liable for infringing the copyright in
rangeCheck and this finding was upheld on appeal. This minor program does not merit
further discussion.

The jury found that Google did not infringe the two patents Oracle
claimed it had infringed. The jury’s verdict relating to the copyright claims was
more complex because the jury decided some issues, while the trial court judge,
Judge William Alsup, decided the critical issue of the protectability of the API
packages. Google had conceded that it had copied the structure and headers of
37 of the Java packages, and Judge Alsup instructed the jury to assume for
purposes of its deliberations that the API packages were protectable. Thus, the
main copyright issue before the jury was whether Google’s copying of the APIs
was permitted under the fair use doctrine.3 The jury could not reach a
unanimous decision on this issue. This deadlock soon became irrelevant because
on May 31, 2012, Judge Alsup ruled that the APIs were not protectable.
However, as will be discussed below, the jury’s failure to reach a decision on the
fair use question is once again significant now that Judge Alsup’s
copyrightability determination has been reversed by the CAFC.
III. The Copyrightability Order.
There was no doubt that the Java API as a whole was copyrightable. The
question Judge Alsup considered was whether the specific elements of the API
that Google copied – the declarations and the SSO of the 37 packages – were
protectable under copyright. Judge Alsup’s order began with a detailed review
of the case law relating to the scope of copyright protection for computer
software. He recognized that there were two lines of cases that in effect reflected
a split in the circuit courts. These two lines of cases articulated different
approaches for applying the idea/expression dichotomy to computer programs.
The idea/expression dichotomy, which is at the heart of copyright law, provides
that copyright protects the expression of ideas, not the ideas themselves. When
there is only one way to express an idea, the idea and expression merge, and
copyright protection is not available. The idea/expression dichotomy is codified
at 17 U.S.C. § 102(b): “in no case does copyright protection for an original work
of authorship extend to any idea, procedure, process, system, method of
operation, concept, principle, or discovery….” Determining whether a particular
element of a computer program is an unprotectable idea or protectable
expression is extraordinarily difficult because every aspect of the work is
functional.
One line of cases arose in the Third Circuit. In Whelan Associates, Inc. v.
Jaslow Dental Laboratory, Inc., 797 F.2d 1222 (3rd Cir. 1986), the Third Circuit
identified the function of the program (automating a dental office) as the
unprotectable idea, and treated the structure, sequence, and organization (SSO)
of program as protectable expression. Likewise, the Third Circuit in Apple/
3 The jury also considered the rangeCheck issue, discussed above in note 2.

Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240, 1253 (3rd Cir. 1983), stated
that compatibility was “a commercial and competitive objective which does not
enter into the somewhat metaphysical issue of whether particular ideas and
expressions have merged.”
In contrast, courts in other circuits, notably the First, Second, and Ninth
Circuits, developed a more nuanced approach to the protection of computer
programs under copyright that, in the words of Judge Alsup, reflected greater
“fidelity to Section 102(b) and recognition of the danger of conferring a
monopoly by copyright over what Congress expressly wanted should be
conferred only by patent.”4 This line of cases recognized that a computer
program could embody many ideas, resulting in a thinner scope of protection.
Because the Northern District of California, where the case was brought, is in the
Ninth Circuit, Judge Alsup paid special attention to the precedents in the Ninth
Circuit. He described Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and Sony v.
Connectix, 203 F.3d 596 (9th Cir. 2000), as two Ninth Circuit decisions “holding
that Section 102(b) bars from copyright software interfaces necessary for
interoperability.”5 Judge Alsup rejected the Third Circuit approach and instead
followed the precedents in Ninth Circuit as well as the First and Second Circuits.
On this basis, he ruled that “functional elements essential for interoperability are
not copyrightable.”6
Judge Alsup then applied the law as he understood it to the facts of the
case. He first considered Oracle’s argument that Google infringed its copyright
by providing the same methods as Java. Judge Alsup declared that “as long as
the specific code written to implement a method is different, anyone is free under
the Copyright Act to write his or her own method to carry out exactly the same
function or specification of any and all methods used by the Java API.”7 Judge
Alsup stressed that “contrary to Oracle, copyright law does not confer ownership
over any and all ways to implement a function or specification, no matter how
creative the copyrighted implementation or specification may be…. Others are
free to write their own implementation to accomplish the identical function, for,
importantly, ideas, concepts and functions cannot be monopolized by
copyright.”8
Next, Judge Alsup addressed the declarations. He reiterated that “to carry
out any given function, the method specification as set forth in the declaration
4 Oracle America I, 872 F.Supp.2d at 996.
5 Id. at 994.
6 Id. at 997.
7 Id. at 996.
8 Id. at 997.

must be identical under the Java rules.… Any other declaration would carry out
some other function. The declaration requires precision.”9 Because there was only
one way to write the declarations within the Java framework, the declarations
were unprotectable under the merger doctrine. Judge Alsup further held that the
declarations were short phrases unprotected by copyright.
Judge Alsup then proceeded to address whether Google could group its
methods in the same way as Java – whether it could organize the Android
methods under the same class and package scheme as in Java. Judge Alsup
agreed with Oracle that the rules of Java did not require that methods be
grouped together in a particular class. Indeed, each method could have been
placed in a stand-alone class. Nonetheless, Judge Alsup found that the overall
scheme of file names was a “command structure for a system or method of
operation of the application programming interface.”10 It was a hierarchy of over
six thousand commands to carry out pre-assigned functions. As such, it was
unprotecable, as was the command structure in Lotus v. Borland, 49 F.3d 807 (1st
Cir. 1995).
According to Judge Alsup, “interoperability sheds further light on the
character of the command structure as a system or method of operation.”11
Millions of lines of code had been written in Java before Google developed the
Android. These programs called on some of the 37 specific packages at issue and
necessarily used their command structure. In order for at least some of this
developer-written code to run on Android, Google was required to provide the
same command system using the same names and with same functional
specifications. According the Judge Alsup, “Google replicated what was
necessary to achieve a degree of interoperability – but no more, taking care … to
provide its own implementations.”12 Under Sega and Connectix, copyright did not
protect the elements related to interoperability that Google replicated.
IV. The CAFC’s Holding
In May 2014, a three judge panel of the CAFC reversed Judge Alsup.13 The
appeal was heard by the CAFC, rather than the Ninth Circuit, because Oracle in
its original complaint alleged patent claims, and the CAFC has exclusive
jurisdiction over appeals of cases involving patent claims. This is so even if, as in
9 Id. at 998.
10 Id. at 999.
11 Id. at 1000.
12 Id.
13 Oracle America, Inc., v. Google, Inc., 750 F.3d 1339 (Fed. Cir. 2014)(Oracle America
II).

this case, no patent issues were before the appellate court. Although the CAFC
heard the appeal, it was required to apply Ninth Circuit precedents because on
non-patent matters, the CAFC must apply the law of the circuit from which the
case arose.
The CAFC rejected the Judge Alsup’s finding that the method declarations
were short phrases unprotectable by copyright. Further, the CAFC ruled that
Judge Alsup incorrectly held that the idea and expression in both the
declarations and the SSO of the API packages had merged. At the time that Sun
engineers had written the APIs, they were unconstrained by other programs.
Because the Sun engineers were writing on a clean slate, their choices in
designing the APIs were expressive and thus protectable. On this basis, the
CAFC distinguished cases such as Computer Associates v. Altai, 982 F.2d 693 (2nd
Cir 1992), where the elements of the Computer Associates program copied by
Altai were dictated by the IBM platform on which the Computer Associates
program ran. For the CAFC, the fact that Google may have had to use the same
declarations and SSO as Java in order to interoperate with Java was irrelevant to
the merger issue. Merger was based on the choices available to Sun when it
wrote Java, not the choices available to Google when it wrote Android.
The CAFC also disagreed with the First Circuit in Lotus v. Borland that a
program’s command structure is an unprotectable method of operation. The
CAFC said that under the First Circuit’s reasoning, all aspects of a computer
program would be unprotectable because they were functional.
The CAFC then returned to the issue of interoperability. It first found as a
factual matter that Java and Android were not interoperable – that no application
written in Java could in fact run on Android. Instead, Google had simply
replicated elements of the Java API to appeal to the community of Java
programmers, to make it easier for Java programmers to write apps in the
Android environment.
Next, the CAFC cited the statement in the Third Circuit decision in Apple
v. Franklin that compatibility is “a commercial and competitive objective which
does not enter into the somewhat metaphysical issue of whether particular ideas
and expressions have merged.”14 On the basis of this statement, the CAFC held
that the fact that program elements were necessary for interoperability had no
impact in the determination of their protectability.15 Instead, interoperability was
14 Franklin, 714 F.2d at 1253.
15 The CAFC also relied on a more recent Third Circuit decision, Dun & Bradstreet
Software Servs. v. Grace Consulting, 307 F.3d 197 (3rd Cir. 2002).

relevant to assessing the applicability of the fair use defense.16 The CAFC
reached this conclusion by noting that the Ninth Circuit in Sega v. Accolade had
considered interoperability in the context of determining whether the reverse
engineering by Accolade was a fair use.
Finding that the elements of the Java APIs copied by Google were
protectable under copyright, the CAFC remanded the case to the trial court to
determine whether fair use permitted Google to copy those elements. As
discussed above, the jury had deadlocked on this issue.
Many aspects of the CAFC’s decision warrant closer scrutiny.
A. The Ninth Circuit Case Law Regarding Interoperability.
The CAFC was required to apply Ninth Circuit precedent. Judge Alsup
found that the Ninth Circuit had ruled in Sega and Connectix that copyright
protection did not extend to program elements necessary for interoperability.
The CAFC disagreed with Judge Alsup’s interpretation of these precedents;
because Sega and Connectix were fair use cases, the CAFC concluded that
interoperability was relevant only to the question of the applicability of the fair
use defense.
In fact, the case law in the Ninth Circuit clearly articulates that 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).”17 To be sure, the Sega court issued this ruling in
the context of determining whether Accolade’s reverse engineering was a fair
use. But 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 that if reverse engineering were
not permitted,
16 Fair use is a flexible, open-ended exception that U.S. courts apply on a case-by-case
basis. In determining whether a use made of a work in any particular case is a fair use, the
factors a court considers include: “1) the purpose and character of the use, including
whether such use is of a commercial nature or is for nonprofit educational purposes; 2)
the nature of the copyrighted work; 3) the amount and substantiality of the portion used
in relation to the copyrighted work as a whole; and 4) the effect of the use upon the
potential market for of value of the copyrighted work.” 17 U.S.C. § 107.
17 Sega, 977 F.2d at 1522.

Moreover, even if Android and Java are not interoperable, the CAFC’s
explanation of what Java elements Google copied and why it copied them
underscores that those elements are unprotectable under 17 U.S.C. § 102(b),
which as stated above withholds copyright protection from “any idea,
procedure, process, system, method of operation, concept, principle, or
discovery….” The CAFC found that Google’s real objective in replicating the
structure of the Java API was
to capitalize on the fact that software developers were already trained and
experienced in using the Java API packages at issue. The district court
agreed, finding that, as to the 37 API packages, “Google believed that Java
application programmers would want to find the same 37 sets of
functionalities in the new Android system callable by the same names as
in Java.” Google’s interest was in accelerating its development process by
“leverag[ing] Java for its existing base of developers.”22
The CAFC went on to say that
Google was free to develop its own API packages and to “lobby”
programmers to adopt them. Instead, it chose to copy Oracle’s declaring
code and the SSO to capitalize on the preexisting community of
programmers who were accustomed to using the Java API packages.23
The CAFC opined that the desire to capitalize on the preexisting
community of Java programmers “has nothing to do with copyrightability.”24
But this is a questionable assertion. What could be better proof that something is
a procedure, system, or method of operation than if a person can become
“trained,” “experienced,” or “accustomed” to using it in the course of developing
new works? Earlier in the opinion, the CAFC described the API packages as
“shortcuts” programmers can use when writing their own programs. While the
detailed steps of each shortcut may be copyrightable, the structure of the entire
set of shortcuts surely isn’t. If a framework of shortcuts used by programmers in
their development process isn’t a procedure, system, or method of operation,
what is? Further, as Judge Alsup pointed out, Oracle’s concern over Google’s
“fragmentation” of Java underscores that Java was a system.
22 Id.
23 Id. at 372.
24 Id.

C. The First Circuit’s Decision in Lotus v. Borland
While the CAFC gave weight to the Third Circuit’s decisions in Whelan
and Franklin, it rejected the First Circuit’s decision in Lotus v. Borland.25 However,
Borland is directly on point and provides a convincing rationale for finding the
structure of the APIs to be unprotectable. Lotus 1-2-3 was the dominant
spreadsheet program. It had a menu tree structure with over 400 commands that
users could employ when working with the program. Additionally, a user could
employ the commands to write a “macro” – a program that used a sequence of
menu commands to perform a series of spreadsheet operations in a particular
order. These macros could be quite complex, including thousands of individual
commands.
Borland developed a competing spreadsheet program with its own code
and command structure. However, Borland wrote the program so that it also
could operate in a Lotus 1-2-3 mode. In this mode, the user could employ the
Lotus commands as well as the macros he had written with the Lotus commands.
The First Circuit found that the Lotus 1-2-3 command structure was an
unprotectable method of operation. The court recognized that “Borland included
the Lotus command hierarchy in its programs to make them compatible with
Lotus 1-2-3 so that spreadsheet users who were clearly familiar with Lotus 1-2-3
would be able to switch to the Borland programs without having to learn new
commands or rewrite their Lotus macros.”26 The court’s concern about
preserving the user’s ability to switch products underlay its conclusion that the
command structure was an unprotected method of operation. The court viewed
as “absurd” Lotus’s theory that “if a user uses several different programs, he or
she must learn how to perform the same operations in a different way for each
program used.”27 Likewise, the court rejected Lotus’s view that a user should be
unable to employ a macro he wrote with the Lotus commands on a competing
program, but instead should “have to rewrite his or her macros using that other
program’s menu command hierarchy.”28
Judge Boudin wrote a concurring opinion that delved even deeper into the
economic and policy ramifications arising from the interoperability dimension of
25 Lotus appealed the First Circuit’s decision to the Supreme Court. One justice recused
himself, and the remaining eight justices were equally divided. 516 U.S. 233 (1996).
This meant that the First Circuit’s decision was left standing, but was binding precedent
only in the First Circuit.
26 Borland, 49 F.3d at 810.
27 Id. at 817.
28 Id. at 818.

the case. Judge Boudin observed that, because of the utilitarian and functional
nature of a computer, the danger of over-protection is greater than in the case of
traditional literary works: “[A] ‘mistake’ in providing too much protection [for
traditional works] involves a small cost: subsequent authors treating the same
themes must take a few more steps away from the original expression.”29 But in
the case of computer programs, the improper grant of copyright protection “can
have some of the consequences of patent protection in limiting other people’s
ability to perform a task in the most efficient manner.”30
Judge Boudin noted that if Lotus could receive a copyright in its
command structure, users who invested in learning Lotus 1-2-3 and writing
macros compatible with it would be “locked” into Lotus, and the copyright
would preclude competitors from developing products capable of interoperating
with the installed base. Judge Boudin wrote:
if a better spreadsheet comes along, it is hard to see why customers who
have learned the Lotus menu and devised macros for it should remain
captives of Lotus because of an investment in learning made by the users
and not by Lotus. Lotus has already reaped a substantial reward for being
first; assuming that the Borland program is now better, good reasons exist
for freeing it to attract old Lotus customers: to enable the old customers to
take advantage of a new advance. . . .31
The First Circuit’s concern about inefficiency and unfairness of requiring users to
learn a new spreadsheet command hierarchy so as to use a new platform is
directly parallel to the inefficiency and unfairness of requiring Java programmers
to learn a new language if they wished to write programs for the Android
environment.
D. The CAFC’s Decision in Chamberlain v. Skylink
In addition to giving insufficient weight to precedent from the First and
Ninth Circuit’s, the CAFC arguably disregarded its own precedent as well. In
Chamberlain v. Skylink, 381 F.3d 1178 (Fed. Cir. 2004), Chamberlain claimed that
Skylink violated the Digital Millennium Copyright Act’s (DMCA) prohibition on
the circumvention of access controls when Skylink developed a universal remote
control that could operate Chamberlain’s garage door openers. Skylink’s remote
control bypassed a lockout code in a piece of software embedded in the motor of
29 Id. at 819 (Boudin, J., concurring).
30 Id.
31 Id. at 821.

the Chamberlain garage door opener. Chamberlain argued that this
circumvention triggered DMCA liability, even though no infringement occurred.
The CAFC rejected Chamberlain’s DMCA claim, finding that a
circumvention device violates 17 U.S.C. 1201 only if the circumvention enabled
access that infringes or facilitates infringement of copyright. Because accessing
the software in the garage door opener did not enable infringement of the
software, Skylink did not violate the DMCA.
In interpreting the DMCA as requiring a nexus between access and
infringement for liability to attach, the CAFC considered the implications of a
contrary rule.
Chamberlain’s proposed construction would allow any manufacturer of
any product to add a single copyrighted sentence or software fragment to
its product, wrap the copyrighted material in a trivial ‘encryption’
scheme, and thereby gain the right to restrict consumers’ rights to use its
products in conjunction with competing products. In other words,
Chamberlain’s construction of the DMCA would allow virtually any
company to attempt to leverage it sales into aftermarket monopolies -- a
practice that both the antitrust laws and the doctrine of misuse normally
prohibit.32
The CAFC noted that while the antitrust laws do not negate an IP owner’s right
to exclude others, neither do IP rights confer a privilege to violate the antitrust
laws. “We must harmonize” the IP laws and the antitrust law “as best we can.”33
Because Chamberlain’s proposed interpretation of the DMCA would create a
“plain repugnancy” with the antitrust laws, the CAFC refused to accept it.
In contrast, when applying section 102(b) of the Copyright Act to elements
of the Java APIs, the CAFC displayed little interest in the impact of its decision
on the competition enabled by interoperability. It relegated interoperability to
the fair use calculus, rather than recognizing that the fact that program elements
can function as rules of interconnection or short cuts in the creation of new
programs suggests that those elements are on the idea (or unprotected) side of
the idea/expression dichotomy.
E. Policy Considerations
32 Skylink, 381 F.3d at 1201.
33 Id.

Tenth Circuit reflected a more sophisticated understanding of the nature of
computer programs and how overly-broad copyright protection could harm
legitimate competition by granting de facto patent protection over processes and
methods without meeting the nonobviousness standard. These decisions did not
occur in a vacuum. Industry groups such as CCIA and the American Committee
for Interoperable Systems (ACIS) filed amicus briefs in these cases urging a pro-
competitive position. Ironically, the initial meeting of ACIS occurred at the
corporate headquarters of Sun Microsystems, the company that created the Java
APIs at issue in the Oracle litigation. Chaired by Sun’s Deputy General Counsel
Peter Choy, ACIS agreed upon a Statement of Principles that stated that “the
rules or specifications according to which data must be organized in order to
communicate with another program or computer, i.e., interfaces and access
protocols, are not protectable expression under copyright law.”
For the past 20 years, since this wave of decisions sensitive to competitive
effects, computer programmers in the United States have understood that
copyright does not protect command structures and program elements necessary
for interoperability. Based on this understanding, programmers have freely
copied these elements, which was encouraged enormous creativity, innovation,
and competition in the digital environment. The Court of Justice of the European
Union in the 2012 decision in SAS Institute v. World Programming Limited adopted
a similar approach when it ruled that program functionality, programming
languages, and data formats were not protectable under copyright.
The CAFC’s decision casts doubt on this understanding. By ruling that
interoperability is relevant only to fair use, and not to protectability, the CAFC
would require a developer to perform a fair use analysis before developing an
interoperable product. Judge Boudin in the Borland case recognized that
widespread application of the fair-use doctrine for purposes of achieving
interoperability “would entail a host of administrative problems that would
cause cost and delay, and would also reduce the ability of the industry to predict
outcomes.”39 This would place U.S. programmers at a competitive disadvantage
to developers in other jurisdictions, such as the EU, that recognized that
copyright does not protect program elements necessary for interoperability.
V. The Cert. Petition
39 Borland, 49 F.3d at 821-22.

Google filed a petition for a writ of certiorari with the Supreme Court.40
Although the Court ultimately rejected the petition, the briefing before the Court
is worthy of discussion.
In its petition, Google argued that there was a circuit split; that the CAFC
had joined the Third Circuit in holding that interoperability was not relevant to
protectability, while the First, Second, Sixth, and Ninth Circuits had all found
that program elements necessary for interoperability were not protectable.
Google further argued that this was an issue of great significance to the
technology industry. By discounting the importance of interoperability, the
CAFC disrupted settled expectations and long established practices of
programmers copying and building upon the APIs developed by an earlier
generation of programmers.
Numerous entities filed amicus briefs in support of Google’s cert. petition:
1) The Computer & Communications Industry Association;
2) Hewlett-Packard, Red Hat, and Yahoo;
3) Public Knowledge;
4) 77 computer scientists represented by the Electronic Frontier Foundation;
5) The Open Source Initiative, Mozilla, and Engine; and
6) 41 intellectual property law professors represented by Pam Samuelson of
U.C. Berkeley Law School.
These briefs largely focused on the potentially adverse impact of the CAFC’s
decision on interoperability and competition in the information technology
industry.
Not surprisingly, Oracle opposed cert., arguing that there was no split in
the circuits and that Google exaggerated the significance of the CAFC’s decision.
The only amicus brief opposing cert. was filed by the Software Freedom Law
Center and the Free Software Foundation. This brief asserted that although the
CAFC’s decision was wrong, cert. should be denied because the decision was
narrowly factbound and there was no public interest in the continued
adjudication of this dispute.
40 All the briefs relating to the cert. petition can be found at
http://www.scotusblog.com/case-files/cases/google-inc-v-oracle-america-inc/.

In May 2015, the Solicitor General filed a very peculiar brief advising the
Supreme Court not to hear Google’s appeal. The SG’s brief was peculiar in
several ways. First, it reflected a profound misunderstanding of the Copyright
Act subsection that codifies copyright’s “idea-expression dichotomy” by
prohibiting protection for ideas, systems, and methods: 17 U.S.C. § 102(b).
Second, it completely ignored the obvious “circuit split” between the federal
courts of appeal, which was exacerbated by the Federal Circuit’s decision. Third,
it mistakenly concluded that Google’s “substantial and important” concerns
about the impact of the Federal Circuit’s decision on “interoperability and lock-in
effects” are better addressed through the fair use doctrine than the
idea/expression dichotomy.
A. Section 102(b)
The SG brief made the bizarre argument that Section 102(b) can never
exclude computer code within a copyrightable computer program from
copyright protection.
The SG correctly noted that Google wrote its own “implementing code”
(the code that performs the function) for the 6000 methods or subprograms at
issue in this case. However, for each of the methods, Google copied the
“declaring code,” a line or two at the beginning of the method that declares the
name of the program and what it does. Additionally, Google replicated Java’s
arrangement of the 6000 methods into 37 packages and 600 classes. (The Java API
contained 129 other packages not involved in this litigation.)
The SG appeared to have at least a basic understanding of what the Java
API is and why Google copied some of its declaring code and the arrangement of
some of its the methods. The SG understood that the Java API provides
programmers with a library of standard subprograms that programmers can use
as “building blocks” for larger programs. The SG also recognized that Google
“copied the declaring code so that programmers familiar with the Java platform
would be able to switch over to the Android platform without having to learn
entirely new commands for invoking commonly used methods.”
The Federal Circuit ruled that copyright protected both the declaring code
and the organization of the methods, and that Google had infringed the
copyright in these “literal” and “non-literal” elements. Oddly, the SG focused
only on the first holding: that Google infringed the copyright in the declaring
code. The SG reasoned as follows: copyright protects lines of computer code;
declaring code is a kind of computer code; therefore, copyright protects the
declaring code.

In its cert. petition, Google argued that the declaring code had a
fundamentally different function from the implementing code, and this
difference limited its protectability. The declaring code enabled a programmer to
use a shorthand command to call a method’s implementing code. The declaring
code thus was part of the method of operating the pre-written programs of the
Java language and platform. Accordingly, the declaring code was unprotectable
under 17 U.S.C. § 102(b).
The SG rejected this argument, finding no basis for distinguishing the
declaring code from the implementing code; code is code. Yet, the SG
acknowledged that “verbatim copying of [Java’s] declaring code was necessary
for familiar commands to work on the Android platform.” In contrast,
differences in implementing code have absolutely no impact on the ability of
programmers to move between the Java and Android environments. Thus,
declaring code is qualitatively different from implementing code.
It is worth noting that the declaring code and the implementing code are
also referred to by programmers—and the district court--as the method header
and the method body, respectively, further emphasizing the differences between
these two types of code.
In rejecting the applicability of Section 102(b) to the declaring code, the SG
articulated an exceedingly narrow interpretation of this foundational principle of
copyright law. The SG stated that “the basic purpose of Section 102(b)…is not to
distinguish between copyrightable and uncopyrightable portions of a larger
work of authorship, but rather to distinguish between the work of authorship
and something else—be it an idea, a process, or a method of operation that the
work of authorship describes or explains.” This is plainly wrong. Section 102(b)
does far more than differentiate between a work of authorship and the
underlying idea the work describes or explains. It also excludes from protection
certain elements of a work, such as facts and aspects of the work’s structure.
Judge Learned Hand famously noted that within every work there were “a great
number of patterns of increasing generality,” and “there is a point in this series
of abstractions where they no longer are protected….”
Moreover, contrary to the SG’s suggestion, the merger doctrine is an
application of Section 102(b), and not a distinct concept. Additionally, the SG’s
discussion of the merger doctrine is flawed. The SG attempted to distinguish this
case from the Supreme Court’s decision in Baker v. Selden, where the Court found
that the copyright in a book that explained an accounting system could not
prevent others from copying the forms necessary to practice the accounting
system. The SG noted that critical to the Court’s analysis “was that the
accounting method could not be practiced other than through forms like the ones
reprinted in the book.” The SG claimed that in contrast to Baker v. Selden, there

were an unlimited number of ways that Java API methods could have been
named and structured, and nothing required Google to copy Java’s declaring
code when it created the Android platform. But the SG overlooked the fact that
Selden could have designed his accounting system in many different ways, and
nothing required Baker to use Selden’s system. The point is that the Java API is a
system for enabling programmers to use standard subprograms as building
blocks for writing new programs. The system could have been designed in many
different ways, but it was designed in a particular way, and the declaring code
was necessary to practice the system in that way.
The fallacy underlying the SG’s bizarre notion that declaring code cannot
be unprotectable under Section 102(b) is demonstrated by the following analogy.
Imagine an American History study guide that contains a separate chapter for
each decade from 1492 until the present. Each chapter starts with a topic sentence
with this format: “This chapter covers the decade from x to x+9.” While the study
guide as a whole is copyrightable, and many of its passages contain protectable
expression, the 53 topic sentences are not protectable. The topic sentences only
recite the fact that the chapter covers a particular decade. Moreover, any
expression in the topic sentences has merged with the study guide’s system of
devoting a chapter to each decade.
B. Circuit Split
The SG completely ignored the circuit split exacerbated by the Federal
Circuit’s decision.
As discussed above, the Third Circuit has long been an outlier on software
copyright issues, according computer programs a “thick” scope of protection
more appropriate for artistic works than functional works. The other circuits
have largely ignored the Third Circuit, and have applied Section 102(b) to
computer programs in a manner that encouraged legitimate competition. In
particular, numerous circuits have found that copyright did not protect
command structures and other program elements necessary for interoperability.
The Federal Circuit’s decision, however, relied on the Third Circuit’s
jurisprudence. In rejecting the district court’s finding that copyright does not
protect program elements necessary for interoperability, the Federal Circuit cited
the Third Circuit’s statement in Apple v. Franklin that compatibility is “a
commercial and competitive objective which does not enter into the somewhat
metaphysical issue of whether particular ideas and expressions have merged.”
By endorsing the Third Circuit’s approach to software copyright, the Federal
Circuit magnified the circuit split.

C. Fair Use
The SG recognized that Google “has raised important concerns about the
effects that enforcing [Oracle’s] copyright could have on software development.”
Nonetheless, the SG believed that these concerns are better addressed in the
context of fair use on remand.
This belief is premised in part on the misunderstanding of Sega, discussed
above. The SG also believed that fair use is the more appropriate theory for
considering the protectability of interface information because it would “allow
courts to consider the full range of competing equities” in each case.
This approach would significantly interfere with competition in the
software industry. A developer would have to perform a fair use analysis before
developing a compatible product. In his concurring opinion in the Lotus case,
Judge Boudin observed that the widespread application of the fair use doctrine
for purposes of achieving compatibility “would entail a host of administrative
problems that would cause cost and delay, and would also reduce the ability of
the industry to predict outcomes.”
In July 2015, the Supreme Court denied Google’s petition.
VI. Next Steps.
With the Supreme Court’s denial of Google’s petition, the Federal Circuit’s
holding that the Java API’s declaring code is protectable under copyright
remains standing, and the district court will now consider whether Google’s
copying of the declaring code is a fair use. At the trial stage, this issue was put
for the jury and the jury deadlocked—one of the six jurors rejected the fair use
defense. It appears that Judge Alsup will order a new trial on the fair use issue,
rather than ruling on the issue as a matter of law (i.e., he will let the jury decide
the issue rather than deciding it himself). At a hearing in July 2015, Judge Alsup
indicated that his calendar would not allow a retrial on fair use until the spring
of 2016. He also ordered the parties into mediation.
Additionally, Oracle has filed a motion to file a supplemental complaint in
the district court. Oracle’s supplemental complaint would update its copyright
infringement claim to set forth: (1) Google’s continuing copyright infringement
through new versions of Android in both existing and new markets; and (2) the
resulting harm to Oracle and benefit to Google. Oracle claims that these new
facts relate directly to the fourth factor of Google’s fair use defense: the effect of
the use upon the potential market for or value of the copyrighted work.
Thus, the case appears a long way from being over. Additionally, it
remains to be seen whether much weight will be attached by other courts to the

Federal Circuit’s determination that the Java API’s declaring code is protectable.
The court’s ruling is not binding on any district court in any circuit, including in
the Ninth Circuit, where the case arose. (As mentioned above, the case ended up
before the Federal Circuit because Oracle had patent claims as well as copyright
claims, and the Federal Circuit has exclusive jurisdiction over appeals in cases
with patent claims.) To be sure, district courts may be influenced by the Federal
Circuit’s ruling, even if it is not binding. But it is doubtful that district courts in
the First and Ninth Circuits, which have contrary precedent (Lotus v. Borland and
Sega v. Accolade), will give it any weight.

Band paper

Recommended

Recommended

More Related Content

Similar to Band paper

Similar to Band paper (20)

Recently uploaded

Recently uploaded (20)

Band paper