The Google motion was largely unhinged because, much as Oracle had done in its response [PDF, text] to the motion, Google argued at too high a level and failed to get into the specifics of whether copying had occurred or whether such copying was defensible under an exception to copyright protection.
The one issue upon which Google won was the issue of copyright protection of file names. Judge Alsup agreed that such names are not protected under copyright: "Google argues that 'the names of the Java language API files, packages,
classes, and methods are not protectable as a matter of law' (Br. 17). This
order agrees."
One of Oracle's arguments as to how it has been damaged by Google's alleged infringement is that Android has fragmented the Java market because of its incompatibility with Java. Judge Alsup provides a brief summary of this argument that may be helpful in understanding it:
As we noted at the top, the threshold for a motion for summary judgment is high, and the burden of proof lies with the moving party. Here are each of the elements Judge Alsup considered in the context of the motion and his decision with respect to each:
423 – Filed and Effective: 09/13/2011
CERTIFICATE OF SERVICE
Document Text: CERTIFICATE OF SERVICE by Oracle America, Inc. (Swoopes, Roman) (Filed on 9/13/2011) (Entered: 09/13/2011)
424 – Filed and Effective: 09/13/2011
LETTER
Document Text: Letter from Michael S. Kwun in Opposition to Oracle's Request for Leave to File Portions of Deposition Transcript. (Kwun, Michael) (Filed on 9/13/2011) (Entered: 09/13/2011)
425 – Filed and Effective: 09/14/2011
ORDER
Document Text: ORDER DENYING PRECIS REQUESTS REGARDING SUPPLEMENTAL FILINGS re 420 Letter filed by Oracle America, Inc., 424 Letter filed by Google Inc.. Signed by Judge Alsup on September 14, 2011. (whalc1, COURT STAFF) (Filed on 9/14/2011) (Entered: 09/14/2011)
426 – Filed and Effective: 09/14/2011
Administrative Motion
Document Text: Administrative Motion to File Under Seal re: Dkt. 398-10 filed by Oracle America, Inc.. (Swoopes, Roman) (Filed on 9/14/2011) (Entered: 09/14/2011)
427 – Filed and Effective: 09/14/2011
Administrative Motion
Document Text: Administrative Motion to File Under Seal ORACLE AMERICA, INC.S ADMINISTRATIVE MOTION TO FILE UNDER SEAL PORTIONS OF ORACLES RESPONSE PRECIS filed by Oracle America, Inc.. (Norton, William) (Filed on 9/14/2011) (Entered: 09/14/2011)
428 – Filed and Effective: 09/14/2011
Exhibit
Document Text: EXHIBITS re 398 Exhibits, 426 Administrative Motion to File Under Seal re: Dkt. 398-10 Revised Exhibit 13 to the Declaration of Roman A. Swoopes in Support of Oracle's Opposition to Google's Motion for Summary Judgment on Count VIII of Oracle's Second Amended Complaint filed byOracle America, Inc.. (Related document(s) 398 , 426 ) (Swoopes, Roman) (Filed on 9/14/2011) (Entered: 09/14/2011)
429 – Filed and Effective: 09/14/2011
Letter
Document Text: Letter Norton Letter re Lindholm. (Norton, William) (Filed on 9/14/2011) (Entered: 09/14/2011)
430 – Filed and Effective: 09/14/2011
ORDER
Document Text: ORDER GRANTING REQUEST TO FILE RULE 72 MOTION re 418 Letter Brief filed by Google Inc.. Signed by Judge Alsup on September 14, 2011. (whalc1, COURT STAFF) (Filed on 9/14/2011) (Entered: 09/14/2011)
431 – Filed and Effective: 09/15/2011
DECLARATION
Docket Text: DECLARATION of Michael S. Kwun in Opposition to 419 Administrative Motion to File Under Seal RE: REQUEST FOR LEAVE TO FILE PORTIONS OF DEPOSITION TRANSCRIPT filed by Google Inc.. (Related document(s) 419 ) (Kwun, Michael) (Filed on 9/15/2011) (Entered: 09/15/2011)
432 – Filed and Effective: 09/15/2011
STIPULATION
Docket Text: STIPULATION AND [PROPOSED] ORDER TO EXTEND THE NON-DAMAGES EXPERT DISCOVERY CUT-OFF FOR THE DEPOSITION OF DAVID AUGUST by Oracle America, Inc.. (Muino, Daniel) (Filed on 9/15/2011) (Entered: 09/15/2011)
433 – Filed and Effective: 09/15/2011
ORDER
Docket Text: ORDER PARTIALLY GRANTING AND PARTIALLY DENYING DEFENDANT'S MOTION FOR SUMMARY JUDGMENT ON COPYRIGHT CLAIM by Judge Alsup granting in part and denying in part 260 Motion for Summary Judgment (whalc1, COURT STAFF) (Filed on 9/15/2011) (Entered: 09/15/2011)
434 – Filed and Effective: 09/15/2011
Minute Entry
Docket Text: Minute Entry: Motion Hearing held on 9/15/2011 before William Alsup (Date Filed: 9/15/2011) re 260 MOTION for Summary Judgment on Count VIII of Plaintiff Oracle America's Amended Complaint filed by Google Inc.. (Court Reporter Kathy Wyatt.) (dt, COURT STAFF) (Date Filed: 9/15/2011) (Entered: 09/15/2011)
IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF CALIFORNIA
____________________
ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.
__________________
No. C 10-03561 WHA
ORDER PARTIALLY
GRANTING AND
PARTIALLY DENYING
DEFENDANT’S MOTION
FOR SUMMARY JUDGMENT
ON COPYRIGHT CLAIM
INTRODUCTION
In this patent and copyright infringement action involving features of Java and Android,
defendant moves for summary judgment on the copyright infringement claim. With one
exception described below, the motion is DENIED.
STATEMENT
Oracle America Inc. accuses Google Inc. of infringing some of Oracle’s Java-related
copyrights in portions of Google’s Android software platform. Specifically, Oracle accuses
twelve code files and 37 specifications for application programming interface packages. The Java
technology and the basics of object-oriented programming were explained in the claim
construction order (Dkt. No. 137). An overview of application programming interfaces and their
role in Java and Android is provided here.
1. APPLICATION PROGRAMMING INTERFACES (APIS).
Conceptually, an API is what allows software programs to communicate with one another.
It is a set of definitions governing how the services of a particular program can be called upon,
including what types of input the program must be given and what kind of output will be returned.
APIs make it possible for programs (and programmers) to use the services of a given program
without knowing how the service is performed. APIs also insulate programs from one another,
making it possible to change the way a given program performs a service without disrupting other
programs that use the service.
APIs typically are composed of “methods,” also known as “functions,” which are software
programs that perform particular services. For example, a programmer might write a software
program method A, which calculates the area of a room when given the shape and dimensions of
the room. A second programmer then could write a program method called B, which calculates
the square footage of an entire house when given the shape and dimensions of each room. Rather
than reinventing a new way to calculate area, the second programmer could simply write an
instruction in B, “for each room, ask program A to calculate the area; then add all of the return
values,” using, of course, real programming language. As long as the second programmer knows
what A is named, what type of “arguments” A must be given as inputs, and what return A outputs,
the second programmer can write a program that will call on the services of A. The second
programmer does not need to know how A actually works, or is “implemented.” There may in
fact be multiple ways to implement A — for example, different ways to divide an oddly shaped
room into geometric components — and the first programmer may refine his implementation of
program A without disrupting program B.
A method must be defined before it can be used. A method can be “declared”
(i.e., defined) in a programming language such as Java by stating its name and describing its
argument(s) and return(s) according to syntax conventions. Once a method has been declared, it
can documented and implemented. Documentation is not code; it is a reference item that provides
programmers with information about the method, its requirements, and its use. An
2
implementation is code that actually tells the computer how to carry out the method. Often, as in
the example above, multiple implementations are possible for a given method.
In object-oriented programming, methods are grouped into “classes.” A class file
typically contains several methods and related data. Classes, in turn, are grouped into “packages”
known as API packages. Whereas a class generally corresponds to a single file, a package is
more like a folder or directory providing an organizational structure for the class files. A given
API package could contain many sub-packages, each with its own classes and sub-classes, which
in turn contain their own methods. These elements generally are named and grouped in ways that
help human programmers find, understand, and use them. A well developed set of API packages,
sometimes called a “class library,” is a powerful tool for software developers; as such, it can help
attract developers to a particular platform.
The specification for a class library — much like the specification for an automobile — is
an item of detailed documentation that explains the organization and function of all packages,
classes, methods, and data fields in the library. The class library specification for a given
software platform, sometimes called the “API Specification” is an important reference item for
programmers. In order to make effective use of the APIs, a programmer must be able to find the
portion of the specification describing the particular package, class, and method needed for a
given programming task.
2. JAVA AND ANDROID.
As explained in previous orders, Java and Android are both complex software platforms
with many components. For example, the Java platform includes the Java programming
language, Java class libraries, the Java virtual machine, and other elements. The Java
programming language has been made freely available for use by anyone without charge. Both
sides agree on this. Other aspects of the Java platform, however, such as the virtual machine and
class libraries, allegedly are protected by patents and copyrights.
The Android platform uses the Java programming language; thus, software developers
already familiar with the Java language do not have to learn a new language in order to write
programs for Android. In contrast to Java, the Android platform uses the Dalvik virtual machine
3
instead of the Java virtual machine, provides Android class libraries, and has other non-Java
components. The Java platform has been used primarily on desktop computers, but it also has
been used on cell phones and other mobile computing devices. Android, on the other hand, was
designed specifically for mobile devices. Java and Android compete in the market for mobile
computing software.
According to Oracle, Android is an unauthorized and incompatible Java implementation.
The Java platform and the Android platform each includes class libraries with more than one
hundred API packages. Android allegedly supports some, but not all, of the APIs defined for the
Java platform. Thus, some programs written for the Java platform will not run properly on the
Android platform, even though both use the Java language. Similarly, the Android platform
allegedly includes additional APIs that are not part of the Java platform. Thus, some programs
written for the Android platform will not run properly on the Java platform, even though they are
written in the Java language. This so-called fragmentation undermines the “write once, run
anywhere” concept underlying the Java system and supposedly damages Oracle by decreasing
Java’s appeal to software developers.
3. TERMINOLOGY.
The term API is slippery. It has been used by the parties and in the industry as shorthand
to refer to many related concepts, ranging from individual methods to code implementations to
entire class libraries and specifications. In this order, the term API will be used only to refer to
the abstract concept of an application programming interface. API documentation (e.g., the
specification for a class library or for an API package within the library) and API
implementations (e.g., the source code relating to a particular method within a class file) will be
referenced as such. Having clarified this linguistic point, this order proceeds to consider the
specific items accused of copyright infringement in this action: twelve files of code, and 37 API
package specifications.1
4
ANALYSIS
Summary judgment is proper when “there is no genuine dispute as to any material fact and
the movant is entitled to judgment as a matter of law.” FRCP 56(a). Where the party moving for
summary judgment would bear the burden of proof at trial, that party bears the initial burden of
producing evidence that would entitle it to a directed verdict if uncontroverted at trial. See C.A.R.
Transp. Brokerage Co. v. Darden Rests., Inc., 213 F.3d 474, 480 (9th Cir. 2000). Where the party
moving for summary judgment would not bear the burden of proof at trial, that party bears the
initial burden of either producing evidence that negates an essential element of the non-moving
party’s claims, or showing that the non-moving party does not have enough evidence of an
essential element to carry its ultimate burden of persuasion at trial. If the moving party satisfies
its initial burden of production, then the non-moving party must produce admissible evidence to
show there exists a genuine issue of material fact. See Nissan Fire & Marine Ins. Co. v.
Fritz Cos., 210 F.3d 1099, 1102–03 (9th Cir. 2000).
Copyright protection subsists in “original works of authorship fixed in any tangible
medium of expression.” 17 U.S.C. 102. In order to succeed on a copyright infringement claim, a
plaintiff must show that it owns the copyright and that the defendant copied protected elements of
the work. Only expressive elements that are “original,” i.e., independently created, are protected.
Copying can be proven by showing that the alleged infringer had access to the copyrighted work
and that the protected portions of the works are substantially similar. Jada Toys, Inc. v.
Mattel, Inc., 518 F.3d 628, 636–37 (9th Cir. 2008). Google advances a number of arguments why
Oracle supposedly cannot prove all or part of its copyright infringement claim. Google is entitled
to summary judgment on only one issue.
1. THE CODE FILES.
Regarding the twelve code files at issue, Google argues that its alleged copying was
de minimis (Br. 22–24). In the copyright infringement context, “a taking is considered de minimis
only if it is so meager and fragmentary that the average audience would not recognize the
appropriation.” Fisher v. Dees, 794 F.2d 432, 434 n.2 (9th Cir. 1986). The extent of the copying
“is measured by considering the qualitative and quantitative significance of the copied portion in
5
relation to the plaintiff’s work as a whole.” Newton v. Diamond, 388 F.3d 1189, 1195
(9th Cir. 2004).
Here, the parties dispute what constitutes the plaintiff’s work as a whole. Google argues
that its alleged copying should be compared to the entire Java platform, which Oracle registered
as a single work (Br. 22–23; Kwun Exh. B). Oracle, on the other hand, argues that each of the
twelve code files at issue is a separate work for purposes of this analysis (Opp. 23–24). Google
has not shown that the Java platform is the proper basis for comparison. Google cites two
provisions of the copyright regulations, but neither one supports Google’s position (Reply
Br. 12–13).
First, Google misapplies 37 C.F.R. 202.3(b)(4)(i)(A). That provision states: “For the
purpose of registration on a single application and upon payment of a single registration fee, the
following shall be considered a single work: (A) In the case of published works: all
copyrightable elements that are otherwise recognizable as self-contained works, that are included
in a single unit of publication, and in which the copyright claimant is the same.” The plain
meaning of this provision is that when a single published unit contains multiple elements “that are
otherwise recognizable as self-contained works,” the unit is considered a single work for the
limited purpose of registration, while its elements may be recognized as separate works for other
purposes. Courts considering Section 202.3(b)(4)(i)(A) generally agree with this interpretation.
See, e.g., Tattoo Art, Inc. v. TAT Int’l., LLC, --- F. Supp. 2d. ---, No. 2:10cv323,
2011 WL 2585376, at *15–16 (E.D. Va. June 29, 2011) (interpreting Section 202.3(b)(4)(i)(A) to
codify the principle that “the copyrights in multiple works may be registered on a single form,
and thus considered one work for the purposes of registration while still qualifying as separate
'works’ for purposes of awarding statutory damages”). Google relies on
Section 202.3(b)(4)(i)(A) to show that the code files comprising the Java platform should be
treated collectively as a single work for purposes of an infringement analysis. This interpretation
is contrary to the plain language of the regulation and is not supported by any cited authority.
Second, Google cites to 37 C.F.R. 202.3(b)(3), which concerns continuation sheets.
Continuation sheets are used “only in submissions for which a paper application is used and
6
where additional space is needed by the applicant to provide all relevant information.”
37 C.F.R 202.3(b)(3). The regulation requires use of a separate continuation sheet “to list
contents titles, i.e., titles of independent works in which copyright is being claimed and which
appear within a larger work.” Ibid. It does not, however, state that a failure to list individual
titles precludes an applicant from later asserting those titles as separate works in infringement
litigation. Nor does it address works registered by means other than a paper application. Google
does not provide enough factual context to show that Section 202.3(b)(3) applies to the works at
issue, and Google does not explain how it might bear upon the dispute at hand, even if it
does apply.
Google cites no other authority. This order finds that, at least on the present record,
Google has not shown that the Java platform as a whole is the work to which Google’s alleged
copying should be compared. Because all of Google’s de minimis arguments compare the
accused material in the code files to the entire Java platform as a whole, this order need not
consider the de minimis question further.
2. THE API PACKAGE SPECIFICATIONS.
Regarding the 37 API package specifications at issue, which are reference items and not
code, Google argues that the only similarities between the accused works and the asserted works
are elements that are not subject to copyright protection. Google, however, does not specify
which elements it views as similar. Google instead presents an array of theories why various
categories of specification elements do not merit copyright protection. With one exception, this
broad categorical approach fails. Google’s other arguments regarding the API package
specifications — that the disputed works are not virtually identical or substantially similar, and
that Google’s alleged copying was fair use — also fail to earn summary judgment for Google.
A. Names.
“Words and short phrases such as names, titles, and slogans” are “not subject to
copyright.” 37 C.F.R. 202.1(a); Planesi v. Peters, No. 04-16936, slip op. at *1 (9th Cir.
Aug. 15, 2005). Google argues that “the names of the Java language API files, packages, classes,
and methods are not protectable as a matter of law” (Br. 17). This order agrees. Because names
7
and other short phrases are not subject to copyright, the names of the various items appearing in
the disputed API package specifications are not protected. See Sega Enters. Ltd. v.
Accolade, Inc., 977 F.2d 1510, 1524 n.7 (9th Cir. 1992) (“Sega’s security code is of such de
minimis length that it is probably unprotected under the words and short phrases doctrine.”).
Oracle argues that it is entitled to a “presumption that the names in the Java API
specifications are original” (Opp. 14). Not so. The decision Oracle cites for this proposition
shows only that a certificate of registration may entitle its holder to a presumption of copyright
validity as to the registered work. Swirsky v. Carey, 376 F.3d 841, 851 (9th Cir. 2004) (citing
17 U.S.C. 410(c)). Oracle cites no authority requiring a presumption of originality as to specific
elements of a registered work.
Oracle also argues that its selection and arrangement of component names within the
specifications is entitled to copyright protection (Opp. 15). This argument is non-responsive.
Copyright protection for the selection and arrangement of elements within a work is a separate
question from whether the elements themselves are protected by copyright. In finding that the
names of the various items appearing in the disputed API package specifications are not protected
by copyright, this order does not foreclose the possibility that the selection or arrangement of
those names is subject to copyright protection. See Lamps Plus, Inc. v. Seattle Lighting Fixture
Co., 345 F.3d 1140, 1147 (9th Cir. 2003) (“[A] combination of unprotectable elements is eligible
for copyright protection only if those elements are numerous enough and their selection and
arrangement original enough that their combination constitutes an original work of authorship.”)
(emphasis added).
Having found that the names of the various items appearing in the disputed API package
specifications are not protected by copyright on account of the words and short phrases doctrine,
this order need not consider Google’s alternative theory that the names are unprotected because
they are the result of customary programming practices.
B. Scenes a Faire and the Merger Doctrine.
“Under the scenes a faire doctrine, when certain commonplace expressions are
indispensable and naturally associated with the treatment of a given idea, those expressions are
8
treated like ideas and therefore not protected by copyright.” Swirsky v. Carey, 376 F.3d at 850.
“Under the merger doctrine, courts will not protect a copyrighted work from infringement if the
idea underlying the copyrighted work can be expressed in only one way, lest there be a monopoly
on the underlying idea.” Satava v. Lowry, 323 F.3d 805, 812 n.5 (9th Cir. 2003).
Google argues that “[t]he API declarations are unprotectable scenes a faire or
unprotectable under the merger doctrine” (Br. 14). Google, however, does not specify what it
means by “API declarations.” Google applies this argument to all of “[t]he allegedly copied
elements of the Java language API packages,” providing only a few examples: “the names of
packages and methods and definitions” (id. at 14–16). To the extent Google directs this argument
to names, it is moot in light of the above ruling. To the extent Google directs this argument to
other elements of the API package specifications, it is not adequately supported.
Google’s lack of specificity is fatal. If Google believes, for example, that a particular
method declaration is a scene a faire or is the only possible way to express a given function, then
Google should provide evidence and argument supporting its views as to that method declaration.
Instead, Google argues — relying mostly on non-binding authority2
— that entire categories of
elements in API specifications do not merit copyright protection. This approach ignores the
possibility that some method declarations (for example) may be subject to the merger doctrine or
may be scenes a faire, whereas other method declarations may be creative contributions subject to
copyright protection. Google has not justified the sweeping ruling it requests. Google has not
even identified which categories of specification elements it deems unprotectable under these
doctrines. This order declines to hold that API package specifications, or any particular category
of elements they contain, are unprotectable under the scenes a faire or merger doctrines.
C. Methods of Operation.
“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, regardless
of the form in which it is described, explained, illustrated, or embodied in such work.”
9
17 U.S.C. 102(b) (emphasis added). Google argues that “APIs for a programming language” are
unprotected methods of operation (Br. 13). Google, however, does not use the term API
consistently in the relevant portions of its briefs, so it is unclear precisely what Google is
attempting to characterize as a method of operation. Google states that all “elements common to
Oracle’s Java language APIs and the Android APIs are unprotectable methods of operation,” but
Google does not specify which elements it views as common (id. at 12). Context suggests two
possible interpretations for Google’s use of the term APIs. Both of Google’s apparent arguments
are unavailing.
First, Google appears to direct its methods-of-operation argument to APIs themselves as
the term is used in this order — that is, to the abstract concept of an interface between programs.
In its reply brief, Google distinguishes APIs both from their implementation in libraries of code
(“the APIs are not the libraries themselves”) and from their documentation in reference materials
(“The APIs do not ‘tell’ how to use the libraries, they are the means by which one uses the
libraries; the documentationIt is
not the APIs but rather the specifications for 37 API packages that are accused. Even if Google
can show that APIs are methods of operation not subject to copyright protection, that would not
defeat Oracle’s infringement claim concerning the accused specifications.
Google may be trying to head off a possible argument by Oracle that the APIs described in
the specifications are nonliteral elements of the specifications subject to copyright protection. It
is unclear whether Oracle is advancing such an argument. Oracle’s opposition brief seems to use
the term API to refer to API packages and API package specifications. If this interpretation is
correct, then the parties’ arguments concerning whether “APIs” are methods of operation simply
swipe past each other, with each party using the term in a different way. Because the issue is not
properly teed up for summary judgment, this order does not decide whether APIs are methods
of operation.
Second, Google also states that “API specifications are methods of operation” (Br. 14).
This conclusion does not follow from Google’s argument that APIs — meaning conceptual
10
interfaces between programs — are methods of operation. No other supporting argument is
provided. API specifications are written documentation. Even if Google could show that APIs
are methods of operation, that would not mean that a written work that describes or embodies
APIs is automatically exempt from copyright protection. This order finds that the API package
specifications at issue are not “methods of operation” under 17 U.S.C. 102(b).
D. Degree of Similarity.
The copying element of copyright infringement generally can be proven by showing that
the alleged infringer had access to the copyrighted work and that the protected portions of the
works are substantially similar. Jada Toys, 518 F.3d at 636–37. “When the range of protectable
and unauthorized expression is narrow,” however, “the appropriate standard for illicit copying is
virtual identity” rather than substantial similarity. Apple Computer, Inc. v. Microsoft Corp., 35
F.3d 1435, 1439 (9th Cir. 1994).
Google argues that “[g]iven the substantial unprotected elements in the documentation
(such as the API method declarations), the ‘virtual identity’ standard applies here” (Br. 24). This
order agrees with Google that the names of the various items appearing in the disputed API
package specifications are not protected by copyright. Google, however, has not shown that any
other elements of the specifications are exempt from copyright protection. Because Google has
not proven that a substantial portion of the specifications is unprotected, Google’s justification for
applying the virtual identity standard fails. This order therefore need not consider Google’s
arguments that the disputed Java and Android API package specifications are not virtually
identical. In particular, Google analyzes the selection and arrangement of elements within the
specifications under only the virtual identity standard (Br. 24–25).
As a fallback position, Google argues that even under the substantial similarity standard,
the disputed Java and Android API package specifications are not sufficiently similar to show
copying. Google analogizes the specifications to dictionary definitions whose similarities are
driven by external constraints, and Google cites an expert opinion that the Java and Android
platforms are not substantially similar (Br. 24; Astrachan Exh. 1 at 77). Predictably, Oracle
presents an opposing expert opinion that the API package specifications at issue are substantially
11
similar (Mitchell Exh. 1 at 45). This conflicting expert testimony highlights a factual issue that
precludes summary judgment; a reasonable trier of fact might agree with either expert’s analysis
of the degree of similarity between the asserted and accused specifications.
Google argues that Oracle’s expert testimony is not sufficient to defeat summary
judgment. Google criticizes the expert for offering a “summary ‘conclusion’” based on a “single
illustrative example,” which Google interprets differently (Reply Br. 11). In his report, however,
the expert provides multiple examples and explains that he conducted a detailed comparison of
each of the API package specification pairs at issue (Mitchell Exh. 1 at 60–63). His opinion that
the Android specifications are substantially similar to their Java counterparts is not a mere
“[c]onclusory statement[] without factual support.” See Surrell v. Cal. Water Serv. Co.,
518 F.3d 1097, 1103 (9th Cir. 2008). If Google disputes the basis for the opinion by Oracle’s
expert or his analysis of the specifications, then Google should raise its critiques during cross-examination
at trial. Google has not earned summary judgment of no copying under either of the
possible standards for comparison — virtual identity or substantial similarity.
E. Fair Use.
The following factors are considered in determining whether the use made of a work is a
fair use: (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 or value of the copyrighted work.
17 U.S.C. 107. Google argues that its alleged use of elements from the Java API package
specifications in its Android API specifications was fair (Br. 19–22). Evaluation of the fair use
factors, however, depends upon disputed questions of material fact. As such, no finding of fair
use can be made on the summary judgment record.
For example, with respect to factor four, Google argues that “Android has contributed
positively to the market for the copyrighted works by increasing the number of Java language
developers” (Br. 21). Google cites positive reactions by Sun executives at the time when Android
was first released in 2007. These statements do not prove anything about Android’s actual impact
12
on the Java market since that time. Moreover, Oracle presents sworn testimony that Android
fragmented the Java platform and locked Java out of the smartphone market (Swoopes Exh. 6
at 111–12). Oracle and Google both employ complex business models for their respective
products. The question of damages is one of the most complicated and hotly contested issues in
this action. On the present record, a reasonable fact finder could disagree with Google’s rosy
depiction of Android’s impact on the Java market.
Because fact issues preclude a summary judgment finding of fair use, this order does not
reach the parties’ arguments on all of the fair use factors.
* * *
This order finds that the names of the various items appearing in the disputed API package
specifications are not protected by copyright. This order makes no finding as to whether any
other elements of the API package specifications (or their selection or arrangement) are protected
or infringed.
3. INDIRECT INFRINGEMENT.
Google argues that Oracle’s indirect copyright infringement theories fail because Oracle
cannot establish any underlying direct copyright infringement (Br. 25). Because Google is not
entitled to summary judgment on direct infringement, Google also is not entitled to summary
judgment on indirect infringement.
CONCLUSION
For the foregoing reasons, defendant’s motion for summary judgment on the copyright
infringement claim is GRANTED IN PART AND DENIED IN PART. This order finds that the names
of the various items appearing in the disputed API package specifications are not protected by
copyright. To that extent, the motion is GRANTED. All of defendant’s other summary judgment
theories regarding the copyright claim are DENIED. Plaintiff’s evidentiary objections to the
Bornstein declaration and the Astrachan declaration are MOOT.
IT IS SO ORDERED.
Dated: September 15, 2011.
/s/ William Alsup
WILLIAM ALSUP
UNITED STATES DISTRICT JUDGE
____________________________
1 At the hearing, counsel for Oracle suggested that Google’s code implementations of the 37 API
package specifications are unauthorized derivative works. This theory was disclosed by Oracle during
discovery (Dkt. No. 263-3 at 11), but it was dismissed summarily in Google’s summary judgment brief (Br. 9).
Because the briefing does not address this theory, it will not be addressed herein.
2 The only binding authority Google cites is the Sega decision. The cited discussion addresses
computer program code, not documentation. Google has not justified applying the Sega rationale to
documentation such as the API package specifications at issue here.
13
