I have been in LWL (limited-wifi-land) the last several days, which will explain why this posting has been delayed but also why it contains so much information. Time to get caught up on Oracle v. Google.

Among the items occurring over the last few days are: an extension of the time for discovery; a hearing before the magistrate on the discovery disputes; and a Motion for Summary Judgment by Google on Oracle's copyright claims with some very interesting attachments. We will tackle these in chronological order, although the MSJ is, by far the most interesting of the three.

First, the time for discovery has been extended by
order [PDF] of Judge Alsup. Both document and deposition discovery have been extended to August 15, but the time for supplementing interrogatory responses has already passed (August 1). Expert reports on patent-related issues are due to be served by August 8, so that ought to trigger some fireworks. All other deadlines remain as is.

As I mentioned, the magistrate also held a hearing [PDF] on the various discovery disputes between the parties. While the magistrate heard the parties, for now they have been left to duke it out themselves.

Then there is Google's Motion for Summary Judgment [PDF] and all of its related filings, all of which are reproduced below in text thanks to some very generous volunteer efforts (thanks, PJ).

Before we start on it in detail, a word about motions for summary judgment at this stage of the proceeding. Generally, such a motion has a very limited likelihood of success. To a large extent this is due to the fact that such motions are dependent on the facts (or as a friend once called them, potential facts) of the case that have been introduced. To the extent those facts are not in dispute, Google may rely on them. However, where the facts are in dispute, for purposes of the motion for summary judgment the court accepts the version of the facts put forward by the non-movant (in this case, Oracle). Suffice it to say, there are plenty of disputed facts in the larger case, but this motion for summary judgment is focused solely on the copyright claims. Because of that limitation and the evidence to which Google points, the possibility of success by Google on this motion goes up.

So what are some of the key points Google raises in its motion and supporting declarations?
First, in the Declaration of Daniel Bornstein [PDF] in support of Google's motion, Bornstein explains the development of Dalvik and the relationship between the failure of Google and Sun to reach a licensing agreement on Java and what Google ultimately did. Bornstein led the
design and creation of the Dalvik VM and related libraries at Google:

2. The Android platform is a freely-distributed, open-source software
stack for mobile devices that includes an operating system, middleware
and key mobile applications. In the early days of its development,
Android, Inc. and then Google (which purchased Android, Inc. in 2005)
pursued numerous possibilities for developing the platform, including a
technology partnership with Sun (incorporating Sun’s implementation of
its virtual machine and Java language libraries into the platform), as
well as developing Android from the ground up. When the partnership
negotiations failed, Google decided to concentrate fully on the ground
up solution, using only new materials and publicly-available open-source
materials.

Second, Bornstein says there is a diagram up on the Internet now showing how
Android is built at
http://developer.android.com/
images/system-architecture.jpg and it's also attached as an exhibit [PDF].

Third, Dr. Owen Astrachan, a Professor of the Practice of Computer Science and Director of
Undergraduate Studies in the Computer Science Department at Duke
University, provides a Declaration [PDF] on the copyright issues. He says Oracle has narrowed its copyright claims from 51
to 37 API packages. He attaches his report, but this declaration adds some thoughts after the
narrowing, which Oracle did after interrogatories were supplemented by
Oracle and Astrachan had done his report and signed it on July 29.

Astrachan's report, exhibit 1 [PDF] to the declaration, explains how Java means three things, not one,
and Oracle is not claiming any literal copying (it is definitely worth a read). Some excerpts from the declaration:

11. In this case, it is my understanding that Oracle contends that
referencing the API, via method names, data names, and data types, is
infringing, but as I discuss below in Section V.J, the APIs at issue in
this case are purely functional. In addition, with respect to Oracle’s
allegation of literal copying of 12 files out of 57,000 files in
Android, as I discuss below in Section VIII, it is my opinion that the
allegedly copied material in these files is qualitatively and
quantitatively insignificant.

12. It is my opinion that the APIs at issue are methods of operation.

13. It is my further opinion that any similarity between the names of
elements (such as package, class and method names) in the
implementations in these APIs in the Java and Android platforms is
driven by functional considerations. It is also my opinion that any
similarity between the organization of elements in the implementations
in these APIs in the Java and Android platforms is also driven by
functional considerations.

14. It is my opinion that many of the names of elements of the Java API
were drawn from usage in other languages or platforms that pre-date Java.

15. It my opinion that Google’s use of these APIs is necessary for
interoperability and efficiency, and/or driven by industry demand.

16. It is my opinion that the Android platform is not virtually
identical or substantially similar to the allegedly copyrighted works
relating to the Java platform.

17. It is my opinion that any similarities between Google’s
documentation of the APIs at issue and Oracle’s documentation are driven
by functional considerations and industry practice regarding such
documentation.

Bottom line, Astrachan views all of the claimed items of copyright infringement to be functional, and if that is the case, they are not protected by copyright.

Next up is the Declaration of Michael S. Kwun [PDF], a Keker & Van Nest lawyer for Google. This one lists a lot of goodies as attachments, including excerpts from the hearings.
For example, Exhibit E [PDF] is a partial transcript from the February hearing, and Google's lawyer
explains what an API is. Also one heading in Google's Motion says,
"APIs define how pieces of software can interact with each other."
Further, on page 5 of Oracle's Supplemental Responses to Google's First Set of Interrogatories,
Exhibit C [PDF] attached to the Kwun declaration (its initial responses are Exhibit O[PDF]), Oracle admits, on page 5, that the copyright issue is primarily about API's:

The Android source and object code (whether or not from the Apache
Harmony project) that purports to implement Oracle’s Java API
specifications is unauthorized derivative work, and Google’s
unauthorized copying and distribution of it is copyright infringement.

But Oracle also claims Dalvik itself is infringing, on page 6:

Google has created and distributed infringing works written in native
code, in addition to Java code, that derive from Oracle’s copyrighted
works. For example, Google makes and
distributes dalvikvmnativejava_lang_Class.c, which is based on
Oracle’s java.lang.Class specification.

Oracle also seems to think it somehow owns or has rights in Apache's Harmony, on page 7:

Among the other supporting documents is an article by David Berlind [PDF] on ZDNet in 2007, explaining the
announcement by Google of the Open Handset Alliance, the same day as the heralded
Schwartz blog post, which is attached as Exhibit L [PDF]. Rich Green, then at Sun, also put out a
statement:

We’re thrilled to have Google amplify the global momentum behind Java
technology, the world’s most prolific open source software platform - on
more than five billion devices. We are excited by the Open Handset
Alliance’s upcoming open source contributions of new services and
frameworks. We welcome Google to the community and look forward to
collaborating on the evolution of the Java platform as part of our
ongoing relationship. In addition, Sun and the NetBeans community will
provide NetBeans support for the Android platform as it becomes
available and will continue to build on the support NetBeans provides to
numerous mobile platforms and standards.

Also of interest are some earlier documents which we have not previously discussed in our Oracle v. Google series, specifically the following:

A. Because Oracle cannot establish that Google copied protected elements of the Java language API specifications, the Android APIs
are not substantially similar to Oracle’s Java language API specifications…………………………………………………………………………………………….11

1. The only elements common to Oracle’s Java language APIs and the Android APIs are unprotectable methods of operation.................12

2. The API declarations are unprotectable scenes a faire or unprotectable under the merger doctrine. ..................................................14

3. The Java language API package and method names are unprotectable as a matter of law. ...............................................................17

4. Alternatively, any similarity between the works is a fair use....................19

B. The alleged similarities in the remaining 12 files are de minimis in the context of the over 9,500 files in the Asserted Works, and the over 50 thousand files in Android……………………………………………………………………………22

C. The documentation for the Android APIs is not substantially similar or virtually identical to the documentation for the Java language APIs. ...................24

D. Any claim based on Oracle’s selection and arrangement of allegedly copied elements must be evaluated under the “virtual identity” standard, and Oracle cannot establish infringement under that standard...............24

PLEASE TAKE NOTICE, that on September 15, 2011, at 2:00 p.m., or at such other
time as the Court may direct, before the Honorable William Alsup, United States District Court,
450 Golden Gate Avenue, San Francisco, California 94102, Defendant Google Inc. ("Google")
will, and hereby does, move the Court for entry of summary judgment on Count VIII of the
Amended Complaint filed by Plaintiff Oracle America, Inc. ("Oracle").

This Motion is based on this Notice of Motion and Motion, the Memorandum of Points
and Authorities below, the Declarations of Daniel Bornstein, Owen Astrachan and Michael S.
Kwun that are being filed herewith, and such other and further papers, evidence and argument as
may be submitted to the Court in connection with the hearing on this motion.

MEMORANDUM OF POINTS AND AUTHORITIES

I. INTRODUCTION

In 1994, the Chief Technology Officer ("CTO") of Sun Microsystems ("Sun")1 offered
the following testimony to Congress: "With respect to intellectual property rights, Sun strongly
believes in--and will defend--the rights of intellectual property owners to maximize their
returns on product implementations. At the same time, we believe that interface specifications
are not protectable under copyright."2

Yet Oracle's copyright claim rests almost entirely on the use of the interface
specifications (specifications for application programming interfaces, or APIs) in thirty-seven3
Java language API packages in Android. Those specifications are "functional requirements for
compatibility . . . that are not protected by copyright." SeeSega Enters. Ltd. v. Accolade, Inc.,

1

977 F.2d 1510, 1522 (9th Cir. 1992) (citing 17 U.S.C. § 102(b)). They define how programmers
interact with the Android platform, much as the menus in a computer program define how users
interact with the program. And just as menus in a computer program are not protected by
copyright, see Lotus Dev. Corp. v. Borland Int'l, Inc., 49 F.3d 807, 815 (1st Cir. 1995), aff'd by
an equally divided court, 516 U.S. 233 (1996), API specifications are not copyrightable. What
the specifications do not do is define how the Android platform actually does the things it does,
just as the "print" menu option in a computer program is different from the code that actually
causes the program to print a document.

That the Java language API specifications are not themselves copyrightable presents a
pure question of law. As Sun's CTO explained in 1994, "The interface, as an element necessary
for interoperability, falls into the category of ideas which the copyright law seeks to disseminate
to promote the public good. This in no way curtails the protectability of the code itself."4

Aside from the Java language API specifications, Oracle's copyright claim is based on
minimal alleged copying, concerning only 12 files out of over 50 thousand in Android, and
material of no qualitative significance. A reasonable jury could only conclude that any such
similarities are de minimis and thus not actionable. Google is therefore entitled to summary
judgment on the entirety of Oracle's copyright claim.

II. FACTUAL BACKGROUND

A. A brief history of Java and Android.

1. The Java language and the Java platform.

Oracle uses "Java platform" to mean a variety of interchangeable and overlapping
elements. These elements purportedly include the Java programming language itself, an "object-oriented" programming language that uses syntax heavily based on prior languages such as the
"C" and "C++" programming languages. Declaration of Owen Astrachan, Ex. 1 ¶ 18. However,
"it is undisputed that the Java programming language is in the public domain and anyone was
free to use it without charge, as Android does." Kwun Decl., Ex. F (July 22, 2011 Order) at 2;

2

see also id., Ex. E (Feb. 9, 2011 Hearing Tr.) at 8:17-18 (“[W]e’re not asserting that we own [the Java] programming language for purposes of this case.”). Also included in the elements of the Java platform are a program known as a “compiler” that creates the “bytecode” in which Java programs are executed; a virtual machine that executes the bytecode; and a set of core libraries that facilitates the development of applications for the Java platform by providing basic system or language functionalities. Astrachan Decl., Ex. 1 ¶ 18.

Today, Java is a popular programming language, and many Internet and mobile applications are written in the Java language. Id. Indeed, Oracle claims that Java has attracted 6.5 million software developers, who must be familiar with, and accustomed to, the naming conventions and functionalities of the basic Java language to develop their programs. See Kwun Decl., Ex. A (Am. Compl.) ¶ 9.

The Java programming language was designed to use a grammar and syntax that was
similar to those of other well-known, existing languages, such as C and C++. Astrachan Decl.,
Ex. 1 ¶ 124. Reusing C and/or C++ grammar and syntax allowed Sun to leverage the existing
knowledge of programmers at the time the Java programming language was developed. Id. As
the primary creator of the Java language has acknowledged, "Java feels very familiar to many
different programmers because Sun had a very strong tendency to prefer things that had been
used a lot over things that just sounded like a good idea." Id., Ex. 1 ¶ 124 & Ex. 2 at 53.

Like any high-level programming language, the Java programming language contains
many rules of grammar and syntax that generally cannot be varied. Id., Ex. 1 ¶ 19. For example,
a statement adding two numbers can only be written in certain ways, and the language requires
specific and precise keywords to express such things as variable types (integers, strings, or
booleans) and more complex object types such as dates or database queries. Id. Even the
capitalization of identifiers in the Java programming language is subject to language
requirements and best practices. Id. ¶ 113. In addition, the Java language, like many
programming languages, employs keywords and operators (such as plus and minus symbols) that
can only be used for specific purposes and in specific ways; using them for other purposes will
cause a program to fail to function correctly. Id. ¶ 19. Much of the structure and appearance of

3

code written in the Java programming language is therefore dictated by functional
considerations. Id.

2. The Android platform.

The Android platform is a freely-distributed, open-source software stack for mobile
devices that includes an operating system, middleware and key mobile applications. Declaration
of Daniel Bornstein ¶ 2. In the early days of its development, Android, Inc. and then Google
(which purchased Android, Inc. in 2005) pursued numerous possibilities for developing the
platform, including a technology partnership with Sun (incorporating Sun's implementation of its
virtual machine and Java language libraries into the platform), as well as developing Android
from the ground up. Id. When the partnership negotiations failed, Google decided to
concentrate fully on the ground up solution, using only new materials and publicly-available
open-source materials. Id.

Android was built to be a truly "open" platform. Android is made available under
permissive open source license terms, primarily the Apache License, Version 2.0. Id. ¶ 3.5 The
information and source code for the Android platform are freely available for developers,
manufacturers, or any member of the general public to download at http://source.android.com
and http://developer.android.com. Id. The software development kit ("SDK") for the Android
platform was first publicly released by Google in 2007. Id.

Android provides access to a wide range of useful libraries and tools that can be used to
build rich mobile applications by interfacing with hardware that is typically not available on
desktop platforms. Id. ¶ 4. For example, Android enables developers to obtain the location of
the mobile device using the phone's built-in GPS technology, or to create photography
applications using the built-in camera. Id. Developers for Android can create software
applications for Android-based mobile devices using various programming languages, including
the Java programming language. Id. Other languages supported by Android include C, C++,
and JavaScript, among others. Id.

4

Android contains over 50 thousand files and over 11 million lines of code, and is built on
an underlying Linux kernel. Id. ¶ 5 The Linux kernel is an open source operating system kernel
that communicates directly with the hardware device and manages core functions and
communications (such as those relating to memory management, process management and
hardware drivers) between the applications and the device. Id. ¶ 5 & Ex. A (diagram illustrating
the major components of the Android platform).

The Android platform includes, among other things, the Android SDK and the Dalvik
Virtual Machine ("VM"). Id. ¶ 6. The Android SDK is a comprehensive set of development
tools provided to software developers who wish to create applications for Android devices. Id.
The Dalvik VM is a new intermediate software layer, created by Google, that allows programs,
including those written in the Java programming language, to run on the Android platform. Id.
The Dalvik VM and Android platform accomplish this function in part by using a collection of
168 libraries (also referred to as "packages") referred to as the "Android Core Libraries." Id.

Some of the Android Core Libraries incorporate and were in part derived from Java
language API libraries from Apache Harmony ("Harmony" or the "Harmony Project"). Id. ¶ 7.
The Harmony Project, founded in May 2005, is an open source project that includes libraries
written to be interoperable with the Java language APIs included in the Java 2 Standard Edition
platform. See Kwun Decl., Exs. H at 2 & I at 1. Harmony, which predates Android, was
developed by the non-profit Apache Software Foundation. The Harmony Project took steps from
its creation to ensure that Sun's (now Oracle's) intellectual property was respected, calling the
issue "very important" in the project's initial announcement and detailing three separate
mechanisms by which the project would ensure respect of Sun's rights. See id., Ex. J at 3 (text
under the heading "How will you ensure that the intellectual property of Sun and others is
respected?"). To the best of Google's knowledge, neither Sun nor Oracle has ever accused the
Apache Software Foundation or its libraries of infringing any of Oracle's copyrights.6

As part of the early development work on Android, Google retained an independent

5

contractor to develop certain Android Core Libraries. Bornstein Decl. ¶ 8. Google informed the
contractor that it was interested in interoperability with version 1.5 (now known as version 5.0)
of the Java 2 Standard Edition platform. Id. In other words, Google--like Apache--was
interested in maximizing compatibility with the Java programming language. The contractor
was retained and instructed to write new code, reuse and improve original code created by
Google, or import and improve code from permissively licensed (or equivalent) open source
projects, such as the Harmony Project--but not from any proprietary materials, including Sun
materials. Id.

B. APIs define how pieces of software can interact with each other.

An API allows one piece of software to call on another piece of software to perform a
function; in other words, it is a method or means through which two computer programs or
portions of programs are able to interact and communicate with each other. Astrachan Decl.,
Ex. 1 ¶ 24; see also id. ¶¶ 26-35. An API is typically defined in a written document known as a
"specification," which describes the API and its function and explains how the API is to be
implemented in code. Id. ¶ 55. The specification gives the name of the API, the required inputs
for the API, the expected results of invoking the API, and the requirements that the code
implementing the API (including any associated files or libraries needed for the API to execute
properly) must meet in order to carry out the purpose of the API correctly. Id. The
specifications for the thirty-seven Java language API packages at issue were published or made
available in various forms, including in books and on the Java website, starting in 1996. Id. ¶ 20.

Much like many prior programming languages, Java language APIs also typically include
subparts or files known as "classes" and, within classes, "methods." Id. ¶¶ 36-38, 48. Each of
the Java language API packages at issue is a grouping of classes, which themselves are
groupings of methods. Id. ¶ 48. The source code for the APIs for the Java programming
language typically includes text known as "comments"; comments do not affect the compiled
code but, instead, may document what the code does. See id. ¶¶ 58, 171. For example, the
comments may describe to the programmer the function and rules for using the API. Id. ¶ 58.
For Java, the reference materials used by programmers (typically referred to as the API's

6

"documentation") is machine-generated automatically from these comments. See id.

C. An example: How to calculate an absolute value in Java.

One of the API packages that Oracle accuses Google of infringing is the "java.lang"
package. Kwun Decl. Ex. C at 10:4. According to Oracle's documentation, this package
"[p]rovides classes that are fundamental to the design of the Java programming language."
Astrachan Decl., Ex. 1 ¶ 39. One of those "fundamental" classes is the "Math" class, which
"contains methods for performing basic numeric operations such as the elementary exponential,
logarithm, square root, and trigonometric functions." Id. One such method defined in the Math
class is the "abs" method, which is used to calculate the absolute value for a given number. Id.

The "integer" version of the abs method7 has the "declaration"8 "public static int abs
(int i)." Id. ¶ 57. The declaration identifies the method and uses the name of the method set
forth in the specification. Id. ¶¶ 40-46. The "int i" in the parentheses means that the abs method
accepts one "argument" as an input, and the input is an integer ("int" is short for "integer"). Id.
¶ 47. The "static int" before the "abs" in the declaration means that this version of the abs
method returns an integer. Id. A programmer who wants to calculate the absolute value of, for
example, -25 would thus include the text "abs(-25)" in his or her program. Id. ¶ 37.

The Android code for the "abs" method discussed above is in the Android file Math.java.
Id. ¶ 57 n.2. The portion of this file relevant to the abs method is:

7

Id. ¶ 57. The first line, "package java.lang," means that this file is part of the "java.lang"
package. Id. This is the name of the package of classes in which this file resides. Id. The text
beside the asterisks in each line are comments embedded in the code (shown in blue) that explain
this method to programmers, which (as discussed above) in turn are used to automatically
generate the "documentation" for the method. Id. ¶ 58. The line "public static int abs(int i)" and
the lines beneath it repeat the declaration of the "abs" method (shown in green) and then present
the program logic for the method (shown in red). Id. ¶ 59.

In this example, the actual program logic of the method--the code that actually
calculates the absolute value--is the text "return i >= 0 ? i : -i;", which effectively says, "if the
number we are given is greater than or equal to 0, return that number, and otherwise return that
number but with the opposite sign." Id. Because the absolute value operation is relatively
simple, very little program logic is needed for this method. Id. For more complicated methods,
many lines of program logic may be needed. Id. Everything other than this program logic
describes what the method is called, how a programmer can invoke it, what the method does, and
what the method will return when it is completed. The program logic for the method, in contrast,
is the code that actually tells the computer how to perform the method (in this case, how to
calculate the absolute value of an integer).

The "abs" method declaration is the same not only in Java and Android, but also in the
two major open source Java language projects--Apache Harmony and GNU Classpath. Id. ¶ 61.
All four use identical method declarations:

Java: public static int abs(int a)

Harmony: public static int abs(int i)

GNU Classpath: public static int abs(int i)

Android: public static int abs(int i)

8

Id. In addition, both Apache Harmony and GNU Classpath have implemented the Java language
API packages that are the subject of Oracle's infringement claim against Google. Id. In each
case, the names of the packages and methods are the same. Id.

D. Oracle's copyright infringement claim.

In its interrogatory answers, Oracle has set forth the basis for its claim of copyright
infringement. See Kwun Decl., Ex. C (relevant excerpts from Oracle's Supplemental Responses
to Google's First Set of Interrogatories, served on July 29, 2011). Oracle alleges in its
Responses that the specifications for thirty-seven Android Java language API packages (the
"Accused Packages") "are unauthorized derivative work" and are "derived from or substantially
similar to" the corresponding Java language API specifications contained in the Oracle's asserted
works.9See id. at 9:15-11:9. Oracle points to no specific code in the API packages that it claims
to have been copied from Oracle code; rather, it asserts that Google has infringed by including in
Android implementations of APIs that provide compatibility for applications written in the
standard Java programming language. See id. at 11:10-14. Indeed, Oracle's illustrative exhibits
that purportedly show the infringement do not include any of the program logic for any of the
methods. See Kwun Decl., Ex. D (exhibits to Oracle's Responses).

Although Oracle also claims that the Android code that implements those specifications is
an "unauthorized derivative work," Kwun Decl. Ex. C at 11:16, when it comes to the actual
material that allegedly was copied, Oracle again points only to its specifications. Id. at 12:22-24
("For example, Google makes and distributes dalvikvmnativejava_lang_Class.c, which is
based on Oracle's java.lang.Class specification").10

9

The only allegations of literal code copying specifically identified by Oracle relate to 12
specific files (the "Accused Files")11--out of more than 50 thousand files in Android--that
contain portions that Oracle alleges are similar to Oracle code. See id at 13:26-14:27. This
group of files, in the aggregate, comprises far less than one percent of Android, whether analyzed
in terms of the number of files or the number of lines of code. Astrachan Decl., Ex. 1 ¶ 150.
These twelve files also amount to far less than one percent of the Asserted Works. Id.

Eight of the twelve files identified by Oracle,12 moreover, came from a Google
contractor, and are "test files" for the purpose of verifying that certain aspects of the
corresponding program file worked correctly. Bornstein Decl. ¶ 8. These files do not have any
effect on the code that ships on Android devices, and there is no reason that these files would
ever be present on Android devices. Id. In fact, after this lawsuit was filed, Google removed
these unnecessary files from the Android platform, and has not replaced them with new files. Id.

The other four files include minimal text similar to text in Oracle materials. The only
allegedly copied text in two of those files13--files that Google received from the same
independent contractor that provided it with the eight files just discussed, id. ¶ 9--is in twenty
"comments," i.e. text that documents the code rather than operative code itself. Astrachan Decl.,
Ex. 1 ¶ 170. Those unnecessary comments have also been removed from the Android files.
Bornstein Decl. ¶ 9.14 The final two files15 each include only nine (out of several hundred) lines

10

that appear to be the same as lines in the Oracle materials. Astrachan Decl., Ex. 1 ¶ 152. Those
nine lines (which are the same in both of the Android files) implement a mundane utility
function. Id. ¶¶ 153-56.

III. ARGUMENT

A. Because Oracle cannot establish that Google copied protected elements of the Java
language API specifications, the Android APIs are not substantially similar to
Oracle's Java language API specifications.
To establish copyright infringement, a plaintiff must prove ownership of the copyrighted
work and that the defendant copied protected elements of the work. Jada Toys, Inc. v. Mattel,
Inc., 518 F.3d 628, 636 (9th Cir. 2008). "The mere fact that a work is copyrighted does not
mean that every element of the work may be protected." Feist Publ'ns, Inc. v. Rural Tel. Serv.
Co., 499 U.S. 340, 348 (1991). Ordinarily, to prove copying, a plaintiff must show that
defendant "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.

Copyright protects only the expression of an idea, not the idea itself. 17 U.S.C. § 102(b).
Where the similarities between a plaintiff's and defendant's works are limited to "ideas and
general concepts," there is no infringement. Data East USA, Inc. v. Epyx, Inc., 862 F.2d 204,
208 (9th Cir. 1988). Substantial similarity cannot be based on expression where an idea and its
expression are inseparable, or where that expression is "as a practical matter, indispensable or at
least standard in the treatment of a given [idea]." Id. (quotation marks and citations omitted). To
avoid an improper finding of infringement based on unprotectable expression, Ninth Circuit law
calls for an "analytic dissection" of similarities. Id. Where all similarities in expression arise
from unprotectable elements, there is no substantial similarity, and thus no infringement. Id.
Analytic dissection to determine the proper scope of a copyright is a question of law. See Apple
Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1443 (9th Cir. 1994) ("Using analytic
dissection, and, if necessary, expert testimony, the court must determine whether any of the
allegedly similar features are protected by copyright" (emphasis added)).

As explained below, the only similarities between the Accused Packages and the Java
language API packages lie in the specifications for those APIs. But similarities in only

11

"functional specifications," as opposed to the program logic that performs the steps required by
those specifications, are not copyright infringement. SeeSega Enterprises Ltd. v. Accolade,
Inc., 977 F.2d 1510, 1526 (9th Cir. 1992). Moreover, where, as here, "the range of protectable
and unauthorized expression is [at most] narrow, the appropriate standard for illicit copying is
virtual identity." Apple, 35 F.3d at 1439. Because Oracle cannot show that the Android platform
is virtually identical to the Asserted Works (or, indeed, even substantially similar), Google is
entitled to summary judgment that the Accused Packages do not infringe the Asserted Works.

1. The only elements common to Oracle's Java language APIs and the Android
APIs are unprotectable methods of operation.

As long ago as 1879, the Supreme Court made clear that publication of a book that
explains a particular accounting system gives the author no rights under the copyright laws to
prevent others from using the system, as long as no protectable expression from the book is
copied. Baker v. Selden, 101 U.S. 99 (1879); see also 17 U.S.C. § 102(b) ("In no case does
copyright protection . . . extend to any idea, procedure, process, system, method of operation,
concept, principle, or discovery, regardless of the form in which it is described, explained,
illustrated, or embodied in such work."). Oracle's Java language books and API specifications
give Oracle no greater rights to prevent implementation by others of the APIs using original
code.

This principle applies equally in the computer context. In Lotus Development Corp. v.
Borland Int'l, Inc., the court reversed a summary judgment against a defendant that developed a
competing program that copied the words and structure of Lotus's menu command hierarchy in
its spreadsheet program (but not the underlying source code). 49 F.3d 807 (1st Cir. 1995), aff'd
by an evenly divided court, 516 U.S. 233 (1996). The court found the menu command hierarchy
to be functional and uncopyrightable. Id.

In so holding, the court concluded that "the Lotus menu command hierarchy is an
uncopyrightable 'method of operation.'" Id. at 815. The court reasoned that it would be "absurd"
to require every software provider to create different methods for performing each function in a
program, which would require users to learn a multitude of different ways to, for example, print

12

files. Id. at 817-18. "The fact that there may be many different ways to operate a computer
program, or even many different ways to operate a computer program using a set of
hierarchically arranged command terms, does not make the actual method of operation chosen
copyrightable; it still functions as a method for operating the computer and as such is
uncopyrightable." Id. at 818; see also 17 U.S.C. § 102(b) (method of operation is unprotectable
"regardless of the form in which it is described, explained, illustrated, or embodied").

The same reasoning applies to APIs for a programming language. See Astrachan Decl.,
Ex. 1 ¶¶ 91-98 (explaining why the Java language APIs are methods of operation). By providing
Android API packages addressing many of the same common methods that are provided by
Oracle's Java language API packages, Google has ensured that programmers using the Java
language need not learn a new way to call these methods when writing programs for both the
Java and the Android platforms. See id. ¶¶ 129-33. For example, to make use of the
functionalities of the java.lang.Math class in the java.lang API package, a programmer would use
the appropriate method name from the java.lang.Math class, such as "sqrt()," to calculate the
square root of a number. Id. ¶ 25. When the program is run by the user, the underlying platform
will then perform the "sqrt()" functionality and return the appropriate data. Id. This is no
different from executing a menu command to perform a spreadsheet function. SeeLotus, 49 F.3d
at 816 ("If specific words are essential to operating something, then they are part of a 'method of
operation' and, as such, are unprotectable."). Oracle has not even tried to allege that the
underlying program logic in Android that performs this function was copied from the Asserted
Works. See supra, Part II.D. It would be "absurd" to require that Android use, for example,
different names than Oracle did for common mathematical methods, or for Android to group
mathematical methods in different packages than Oracle did. "[F]orcing the user to cause the
computer to perform the same operation in a different way ignores Congress's direction in
§ 102(b) that 'methods of operation' are not copyrightable." Lotus, 49 F.3d at 818.

Similarly, in Mitel, Inc. v. Iqtel, Inc., 896 F. Supp. 1050, 1055-56 (D. Colo. 1995), aff'd,
124 F.3d 1366 (10th Cir. 1997), the court held that command codes that served as a user
interface by which technicians activated various functions of a call controller were unprotectable

13

methods of operation. "If, arguably, the command codes are considered part of the computer
program in the call controller then their sole purpose is to provide access to the functions
available in the call controller. Thus, they provide the means to access or operate the program
contained in the software." Id. at 1055. Like the command codes in Mitel, the Java language
APIs at issue constitute unprotectable methods of operation. At their most abstract level, their
purpose is to provide access to common functions of language that are frequently used by
programmers consistent with a published and familiar Java language API specification. See
Astrachan Decl., Ex. 1 ¶¶ 129-33.

The purpose of the Copyright Act is "[to promote the Progress of Science and useful
Arts . . . ." U.S. CONST. art. I, § 8, cl. 8. To accomplish this goal, others must be allowed "to
build freely upon the ideas and information conveyed by a work." Feist, 499 U.S. at 350. As the
Lotus court recognized, "[i]n the context of methods of operation, . . . 'building' requires the use
of the precise method of operation already employed; otherwise, 'building' would require
dismantling, too." 49 F.3d at 818; see also Sega, 977 F.2d at 1522 (citing § 102(b) for the
proposition that "functional requirements for compatibility" are not protected by copyright).16 It
is undisputed that the program logic (other than elements of the 12 files addressed below in
Part III.B) for the Accused Packages was not copied. Because the API specifications are
methods of operation, they are not protected by copyright.

2. The API declarations are unprotectable scenes a faire or unprotectable under
the merger doctrine.

The allegedly copied elements of the Java language API packages are also not protectable
because they are required for interoperability; they allow a program written in the Java
programming language to run on the Android platform. Expression dictated by external factors,
such as industry practices and standard techniques used to perform particular functions in a
specific computing environment, is unprotectable scene a faire or unprotectable under the
merger doctrine, which precludes copyright protection for expression in which the underlying

Because computer programs are essentially "utilitarian" in nature, see Sega, 977 F.2d at
1524, these external factors are prominent and will render unprotectable elements of a program
dictated by compatibility17 requirements, industry demands, or widely accepted programming
practices. Sega, 977 F.2d at 1524. This is because "in many instances it is virtually impossible
to write a program to perform particular functions in a specific computing environment without
employing standard techniques." Computer Assocs., 982 F.2d at 709 (quoting 3 MELVILLE B.
NIMMER & DAVID NIMMER, NIMMER ON COPYRIGHT § 13.03[F][3]); see also id. at 708 (in view
of desire to create programs that meet users' needs efficiently, "the applicability of the merger
doctrine to computer programs becomes compelling"); Lexmark Int'l., Inc. v. Static Control
Components, Inc., 387 F.3d 522, 535-36 (6th Cir. 2004) (programming efficiency "figures
prominently in the copyrightability of computer programs").

Courts have routinely emphasized that compatibility is a legitimate aim, and can override
claims for infringement under either the scenes a faire or fair use doctrines. E.g., Bateman, 79
F.3d at 1547; Baystate Techs. v. Bentley Sys.,, 946 F. Supp. 1079, 1087-90 (D. Mass. 1996);
Mitel, 896 F. Supp. at 1055-56. In Baystate, the plaintiff sued Bentley, a competing CAD
program developer, contending that Bentley had infringed Baystate's rights in the CADKEY
source code, the Part File Tool Kit source code and the Part File Tool Kit documentation. 946 F.
Supp. at 1085-86. The Part File Tool Kit consisted of definitions or header files, a library of
executable files, and documentation that described the organization of the file data structure and
descriptions of the access functions included in the library of executable files, and allowed a user
or third party developer to read and write the data files into a non-CADKEY program. Id. at
1083. Bentley's contractor admitted that it "referred" to the Tool Kit documentation in

15

developing a data translator that would permit the transfer of information between Baystate's
CADKEY program and Bentley's CAD program. Id. at 1082-87. The court held that the names
and organization of the data structures were not protectable and there was no infringement:

The product being developed is a data translator that is designed to "read" the data
files of CADKEY. The process of "reading" the CADKEY data files requires that
the elements contained within the data structures of the Translator be organized in
the same manner as the elements in the data structures of CADKEY. Without
such compatibility, the Translator would not function because it would "misread"
the CADKEY data files.

Id. at 1088.

Similarly, the court in Mitel found the command codes at issue to be unprotectable scenes
a faire. The court found that the "proclivities of technicians largely dictate the need to conform
the command codes in order to have market accessibility." Mitel, 896 F. Supp. at 1055-56.
Because Iqtel had copied the command codes for efficiency reasons (as "[t]echnicians who
installed and programmed call controllers were accustomed to Mitel's command codes and
expressed a reluctance to learn new codes"), use of those elements was dictated by external
factors. Id. at 1053.

The similarities in the unprotected elements present in the Oracle Java language API
packages and the Android Java language API packages, e.g., the names of packages and methods
and definitions, are there for one purpose and one purpose only: enabling programs written in the
Java programming language to run on the Android platform. See Astrachan Decl., Ex. 1 ¶¶ 129-33. If different names had been used for these interfaces in Android, existing code written in the
Java programming language simply would not run properly and the programs would not
function, and programmers writing new applications in the Java language for Android devices
would have to learn new API names for methods they already knew. See id. ¶ 135. As in
Baystate, where the names and organization of the data files used by the defendant had to be
identical to those in plaintiff's program in order for defendant's translator to function correctly,
the specifications for the APIs must be identical in order for programs written in the Java
programming language to operate on Android devices. See also Paul GOLDSTEIN, GOLDSTEIN ON
COPYRIGHT § 2.15.3, at 2:208 (3d ed. 2011) (identifying machine to machine, program to

16

program, and program to machine interface specifications as interfaces "in which design
consumes relatively few creative resources and no room for variation exists if one element is to
be able to interoperate with the other").

The APIs at issue were implemented in order to provide experienced programmers with
an efficient, familiar method of performing the same basic operations. See Astrachan Decl.,
Ex. 1 ¶¶ 134-38 (discussing industry demand for compatibility). For example, as has already
been noted, for compatibility and standardization reasons, the "abs" function discussed earlier
has the following identical method declaration not only in Java and Android, but also in
Harmony and GNU Classpath. Id. ¶ 61. Indeed, both Harmony and GNU Classpath have
implemented the API packages that are the subject of Oracle's infringement claim against
Google. In each case, the names of the packages and methods are the same, id., so that
programmers need not resort to the "absurd" task of learning to perform the same operation in
different ways. While the program logic that performs the actions required by the APIs may be
(and in fact is) different, the names (or abbreviations), specifications for the APIs must be
identical to allow for interoperability. Id. ¶ 53.

3. The Java language API package
and method names are unprotectable as a matter of law.

Oracle has alleged that Google "copied" the names of the Java language APIs at issue.
But the names of the Java language API files, packages, classes, and methods are not protectable
as a matter of law. See 37 C.F.R. § 202.1(a) ("Words and short phrases such as names, titles and
slogans" are not subject to copyright). Moreover, the names merely describe the functionality of
the packages and methods, and/or otherwise are the result of customary programming practices.
Astrachan Decl. ¶ 7(b)-(f) & Ex. 1 ¶¶ 99-117, 120-22; see also Merchant Transaction Sys., Inc.
v. Nelcela, Inc., No. CV 02-1954-PHX-MHM, 2009 WL 723001, at *12 (D. Ariz. March 18,
2009) ("Clearly, isolated field names `are not original, are within the public domain, and are not
entitled to individual protection.'"); CMM Cable Rep, Inc. v. Ocean Coast Props., 97 F.3d 1504,
1519 (1st Cir. 1996) ("It is axiomatic that copyright law denies protection to 'fragmentary words
and phrases' and to 'forms of expression dictated solely at functional considerations' on the

17

grounds that these materials do not exhibit the minimal level of creativity necessary to warrant
copyright protection."); Baystate, 946 F. Supp. at 1088 (finding that "data structure names or,
more specifically, the words and abbreviations used to describe the files contained within the
data structures and the data structures themselves" were not protected by copyright because "the
name of a file is typically related to its function").

The names, methods, and contents of the Java language API packages reflect customary
naming practices in the computer industry. For example, package names such as "java.io,"
"java.util," and "java.net" reflect industry shorthand for common functionality, namely
input/output, utilities, and networking, respectively. Astrachan Decl., Ex. 1 ¶ 124. These
packages with common names then, in turn, contain methods whose naming reflects industry
custom and representation of the underlying functionality. Astrachan Decl. ¶ 7 (d)-(f) & Ex. 1
¶¶ 103-17. Some examples of function names that are very similar in Java and the pre-existing C
and C++ languages as a result of their functionality and industry custom include: "char" to
identify a data type holding a character; "int abs (int i)" to identify a function that returns the
absolute value of a number; and "printf()" for a function that prints a string to an output device.
Astrachan Decl., Ex. 1 ¶ 124. All of these names were used in at least the C language before
they were used in Java. Id.; see also Astrachan Decl., Ex. 2 at 53 ("Java feels very familiar to
many different programmers because Sun had a very strong tendency to prefer things that had
been used a lot over things that just sounded like a good idea.").

These are not the only examples; many of the "names" used in the Java language have
been used by the industry for decades. For example, the C Reference Manual, written by Brian
Kernighan, the inventor of the C programming language, and published in 1975, references "int,"
"double" and "char"--all of which are used in Java. Astrachan Decl., Ex. 1 ¶ 125. "Bool"
(which became "Boolean" in Java) dates back further, to at least 1968. Id.; see also id. ¶¶ 126-28; Computer Assocs., 982 F.2d at 710 ("Closely related to the non-protectability of scenes a
faire, is material found in the public domain. Such material is free for the taking and cannot be
appropriated by a single author even though it is included in a copyrighted work," citing Brown
Bag Software v. Symantec Corp., 960 F.2d 1465, 1473 (9th Cir. 1992), in affirming the district

18

court's finding that "'[p]laintiffs may not claim copyright protection of an . . . expression that is,
if not standard, then commonplace in the computer software industry'").

4. Alternatively, any similarity between the works is a fair use.

For much the same reasons that the elements of the Java language APIs at issue are
unprotectable, the inclusion of those elements in Android for the purpose of allowing third party
Java programmers to write compatible applications constitutes a fair use as a matter of law. See
Bateman, 79 F.3d at 1547 (relying on fair use as an alternative basis for non-infringement);
Mitel, 896 F. Supp. at 1056 ("Even assuming the command codes are copyrightable, Iqtel's use
of these same command codes constitutes a 'fair use' under the Act.") A finding of fair use can
be made on summary judgment and is especially appropriate where, as here, any alleged copying
serves a transformative purpose. E.g., Kelly v. Arriba Soft Corp., 336 F.3d 811, 817-22 (9th Cir.
2003) (affirming summary judgment finding that defendant's use of thumbnails that copied
plaintiff's images and linked to the website where the image was stored was fair use).

The use of the same names and functional method declarations for the thirty-seven Java
language APIs serves the transformative purpose of allowing applications written in the Java
language to run on the Android platform. Section 107 of the Copyright Act lists several non-exhaustive factors to be considered to determine fair use: (1) the purpose and character of the
use, including whether such use is of a commercial nature or is for non-profit 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. Sega, 977 F.2d at 1521-22.

The character of the use: Where, as here, a use serves a transformative purpose,
summary judgment is appropriate. See, e.g., Perfect 10, Inc. v. Amazon.com, Inc., 508 F.3d
1146, 1164 (9th Cir. 2007) ("A work is 'transformative' when the new work does not 'merely
supersede the objects of the original creation' but rather 'adds something new, with a further
purpose or different character, altering the first with new expression, meaning, or message,'"
citing Campbell v. Acuff-Rose Music, Inc., 510 U.S. 569, 579 (1994)).

As discussed above, the names and method declarations of the Java language API

19

packages are used in Android for compatibility and standardization reasons, as part of the open source Android platform. Open source licensing has generally transformed what have historically been thought of as commercial uses, creating a new model of technology development that leverages public goods and participation. See Sega, 977 F.2d at 1523 (courts “are free to consider the public benefit resulting from a particular use”; “[p]ublic benefit need not be direct or tangible, but may arise because the challenged use serves a public interest”; finding fair use and concluding that “Accolade’s identification of the functional requirements for Genesis compatibility has led to an increase in the number of independently designed video game programs offered for use with the Genesis console”).

Moreover, the Ninth Circuit has specifically held that a computer program is transformative if it is developed for a new platform, even one that competes with that of the copyright owner. See, e.g., Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 606-07 (9th Cir. 2000). The court in Sony held it was a fair use for Connectix to reverse engineer the BIOS software that operates the Sony PlayStation console in order to create a competing program that emulated the functioning of the PlayStation and allowed PlayStation games to be played on a computer. Id. at 599, 608. In finding fair use, the Sony court concluded that the defendant’s product was transformative because it created a new product that was compatible with PlayStation games, “notwithstanding the similarity of uses and functions between the Sony PlayStation” and Connectix’s product. Id. at 606-07. Similarly, Google’s implementation of the Java language APIs at issue was transformative because it enabled programmers to develop applications written in the Java programming language to run on Android, a wholly new “smart phone” platform.

The nature of the copyrighted work: “To the extent that a work is functional or factual, it may be copied.” Sega, 977 F.2d at 1524, 1527 (concluding that computer programs are “essentially utilitarian” in nature and that under the Copyright Act, “if a work is largely functional, it receives only weak protection”). As discussed above, the APIs at issue serve an entirely functional purpose and were included in Android to enable interoperability.

The portion of the work used: The thirty-seven API packages identified by Oracle are

20

approximately one-quarter of the API packages in the Asserted Works. Within these packages and their implementations, only the names of the packages and methods were used by Google for compatibility reasons. It is undisputed (and Oracle has never alleged to the contrary) that the underlying source code implementing those packages and methods, which constitute the vast majority of that code—hundreds of thousands of lines, see Astrachan Decl. ¶ 7(h) & Ex. 1 ¶ 143—was not used by Google. Instead, Google independently developed or obtained from a third party open source project the code that implemented these APIs. Because Google used only the portions of the API packages necessary for compatibility, this factor weighs in its favor. See Kelly, 336 F.3d at 820-21 (“If the secondary user only copies as much as is necessary for his or her intended use, then this factor will not weigh against him or her.”).

The effect upon the market for the copyrighted work. If anything, Android has contributed positively to the market for the copyrighted works by increasing the number of Java language developers. As Sun’s CEO Jonathan Schwartz said when Google released the Android SDK in 2007, “needless to say, Google and the Open Handset Alliance just strapped another set of rockets to the [Java] community’s momentum - and to the vision defining opportunity across our (and other) planets.” Kwun Decl., Ex. L. Rich Green, then Sun’s executive vice president of software, also said that Sun was “thrilled to have Google amplify the global momentum behind Java technology . . . .” Id., Ex. M.

Moreover, even if Android’s use of these API elements was considered to be competitive with Oracle’s, the outcome is the same. E.g., Sega, 977 F.2d at 1523 (Accolade “sought only to become a legitimate competitor in the field of Genesis-compatible video games. Within that market, it is the characteristics of the game program as experienced by the user that determine the program’s commercial success. As we have noted, there is nothing in the record that suggests that Accolade copied any of those elements.”); Kelly, 336 F.3d at 821 (“A transformative work is less likely to have an adverse impact on the market of the original than a work that merely supersedes the copyrighted work”); Sony, 203 F.3d at 607 (recognizing that some economic loss by Sony as a result of the defendant’s competition does not compel a finding of no fair use; “Sony understandably seeks control over the market for devices that play games

21

Sony produces or licenses. The copyright law, however, does not confer such a monopoly.”).

Finally, like the uses of these same common elements by others such as Apache Harmony
and GNU Classpath, Android’s use of the Java language API names and method descriptions are essential for compatibility. Their inclusion in Android could not have had any greater impact than the existing use of these same functional elements by others already in the “market.”

Google’s use is a fair use. The limited and transformative nature of Google’s use of the functional names and method descriptions of the APIs to make Android’s mobile platform interoperable and compatible with Java applications and to further the efforts of third party developers weighs heavily in favor of finding fair use. “In determining whether a challenged use of copyrighted material is fair, a court must keep in mind the public policy underlying the Copyright Act. . . . [T]he fundamental purpose of the Copyright Act [is] to encourage the production of original works by protecting the expressive elements of those works while leaving the ideas, facts, and functional concepts in the public domain for others to build on.” Sega, 982 F.2d at 1527; see also Sony, 203 F.3d at 608 (“The four statutory fair use factors must be ‘weighed together, in light of the purposes of copyright,’” citing Campbell, 510 U.S. at 578); Perfect 10, 508 F.3d at 1166, 1168 (“‘the more transformative the new work, the less will be the significance of other factors, like commercialism, that may weigh against a finding of fair use,’” quoting Campbell, 510 U.S. at 579; finding fair use where Google’s thumbnails were transformative and there was no proof of harm to Perfect 10’s market); Kelly, 336 F.3d at 818 (applying same principle).

B. The alleged similarities in the remaining 12 files are de minimis in the context of the
over 9,500 files in the Asserted Works, and the over 50 thousand files in Android.

De minimis acts of copying are not actionable. Newton v. Diamond, 388 F.3d 1189,
1192-93 (9th Cir. 2004). Where the only similarity is as to "nonessential matters," the copying is
de minimis. See id. at 1195 (quoting 4 MELVILLE B. NIMMER & DAVID NIMMER, NIMMER ON
COPYRIGHT § 13.03[A][2], at 13-48). Where a defendant copies only "a portion of the plaintiff's
work exactly or nearly exactly . . . the dispositive question is whether the copying goes to trivial
or substantial elements." Id. That substantiality is judged by "considering the qualitative and

22

quantitative significance of the copied portion in relation to the plaintiff's work as a whole." Id.
(emphasis added).

The twelve Accused Files that Oracle contends contain Oracle source code or other material allegedly copied from the Asserted Works cannot support a finding of infringement. First, even assuming for purposes of this motion that the Accused Files contain copied Oracle material, that copying is quantitatively miniscule, comprising less than 750 lines of comments and code out of 2.8 million lines of code in the Asserted Works as a whole, and 12 files out of more than 9,500 files in the Asserted Works as a whole. Astrachan Decl., Ex. 1 ¶ 150.

Second, the allegedly copied lines are qualitatively insignificant. Eight of the files (files provided by an independent contractor to Google, which have since been removed from the Android platform) are simple test files that do not have any effect on the code that ships on Android devices, and are never present on Android devices. Bornstein Decl. ¶ 8; Astrachan Decl., Ex. 1 ¶¶ 160-68. In two other files, also provided by the independent contractor, the allegedly copied lines are only in the comments (which also have since been removed), and those comments are in any event are largely descriptive and functional. Bornstein Decl. ¶ 9; Astrachan Decl., Ex. 1 ¶¶ 169-77. As to these two files, any alleged copying has no effect on the code in shipped devices because comments do not change the code that results from a programming file. Astrachan Decl., Ex. 1 ¶ 171. The final two files both contain, as part of hundreds of lines of code, the same nine lines similar to code in the Asserted Works. Id. ¶ 152. Those nine lines18 implement a mundane task that, far from being the heart of the Asserted Works,19 represent a utilitarian function that performs a simple “sanity check” to make sure that certain variables are “in bounds.” Id. ¶¶ 153-66; see Newton, 388 F.3d at 1196 (expert testimony that the copied elements were “common, trite, and generic” sufficed to demonstrate that the elements were qualitatively insignificant).

Because the alleged similarities in the twelve files are both quantitatively and

23

qualitatively insignificant, any alleged copying is de minimis, and thus not actionable. MiTek Holdings, Inc. v. Arce Eng’g Co., Inc., 864 F. Supp. 1568, 1585 (S.D. Fla. 1994) (“Of the protectable elements that are substantially similar, the Court has found that their lack of importance in the context of the programs as a whole renders any copying by Arce to be de minimis.”), aff’d, 89 F.3d 1548, 1560 (11th Cir. 1996) (“We agree with the district court that the elements that were considered original and appropriated were not of such significance to the overall program to warrant an ultimate finding of substantial similarity and hence infringement.”)

C. The documentation for the Android APIs is not substantially similar or virtually
identical to the documentation for the Java language APIs.

Any similarities between the machine-generated documentation for the Android APIs and that of the Java language APIs are due to either the similarities in the APIs themselves, or industry practices regarding how documentation is written. See Astrachan Decl., Ex. 1 ¶¶ 145- 49. Just as two dictionaries will often have similar sounding definitions both because they are defining the same thing and due to external constraints (such as brevity and clarity) on how dictionary definitions are written, skilled technical writers writing about the same API are likely to come up with descriptions that appear very similar and contain very similar descriptions of the critical features. Id. ¶¶ 146-48. Given the substantial unprotected elements in the documentation (such as the API method declarations), the “virtual identity” standard applies here. Apple, 35 F.3d at 1439. No reasonable jury could find infringement based on the Android API documentation.

D. Any claim based on Oracle's selection and arrangement of allegedly copied elements
must be evaluated under the "virtual identity" standard, and Oracle cannot
establish infringement under that standard.

Finally, any residual claim of infringement based on the selection or arrangement of
allegedly copied elements must also fail. Here, the method declarations, package names, and the
rest of the API specifications are unprotectable, as discussed above. See also Astrachan Decl.,
Ex. 1 ¶¶ 48-51, 118-19. Any remaining allegedly copied material (i.e. the portions of the twelve
Accused Files) is, as explained above, de minimis. On these facts, "to the extent there is creative

24

expression left in how the works are put together, as a whole they can receive only limited protection.” Apple, 35 F.3d at 1439. This means that “illicit copying could occur only if the works as a whole are virtually identical.” Id. at 1447 (emphasis added).

Far from being virtually identical to the Asserted Works as a whole, the vast majority of the Android platform is different from the Java platform. Oracle has not even tried to claim that the Android APIs derive from more than about one-quarter of the API packages in the Asserted Works. Moreover, Android includes a host of elements, such as the Dalvik VM and a Linux kernel, that are not part of the Java platform. Astrachan Decl., Ex. 1 ¶¶ 140-42; see also Astrachan Decl. ¶ 7(h)-(i) & Ex. 1 ¶¶ 143-44. Because the “works as a whole” are not virtually identical, there is no copyright infringement.

There are no genuine disputes of material fact relating to the controlling legal issues;
Google is entitled to judgment as a matter of law. As Sun's CTO testified to Congress in 1994,
the lack of copyright protection for interface specifications drives "innovation, competition, and
economic investment" and "[a]rguments to the contrary mix up the distinction between interface
specifications and product implementations, in an attempt to retain or regain monopoly control to
limit competition." See Kwun Decl., Ex. G at 2. Google respectfully requests that the Court
grant it summary judgment on Oracle's Count VIII, for copyright infringement.

2
Declaration of Michael S. Kwun, Ex. G at 2 (emphasis added). The cited exhibit includes
the entirety of the 1994 prepared testimony of Dr. Eric Schmidt, testifying in his capacity as
Sun's CTO.

3
In February, arguing that a motion for summary judgment would be premature, Oracle
said it expected discovery would reveal further instances of alleged copying other than those of
which it was then aware. See Kwun Decl, Ex. N at 1. Today, more than six months later, the
only thing that has changed is that the number of API packages on which Oracle bases its
infringement claim has declined from fifty-one, see id., Ex. O at 7:4-9:1, to thirty-seven, see id.,
Ex. C at 10:1-11:9.

6
Harmony was not the first open source implementation of common Java language APIs.
An earlier effort, now called GNU Classpath, was launched in 1998. See id., Ex. K at 2.

7See id. ¶ 36 (explaining what a "method" is). There are three versions of the abs method,
which are used for calculating the absolute value of integers, floating point numbers (such as
1.23), and double precision floating point numbers.

9
Oracle's Amended Complaint pleads only two copyright registrations. See Kwun Decl.,
Exs. A (Am. Compl.) ¶ 11 & B (Am. Compl., Ex. H). Those registrations correspond to "Java 2
Standard Edition 1.4" and "Java 2 Standard Edition, Version 5.0." These two works are referred
to as the "Asserted Works." Oracle also referred to additional copyright registrations in an
interrogatory response, see Kwun Decl., Ex. C at 9:11-13, but has not sought to further amend its
complaint beyond the Asserted Works. That said, nothing in Oracle's interrogatory responses
suggests that the analysis of its copyright claim would change based on these additional works.

10
Essentially the same text, again without references to anything beyond alleged
similarities in the specifications for the APIs, appears in Oracle's response to Google's
interrogatory seeking identification of the specific material that Oracle alleges was copied from
the Asserted Works. See Kwun Decl., Ex. C at 20:5-22:25.

11
In its response to a Google interrogatory (Interrogatory No. 2), Oracle has specifically
identified the twelve files that it contends contain code copied from Oracle code. See id. at
13:26-14:27. In response to a further interrogatory (Interrogatory No. 5) seeking the specific
copied code, Oracle has steadfastly refused to identify the specific code that it contends was
copied, instead only repeating essentially the same general statements contained in its response
to the other interrogatory. See id. at 20:5-25:10.

13
In Oracle's Responses, these files: CodeSourceTest.java; and
CollectionCertStoreParametersTest.java. See Kwun Decl., Ex. C at 14:22-27.

14
These files were appear to drive from Apache Harmony files, and the allegedly "copied"
comments were apparently added to the Apache Harmony files by Intel in 2006. Astrachan
Decl. ¶¶ 174-75. Google received these files from a contractor. Bornstein Decl. ¶ 9.

15
In Oracle's Responses, these files: TimSort.java; and ComparableTimSort.java. See
Kwun Decl., Ex. C at 14:18-21.

16
Notably, in other products, Sun and Oracle have implemented other companies' APIs in
order to increase compatibility of the Sun and Oracle products with those of those other
companies. See Astrachan Decl., Ex. 1 ¶¶ 62-90.

17
"[I]f manufacturer 'B' would like to design a computer that can use software designed for
a computer manufactured by 'A,' B's operating system interface must match that of
manufacturer A. Without that compatibility, the software designed for A's machine will not
function on B's." Bateman v. Mnemonics, Inc., 79 F.3d 1532, 1546 (11th Cir. 1996); see also id.
at 1537 n.11 (explaining key terms and concepts involved in software copyright cases, including
"operating systems," "application programs," and "interfaces").

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

ORACLE AMERICA, INC.
Plaintiff,
v.
GOOGLE INC.
Defendant.

________________

Case No. 3:10-cv-03561-WHA

DECLARATION OF DANIEL
BORNSTEIN IN SUPPORT OF
DEFENDANT GOOGLE INC.’S MOTION FOR SUMMARY JUDGMENT ON COUNT VIII OF PLAINTIFF ORACLE AMERICA’S AMENDED COMPLAINT

Judge: Hon. William Alsup

Hearing: 2:00 p.m., September 15, 2011

I, Daniel Bornstein, declare as follows:

1. I am and have been employed by Google since October 2005 as an engineer for
the Android team. I submit this declaration in support of Defendant Google Inc.'s Motion for
Summary Judgment on Count VIII of Plaintiff Oracle America, Inc.'s Amended Complaint. I
make this declaration based on my own personal knowledge. If called as a witness, I could and
would testify competently to the matters set forth herein.

2. The Android platform is a freely-distributed, open-source software stack for
mobile devices that includes an operating system, middleware and key mobile applications. In
the early days of its development, Android, Inc. and then Google (which purchased Android, Inc.
in 2005) pursued numerous possibilities for developing the platform, including a technology
partnership with Sun (incorporating Sun's implementation of its virtual machine and Java
language libraries into the platform), as well as developing Android from the ground up. When
the partnership negotiations failed, Google decided to concentrate fully on the ground up
solution, using only new materials and publicly-available open-source materials.

3. Android was built to be a truly "open" platform. Android is made available under
permissive open source license terms, primarily the Apache License, Version 2.0. The
information and source code for the Android platform is freely available for developers,
manufacturers, or any member of the general public to download at http://source.android.com
and http://developer.android.com. The software development kit ("SDK") for the Android
platform was first publicly released by Google in 2007.

4. Android provides access to a wide range of useful libraries and tools that can be
used to build rich mobile applications by interfacing with hardware that is typically not available
on desktop platforms. For example, Android enables developers to obtain the location of the
mobile device using the phone's built-in GPS technology, or to create photography applications
using the built-in camera. Developers for Android can create software applications for Android-based mobile devices using various programming languages, including the Java programming
language. Other languages supported by Android include C, C++, and JavaScript, among others.

5. Android contains over 50 thousand files and over 11 million lines of code, and is

1

built on an underlying Linux kernel, an open source operating system kernel that communicates
directly with the hardware device and manages core functions and communications (such as
those relating to memory management, process management and hardware drivers) between the
applications and the device. A diagram illustrating the major components of the Android
platform is attached hereto as Exhibit A. This diagram is available on the Internet at
http://developer.android.com/images/system-architecture.jpg.

6. The Android platform includes, among other things, the Android SDK and the
Dalvik Virtual Machine ("VM"). The Android SDK is a comprehensive set of development
tools provided to software developers who wish to create applications for Android devices. The
Dalvik VM is a new intermediate software layer, created by Google, that allows programs,
including those written in the Java programming language, to run on the Android platform. The
Dalvik VM and Android platform accomplish this function in part by using a collection of 168
libraries (also referred to as "packages") referred to as the "Android Core Libraries." I led the
design and creation of the Dalvik VM and related libraries at Google.

7. Some of the Android Core Libraries incorporate and were in part derived from
API libraries from Apache Harmony ("Harmony" or the "Harmony Project").

8. Others of the Android Core Libraries were developed by an independent
contractor that Google retained as part of the early development work on Android. Google
informed the contractor that it was interested in interoperability with version 1.5 (now known as
version 5.0) of the Java 2 Standard Edition platform. The contractor was retained and instructed
to write new code, reuse and improve original code created by Google, or import and improve
code from permissively licensed (or equivalent) open source projects, such as the Harmony
Project--but not from any proprietary materials, including Sun materials. The files developed
by this independent contractor include the following eight Android files: AclEntryImpl.java;
AclImpl.java; GroupImpl.java; OwnerImpl.java; PermissionImpl.java; PrincipalImpl.java;
PolicyNodeImpl.java; and AclEnumerator.java. Each of those files is a "test" file for the
purpose of verifying that certain aspects of the corresponding program file worked correctly.
These files do not have any effect on the code that ships on Android devices, and there is no

2

reason that these files would ever be present on Android devices. In fact, after this lawsuit was filed, Google removed these files from the Android platform, and has not replaced them with new files.

9. Two Android files, CodeSourceTest.java; and CollectionCertStoreParametersTest.java, were developed by the same independent contractor discussed in the preceding paragraph. Those files appear to have been derived, at least in part, from Harmony files. After this lawsuit was filed, Google removed from these files comments that appear to have come from the original Harmony files.

I declare under penalty of perjury that the foregoing facts are true and correct.

1. I am of counsel at the law firm of Keker & Van Nest LLP, counsel to Google Inc. in the present case. I submit this declaration in support of Defendant Google Inc.’s Motion for Summary Judgment on Count VIII of Plaintiff Oracle America, Inc.’s Amended Complaint. I make this declaration based on my own personal knowledge. If called as a witness, I could and would testify competently to the matters set forth herein.

2.
Attached hereto are true and correct copies of the following documents:

Exhibit D.
Exhibits A-E to Plaintiff’s Responses to Defendant’s Interrogatories, Set No. 1 (Interrogatories Nos. 1-10), served on or about January 6, 2011.

Exhibits E. Excerpts from the transcript of proceedings in this case on February 9, 2011.

Exhibit F. Excerpts from the Court’s July 22, 2011 Order Granting In Part Motion to Strike Damage Report of Plaintiff Expert Iain Cockburn.

Exhibit G. The September 20, 1994 Prepared Testimony of Sun Microsystems, Inc.’s Chief Technical Officer to the Senate Judiciary Committee, Antitrust, Technology and Law Subcommittee, as reported by the Federal News Service and downloaded from Lexis-Nexis.

Exhibit N. Counsel for Oracle’s February 18, 2011 letter to the Court in opposition to Google’s request for leave to file a motion for summary judgment on Oracle’s copyright infringement claim.

Exhibit O. Excerpts from Plaintiff’s Responses to Defendant’s Interrogatories, Set No. 1 (Interrogatories Nos. 1-10), served on or about January 6, 2011.

3. No exhibits were attached to Plaintiff's Supplemental Responses to Defendant's Interrogatories (Exhibit C to this declaration), so I understand the references therein to Exhibits A-E to refer to the exhibits to Plaintiff’s original responses to those interrogatories (Exhibit D to this declaration).

2

I declare under penalty of perjury that the foregoing facts are true and correct. Executed on August 1, 2011 in San Francisco, California.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

ORACLE AMERICA, INC.
Plaintiff,
v.
GOOGLE INC.
Defendant.

________________

Case No. 3:10-cv-03561-WHA

DECLARATION OF OWEN
ASTRACHAN IN SUPPORT OF
DEFENDANT GOOGLE INC.’S MOTION FOR SUMMARY JUDGMENT ON
COUNT VIII OF PLAINTIFF ORACLE
AMERICA’S AMENDED COMPLAINT

Judge: Hon. William Alsup

Hearing: 2:00 p.m., September 15, 2011

I, Owen Astrachan, declare as follows:

1. I am Professor of the Practice of Computer Science and Director of Undergraduate Studies in the Computer Science Department at Duke University. I earned my AB degree with distinction in Mathematics from Dartmouth College and MAT (Math), MS, and PhD (Computer Science) from Duke University. I submit this declaration in support of Defendant Google Inc.’s Motion for Summary Judgment on Count VIII of Plaintiff Oracle America, Inc.’s Amended Complaint. I make this declaration based on my own personal knowledge. If called as a witness, I could and would testify competently to the matters set forth herein.

2. I have been retained to provide my opinions on certain issues related to the copyright claim in this case.

3. Attached hereto as Exhibit 1 is a true and correct copy of the opening expert report (“Astrachan Opening Report”) I prepared in this action, which is a true and correct expression of my opinions based on the facts I currently know (subject to the qualifications noted below, which are due to narrowing by Oracle of its copyright infringement contentions after I signed the Astrachan Opening Report). The Astrachan Opening Report also provides a more detailed description of my qualifications and experience, including a CV which is attached to Exhibit 1 as Exhibit A. Paragraphs 3-5 of the Astrachan Opening Report also provide a more detailed description of the scope of my retention.

4. Attached hereto as Exhibit 2 is a true and correct copy of James Gosling’s “The Feel of Java” paper, Computer, Vol. 30, Issue 6, June 1997, which I quoted from in paragraph 124 of the Astrachan Opening Report.

5. I signed the Astrachan Opening Report in the evening on Friday, July 29, 2011. I understand that after I had signed the Astrachan Opening Report, Oracle served supplemental responses to certain of Google’s interrogatories. I have now reviewed the July 29, 2011 supplemental responses, which were not available to me at the time I signed the Astrachan Opening Report.

6. In preparing the Astrachan Opening Report, I relied on Oracle’s interrogatory

1

responses as they then stood. Prior to its July 29, 2011 supplemental responses, Oracle’s interrogatory responses asserted that 48 API packages were at issue (and I have been told that before that, Oracle asserted that 51 API packages were at issue). Oracle’s July 29, 2011 supplemental responses assert that 37 (rather than 48 or 51) API packages are at issue. Other than removing some API packages from its copyright infringement contentions, Oracle’s July 29, 2011 supplemental responses appear to assert the same bases for alleged similarities as its prior supplemental responses.

7. In light of Oracle’s July 29, 2011 narrowing of its copyright infringement contentions, I would qualify the statements in the Opening Astrachan Report in the following ways:

a. In paragraph 21, where I state what API packages I understand to be at issue in this case, I would delete reference to the eleven API packages that Oracle no longer places at issue in this case, namely “java.math” and the ten packages that begin with “java.xml.”

b. Similarly, in paragraph 100, the discussion of java.math and java.xml is no longer necessary.

c. In the first sentence of paragraph 102, I would revise downward the three numbers: “In the Android packages at issue, there are 472451 public classes, 150133 public abstract classes, and 176161 public interfaces.” (Here, and below, I indicate deletions using strikethrough, and additions using italics.)

d. The chart in paragraph 110 offers statistics about Oracle’s implementation of the APIs at issue. In light of Oracle’s narrowing of its copyright contentions, I would make the following revisions to the chart:

Method name

Number of
Times
Repeated

Functionality?

toString

194184

Converts an object to a String.

equals

157149

Tests to see if two objects are equal.

2

hashCode

147139

Creates a "Hash Code" (a numeric representation) of a class.

run

139121

Runs the code in the object

read

96

Reads (typically to a stream of characters).

write

94

Writes (typically to a stream of characters)

remove

8886

Removes something (exactly what is removed depends on the class).

get

74

Gets the value of an object

close

72

Closes a stream

size

68

Returns the number of items in a collection of items

clear

6160

Clears the content of the thing referenced.

clone

5958

Clones the thing referenced.

TOTAL

12491201

These 10 method names are used byroughly 1/6 of the methods in Oracle's
implementation of Java 1.5.

e. In paragraph 114, I would revise downward three numbers in the following sentence: “In Oracle’s implementation of Java 1.5, nearly one-third of the method names at issue (2,5782,373 of the 7,7967,252 methods) are determined by these rules, including roughly 2,000 that begin with either ‘get’ or ‘set,’ and 168149 named simply ‘equals.’”

f. In paragraph 115, I would revise several numbers: “An additional 2,3472,218 method names were single words, like ‘run’ or ‘add.’ The remaining 2,8712,661 methods are not long or complicated — they are, on average, only 2.3442.342 words ‘long’ (counting a method name like locateURL as two words and findBestMatch as three words). In Android, of the 92978693 total methods, 32202961 are unique methods, 26762533 or 28.8%29.1% are one word names, 29092721 are required names (like the ‘get’ and ‘set’ examples above), leaving 3,7123,439 other methods whose average word length is

3

2.412.42.”

g. In paragraph 141, I would make these two revisions to the following sentence:
“The 4837 APIs at issue are roughly one-thirdless than one-quarter of the Android Runtime Core Libraries, which currently contains 168 API packages.”

h. I would revise downwards several numbers in paragraph 143: “Using a Python script SlocCounter.py (attached as Exhibit E) based on the ‘sloccount’ tool, a commonly-used tool for measuring the size of the source code of large software projects, Android’s implementation of the APIs at issue in the ‘Gingerbread’ release constitutes 259,474237,158 lines of code, in 1022917 files. This is roughly 1.6%1.5% of the size of the entire Android source code, which comprises 57,076 files and 15,347,169 lines of code,4 and roughly 15%14% of the 6,340 files and 1,713,087 lines of code5 in the overall Android (Gingerbread) Runtime Core Libraries. Similarly, implementation of these APIs is a small portion of Oracle’s JDK 1.5 implementation of the entire Java API, constituting 315,570292,988 lines of code out of 2,867,712 (11%10% of the total) and 1001881 files out of 9521 (10.5%9.2%).”

i. Similarly, in paragraph 144 I would say 1.5% instead of 1.6%.

8.
None of these qualifications change any of the opinions that I offered in the
Opening Astrachan Report.

I declare under penalty of perjury that the foregoing facts are true and correct. Executed on August 1, 2011 in Durham, North Carolina.

J. The APIs at Issue are Methods of Operation ............................... 47

K. The Java API Package Names Are Dictated By Function ........... 51

1

L. The Java API Class and Method Names Are Dictated by
Function........................................................................................ 55

M. The Java Names Are the Product of Mechanical Rules............... 64

N. The Organization of API Elements is Dictated By
Function And Does Not Reflect Creativity.................................. 66

O. The Same Analysis Applies to the Native Files........................... 67

P. Many API Elements are Drawn from the Public Domain
and Are Not Original to Java........................................................ 69

Q. The APIs at Issue Are Necessary For Basic
Functionality and Interoperability................................................ 73

R. The APIs at Issue Are Demanded by the Industry....................... 74

VI. THE ANDROID PLATFORM IS NOT VIRTUALLY
IDENTICAL OR SUBSTANTIALLY SIMILAR TO THE
JAVA PLATFORM................................................................................ 77

VII. ANDROID'S DOCUMENTATION OF THE APIs AT ISSUE
IS NOT VIRTUALLY IDENTICAL OR SUBSTANTIALLY
SIMILAR TO ORACLE'S DOCUMENTATION................................. 80

VIII. THE TWELVE FILES OR PORTIONS OF FILES
ALLEGED BY ORACLE TO HAVE BEEN COPIED ARE
QUALITATIVELY AND QUANTITATIVELY
INSIGNIFICANT AND THEY ADD NO OR VERY LITTLE
VALUE TO ANDROID......................................................................... 82

1. I am Professor of the Practice of Computer Science and Director of Undergraduate
Studies in the Computer Science Department at Duke University. I earned my AB degree
with distinction in Mathematics from Dartmouth College and MAT (Math), MS, and PhD
(Computer Science) from Duke University. I teach undergraduate computer science
courses using the Java, C++, and Python programming languages, and helped develop
broadly-used teaching materials, including a C++ textbook and Java language
programming exercises and documentation. I received a National Science Foundation
CAREER award in 1997 to incorporate design patterns in undergraduate computer
science curricula, an IBM Faculty Award in 2004 to support componentization in both
software and curricula, and was one of two inaugural NSF CISE Distinguished Education
Fellows in 2007 to revitalize computer science education using case- and problem-based
learning. My research interests have been built on understanding how best to teach and
learn about object-oriented programming, software design, and computer science in
general; and I am now working on developing a portfolio of substantial, interdisciplinary
problems that help explain how computer science is relevant to students in the social and
natural sciences. My qualifications and information regarding my prior testimony are
attached hereto as Exhibit A.

2. I am being compensated for my work in this litigation at the rate of $300 an hour. My
compensation does not depend in any way on the outcome of this litigation.

3. I have been asked by Google to:

4

a. opine on whether the Java Application Programming Interface ("API")
specifications from which Oracle alleges certain parts of the Android platform are
derived are methods of operation;

b. opine on whether the allegedly infringing materials are driven by functional
considerations, considerations of interoperability and efficiency, industry practice or
demand, or drawn from public domain material;

c. opine on whether the allegedly copyrighted Oracle works relating to the Java
platform are virtually identical or substantially similar to the Android platform;

d. opine on whether the allegedly copyrighted Oracle documentation relating to the
Java APIs are virtually identical or substantially similar to Google's documentation for
the APIs in Android; and

e. opine on whether the 12 files and/or portions of those files alleged by Oracle to
include material literally copied by Google are qualitatively and/or quantitatively
insignificant.

4. I understand that I may further be asked by Google to review submissions related to
copyright issues from Oracle's experts, and to provide my opinions on issues raised by
any such submissions.

5. I understand that I may be called upon to testify in this case regarding my opinions and
analyses set forth in this report. If called upon to testify, I may use various
demonstratives, including tables or drawings, to assist in presenting my testimony.

5

II. DOCUMENTS AND INFORMATION CONSIDERED

6. My opinions are based on my relevant knowledge and experience, as well as review of
the documents and information identified in Exhibit B.

III. BRIEF SUMMARY OF MY OPINIONS

7. "Java" may refer to three very different things: the Java programming language, the Java
Application Programming Interfaces (APIs), or software source code that references and
implements the APIs. In this case, except for a very small number of files addressed in
Section VII below (12 files out of approximately 57,000), it is my understanding that
Oracle does not allege infringement of the software source code referencing the APIs.
Nor, I am informed, does it allege infringement because Android is written in the Java
language. I have been informed that Oracle's claim of infringement is based on Google's
creation of software source code written in the Java language that references and
implements Java APIs.

8. The Java language is a programming language. As with any language, it has a basic
syntax and grammar that must be followed for code written in the Java language to be
understood by a computer. Java's syntax includes such utilitarian features as spacing,
punctuation, and the meaning of a limited number of defined words and phrases. Starting
in the mid-1990s, Sun Microsystems widely promoted the use of the Java language by
developers, businesses and the general public, without restriction. It is my understanding
that neither Sun nor Oracle, which acquired Sun, claims that the use of the Java language
to write software is infringing.

9. As explained in more detail starting at paragraph 24, an API provides programmers with
a way to access the functionality of a software service. For example, most programming

6

languages provide a way to calculate the square root of a number. Java does this by way
of an API. In order, for example, to calculate the square root of 25.0, a Java programmer
includes the text sqrt(25.0) in the text of his program. The text "sqrt(a)" -- where "a" is
replaced by the variable or number that the programmer for which the programmer wants
to calculate the square root -- is the API for the square root "method."

10. As explained in more detail starting at paragraph 52, APIs are implemented by software.
For example, the sqrt(a) API can be implemented in many different ways. First, there are
many different mathematical algorithms for calculating square roots (much as there are
many different ways to make an apple pie). Second, there are many different ways to
write the programming code that implements any given algorithm (just like two people
who write down the same recipe can describe the various steps using different words and
sentences). However, if one sets out to implement an API, the one part that cannot
change is the API itself. For example, if one wants to implement the sqrt(a) API, one
cannot change the method name from "sqrt" to, say, "squareroot." As I will discuss
below, referencing an API requires the use of the API's method declarations (names,
data, and data types). To implement an API, one must use all these exactly as the API
requires them to be used. If even a minor change is made, code that references the API
will fail to operate. That said, as noted above, there are potentially different ways to
write the underlying implementing code for a given API. It is my understanding that
except for the 12 files discussed below in section VII, Oracle has not identified any literal
code copying by Google in this case.

11. In this case, it is my understanding that Oracle contends that referencing the API, via
method names, data names, and data types, is infringing, but as I discuss below in Section
V.J, the APIs at issue in this case are purely functional. In addition, with respect to

7

Oracle's allegation of literal copying of 12 files out of 57,000 files in Android, as I
discuss below in Section VIII, it is my opinion that the allegedly copied material in these
files is qualitatively and quantitatively insignificant.

12. It is my opinion that the APIs at issue are methods of operation.

13. It is my further opinion that any similarity between the names of elements (such as
package, class and method names) in the implementations in these APIs in the Java and
Android platforms is driven by functional considerations. It is also my opinion that any
similarity between the organization of elements in the implementations in these APIs in
the Java and Android platforms is also driven by functional considerations.

14. It is my opinion that many of the names of elements of the Java API were drawn from
usage in other languages or platforms that pre-date Java.

15. It my opinion that Google's use of these APIs is necessary for interoperability and
efficiency, and/or driven by industry demand.

16. It is my opinion that the Android platform is not virtually identical or substantially
similar to the allegedly copyrighted works relating to the Java platform.

17. It is my opinion that any similarities between Google's documentation of the APIs at
issue and Oracle's documentation are driven by functional considerations and industry
practice regarding such documentation.

IV. BRIEF BACKGROUND ON JAVA

18. Oracle uses "Java platform" to mean a variety of interchangeable and overlapping
elements. These elements purportedly include the Java programming language itself, an
"object-oriented" programming language that uses syntax heavily based on prior

8

languages such as the "C" and "C++" programming languages. Also included in these
elements are a program known as a "compiler" that creates the "bytecode" in which Java
programs are executed; a virtual machine that executes the bytecode; and a set of core
libraries that facilitates the development of applications for the Java platform by
providing basic system or language functionalities. Java is a popular programming
language, and a variety of software, including internet services and mobile applications,
is written in the Java language.

19. Like any high-level programming language, the Java programming language contains
many rules of grammar and syntax that cannot generally be varied. For example, a
statement adding two numbers can only be written in certain ways, and the language
requires specific and precise key words to express such things as variable types (integers,
strings, or Booleans) and more complex object types such as dates or database queries.
In addition, the Java language, like many programming languages, employs key words
and operators (such as plus and minus symbols) that can only be used for specific
purposes and in specific ways; using them for other purposes will cause a program to fail
to function correctly. As a result, much of the structure and appearance of code written in
the Java programming language is dictated by these functional considerations.

20. Java's specifications, including the specifications for the language API packages at issue
here, were published or made available in various forms, including in books and on the
Java website, starting with the release of version 1.0 in 1996. Several revisions have
been released since then, including version 1.5, which in my understanding is the most
recent version at issue in this case. Note that, at times, Java version 1.5 has also been
referred to as Java version 5.0. For consistency, I will refer to it as Java 1.5.

9

V. DETAILED STATEMENT OF THE BASIS FOR MY OPINIONS ON APIS

21. Based on my review of Oracle's responses to Google's interrogatories, I understand that
Oracle is claiming that Google's implementation of the Java API specifications for the
following packages infringe Oracle's copyrights. (It is my understanding that Oracle,
with the exception of the 12 files discussed in Section VIII, has not identified instances of
the copying of specific code.)

java.awt.font

java.beans

java.io

java.lang

java.lang.annotation

java.lang.ref

java.lang.reflect

java.math

java.net

java.nio

java.nio.channels

java.nio.channels.spi

java.nio.charset

10

java.nio.charset.spi

java.security

java.security.acl

java.security.cert

java.security.interfaces

java.security.spec

java.sql

java.text

java.util

java.util.jar

java.util.logging

java.util.prefs

java.util.regex

java.util.zip

javax.crypto

javax.crypto.interfaces

javax.crypto.spec

javax.net

11

javax.net.ssl

javax.security.auth

javax.security.auth.callback

javax.security.auth.login

javax.security.auth.x500

javax.security.cert

javax.sql

javax.xml

javax.xml.datatype

javax.xml.namespace

javax.xml.parsers

javax.xml.transform

javax.xml.transform.dom

javax.xml.transform.sax

javax.xml.transform.stream

javax.xml.validation

javax.xml.xpath

12

22. Based on my review of Oracle's responses to Google's interrogatories, I understand that
Oracle is also basing its infringement claim on the following native code implementations
of Java API classes:

java_lang_Class.c

java_lang_Object.c

java_lang_reflect_AccessibleObject.c

java_lang_reflect_Array.c

java_lang_reflect_Constructor.c

java_lang_reflect_Field.c

java_lang_reflect_Method.c

java_lang_reflect_Proxy.c

java_lang_Runtime.c

java_lang_String.c

java_lang_System.c

java_lang_Throwable.c

java_lang_VMClassLoader.c

java_lang_VMThread.c

java_security_AccessController.c

java_util_concurrent_atomic_AtomicLong.c

13

sun_misc_Unsafe.c

23. Based on my review of Oracle's responses to Google's interrogatories, I understand that
Oracle also bases its copyright claim on code and comments in the following files that
allegedly have been copied from Oracle code or comments in Oracle's source code:

Allegedly copied test files:

AclEntryImpl.java

AclImpl.java

GroupImpl.java

OwnerImpl.java

PermissionImpl.java

PrincipalImpl.java

AclEnumerator.java

PolicyNodeImpl.java

Allegedly copied comments (but not source code):

CodeSourceTest.java

CollectionCertStoreParametersTest.java

Allegedly contain copied source code:

TimSort.java

ComparableTimSort.java

14

A. WHAT IS AN API?

24. An Application Programming Interface (API) is "a particular set of rules and
specifications that software programs can follow to communicate with each other. It
serves as an interface between different software programs and facilitates their
interaction, similar to the way the user interface facilitates interaction between humans
and computers." Wikipedia, Application programming interface,
http://en.wikipedia.org/w/index.php?title=Application_programming_interface&oldid=43
7864024 (as of July 13, 2011, 00:30 GMT). An API provides a specified and
documented mechanism to invoke, operate, and interact with software services. The
interface itself is implemented by software, i.e., by source code that is written to provide
the functionality of the interface.1

25. APIs are used by software developers when writing software that will utilize the
functionalities operated through these communications. When used alone, the term API
can refer to either the set of rules and specifications, or to the software that implements
the rules and specifications and therefore is operated by the communication from another
program, as explained in more detail in paragraph 52. API can also refer to either a
specific "element," "component," or functionality within the API, or to a collection of

15

them. This report will generally use API to mean such a collection, and "API elements"
or "API components" to refer to the individual mechanisms within the collection.

B. USEFUL ANALOGIES

26. APIs are similar to the interfaces that a computer user uses to operate software, like a
keyboard command or button. In each case, the person seeking to use the program does
something to inform the program being used that he wants a specific action to happen,
and then that action happens. No deep expertise or understanding of the inner workings
of the computer system is needed by the person seeking to use the program. For
example, a computer user might type the "Ctl+P" key combination or click an icon that
looks like a printer, and then, in the dialog box that appears, choose the file to be printed
and the number of copies that should be printed. Typing "Ctl+P" or clicking the icon
would invoke the underlying printing functionality, and (once the number of copies is
specified) cause the software to print the document that number of times. The user does
not need to have substantial understanding of the underlying printing mechanism, he just
needs to learn and remember the familiar "Ctl+P," give the necessary information (e.g.,
number of copies he wants printed), and the computer takes care of the rest.

27. Similarly, when invoking or using an API in a software application, a programmer should
not need to review or understand the underlying implementation or source code for the
API, as that code has already been written. Like using "Ctl+P" to print, he only needs to
know the name and functionality of the API. In order to write software that prints, a
programmer would read and learn their chosen operating system's API for printing, and
then invoke that API from their program, telling the API critical information like what
document to print and how many copies to print. Just like typing the "Ctl+P" command
or clicking the printer icon, using the name of the API element in the software invokes

16

the underlying functionality of the API and causes printing to happen, without the
programmer needing to have a deep knowledge of the particular mechanisms that allow
the API to function. Among other benefits, this means that a programmer can use an API
to create software that works on different printers (color, black and white, inkjet, etc.)
without knowing in detail how those different printers work, as long as the underlying
implementation supports them.

28. An API also can be analogized to the interface for driving a typical car. Every car has a
variety of elements that are part of the overall system of communication and operation
that a driver must understand and use in order to drive the car. These elements include
the gear lever, the turn signal stalk, the steering wheel, and the accelerator and brake
pedals. Some of these elements provide information from the driver to the car, while
others provide information from the car to the driver, and others do both things at the
same time. In combination, these elements form the interface to the "application" that is
the car, allowing a driver to "program" the car to do their bidding by using those
elements to operate the car.

29. Thus, for example, the driver of a car can make it accelerate by pressing the accelerator.
The further the driver presses the accelerator, the faster the car speeds up. The
accelerator can be thought of as an API for the car that makes the car go. Every car that
implements this API will have an accelerator, and each of them will share in common the
fact that the car speeds up faster the further the accelerator is pressed down.

30. So long as a driver understands this functionality -- that the rate of speeding up a car
depends on how far the accelerator is pressed down -- the driver need not know how this
happens. Similarly, if a driver understands how the other interfaces to the car's

31. The primary purpose of APIs is to allow one piece of software to speak to another piece
of software in a clearly defined, reusable, interoperable way. This simple goal has a
number of important ramifications and benefits.

32. Familiar interfaces make it simpler to use things and to use them more expertly. When
using a new car, most drivers do not think about how that particular steering wheel
works. For example, the wheels of the car might be turned by a rack and pinion system
or a recirculating ball system. But the steering wheel itself functions the same way
regardless of how the internal steering mechanism and system is designed, i.e., when the
driver turns the wheel to the left, the car moves in the left direction. This interface -- the
same, familiar steering wheel -- facilitates using the car, regardless of which specific car
is being used. The same thing happens in software -- using (or providing) a standard
API allows the users of that API (software programmers) to move between any software
platforms that provide the same API, because their familiarity and existing skills in using
that particular interface transition over.

33. A defined, fixed API allows different programs to substitute for each other, which gives
users the ability to move from one piece of software to another. In this way, APIs enable
user choice between competing software providers, and therefore help to promote
competition, innovation and choice in the software market. For example, if a software
platform provides a set of APIs, a subsequently created platform that implements those
same APIs (for example, by writing different source code to implement those APIs) can

18

improve competition and reliability because developers who use the platform would
already be familiar with the APIs and so would be more able to leverage their existing
knowledge and complementary software. In our printing analogy, another program that
provides the same commands (like "Ctl+P") will be much easier for a user to switch to.
In fact, once a user is used to "Ctl+P," he will often be confused if a program uses
something else to control printing.

34. APIs also help software programmers by insulating programmers from underlying
complexity. This is referred to by programmers as "encapsulation." In the car example,
the internal steering system can be changed specifically because the familiar steering
wheel interface (the car's "API") has hidden these implementation details from the
driver. This shielding and simplification is an important part of what an interface
provides -- most users do not need to know the details, which has in the past allowed car
manufacturers to switch from old technologies to new ones without introducing a new
learning curve for consumers. The concept that moving the wheel left turns the car left
remains the same, and that allows consumers to rely on this familiar concept, regardless
of which car they use.

35. APIs also help programmers and the industry by allowing software to be reused. This is
important; new code is difficult and expensive to write and test, and so individual
programmers and corporations like to reuse code as much as possible. Even if they
cannot reuse an entire program (say, because the two pieces of hardware are very
different, as they are between a desktop computer and a phone) they still prefer to reuse
as many parts of the software as possible. APIs help make this possible by allowing the
same basic functionalities to be provided and used in a replicable, but portable, way.

19

D. THE ELEMENTS OF AN API

36. An API typically consists of what programmers call methods or, equivalently, functions.
These two terms are synonyms, used somewhat interchangeably depending on the
programming language. Java programmers (and therefore this report) use the term
"methods." Both represent the same thing -- a piece of software that performs a specific
function and can be reused when needed. Methods are the primary mechanism by which
programmers invoke the functionalities provided by a software system.

37. In the user interface analogy, "Ctl+P" and the printer icon are methods. A user
interacting with a software program might use a menu or a menu shortcut to open a file,
or to save or print what has been opened, e.g., in a word processing program. Often an
icon of a printer or a disk can be pressed to invoke the same functionality as choosing a
menu item or the menu shortcut. In all three cases -- pressing the icon, choosing the
menu item, or typing a keyboard shortcut -- the same underlying software is invoked and
causes a specific action -- printing the file or saving it, for example. The functions or
methods in an API are directly analogous -- just as the user might click on an icon or
press a sequence of keys to use a keyboard shortcut to invoke more complicated
operations such as printing or saving, the program calls the function or method to invoke
and control a more complicated service or feature provided by the underlying software.
For example, when a Java programmer wants to get the square root of 25, his program
will have to contain the following text:

sqrt(25.0)

This will cause the underlying system to do the math and tell the program that the answer
is "5.0". Similarly, to get the absolute value of -25, the program must contain abs(-

20

25) This will cause the underlying system to do the math and tell the program that the
answer is "25."

38. Related methods are often grouped together to make them easier to use, frequently into
groups called (depending on the programming language) libraries or packages. In Java,
these groupings are called packages. Because Java is what is known as an "object-oriented" language, related methods are themselves encapsulated in a class, and then
related classes are encapsulated into a package or a sub-package. To put it a different
way, the API packages include subparts or files known as classes, and within these
classes are methods. As an analogy, one can think of menus (like "File," "Edit," etc.) as
"packages" of menu items, which organize the menu items so that they are grouped
together in reasonable groupings. For example, to print using the menu, a user needs to
know that Print is under File, rather than under Edit.

39. As an example from the Java API, the java.lang package (according to Oracle's
documentation) "[p]rovides classes that are fundamental to the design of the Java
programming language." One of these "fundamental" classes is the "Math" class, which
Oracle describes as containing "methods for performing basic numeric operations such as
the elementary exponential, logarithm, square root, and trigonometric functions." The
actual methods contained with the class are listed in this chart:

Method Name

Functionality of the Method

abs

Returns the absolute value of the argument.
(Four variants)

acos

Returns the arc cosine of the argument.

21

Method Name

Functionality of the Method

asin

Returns the arc sine of the argument.

atan

Returns the arc tangent of the argument.

atan2

arguments) to polar coordinates.

ceil

Returns the smallest integer that is not less
than the argument, e.g., if the argument is 1.9,
will return 2.

cos

Returns the cosine of the argument.

exp

Returns e raised to the power of the argument.

floor

Returns the largest integer that is not more
than the argument, e.g., if the argument is 1.9,
will return 1.

IEEEremainder

Returns the remainder of two arguments as
prescribed by the IEEE 754 standard.

log

Returns the natural logarithm of the argument.

max

Returns the greater of two arguments, e.g., if
the arguments are 3 and 4, will return 4. (four
variants)

min

Returns the lesser of two arguments, e.g., if

22

Method Name

Functionality of the Method

-

the arguments are 2 and 3, will return 2. (four
variants)

pow

Returns the value of the first argument raised
to the power of the second argument.

random

rint

Returns the closest integer to the argument.

round

Returns the closest number to the argument.

sin

Returns the sine of the argument.

sqrt

Returns the square root of the argument.

tan

Returns the tangent of the argument.

toDegrees

Returns the result of a conversion of the
argument (an angle in radians) to degrees.

toRadians

Returns the result of a conversion of the
argument (an angle in degrees) to radians.

E. THE COMPONENTS OF A METHOD DECLARATION

40. Every method has several important characteristics that collectively are referred to as the
"method declaration." The first is simply the method's name. Method names describe
the purpose of the method, so that a programmer can easily memorize and recognize the
purpose from the method's name, and vice-versa. A simple example of this is the method

23

in the table above named "abs," so named because its function is to calculate the absolute
value of a number. To use a method, the programmer must know the method's name. If
the programmer does not know the precise name, or knows only something similar, he
cannot use the method, because the software cannot guess at what the programmer meant.
For example, if a Java programmer writes "squareroot(25.0)" instead of "sqrt(25.0)", this
will result in an error instead of calculating the square root of 25.0.

41. The second important characteristic of essentially every method is the set of arguments
that the method expects to receive when invoked. When the method is called, the
programmer typically provides information to the method that informs the software
exactly what the programmer wants to happen, just as a user must usually specify how
many copies he wants printed after he clicks the print button. The information provided
to the method is called an argument (or parameter), and a method is said to "accept" the
permitted arguments. The ability of a method to accept an argument is what allows a
general purpose method to act on specific data.

42. For example, think of the "plus" or "add" button on a calculator. This is a "general
purpose" button -- it can add any numbers one can type in, not just one specific set of
numbers. If one thinks of the "plus" button on a calculator as a method, the numbers one
asks the calculator to add (say, 2 and 2) are the parameters to the "plus" button -- those
parameters determine the specific outcome of the general purpose button. Similarly, the
number of copies one tells the print dialog (or print method) to print is also an argument
-- they again tell the general purpose function ("print") a specific behavior ("print two
copies.") In the "abs" function mentioned previously, there is only one argument, and
that argument is simply a number, whose absolute value the program wishes to calculate.

24

43. These arguments or parameters must be defined when the API is first created, and are
typically limited. For example, it would not make sense to ask one's printer to print
"hippopotamus" number of copies of a document -- that argument must be a number. In
fact, the definition of a method in many languages, including Java, will indicate what
"type" of argument a function will accept, such as an integer, a string, or another data
type. A steering wheel, similarly, can accept arguments of left, right, or any angle in-between, but cannot accept "up" or "down." The functionality of each method constrains
what parameter(s) are acceptable, and if the proper parameters are not passed to the
method, any attempt to use the method will fail.

44. When a program uses a method and passes it the arguments, the method then typically
returns a result that the program can use for other purposes. This result is the final
important characteristic of the method, and is called the return (sometimes the return value). In the calculator example, where plus is the method and the arguments are 2 and
2, the return value will be 4 -- 2+2 returns 4. For the abs method, which computes the
absolute value of a number, when the argument is 2 or -2, the return value will be 2.

45. The purpose of the return value is to return information that can be used by the program
for other purposes. For example, after one asks one's calculator to add 2 and 2, the
calculator returns "4," which one can use as the first step in the next math problem one
intends to solve. Similarly, the return may be a message indicating the status of a method
-- for example, a "print" method might return "OK" (telling the program that the printing
functionality has successfully completed) or "OUT OF PAPER" (telling the program that
the printing functionality has hit a snag). These status messages would in turn be handled
by other methods, possibly doing something like popping up an error message, or silently
concluding that all is well and allowing the user to continue with his work.

25

46. To summarize, each method declaration has three parts -- the name, arguments, and
return. As a shorthand, programmers may refer only to the name of the method, but to
fully know what method they are describing, it is necessary to know all three parts of the
method declaration. They can be defined succinctly as:

name: the method name, which indicates its purpose and is used by a
programmer or program to call or invoke the method.

argument: the data on which the method acts. The data passed as an
argument to a method is often manipulated and referred to within
the method itself.

return: the result of calling the method with specific arguments. This is
"returned" to the programmer.

47. The documentation for a method will combine these pieces to form a reference for
programmers using the API. For example, the brief version of the documentation for the
abs method is:

int abs(int a) Returns the absolute value of an int value.

While this may not be easy for a non-programmer to understand, it is quite
straightforward to a programmer:

The first part ("int") shows that the return will be an "int" (short for an
"integer"; i.e., a number). This tells the programmer what type of result to
expect when using the function.

The second part ("abs") is the name of the method.

26

The part in the parentheses ("int a") is the argument. Again, this uses "int"
to indicate that a single integer is expected; if the abs method is given
something other than an integer, such as "hippopotamus," an error will
occur. (The letter "a" is a convenient name for the argument, and can be
changed without affecting compatibility.)

The first, second and third parts discussed above comprise the "method
declaration." The final part is a brief explanation of what the method
does.

In combination, this short statement will allow a programmer to know how to use "abs"
in their program to find the absolute value of a number. I will discuss documentation in
more detail in paragraph 145. This section is intended to explain how the various parts of
a method fit together.

F. ORGANIZING RELATED METHODS INTO PACKAGES

48. As noted in paragraph 38, most methods in an API are organized into packages of
functionalities that group related methods together. As with the method names
themselves, these packages are logically organized into functional groupings and named
so as to make it easy for programmers to remember and find the functionalities they need.
In Java, these groupings can be packages (the highest-level grouping, typically containing
many classes), sub-packages, or classes (the lowest level of grouping, typically
containing a handful of related methods). (See, e.g. "The Java Platform: A White Paper,"
Douglas Kramer, May 1996, available at
http://java.sun.com/docs/white/platform/javaplatform.doc1.html,
and "Package
Members" in The Java Language Specification, Third Edition, available at
28

27

http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.1,
for discussion
of packages, class, and methods.)

49. As an example of this grouping, take the "sqrt" method, which calculates the square root
of a number. This method is typically grouped together in a library or package with
other, related mathematical functions, such as "sin" and "cos" (short for the trigonometric
functions sine and cosine). Sqrt has been grouped with other math functions since at least
the Algol programming language in 1968, and is still grouped together with them in Java
and other modern languages, such as the Python and Ruby languages.

50. Methods that do not have related functionalities are not typically grouped together -- for
example, a method that prints text to a screen would not typically be in the same class or
package as "sqrt."

51. To use a particular method, the Java programmer has to know what class, and what
package, the method is in. A programmer calling the square root function or method in
Java, for example, needs to know that the method is in the Math class, and the name of
the method is sqrt. Frequently this is expressed in shorthand by combining the two
names, so that "sqrt" becomes "Math.sqrt." The programmer also must know the other
key parts of the structure -- specifically that the method takes one argument (a number)
and returns the square root of the argument. Once the programmer knows these things
the underlying functionality can then easily be invoked, allowing the programmer to
focus on the more complex task of writing their own software.

G. THE DISTINCTION BETWEEN AN API AND ITS IMPLEMENTATION

52. Every API, including the Java APIs at issue in this case, exists in two forms: the method
declaration of the API (comprising the elements mentioned above -- name, arguments,

28

and return), and the implementation of the API (which includes those three elements as
well as the program logic that actually performs the steps necessary to accomplish the
purpose of the method). The method declaration can be combined with a brief, factual
explanation in the documentation so that developers can have a reference for the API,
much like a dictionary might help someone learn and reference a language. The method
declaration embodies the concept of the particular API.

53. Independent of, but related to, the API's method declaration is an implementation of the
API -- the actual underlying source code that implements the API and allows the API to
function. An implementation will have some portions that are similar to the
documentation, because both the implementation and the documentation must also
include the exact method declaration, including all the elements of the declaration, such
as the arguments and return values. However, a given API may have more than one
implementation, i.e., the underlying program logic for the implementation of the API will
differ from implementation to implementation. But each of the implementations must
necessarily share the elements of the method declaration -- the package names and
related method elements -- in order to interoperate with each other. If these elements are
not present and identical in different implementations of the same API, programmers will
not be able to use the same names and structures when using the API, since it is these
elements that allow each piece of the software to speak to each other. If these names or
structures are changed, software that references these names will fail to function, because
the software will not be able to find and access the functionality it needs. To see why
using the same names and structures is important, it may be useful to analogize this to
non-programming languages. It is only by having a common vocabulary of words like
"truck" that people can speak to each other. If the language is changed, even slightly --
as it is when a speaker of American English uses "truck" while a speaker of British

29

English uses "lorry" -- then confusion arises. For programmers, similar confusion would
occur if two different implementations of the same API used different names, arguments,
and return values. For software, the result would be even worse than mere confusion,
since computers cannot guess at what the original software meant to say. Instead, faced
with a similar situation, software would fail to execute altogether. Different
implementations of the same API must use these same elements, in order to avoid
confusion, inefficiency, and incompatibility.

54. Other portions of the implementation not directly governed by the method declaration of
the API (i.e., what I have referred to as the method's program logic) will vary between
different implementations, i.e., the source code comprising the different implementations
will be different. For example, different programming languages can be used to
implement a particular API. In the case of Android, both the Java programming language
and the C programming language were used to create code to implement the APIs at
issue. Any two given implementations, other than the parts required for compatibility
(i.e., the elements of the method declaration), are not likely to be identical if they are
written by different programmers or companies. However, because they are constrained
by the API and practical considerations such as programming efficiency and the
underlying hardware, some portions may appear similar. For example, since cars are
constrained by the requirements to have a steering wheel, gas and brake pedals, and four
tires, they will often be similar "under the hood" to the untrained eye, featuring an
engine, drive train, and brakes. But an expert will be able to distinguish a V8 from a V6
or direct fuel injection from a carburetor. Similarly, the source code that is "under the
hood" of an API implementation may appear similar to another implementation of the
same API, in large part because of practical programming constraints. At the same time,
implementations can occasionally look quite different if there are specific reasons for

30

such differences -- the digital equivalent of choosing between a fuel-efficient but slow
four-cylinder (or even a hybrid) versus a hungry but powerful V8.

55. Typically, the written form of the software is captured in a specification independent
from any specific implementation. The specification is a written document that describes
the API, including the method declaration (name, arguments, and return values) as well
as specifying any requirements that the code must meet. Despite capturing important
information about the API, it would be incorrect to say that the API is the specification,
or vice-versa. The analogies to written words may again be useful -- just as one does not
say that the definition of a lion in a dictionary is, in fact, a lion, so the API's specification
is not the API, but rather a description of the API which may then take different forms.

56. This abstraction and conceptualization of the API is what makes it possible for new
implementations of APIs to be built. One of the key values of an API is that when
improvements are made "behind the scenes," programmers who use the API do not need
to know that the change has occurred; they should only notice that the program is now
faster, more efficient, or more error-free. This can only happen because the programmers
(and the software they built) used the high-level abstraction represented by the API (e.g.,
the name) and did not work directly with the concrete, underlying implementation.

57. The full Android API documentation for the "abs" method (available at
http://developer.android.com/reference/java/lang/Math.html#abs%28int%29)
can help
illustrate these issues:

31

The documentation's first line, "public static int abs (int i)," is the declaration of the
method. The declaration is the formal statement of a method's structure, containing the
method's name, the list of arguments it accepts, and the type of result it returns (the
"return value"). I have already shown similar text in the short version of the
documentation shown in paragraph 47. Here, both the input and the result are numbers
("int" is short for "integer."). There is effectively only one way to say this, and the only
thing the programmer chooses is the name of the method ("abs") and the shorthand for
the argument variable name ("i"). Presumably, Oracle named this method "abs" in part
to increase efficiency and ease of learning for programmers who were familiar with other
preexisting programming languages, since this name has been used for this function in
many older programming languages, such as C.

The first line, "package java.lang;" is the name of the package of API elements in which
the abs method resides, and indicates that this file contains a class which is part of that
package. "public final class Math" is also part of this organization, reflecting the class
which contains the abs method. Both of these lines (which appear above in black), in this
exact form, must be present in order to accurately implement the API, so all
implementations of the Math.abs function will contain these two lines. (The variable
name, here "i", is not part of the definition, and so can be different between different
implementations without impacting compatibility.)

33

58. The lines of text that begin with asterisks (which appear above in blue) are programmer's
comments. Comments do not provide functionality to the software or affect the compiled
code that is distributed to users; instead, they document what the code does and explain it
to other programmers. In this case, they describe to a programmer the function of this
API, and may also contain information about how to use the API. These comments, in
turn, are used to automatically generate the documentation for the method.

59. Finally, the actual source code for the method is shown here in green and red. It starts by
repeating the declaration of the method -- "public static int abs(int i)" (in green). It then
presents the program logic for the method -- the single line "return i >= 0 ? i : -i;" (in
red). This red portion is what actually tells the computer how to perform the method's
functionality. In this case, the program logic could be stated in English as "if the number
we are given is greater than or equal to 0, return that number, and otherwise return that
number but with the opposite sign." Because creating the absolute value is simple, this
program logic is brief, but for more complicated methods many more lines of program
logic may be needed.

60. Of this substantial amount of text that constitutes the implementation and documentation
of the abs method, other than the required organizational lines I discuss in paragraph 57,
only the single line "public static int abs(int i)" (the method's name and declaration,
underlined above) is identical between this implementation of abs (in Android) and
Oracle's implementation of abs (in the works at issue). This declaration identifies the
method, matching the declaration in the documentation and specification. Use of the
same declaration is necessary if the two implementations are to be compatible, and an
essentially identical declaration is in fact present in any implementation of
java.lang.Math.

34

61. Besides Oracle's open source implementation of Java (typically referred to as OpenJDK),
the non-profit GNU Project has written a Java implementation called GNU Classpath,
and the non-profit Apache Foundation has written a Java implementation called Apache
Harmony. See, e.g., GNU Classpath documents at
http://www.gnu.org/software/classpath/docs/cp-hacking.html and Apache Harmony
documents at http://harmony.apache.org/faq.html and

http://harmony.apache.org/subcomponents/classlibrary/compat.html.
Compatibility
between these implementations is desirable for a number of reasons (discussed in more
detail in paragraph 33) -- primarily the benefit to software developers and consumers that
results from having choice and competition between API implementation providers. For
example, for compatibility and standardization reasons, the "abs" function discussed
earlier has the following identical method declaration not only in Java and Android, but
also in Harmony and GNU Classpath:

Java: public static int abs(int a)

Harmony: public static int abs(int i)

GNU Classpath: public static int abs(int i)

Android: public static int abs(int i)

The similarities are not limited to the abs method. Each of these projects implements the
API packages at issue in this case, using the same package, class, and method names.

H. SUN AND ORACLE ALSO HAVE IMPLEMENTED AND DISTRIBUTED
APIs FROM OTHER SOFTWARE

62. One way of seeing the distinction between API and implementation is by noting that
companies such as Sun and Oracle have, in the past, implemented pre-existing APIs.

35

1. Sun Implemented and Distributed APIs from Previous Generations of Spreadsheets
as Part of StarOffice and OpenOffice.org

63. Between 1999 and 2011, Oracle, and Sun Microsystems before it, developed and
distributed the StarOffice and OpenOffice.org "Calc" spreadsheet software, and this
software implemented and distributed APIs from previous generations of spreadsheets
created by other companies. As I will explain in this section, the Calc spreadsheet
software contains an API, and this API is in large part based on the APIs originally
developed for older spreadsheet software, including Visicorp's Visicalc and Microsoft's
Excel spreadsheet software. The implementation of the APIs in the Calc spreadsheet
program allows spreadsheet models developed in Excel, for example, to also be useful
and run in the StarOffice or OpenOffice programs.

64. Most spreadsheet programs provides "spreadsheet functions" that enable users to write
small programs -- called "macros" -- that manipulate data in a spreadsheet cell. For
example, the function "ABS" calculates the absolute value of the number in a given
spreadsheet cell, the function "AVERAGE" calculates the average value of the numbers
in multiple spreadsheet cells, and "NPV" returns the net present value of an investment.
These functions or macros are used by people using spreadsheets to create models
whether these people are professional software developers, engineers, lawyers,
investment bankers, scientists, or hobbyists These functions and the macros that they are
used by constitute an API, because they are a mechanism that allows creation of written
programs that communicate with the spreadsheet software's functionality.

65. Spreadsheets created by different software companies frequently use function names and
argument structures from older spreadsheet programs. For example, the first column of
the following table shows the names of all the spreadsheet functions that were supported

36

in VisiCalc in 1979 -- VisiCalc's API. The other columns of the table show the function
names used to operate the same functionality in Lotus 1-2-3, Microsoft Excel, and
OpenOffice Calc. (The additional API elements or functionalities added in the later
programs are not shown in this table.) As the chart shows, the function names originally
used by VisiCorp's VisiCalc in 1979 were then used by Microsoft Excel 2003 and
Oracle's OpenOffice.org. This shows that the original VisiCalc API of 1979 is included
to this day in the Microsoft and Oracle products, with only one exception (VisiCalc's
"ERROR" function, which has been replaced by #N/A or #VALUE in Excel and Calc).

VisiCalc (1979)

Microsoft Excel

Oracle
OpenOffice.org Calc
(Today)

@ABS

ABS

ABS

@ACOS

ACOS

ACOS

@ASIN

ASIN

ASIN

@ATAN

ATAN

ATAN

@AVERAGE

AVERAGE

AVERAGE

@COS

COS

COS

@COUNT

COUNT

COUNT

@ERROR

#N/A or
#VALUE!

#N/A or #VALUE!

@EXP

EXP

EXP

@INT

INT

INT

@LN

LN

LN

@LOG10

LOG10

LOG10

@LOOKUP

LOOKUP

LOOKUP

@MAX

MAX

MAX

37

VisiCalc (1979)

Microsoft Excel(2003)

Oracle
OpenOffice.org Calc
(Today)

@MIN

MIN

MIN

@NA

NA

NA

@NPV

NPV

NPV

@PI

PI

PI

@SIN

SIN

SIN

@SQRT

SQRT

SQRT

@SUM

SUM

SUM

@TAN

TAN

TAN

66. Attached as Exhibit C is a table showing the names of the spreadsheet functions in
Microsoft Excel 2003 and Oracle's most recent version of OpenOffice.org Calc, which
was prepared based on the publicly available documentation available for Microsoft
Office Excel 2003 at
http://office.microsoft.com/en-us/excel-help/
excel-functions-by-
category-HP005204211.aspx
and for OpenOffice.org Calc at
http://wiki.services.openoffice.org/wiki/
Documentation/How_Tos/Calc:_Functions_listed
_by_category.
Five rows from Exhibit C are reproduced here for discussion purposes:

Microsoft
Excel (2003)

Oracle OpenOffice.orgCalc (Today)

AMORLINC

AMORLINC

AND

AND

-

ARABIC

AREAS

AREAS

ASC

-

ASIN

ASIN

38

67. Exhibit C shows that many of the functions that constitute the API of Microsoft Excel
2003 were also implemented in OpenOffice.org Calc. Functions on the left are
implemented in Excel, and functions on the right are implemented in Calc. In this sample
from Exhibit A, three of the functions (AMORLINC, AREAS, and ASIN) are
implemented in both spreadsheets, while ASC is implemented only in Excel and
ARABIC is implemented only in StarOffice.

68. As shown in Exhibit C, overall, of the 340 functions implemented in the Excel 2003
spreadsheet function API, 324 (95%) are also implemented in StarOffice.

2. Sun Implemented and Distributed APIs from Linux as Part of the Solaris Operating
System

69. As I will explain in this section, since 1999, the Solaris operating system, developed and
distributed by Oracle, and Sun Microsystems before it, has contained or been delivered
with APIs that are based on the APIs originally developed by the developers of the Linux
operating system. The implementations of these APIs in Solaris facilitates the use of
programs developed in Linux environments to run on Solaris machines.

70. The BrandZ project, also known as Solaris Containers, was a software system that Sun
implemented starting in 2004. BrandZ worked with other software, called a "brand," to
translate a non-Solaris operating system's functionality into the Solaris functionality, so
that software written for the other operating system would run on Solaris. Essentially,
each brand helped "translate" communications that used the other operating system's
APIs into communication with similar Solaris APIs. In particular, Sun developed a brand
called the "LX Brand". The purpose of the LX Brand software was to "enable[] Linux
binary applications to run unmodified on Solaris" ("BrandZ WebHome," available at

39

hub.opensolaris.org/bin/view/Community+Group+brandz/WebHome). In order to
achieve this goal, several components of the Linux API are implemented by the LX
Brand software, including signals, system calls, and the "/proc" interface. (See "BrandZ
Overview" (available at

71. For example, the "/proc" interface allows programs to interface with the Linux operating
system by reading and writing the contents of files in a special directory called "/proc."
Reading and writing these files allows a program to discover the status of the operating
system and processes running on the operating system. A process can be a program or a
part of a program that the user is running and it can be part of the operating system, e.g.,
it might facilitate communication over the Internet, with a printer, or allow one program
to pass data to another program. In Linux environments and many Unix environments,
every process has a number that identifies it, the so-called Process Identifier or PID.
Processes also have names -- for example the process that starts up the first process for
the operating system has PID one, but the name `init' and a process designated for
cryptographic programs might have the name `crypto' and would certainly have a
different PID than the `init' process. One representative element of the /proc interface,
known as "/proc/[pid]/status," allows a program to communicate with the operating
system about the status of a particular process. To initiate the communication, the
program asks for the contents of the /proc/[pid]/status file -- that is a file whose name is
'status' that is located in the directory/folder corresponding to the process identifier of a
process, e.g., /proc/523/status is the file that gives the status of process 523. The
operating system responds to a request for information about a particular process by

40

filling the file named `status' with text that shows the status of the process. After such a
request, the first eight lines of the /proc/[pid]/status file might, for example, look like this:

Name: [the name of the process]

State: [the status of the process]

Tgid: [the "Thread Group ID" of the process]

Pid: [the "Thread ID" of the process]

PPid: [the "Thread ID of the process's parent]

TracerPid: [The "Thread ID" of the tracing process]

Uid: [ID numbers of users involved in the process]

Gid: [ID numbers of groups involved in the process]

72. The text on the lefthand side of the file (such as "Name: ") is part of Linux's API. These
are always present in /proc/[pid]/status. The text on the right is the information about the
specific process, and will be different each time /proc/[pid]/status is accessed. Changes
to this layout (for example, changing "Name" to "ID" or "Reference") would break
applications that use this API. As a result, if another operating system wanted to be
compatible with this API, it would need to print "Name:," "State:," etc., in exactly the
same manner as Linux prints it.

73. The following chart shows the values -- taken directly from the respective publicly
available source code -- which Linux and Sun's LX Brand use to create the text on the
left hand side of the /proc/[pid]/status file. In each entry in the chart, "t" means "tab",
"n" means end of line, and the "%s" is replaced by the relevant information for the
particular process, so that "Name:t%sn" becomes

Name: [the name of the process]

when the /proc/[pid]/process file is accessed.

41

74. Each line of the chart is identical, and this demonstrates that the output of the
/proc/[pid]/status API is the same between Linux and the LX Brand software, and
therefore that (in this respect, at least) Linux and the LX Brand software are compatible.
If these lines were different, then the resulting file would be different, and the LX Brand
software would not be compatible with Linux. Other elements of the /proc interface are
similarly implemented in the LX Brand software.

75. The LX Brand software also reimplements Linux kernel system calls. System calls are a
part of an operating system's API; they allow programs written by users to access
resources managed by the operating system, e.g., to read and write files to kill processes,
or to allocate memory to use in a program. These resources are managed by the
operating system, but programs written by users to run on the operating system need
access to some of the resources to be able to run properly or at all. The LX Brand
software provides an emulation function which translates the Linux system call to an

42

equivalent Solaris operating system call, for each of 317 Linux system calls. A relevant
fragment of the publicly available source code that performs this translation, listing each
Linux system call, and the LX Brand function that implements the system call, is attached
as Exhibit D. This source code file indicates that there were 178 Linux system calls that
were implemented as part of LX Brand (the other 139 system calls were either not
supported or were able to directly use the equivalent Solaris system calls without
translation). Each of the LX Brand implementations of the Linux system calls use the
same name as the relevant Linux system call, with "lx_" prepended to distinguish them.

76. For example, the Linux system call "futex" was introduced to Linux beginning in 2002,
and Solaris does not have a "futex" system call. In order to provide compatibility for
Linux software running on the LX Brand, the LX Brand software provides an
implementation of futex called lx_futex, which has essentially the same name as futex,
takes similar arguments, and behaves similarly. The actual program logic that
implements the LX Brand lx_futex function and the Linux system call are not similar,
suggesting that they were independently created.

77. The 177 other system calls implemented by the LX Brand follow the same pattern: the
Linux system call name, plus the lx_ prefix, is used to identify a function that takes
similar arguments and behaves similarly to the Linux system call for which the function
is named.

78. Sun's "LX Brand" software implements only a subset of the Linux operating system API,
and so is not completely compatible with Linux. Sun's overview presentation states that
it "support[s] a subset" of the /proc API and the "minimum needed" devices ("BrandZ
Overview" at 23 and 24) and the design document notes that the "CLONE_PARENT"
argument to the clone(2) system call is also only partially implemented (see "BrandZ

43

Design Doc", section 3.5.1 ("Linux Threading"), available at
http://hub.opensolaris.org/bin/view/
Community+Group+brandz/design). This partial
implementation still aids compatibility and programmer efficiency, because it is still
better for the programmer to use some of the APIs than to have to completely rewrite the
software to use new APIs.

79. Solaris has also incorporated specific APIs from the Linux C Library ("glibc") into the
Solaris C Library. For example, the "uucopy()" system call, according to Sun's BrandZ
Design Doc, "seems to be generically useful, so the uucopy() will be implemented in
[Solaris] libc" and, in fact, Solaris gained an implementation of the uucopy system call in
2006, shortly after BrandZ was introduced (see Solaris's common/syscall/uucopy.c).

3. ORACLE IMPLEMENTED AND DISTRIBUTED APIs FROM IBM AS PART OF
THE ORACLE DATABASE SERVER

80. As I will explain in this section, the Oracle Database server distributed by Oracle since
1979 contains an implementation of the API originally developed by IBM for the
"System R" database.

81. The System R database's SQL API was first described in an academic paper published by
IBM employees in 1974 ("SEQUEL: A Structured English Query Language," DD
Chamberlin, et al.), and elaborated in a subsequent paper published in 1976.

82. The 1974 SEQUEL paper defined the following API elements or functionalities:

SELECT FROM

WHERE

GROUP BY

44

SUM

COUNT

AVG

MAX

MIN

83. IBM supplemented the functions in the 1974 paper in a subsequent paper published in
1976 ("System R: relational approach to database management," M. M. Astrahan et al.),
adding several new elements or functionalities to the SQL API: HAVING, ORDER BY,
CURSOR, INSERT INTO, and DELETE.

84. Each of the API elements or functionalities referenced in paragraphs 82 and 83, and
defined in the 1974 and 1976 papers, were implemented by Oracle in 1979 and are still
present in current releases of the Oracle Database server. Because these API elements
are implemented in the Oracle Database server, a command using the API elements
"SELECT FROM ... WHERE ..." would also be able to operate, with minimal changes,
with current Oracle Database servers, as it did with the original IBM System R software
(see "Oracle SQL: The Essential Reference," David C. Kreines (2000), Chapter 1,
"Elements of SQL," available at http://oreilly.com/catalog/orsqlter/chapter/ch01.html).

85. For example, because the Oracle system implements the API elements or functionalities
defined in the 1974 paper, it will still execute commands written using the 1974
SEQUEL API. The 1974 paper gives this short command that uses elements defined in
the 1974 paper:

SELECT NAME

FROM EMP

WHERE SAL

45

SELECT SAL

FROM EMP

WHERE NAME = Bl.MGR;

86. Because this command was written using API elements (in bold) originally defined by
IBM but later implemented in the Oracle Database server, this command should still
function in a modern Oracle Database server, and indeed, some sources report that this
exact command was used in early demonstrations of the Oracle database (see "Oracle
SQL: The Essential Reference," David C. Kreines (2000), p. xiv and Chapter 1,
"Elements of SQL").

I. BASIC EXAMPLE OF JAVA METHOD USAGE

87. When a programmer is writing an application, and wants to use a particular functionality,
he must invoke the functionality by using the appropriate method. If a programmer
writing in the Java programming language wants to use Java's square root functionality
to find the square root of 25, he would do that by incorporating the following language in
his program:

double result = Math.sqrt(25.0);

88. The argument 25.0 is passed to the method Math.sqrt when the method is called, and
"5.0" is returned by the method. In this example, the return value is then stored in the
variable named "result" for use elsewhere in the program.

89. To write this example, a programmer who had never previously used Java would likely
have started by guessing that square roots were in the class "Math," looking at that class's
documentation, finding the familiar "sqrt" method, and then reading the documentation

46

for that method to understand what result is returned and what special cases need to be
considered in writing code. He would then write the fragment of code above, and in the
future, having learned to use this part of the API, he would not likely have to refer to the
documentation again.

90. Note that at no point does the programmer need to know how the program logic that is
invoked by the sqrt method actually calculates the square root -- it could use a Newton-Raphson method, logarithms, or another mathematical algorithm for calculating the
square root. As previously noted in paragraph 34, these details are "encapsulated" --
hidden behind the scenes. This focus on knowing and understanding the API name and
functionality, rather than understanding how the method's underlying program logic
works behind the scenes, allows programmers to work more efficiently.

J. THE APIS AT ISSUE ARE METHODS OF OPERATION

91. I understand that section 102(b) of the Copyright Act states, "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." I also
understand that a method of operation has been described by the First Circuit as "the
means by which a person operates something, whether it be a car, a food processor, or a
computer." I further understand that the Ninth Circuit, citing section 102(b) of the
Copyright Act, has stated that the functional requirements for compatibility are not
protectable. Under either of those definitions, as I will explain in more detail below, it is
my opinion that the Java API specifications at issue in this case are methods of operation.

47

92. As previously mentioned, in some computer languages, methods are referred to as
"functions." Both the terms function and method suggest -- correctly -- that functions
and methods are literally a functional way to operate software. Once the method that is
part of the API is called and the right parameters are passed to it, the API invokes
functionality provided by the underlying software system. This "operates" the underlying
software system to create the return value, just as use of the car steering wheel makes the
car (through the steering system) take action to steer the car, the "plus" button makes a
calculator add two numbers, and the "print" command makes the operating system print a
paper copy of a document.

93. That an API is a functional method of operation is implicit in the definition of an API:
the entire purpose of an API is to allow one program to "interface" with another
"application." This interfacing is not a social or creative chat, but a formal, functional
command from one program to another: "Do this thing for me, and report back when you
are done." The program in command is using the API to operate the underlying program;
and the underlying program, likewise, is being operated by means of the API. In fact, it
is typically difficult, if not impossible, to operate the underlying system in any way
except through an API.

94. As demonstrated above in the example of Math.sqrt, using the name is necessary to
invoke the underlying functionality. It is also the only way to invoke the underlying
functionality -- one cannot, for example, change "sqrt" to "square_root" in the example
above and still expect the code to work. Nor could one change the number or type of
arguments. Programs, unlike the human operators of our calculator and car analogies, are
not flexible -- they must be fed precise information in order to operate.

48

95. Like "Ctl+P", the print icon, or the steering wheel, APIs provide mechanisms that operate
underlying functionality, causing the libraries at issue to perform activities and return the
information requested by the programmer -- that is to say, by the "operator" of the
software in question.

96. As an example of how APIs in Java are methods of operation, I will consider three
classes in the java.util package that allow developers, and the software they write, to
operate on dates and times: Date, Calendar and TimeZone. As the names convey, these
classes are used by programmers to create, manipulate, and use calendars and dates in
Java programs. As software is increasingly deployed throughout the world, it is
important that developers be able to simply create and manipulate dates and times in a
way that works across all cultures and time zones. These Java classes provide such an
API. These classes are used together, and the methods in these classes mirror the
functionality and operation non-programmers would expect if you needed to create and
use dates and times. For example, to use dates and times, first a programmer has to
record them. A Date allows that by representing a specific instant in time. While one
might expect this would be something like January 22, 2009, a Date actually represents a
specific millisecond on a specific day of a month of a year, and then provides methods
that translate that millisecond into a particular date, automatically translating (if
necessary) into other calendars (like the Chinese or Hebrew calendars). Having provided
a way to store the date, a programmer manipulating dates would likely want to be able to
perform a variety of actions on the date, and it is these actions that are most clearly
methods of operation. For example, a programmer might want to know whether one Date
comes "before" another, so that they could sort a list of files by time-of-modification, or
display a list of songs arranged by date of recording. Not surprisingly, the Date class
provides a method to test if one date comes before another called "before." The code to

49

execute that test and determine if a Date A comes before a Date B is written as
"A.before(B)." This method executes the test and returns "true" if A is chronologically
before B, and returns "false" otherwise. The Date class also has methods to determine if
a date comes after another date and if two dates are equal. The names of these methods,
respectively, are after and equals, providing a clear example of how the form/name of the
methods follow their function. The Date class also provides a getTime() method that
returns the exact time in milliseconds. The Calendar class contains methods used to
create a calendar, e.g., for a specific time zone, year, and/or a specific international
location. The Calendar class has methods that allow the programmer to determine the
first day of the week, which is SUNDAY in the United States, but MONDAY in France,
for example. This method is Calender.getFirstDayOfWeek() and it returns a value such
as Calendar.MONDAY or Calendar.SUNDAY -- two values of the calendar class that
are clearly functional in representing days of the week. These classes are typically used
together with the TimeZone class, which provides convenient methods for creating and
using the timezones that occur in the world. For example, the method
TimeZone.inDayLightTime(d) determines whether the Date d is in daylight saving time
in the given time zone.

97. Methods can also invoke more concrete functionality. For example, the class java.io.file
gives programmers the ability to do operations on a file. This includes useful methods
like "createNewFile" (which creates a file), "getName" (which gets the name of the file),
and "delete" (which deletes the file). In each case, the programmer invokes the
underlying functionality -- such as creating or deleting a file -- by using the name of the
method. Once a file has been opened, the methods in the java.io class can be used to read
and write the file; for example, use of the method name "readLine" will invoke software
that reads a line from the file.

50

98. In each of these cases, whether operating on simple data like a date, or more complex
things like a file or web page, the method names are the way in which the underlying
functionality is invoked, providing information and taking actions as needed by the
program. The method name is, quite literally, the method of operation, just as the gas
pedal is the way that an engine is invoked.

K. THE JAVA API PACKAGE NAMES ARE DICTATED BY FUNCTION

99. It is my understanding that names are not entitled to copyright protection. However, even
if they were, it is my opinion that the Java API package names are short, fragmentary,
and functional. It is my understanding that short, fragmentary names that are dictated by
function are not protectable under copyright law.

100. It is my understanding that the following API packages (and, in some cases, certain
subpackages of these packages) are at issue in the case. In each case, the name of the
package and the basic organization of the classes and methods within each package are
merely descriptive of the functionalities in those packages.

java.lang

The java.lang package and its subpackages java.lang.ref, java.lang.reflect, and
java.lang.annotation are part of a group of classes that facilitate interacting with and
programming related to the Java language. The package name ("lang") and contents of
the classes and methods in this package reflects this emphasis on the core Java language.

java.math

The java.math package provides the programmer with access to classes that facilitate
arbitrary precision arithmetic with integers, e.g., integers with no upper or lower limit.

51

The package name ("math") and contents of the classes in this package reflect this
underlying functionality.

java.net

The java.net package, and its extension javax.net and subpackage javax.net.ssl, provide
classes for the programmer to implement network connections at both a low- and high-
level. The package name ("net") is short for "network" and therefore reflects this
underlying functionality.

java.io and java.nio

The java.io and java.nio packages group together classes for dealing with input and
output. Input and output are called "I/O" in long-standing programmer jargon, explaining
the name of the io package. (The nio package is so-named because it was an attempt to
present a "new" io (nio) package.) The java.nio hierarchy of classes also contains the
subpackages java.nio.channels, java.nio.channels.spi, java.nio.charset
java.nio.charset.spi. The nio package provides classes that facilitate more efficient
(faster) input and output. The nio package are designed to interact with each particular
operating system's efficient I/O mechanisms, so that the Java programmer can use the nio
classes knowing that they will likely be faster than the java.io classes that were not
originally designed for efficiency.

java.security and javax.security

The java.security package, its subpackages java.security.acl, java.security.cert,
java.security.interfaces and java.security.spec, and its extensions, javax.security.auth,
javax.security.auth.callback, javax.security.auth.login, javax.security.auth.x500,
javax.security.cert, provide classes and functionality related to security, as the names

52

suggest.

java.sql

The java.sql package, and its extension, javax.sql, facilitates interacting with relational
databases or data in a format similar to that defined in such a database. These packages
are based on the "SQL" standard (Structured Query Language), a standard named and
defined in the late 1970s and early 1980s, and the name of the packages ("sql") reflects
the name of this standard.

java.text

The java.text package facilitates writing software to handle text, dates, numbers, and
messages in a format that is independent of a particular natural language -- allowing
programmers to cope more easily with languages other than English.

java.util

The java.util packages provides utilities and collection classes. Its subpackages
java.util.logging, java.util.jar, java.util.prefs, java.util.regex, and java.util.zip provide
utilities that are more specialized, e.g., to deal with logging, archives (jar files), user
preferences, regular expressions, and zipped or compressed files, respectively. These
functionalities are diverse, but "utilities" are a traditional name for small, single-purpose
tools in the computing world, and so grouping these together under the name "util" is a
straightforward mapping of functionality to traditional naming.

javax.crypto

The javax.crypto package and its subpackages javax.crypto.interfaces and
javax.crypto.spec provide classes to write code that adheres to cryptographic protocols.

53

"Crypto" is common programmer shorthand for "cryptography" and so makes for a
natural mapping of name to functionality.

In some cases, a given package may require the functionality of another package in order to
function correctly, much like the upper floors of a building need the lower floors of the building
to remain standing. The final two packages listed below, while not themselves basic to the
functionality of modern operating systems, must be present in order for the previously listed
packages to operate correctly and provide their complete, intended functionality to users:

The java.beans package facilitates software interaction with JavaBeans -- traditionally
viewed as a reusable software component conforming to specific conventions so that the
component can be manipulated with visual and graphical tools.

101. Because these names all describe specific functionalities, and (as will be discussed in
paragraph 113) they are limited by design rules to short, fragmentary words and phrases,
there is no meaningful creativity in the package names.

54

L. THE JAVA API CLASS AND METHOD NAMES ARE DICTATED BY
FUNCTION

102. In the Android packages at issue, there are 472 public classes, 150 public abstract classes,
and 176 public interfaces. A public class is a class that is accessible to programmers who
are using the API; a private class is internal to the library and can only be used by other
parts of the library.

103. API element names, such as class names, must be factually descriptive of the underlying
functionality so that programmers can recognize, understand, and remember them when
reading and writing a program. While this is formally enshrined in the Java Language
Specification (see discussion in paragraph 113), the rule has more pragmatic roots that
date back to the earliest computer languages. The core reason that API component names
are short and reflect underlying functionality is that inventive and creative names only
loosely tied to the functionality would be difficult for programmers to remember.

104. For example, the method "sqrt" is short, simple, and memorable for programmers -- and
possibly even for non-programmers; a reader of this report may not need to be reminded
more than a few times that "sqrt" means "square root." It is technically possible to
instead call the square root method "Steve," just as it would be possible to build a
calculator whose buttons use colors instead of numbers and mathematical symbols. But
such a calculator would be difficult to use; a user would have to memorize the colors and
their mapping to the underlying numbers and symbols. That would take some time and
effort -- so much time and effort, in fact, that users are likely to use a traditional
calculator instead. Similarly, when the name of a method does not reflect the underlying
functionality (as in the case where a square root method is called "Steve") the method

55

would become difficult to learn and remember. As a result, in practice all API element
names are simple and factually descriptive.

105. A method whose underlying functionality is to test to see if two file names are equivalent,
for example, could be called "equals" or "equivalent" but likely not much else. Even the
longest API element names, such as SQLNonTransientConnectionException, are still tied
to the underlying functionality. In that case, the name has three parts which demonstrate
the underlying functionality: the word "SQL" reflects that this relates to the SQL
database language (a language that pre-dates Java, and was not created by Sun or Oracle),
and the word "exception" reflects that this relates to an "exception" (similar to an error
message). Both of these terms have been used in software programming for over 30
years, predating Java by some time. A programmer would recognize that the third part of
the name ("Non-Transient Connection") reflects underlying SQL functionality that is a
term of art from outside the Java language. Since the names of all of these underlying
concepts are fixed, or nearly so, the name of the method reflecting these concepts is also
necessarily inflexible. The fact that the name reflects the underlying functionality is not
merely convenient -- it is practically required to allow the system to be comprehensible
to programmers.

106. Class names, like the method names discussed above, are highly functional, in many
cases showing only small variations directly related to the class functionality. For
example, consider the seven classes whose names end in Event as shown below. These
seven classes come from three different packages.

56

Class Name

FromPackage

What is theFunctionality?

Why is it in this
Package?

HandshakeCompletedEvent

javax/net/ssl

A class describing anevent that takes placeonce a Handshake is Completed.

"Handshakes" are part
of the Secure Sockets
Layer (SSL)
networking protocol,
and so this is grouped
with other "net" and
"ssl" features.

PreferenceChangeEvent

java/util/prefs

A class describing anevent that takes placewhen a PreferenceChanges

Utilities that user track
Preferences must have a
way to track what
happens when the
preferences change, and
so this is grouped with
"util" "prefs."

NodeChangeEvent

java/util/prefs

A class describing anevent that takes placewhen a PreferenceNode Changes

"Nodes" are a common
way to organize data.
Since these nodes are
used to store user
preference data,
information about the
nodes (including changes to them) are grouped with other "prefs"-related functionality

57

Class Name

FromPackage

What is theFunctionality?

Why is it in this
Package?

SSLSessionBindingEvent

javax/net/ssl

A class describing anevent that takes placewhen an SSL Session Binds.

As part of the
implementation of the
SSL networking
protocol, this is grouped
with other "net" and
"ssl" classes.

ConnectionEvent

javax/sql

A class describing an event that takes place when a Connection occurs.

Because this is an SQL
Connection, it is
grouped with other
SQL methods.

RowSetEvent

javax/sql

A class describing an event that takes placewhen an SQL RowSet is changed.

Because this is an SQL Rowset, it is grouped with the otherSQL methods.

StatementEvent

javax/sql

A class describing anevent that takes place when an SQL Statement is changed.

Because this is an SQL Statement, it is grouped with other SQL methods.

58

These names are functional in specifying the purpose of the methods. The noun part of
each name that precedes Event describes the event, but there is essentially no creativity in
choosing the noun. For example, the HandShakeCompleteEvent describes an event that
takes place after the hand-shaking protocol in making an SSL connection has been
completed. Similarly, the RowSetEvent class describes an event that takes place when a
"rowset" is changed in an SQL database. The names have been chosen not because of
deep introspection or creativity on the part of the author, but by simply describing what
functionality is contained in the class.

107. Another example of class names that conform to simple rules describing the underlying
functionality are the 18 classes whose names end with InputStream and that end with
OutputStream. These classes are part of a variety of packages -- some are grouped with
other input and output functions in java.io and java.nio, but several are part of the
packages java.util, java.util.zip, java.util.jar, java.security and javax.crypto. The table
below shows thirteen of the InputStream classes below and their corresponding packages.
Again the names for the classes are functional and limited by the responsibilities of each
class: the LineNumberInputStream class reads data while keeping track of line numbers
while the CipherInputStream uses a cryptographic cipher for reading data.

59

Class Name

FromPackage

What is theFunctionality?

Why is it in this
Package?

FileInputStream

java/io

A stream of inputs from a file.

This is part of the
basic input/output
("io") functionality.

PushbackInputStream

java/io

Adds the ability to push data back into an input stream.

This is part of the
basic input/output
("io") functionality.

ZipInputStream

java/util/zip

A stream of inputs from a zipped file.

Reading from a
zipped file is part of
the basic zip file
("zip") functionality.

JarInputStream

java/util/jar

A stream of inputs from a "jar" file.

Reading from a jar
file is part of the basic
jar file ("jar")
functionality.

LineNumberInputStream

java/io

Adds the ability to countthe line number to an input stream.

This is part of the
basic input/output
("io") functionality.

StringBufferInputStream

java/io

A stream of inputs from a string buffer.

This is part of the
basic input/output
("i/o") functionality.

60

Class Name

FromPackage

What is theFunctionality?

Why is it in this
Package?

CipherInputStream

javax/crypto

A stream of inputs that have been passed through a cipher.

Ciphers are part of
cryptography, and so
functionality to use
ciphers is part of the
cryptography
("crypto") package.

InflaterInputStream

java/util/zip

A stream of inputs from an "inflater" that "inflates" a zipped file.

Inflaters are part of
"zipping" a file and
so this is part of
util/zip.

FilterInputStream

java/io

Adds the ability to filter to an input stream.

This is part of the
basic input/output
("io") functionality.

ObjectInputStream

java/io

A stream of inputs from an object.

This is part of the
basic input/output
("io") functionality.

DigestInputStream

java/security

Creates a "messages digest" of a stream of inputs.

Message digests are
part of certain
security routines, sothis class is part of the java/security packages.

61

Class Name

FromPackage

What is theFunctionality?

Why is it in this
Package?

ByteArrayInputStream

java/io

A stream of inputs from a byte array.

This is part of the basic input/output ("io") functionality.

108. Java class names are short, fragmentary words and phrases. This is true of other Java
API elements, like method names, as well. Most Java API element names are short word
phrases, typically of 1-3 words in length. (See paragraph 115 for more detailed statistics
on method name length). One example is the class "PrintStream," which (not
surprisingly) adds printing functionality to output "streams." Elements in the PrintStream
class include the method named "append," which appends the argument to the output
stream, the method named "print," which prints the stream, and the method named
"close," which closes the stream. In fact, every method in the PrintStream class, with
only four exceptions, is one word. Two of the exceptions are two words -- "setError"
and "checkError," which, as one would expect, set and check the error state of the output
stream. The other exceptions are "printf" and "println" -- abbreviations for "print
formatted" and "print line." Besides being brief and fragmentary, these abbreviations
have been in use by programming languages since the 1970s, in Algol and C.

109. Other classes, such as the SecurityManager class, have slightly longer names. In this
class, three-word phrases (such as "checkPackageDefinition") are predominant and there

62

are some four-word phrases (such as “checkCreateClassLoader”). But even here, the naming follows a consistent pattern — 30 of the 40 methods are named check[SomeProperty], consistently describing their underlying functionality, which is to check the status of the property referred to by the method name. For example, “checkCreateClassLoader” checks to see if it is possible to create a new class loader.

110. Because many classes need the same functionality, and the names of the methods in question are dictated by functionality or by rules (see next section), it is not surprising that many of the names are repeated. The most common names in Oracle’s implementation of Java 1.5 are:

Method name

Number ofTimes Repeated

Functionality?

toString

194

Converts an object to a String.

equals

157

Tests to see if two objects are equal.

hashCode

147

Creates a "Hash Code" (a numeric
representation) of a class.

run

139

Runs the code in the object

read

96

Reads (typically to a stream of characters).

write

94

Writes (typically to a stream of characters).

remove

88

Removes something (exactly what is removed depends on the class).

get

74

Gets the value of an object.

close

72

Closes a stream.

size

68

Returns a number of items in a collection of items.

clear

61

Clears the content of the thing referenced.

clone

59

Clones the thing referenced.

TOTAL

1249

These 10 method names are used by roughtly 1/6 of the methods in Oracle's implementation of Java 1.5.

63

111. The organization of the methods into classes, like the organization of classes into package, is driven by functionality and the requirement that programmers be able to efficiently find and use these methods. This is why, for example, all of the math functions listed in the table in paragraph 39 are in the same java.lang.Math class.

112. Because these names all describe specific functionalities, limited by design rules to short, fragmentary words and phrases, there is no meaningful creativity in the class or method names.

M. THE JAVA NAMES ARE THE PRODUCT OF MECHANICAL RULES

113. Java API element names frequently repeat certain key terms and patterns, following mechanical rules laid out in the Java Language Specification and elaborated over time by practice. The rules provide suggestions for structure and naming, stating, for example, that “[m]ethod names should be verbs or verb phrases, in mixed case, with the first letter lowercase and the first letter of any subsequent words capitalized.” Similarly, names of class types are to be “descriptive nouns or noun phrases.” Java Language Specification, First Edition, Section 6.8 “Naming Conventions,” available at java.sun.com/docs/books/jls/
first_edition/html/6.doc.html#11186. Both of these rules are followed by all the examples shown in this report, except for those methods that are drawn from older programming languages (like “sqrt”).

114. Additional word patterns crop up repeatedly throughout the Java APIs. “InputStream” and “ChangeEvent,” cited above, are two examples affecting a few dozen names, but others go much further. For example, the Java Language Specification rules for method

64

names state that methods that return the value of a variable should start with “get,” and method names that set the value of a variable should start with “set.” Other rules require specific methods to be in many classes, such as “hashCode” and “toString.” In Oracle’s implementation of Java 1.5, nearly one-third of the method names at issue (2,578 of the 7,796 methods) are determined by these rules, including roughly 2,000 that begin with either “get” or “set,” and 164 named simply “equals.” Testing whether one thing is equal to another thing is an extremely common operation for programmers, and so it makes sense that many different methods for testing equality would exist. At the same time, it makes sense to make sure that the operation has the same name everywhere — it would unnecessarily complicate the learning process if it were “equals” in one place, “sameAs” in another place, and so forth. These constraints yield the resulting name (“equals”) — which is wholly functional, dictated by efficiency constraints and not creativity.

115. An additional 2,347 method names were single words, like “run” or “add.” The remaining 2,871 methods are not long or complicated — they are, on average, only 2.344 words “long” (counting a method name like locateURL as two words and findBestMatch as three words). In Android, of the 9297 total methods, 3220 are unique methods, 2676 or 28.8% are one word names, 2909 are required names (like the “get” and “set” examples above), leaving 3,712 other methods whose average word length is 2.41.

116. Following these mechanical rules and seeking to create consistency reduce the amount of creativity and work necessary to write the API, and, more importantly, reduces the amount of work necessary to learn and memorize the API. As a result, any good API design will have naming rules like the Java API naming rules contained in the Java

65

Language Specification, which result in names that are functional and primarily dictated by efficiency constraints.

117. It is also my opinion that the rules and naming conventions imposed by the Java Language Specification further constrains any creativity associated with the API names.

N. THE ORGANIZATION OF API ELEMENTS IS DICTATED BY FUNCTION AND DOES NOT REFLECT CREATIVITY

118. The same restrictions that apply to naming also apply to the organization of methods. Just as the name must be tied to functionality so that the API is easy to find and remember, the organization into related groupings must also reflect underlying functionality so that programmers can discover and use the elements efficiently. For example, methods related to security, such as AccessController.checkPermission and Signature.sign, are most sensibly organized into packages primarily related to security — java.security and javax.security.

119. The practical requirement that all API element names and package organizations be related to the underlying functionality restricts the packages in which any class can be placed, and restricts the classes in which any method can be placed. The fourth column in the tables in paragraphs 106, and 107 show how and why various classes fit into their respective packages, and various methods fit into their respective classes, which can help demonstrate this. For example, ZipInputStream is a class which allows creation of an “input stream” which can read from a compressed file (known as a .zip file). Because it relates to .zip files, developers will look for it with other classes and methods related to .zip files, and so it is grouped with them in an appropriately named subpackage called java.util.zip.

66

O. THE SAME ANALYSIS APPLIES TO THE NATIVE FILES

120. It is my understanding that Oracle has alleged that a number of files written in the C programming language are at issue. These files are part of the implementation of the Java API. For example, the file name java_lang_reflect_Array.c (which I understand is one of the files at issue) reflects the name of the java.lang.reflect.Array class. Similarly, the C function names within the file java_lang_reflect_Array.c reflect method names within the java.lang.reflect.Array class. As with the implementation files in the Java language discussed above, these files written in the C language must use these names and organizing principles in order to implement the API in a compatible and interoperable manner. If Android could not use these names in these files, Android could not create a compatible, efficient implementation of these APIs.

121. For example, the file java_lang_Class.c has these 29 C language functions:

Each of these functions corresponds exactly to a so-called native method in the class

java.lang.Class. For example the C language function

Dalvik_java_lang_Class_isAnonymousClass corresponds to the method

AnonymousClass in the class java.lang.Class; the C function

Dalvik_java_lang_Class_setAccessibleNoCheck corresponds to the method

setAccessibleNoCheck in the class java.lang.Class, and so on for each function in the file.

122. The other .c files share similar characteristics to their corresponding .java files. The
functions in the .c files typically correspond exactly to a corresponding public method in the related .java file or to a private method used to implement the private method. For example, in the file java_lang_Runtime.c ,the function Dalvik_java_lang_Runtime_nativeLoad corresponds to the private method nativeLoad in java.lang.Runtime which is used in the implementation of the public method

68

java.lang.Runtime.load. In my opinion, there is no expressiveness in the names used in the C files, because they are directly derived from the functional names in the .java files (as explained above), and are required for efficient implementation of those files.

P. MANY API ELEMENTS ARE DRAWN FROM THE PUBLIC DOMAIN AND ARE NOT ORIGINAL TO JAVA

123. It is my understanding that names are not entitled to copyright protection. However, even if they were, it is my opinion that many of the Java names are drawn from the public domain.

124. Java, like many other programming languages, is based on features of previous well-known languages, such as C and C++, including their grammar and syntax. See, e.g.,
http://java.sun.com/docs/books/jls/first_edition/html/1.doc.html
(“the lexical structure of Java . . . is based on C and C++”); see also http://www.gotw.ca/publications/c_family_interview.htm
(James Gosling, inventor of Java, quoted as saying “You can go through everything in Java and say ‘this came from there, and this came from there’”). Reuse of grammar and syntax from already-familiar languages allowed developers to leverage their existing knowledge and more quickly adopt Java. Similarly, authors of new programming languages often use old method and class names when appropriate, in order to help developers reuse their skills and transition to new languages, and to help make sure the ideas are time-tested. See, e.g., James Gosling’s “Feeling of Java” paper, Computer, Vol. 30, Issue 6, June 1997, where he writes “Java feels very familiar to many different programmers because Sun had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea.” As a result, many API element names in modern languages are drawn from the public domain. For example, package names like java.io, java.util, and java.net

69

reflect industry shorthand for common functionality like input/output, utilities, and networking, respectively. These packages with common names then, in turn, contain methods whose naming reflects industry custom and representation of the underlying functionality of the method. Some examples of functions that are very similar in Java and the pre-existing C and C++ languages as a result of their functionality and industry custom are shown below:

A data type holding a character; used repeatedly in method names, such as C++ "getchar" and Java "getChars." Other datatypes, such as int and double, also date back to C and at least the 1970s.

int abs (int i)

At least C; see C Reference Manual

public static int abs (int a)

A function, returning the absolute value of the argument.

printf()

At least C; see C Reference Manual.

printf() (part of the java.io package)

A function, printing a formatted string to the screen or other output device.

70

125. Indeed, many of the names and concepts in Java have been used by the industry for decades. For example, the C Reference Manual references “int,” “double,” and “char,” all used in Java. The “Bool” data type, which became “Boolean” in Java, dates back to at least Algol in 1968, and is a direct reference to Boolean logic — invented in the 1800s.

126. Another example of this is the java.util.regex API package, which implements “regular expressions” — a standardized way of testing if a given string of characters matches a particular pattern. Regular expressions were first formalized in 1968 (“Programming Techniques: Regular expression search algorithm,” Ken Thompson, Communications of the ACM, Vol. 11, Issue 6, June 1968) and were known by the abbreviated name used by Java (regex) at least as early as 1983 (see, e.g. http://groups.google.com/group/
net.lang.c/ browse_thread/thread/6409987225e13a31/50da7fdd143184bd?q=regex#50da7fdd143184 bd). Java.util.regex has two classes: Pattern, and Matcher. Method names in the Pattern class are compile, flags, matcher, matches, pattern, and split, while method names in the Matcher class include matches, pattern, reset, and start. Each of these names — particularly the extremely common “pattern” and “matcher” — are used in publicly available regular expressions software that predate java.util.regex, and all of them are discussed in Mastering Regular Expressions, Jeffrey E. F. Friedl, O'Reilly and Associates, 1997, which Oracle’s documentation for java.util.regex cites. Sun also used third-party source code (Jakarta Regexp) to implement java.util.regex, and this code also had references to many of these terms, including “compile,” “pattern,” and “match.”

127. Similarly, the java.sql and javax.sql packages are also based in part on pre-existing terms widely used in the industry. The package names themselves are a reference to the SQL standard, originally introduced in the academic literature as SEQUEL in 1974 (SEQUEL: A structured English query language, Proc. ACM SIGFIDET Workshop, May 1974, pp.

71

249-264). The classes and methods frequently are named after SQL concepts, and in particular (according to Sun’s documentation at http://jcp.org/
aboutJava/communityprocess/first/jsr054/
jdbc-3_0-pfd-spec.pdf) on the X/Open SQL Call Level Interface (CLI), which dates to the first half of the 1990s (available at http://
pubs.opengroup.org/onlinepubs/009654899/toc.pdf). For example, java.sql includes classes named “Array,” “Blob,” “Clob,” and “Ref,” which are the names of data types from the SQL standard. Similarly, the SQL CLI standard defines a method called “prepare” that operates on a StatementText. Java.sql’s Connection class has a method called prepareStatement that has similar functionality. The SQL CLI standard also uses “commit” and “rollback” to discuss specific actions that can be done to a database, and java.sql’s Connection class has matching “commit” and “rollback” methods that perform the actions discussed in the standard.

128. Java.util.zip is another example where the name of the package, and at least some API element names within the package, are references to terms that substantially predate Java’s use of the terms. In this case, “zip” is a reference to the zip file format that has been in use since before the creation of Java. Class names in this package include “Adler32” (named after the Adler-32 algorithm invented by Mark Adler and licensed to the public as part of the zlib library) and “CRC32” (named after the CRC-32 algorithm, which dates back to the 1970s). Within the java.util.zip classes, method names include “deflate,” “inflate,” and “setDictionary,” which are very similar both to general industry terms for these processes but also to the specific function names “deflate,” “inflate,” and “deflatesetdictionary” that are in the publicly available open source library (zlib) that predates, and is incorporated by, Java. (See http://www.zlib.net/manual.html)

72

Q. THE APIS AT ISSUE ARE NECESSARY FOR BASIC FUNCTIONALITY AND INTEROPERABILITY

129. In my opinion, the functionalities grouped into each of the API packages at issue (as listed above) are basic to most modern operating systems and particularly to mobile systems. As a result, it is necessary to include these functionalities in the Android platform. For example, the java.net package contains functionality relating to networking, and every modern mobile software platform must have networking functionality. If this functionality was not included in Android, Android would not be a competitive, modern platform.

130. Once Google decided to provide the ability for developers to write applications using the Java programming language, compatibility and interoperability with the existing body of software, tools, and knowledge about the Java APIs was an external factor constraining Android’s options. This essentially required Google to include the APIs at issue.

131. Because Android is written primarily in the Java language (over which I understand
Oracle does not claim copyright protection), Google was practically required to include
the APIs at issue. There would be little benefit to merely using the same grammar and
syntax; in order for existing code in a language to be compatible and interoperable with
new software written in the same language, the API elements that constitute the language
must also be present, and named and organized identically. Even the slightest changes to
the names or organization of API elements will thwart compatibility and interoperability,
because existing code that used those elements would not run properly, and programmers
would have to learn new API element names. For example, I have previously discussed
the method “sqrt,” which computes the square root of a number. If the method were
changed even the slightest (say, to “sqroot”), then existing source code written in the Java

73

programming language would not compile. Even more work on the part of the programmer would be required if, for some reason, the organization, arguments, or return values of the methods needed to be changed. It is not necessary to be a programmer to understand how this could be jarring; changing the shortcuts for copy and paste from Ctl+C and Ctl+V to something else would require every user of word processors to change their behaviors, which is why those two keyboard commands have been used unchanged across many programs since the first graphical user interfaces. As previously mentioned in paragraph 35, this sort of compatibility and interoperability is important to the industry, since (in the worst case) it allows programmers to reuse known, tested code fragments — an important practice in the industry — and in the best case, where compatibility is complete, it allows reuse of entire programs without modification. Therefore, the APIs at issue were included in Android in order to allow Android to be interoperable with existing code written in the Java programming language.

132. It is worth emphasizing that reuse of the API in this way does not mean that the underlying program logic implementing the API was copied.

133. In my opinion, the Java APIs are necessary for functionality, interoperability and programming efficiency.

R. THE APIS AT ISSUE ARE DEMANDED BY THE INDUSTRY

134. In my opinion, industry demand requires APIs that are compatible with Java, rather than APIs that are similar to, but not compatible with, Java.

135. Industry and developer practice would tend to make it very difficult for Google to choose a different API, or modify an existing Java API, when the Java language is used and supported by Google. While curious developers do teach themselves new APIs, as a

74

general rule they prefer not to be forced to retrain on new APIs unless there is an extremely good reason to do so. This is not simply a matter of losing the time spent learning; learning new APIs also means buying new books, losing the ability to reuse code fragments, and temporarily losing the fluency that comes with expertise in a particular language’s idioms and structures. Indeed, a significant goal of the discipline of programming has always been to create reusable tools and build on what has been developed before, and the value of sensible reuse of existing APIs has been understood to be a significant part of this.

136. It is not just individual developers who strongly prefer existing languages. Companies also prefer to write programs in existing languages. Doing so allows them to reuse existing source code and tools; even where they cannot reuse entire programs, reuse of fragments of code is very common. Such code reuse helps make software better by allowing the reuse of tested, well-understood code, but it is only possible where platforms allow the same APIs to be used. For example, existing code written in the Java language which references the “abs” method would not run on a new platform unless the new platform supported this method and the class and package in which this method resides by implementing the API. As a result of these factors, the industry as a whole — both programmers and the companies who employ them — strongly prefer to work with APIs and API elements with which they are familiar.

137. It is not a coincidence that many software developers are familiar with Java APIs. Sun went to great lengths to encourage developers to learn and use Java. This began when Sun made the Java language, documentation, and API implementation available at no charge in 1996, apparently with the intent to ensure that programmers throughout the industry knew and had internalized the Java language, including these APIs. Sun also

75

worked extensively with educational institutions to help make the Java language a common tool for introductory programming classes. For example, there was active collaboration between Sun and the College Board in promoting Java as the language to be used in the Advanced Placement Computer Science (AP CS) exams developed by the College Board. These changes began just as the exam was switched from Pascal to C++ in 1999. Java was too large a language to be taught completely, so a subset of the classes and methods were identified as being an important part of teaching computer science. This led to the development of a group of classes that were part of the AP CS program and that mirrored the Java API exactly, e.g., instead of using java.lang, the AP CS program identified and used ap.java.lang with a corresponding documentation as part of the subset. At a similar time, Sun collaborated with the BlueJ group headed by Michael Kolling to develop an IDE (Integrated Development Environment) for novice programmers that was simple, but that used best practices that were part of Sun’s official NetBeans IDE. The development of BlueJ led to a world wide adoption of BlueJ in many colleges and high schools that continues today with the use of BlueJ and its derivative GreenFoot which sees widespread adoption. In part as a result of that effort, I taught Java to my students for many years, and continue to do so. This effort created a large base of programmers who had learned the Java language and APIs, and would be reluctant to retrain on other languages because of their investment in Java. It is my understanding that Oracle, in its filings to the court, has claimed that the number of programmers who have invested time and effort to learn Java is in the range of 6-7 million. The investment of these programmers in learning the APIs is likely in the hundreds of millions of man hours.

138. In part as a result of Sun’s substantial efforts to encourage programmers to learn and use the Java language, a large number of software applications have been written in the Java

76

language. The investment involved in creating these existing applications creates further industry demand for compatibility that would allow use of this existing software or code fragments on new platforms.

139. In conclusion, it is my opinion that the Java APIs have the following qualities: First, the APIs represent concepts and methods of operation. Second, the API names, method declarations, and organization are dictated by function or mechanical rules and do not reflect creative expression. Indeed, as noted, many API element names existed in the public domain and were not original to Java. Third, the APIs at issue are necessary for interoperability and efficiency reasons, and their use is driven by industry demand.

VI. THE ANDROID PLATFORM IS NOT VIRTUALLY IDENTICAL OR SUBSTANTIALLY SIMILAR TO THE JAVA PLATFORM

140. The Android platform uses the unprotectable API elements at issue as part of a larger overall framework that is substantially different from the Java platform, and more appropriate for the mobile platform.

141. The Java API packages which have been implemented by Android are a small part of the overall Android system, both in terms of the functionality they provide and the lines of code involved. The 48 APIs at issue are roughly one-third of the Android Runtime Core Libraries, which currently contains 168 API packages. The Core Libraries, in turn, are themselves only a small part of the overall Android architecture — they are the small blue box labeled “core libraries” in the yellow box at the right.3 Other elements include the

77

Dalvik Virtual Machine, the Linux kernel, a web browser, and a variety of other libraries and systems that are not part of the Java platform. These other components, when combined with the Android Core Libraries, make for a complete mobile operating system — something substantially different in scope and ability than the Java platform.

142. While the diagram above is not “to scale” (boxes of the same size may represent software of different size and complexity), an analysis of the number of lines of source code in the API packages at issue, in the Android Runtime Core Libraries, and in the other components in the diagram suggests that, if anything, the diagram likely overrepresents the size of the APIs at issue.

143. Using a Python script SlocCounter.py (attached as Exhibit E) based on the “sloccount” tool, a commonly-used tool for measuring the size of the source code of large software projects, Android’s implementation of the APIs at issue in the “Gingerbread” release

78

constitutes 259,474 lines of code, in 1022 files. This is roughly 1.6% of the size of the entire Android source code, which comprises 57,076 files and 15,347,169 lines of code,4 and roughly 15% of the 6,340 files and 1,713,087 lines of code5 in the overall Android (Gingerbread) Runtime Core Libraries. Similarly, implementation of these APIs is a small portion of Oracle’s JDK 1.5 implementation of the entire Java API, constituting 315,570 lines of code out of 2,867,712 (11% of the total) and 1001 files out of 9521 (10.5%).

144. Because Android’s implementation of the APIs at issue comprises only 1.6% of the entire Android source code, Android as a whole is not virtually identical or substantially similar to the Java platform. The Java APIs at issue are not only a small portion of the Android platform, in my opinion the use of the Java APIs in the Android context is substantially different from the use of those APIs in the Java platform, which creates a different platform with different capabilities and functionalities targeting the emerging smartphone market rather than the desktop.

79

VII. ANDROID’S DOCUMENTATION OF THE APIS AT ISSUE IS NOT VIRTUALLY IDENTICAL OR SUBSTANTIALLY SIMILAR TO ORACLE’S DOCUMENTATION
145. Every API has documentation. This documentation is a written description of the functionalities provided by the API. The documentation is relied on by programmers when they need more detail and context than what is available from the name and organization of the method. Documentation also helps the programmer see what related functionality is available in the same classes and packages. Like the naming and organization of methods, good documentation of API components is extremely constrained, because it must be factual and succinct. Just as a square root function should not be named “Steve,” the documentation of the square root function, in order to be maximally efficient for programmers who are referring to it, should be — and typically is — factual and strictly descriptive of the underlying functionality.
146. Because of the practical requirement that documentation for an API strictly describe the underlying functionality, and because programmers typically want to know the same important pieces of information about a given API, there are not many ways to write documentation for a specific API element. Two different authors documenting the same API components would necessarily write very similar documentation because they are describing the same functionality.
147. It may be useful to analogize writing documentation to writing a dictionary. If Merriam-
Webster defines a zebra as an “African mammal [] . . . related to the horse but
distinctively and conspicuously patterned in stripes of black or dark-brown” and
Dictionary.com defines a zebra as an “African mammal[] . . . each . . . having a
characteristic pattern of black or dark-brown stripes,” this does not mean that the second

80

dictionary copied from the first. The definitions are similar because they are describing the same thing. It would be difficult to describe a zebra briefly without using words like “Africa,” “stripes,” “black,” and “dark-brown.” In addition, even where there may be multiple ways to describe things, the normal requirements that influence a dictionary (e.g., clarity and brevity) are present for both dictionaries. This results in dictionary definitions that are similar even when written without copying.

148. Similarly, writing software documentation is significantly constrained, because the writer must convey the same factual information briefly, accurately, and with clarity. As a result of these constraints, skilled technical writers writing about the same API are likely to come up with descriptions that appear very similar and contain very similar descriptions of the critical features. The documentation for Java follows this pattern. For example, the method in the class java.io.PrintStream whose prototype is “void write(int OneByte)” takes one byte and writes (hence the name) that byte to the relevant “stream.” Not surprisingly, Android’s brief documentation of this method states that this method:

Writes one byte to the target stream.

Oracle’s brief documentation for the same method states:

Write the specified byte to this stream.

The two different documentation writers have chosen different verb tenses for “write,” and described the byte to be written slightly differently (“one byte” versus “the specified byte”) but the descriptions are generally similar, not because they were copied from each other but because they must accurately and briefly describe the underlying functionality. Most documentation of the same method by two different authors will show the same pattern of similarity, because the authors are aiming at efficient, factual statements.

81

149. In my opinion, the Android and Java documentations are not virtually identical, nor are they substantially similar. Any similarity is dictated by the fact that they both document the same functionalities, and does not imply or demonstrate that they both involve the same creative expression. Indeed, the level of creativity reflected in the documentation is very low because it is intended to be highly descriptive, and is generally circumscribed by the nature of the functions described. It is my understanding that, in order to show that the Android documentation for the APIs at issue infringes Oracle’s copyrights purportedly covering Oracle’s documentation of the Java APIs, it must be shown that original and creative elements of the Java documentation, if any, have been copied into Android’s documentation.

VIII. THE TWELVE FILES OR PORTIONS OF FILES ALLEGED BY ORACLE TO HAVE BEEN COPIED ARE QUALITATIVELY AND QUANTITATIVELY INSIGNIFICANT AND THEY ADD NO OR VERY LITTLE VALUE TO ANDROID

150. In this section, I will analyze the 12 files that Oracle alleges were copied by Google. These files represent, by number of files, 0.02% of Android and 0.13% of Oracle’s implementation of Java 1.5 (12 files out of 57,076 in Android and 9,521 in Oracle’s implementation of Java 1.5), and a similar percentage when measured by lines of code (742 lines out of 15 million and 2.8 million lines of code for Android and Oracle Java 1.5, respectively.) It is my understanding that, aside from these 12 files, Oracle does not allege that Google literally copied source code from Oracle.

82

A. TIMSORT FILES

151. It is my understanding that two Android files, TimSort.java and ComparableTimSort.java, are at issue. These files are a tiny fraction of a percent of Android and appear to have been donated by Google to Oracle, as explained below.

152. I have inspected three files: TimSort.java, ComparableTimSort.java, and Oracle’s implementation of the Array class contained in Arrays.java. Only a single method out of the 11 methods in TimSort.java and 13 methods in ComparableTimSort.java is shared between those two files and Arrays.java. This method is called rangeCheck, and I have reproduced this method below:

Quantitatively, this method is 9 lines of code out of 3,179 lines in the Oracle JDK 1.5 version of Arrays.java, 9 lines out of 924 lines in the latest Android version of TimSort.java, and 9 lines out of the total 46,269 lines (0.5%) that compose Android’s implementation of the single java.util package at issue.

153. Qualitatively, the rangeCheck method is also trivial. It merely performs a simple, utilitarian, and fairly mundane “sanity check,” checking that certain arguments used

83

elsewhere are correct before they are used. The two arguments tested are the index to the first element of interest in an array (“fromIndex”), and the index to the last element of interest in the array (“toIndex”). They are compared against the number of elements in the given array (“arrayLen”), against zero, and against each other to ensure that their values are “in range” — that is to say that they are acceptable in the context of this code.

154. Because the first element should always come before the last element, if fromIndex is larger than toIndex — line #2 in the code, “if (fromIndex > toIndex)” — that means that the programmer made an error. If that happens, lines 3 and 4 of the method “throw an exception” (in programming jargon, they indicate that an error has occurred).

155. Similarly, because an index should, by convention, never be less than zero, if fromIndex is less than zero, this indicates another type of error. Line 5 tests for this (“if (fromIndex
156. Finally, the last element of interest (“toIndex”) must refer to an element that actually exists, so if toIndex is greater than the total number of elements in the array (“arrayLen”) (line 7), that also indicates an error, and the another exception is thrown by line 8.

157. This code was also necessary for API compatibility with other sort implementations in Java. Because the “exceptions” thrown when an error occurs can be considered to be part of the API of a method, using code extremely similar to this was necessary for TimSort to be completely compatible with other sort implementations. If code extremely similar to this, throwing the same exceptions under the same circumstances, had not been used, the TimSort files could not have been accepted by Oracle into Java for use with Java 7.

158. It is my opinion that this single function is both qualitatively and quantitatively an extremely small portion of the functionality of the TimSort.java and

84

ComparableTimSort.java files, which are in turn an extremely small portion of the overall functionality of Java.

159. I have also reviewed the publicly available documents discussing the history of these two files. It appears that they were written by Google employee Joshua Bloch. While the files were first included in Android, it also appears that Google offered the files to Oracle (see http://markmail.org/
thread/xwyxemce75vvz33h#
query:+page:1+mid:vnipd7bqzs5vxfjw+ state:results), and that this donation was accepted by Oracle (see http://blogs.sun.com/mr/entry/jdk7_m5). As a result of this donation, these files are now part of the most recent version of Oracle’s implementation of Java.

B. SECURITY TEST FILES

160. It is my understanding that eight files in the directories "/support/src/test/java/org/apache/harmony/security/tests/support/acl/" and "/support/src/test/java/org/apache/harmony/security/tests/support/cert/" are at issue. These files are all what are known as “test files,” and as explained below they add minimal if any material value to, and are a very small portion of, Android. Specifically, the files at issue are:

161. It is good engineering practice to write companion software that tests the functionality of the parts of the software that will be delivered to customers. This software (referred to as “test software”) will do the software equivalent of factory testing, feeding the software test inputs (such as “2 + 2”) and verifying that the correct output is returned (such as “4”). Individual tests are known as “unit tests,” because they test a specific “unit” of the software, and the files that are used to implement these unit tests are often referred to as test files. Doing this testing in software, rather than manually, allows for the testing to be done quickly and reliably. The testing can be done, for example, after every single change to the software, rather than only every day or every week as might be required with manual testing.

162. These particular files are in directories labeled “test,” and the structure of their source code indicates that they are part of a test package, instead of a package which is part of the publicly-available Android API. In addition, several of the files contain comments indicating that they are for “verification” of a specific interface. Verification of an interface is a common part of software testing. Finally, these files are referenced only in trunk/dalvik/libcore/security/src/test/
java/tests/security/acl/IAclTest.java and other files in the same directory. This file, and others like it, appears to be the so-called “test framework” — the software that runs the tests. This code is clearly structured to call these files as tests, and not to use the files as part of the actual functionality of the Android platform. In addition, it is worth noting that Android’s history shows that these

86

were removed from Android in January of 2011 and have not, as of this writing, been replaced.6 This confirms that the files were immaterial.

163. These files are also in large part “dummy” files — instead of having complex logic, they return certain, fixed values, which is a common practice in test files. For example, one method in AclEntryImpl.java consists entirely of the following code:

public boolean isNegative() {
return negative;
}

164. In a real (not test) file, the “isNegative” method would do some complex logic to understand whether the quality was negative. Here, because this is a “dummy” file used for test purposes, no logic or work is done — instead, it simply immediately returns “negative.” This “dummy” result would not do much good for real code, but in a test environment, this predictability is useful — if a test shows that for some reason this function is returning “positive,” then something is wrong and must be fixed. Dummy files in general, and these files in particular, are not particularly creative — given the functional constraint of the method names that they are testing, there is typically only one efficient, reasonable way to write them.
165. In general, test files are written for internal use by developers prior to a product’s release. They are typically not distributed as part of consumer products, for two reasons. First,

87

the testing is finished when the software is finalized since end users of consumer products cannot fix any problems found by the testing. Test files are simply not material to the customer experience. Second, distributing them takes up additional space and resources that could be used for other purposes that actually provide direct functionality to consumers, so test files can negatively impact the customer experience if distributed. As a result of these factors, test files generally are not used by or distributed to consumers.
In my opinion, these test files are likely to be the same as others — not distributed to consumers and not material to the consumer experience.

166. Quantitatively, these eight files represent an extremely small part of Android’s and Oracle’s implementations of the Java APIs at issue. These codebases are roughly 1.7 million lines of code and 2.8 million lines of code, respectively, and so these eight files represent less than 0.1% of the lines of code. They are not even a substantial portion of the overall number of test files. My analysis of Android 2.3 suggests that there are at least 142 test files comprising 48,376 lines of code. These eight accused test files are less than 5% of this, measured in terms of lines of code.

167. Qualitatively, these eight files have no material effect on how Android implements the Java APIs at issue, because they are not used by or distributed to consumers.

168. In my opinion, these test files are qualitatively and quantitatively insignificant to the overall Android system.

C. COMMENTS IN CODESOURCETEST.JAVA AND COLLECTIONCERTSTOREPARAMETERSTEST.JAVA

169. It is my understanding that the files CodeSourceTest.java and CollectionCertStoreParametersTest.java are at issue. The comments in these files that are

88

at issue were not written by Google, add no value to Android, and are a very small portion of Android.

170. I have inspected these four files (two each from Oracle’s implementation and Android’s implementation), and the only things that appear to be the same between these classes are certain comments. Of the 36 comments in Android’s CodeSourceTest.java at the time of the complaint, eight appear to be the same as comments in Oracle’s implementation of the CodeSource class. Of the 16 comments in Android’s CollectionCertStoreParametersTest.java, 12 appear to be the same as comments in Oracle’s implementation of the CollectionCertStore Parameters class. No source code appears to have been copied, and the comments at issue appear to have been removed
from Android.7

171. Comments are used in software source code because they help programmers understand the code that they are reading and potentially modifying. However, comments do not become part of the final product that is shipped to the user of the software. If all comments were removed, the functionality would be identical, and users would be generally unaffected. These comments, like all comments generally, would not have been distributed as part of any Android-based products; they would have only been available to any programmers who downloaded the source code from the Android website. It is my opinion, therefore, that these comments did not add material value to the Android platform.

89

172. In addition, these comments are largely very descriptive and functional. For example, one of the copied comments appears to be from the following source code:

173. The similar portion of the comment is “Returns a formatted string describing the parameters.” This is a simple, declarative statement, which describes the source code below it. Like other documentation discussed in paragraph 145, there are very few ways to state this, because it is a simple, factual description of the operation of the public method below it. The other comments at issue, with one exception, are very similar — a single sentence factually describing the method in question. The one exception, slightly longer and more detailed, is still only three sentences long.

174. I have investigated the history of these files, and have determined that these comments were not created by Google. It appears that they were written by Intel employees who donated the files containing the comments to an open source project called Apache Harmony. My understanding is that Apache Harmony is an independent implementation of the Java APIs, created by a non-profit foundation called the Apache Foundation. My understanding is that Apache Harmony is licensed to the public under the terms of the Apache License, which allow anyone to reuse the code with essentially no restrictions. It is my understanding that, in compliance with the terms of the Apache License, Android reused the Apache Harmony implementation of some parts of the Java APIs, and my inspection of files in Android confirms this understanding. Android’s versions of these

90

two files are virtually identical to Apache Harmony’s versions of the same files, strongly suggesting that these two files
(CollectionCertStoreParametersTest.java and CodeSourceTest.java) were obtained by Google for Android under license from the Apache Foundation.

175. The Apache Foundation makes its software records available to the public, documenting the history of all files distributed by the Apache Foundation, including CollectionCertStoreParametersTest.java and CodeSourceTest.java. By using these records, it is possible to see when a particular file was created, when individual lines of code were written or modified, and by whom. Using these records, I determined that these comments have been present in these files since before the Android project. For example, the Android file “CollectionCertStoreParametersTest.java” contained the comment fragment “the default parameter values (an empty and immutable.” This same comment fragment is also present in the Harmony file
“CollectionCertStoreParametersTest.java.” Finally, this same fragment is present in the Oracle file “CollectionCertStoreParameter.java.” By using the history features of the Apache Foundation’s source code storage tool, I verified that this same fragment and matching surrounding text were present in that Harmony file when the file was initially created by an Intel employee, Geir Magnusson, on Jan. 8, 2006.8 After the file was added to Android, Google did not change the comment; the comment stayed the same from the

91

time that the file was licensed from Harmony until they were removed.9 The same is true of the other comments in these two files, all of which appear to have originated with Intel’s contribution to Apache on Jan. 8, 2006. As a result, while I believe that these files had some identical comments (before they were removed by Google), it appears that this is related to choices made by Intel and not by Google.

176. It is also important to note that these two files represent an extremely small part of Android’s and Oracle’s implementations of the Java APIs. These codebases are roughly 1.7 million lines of code and 2.8 million lines of code, respectively, and so these two files represent less than 0.1% of lines of code.

177. In addition, these files are also test files, similar to the files discussed in the previous section. In my opinion, these files are qualitatively and quantitatively insignificant to the overall Android platform.

//

//

//

92

178. I reserve the right to update and refine my opinions and analyses in light of any additional materials or information that may come to my attention in the future, including additional contentions by Oracle as well as any rulings issued by the Court in this case. I also reserve the right to supplement my opinions and analyses as set forth in this report in light of any expert reports submitted by Oracle and in light of any deposition or trial testimony of Oracle’s experts.

DATED: July 29, 2011

[signature]
Owen Astrachan, Ph.D.

93

________________

1
Newton's Telecom Dictionary, 25th Edition, defines API similarly as "Software that an application
program uses to request and carry out lower-level services performed by the computer's ... operating
system." Sun's Java glossary (available at http://java.sun.com/docs/glossary.html) also provides a
definition for API: "The specification of how a programmer writing an application accesses the behavior
and state of classes and objects." Although these definitions use different terminology, they are not
materially different from, and are in fact consistent with, the definition I have presented above.

2 Available at
http://android.git.kernel.org/?p=platform/libcore.git;a=blob;f=
luni/src/main/java/java/lang/Math.java;h=
1da0b905c4af9aaf930adf5b8b80d92193b7c462;hb=HEAD#l100.

3
Diagram taken from the Android website, available at http://developer.android.com/images/system-architecture.jpg.

4
Numbers generated by running SlocCounterTotal.py (attached as Exhibit E) against a clean copy of Android (obtained following the instructions available here: http://source.android.com/source/downloading.html) and including only lines of code in .h, .c, .cpp, and .java files.

5 directories in a clean copy of Android, counting only lines of code in .h, .c, .cpp, and .java files.
Numbers generated by running SlocCounterTotal.py against the libcore/ and frameworks/base/core/

z. Solaris source code and revision history as available at
http://cvs.opensolaris.org/source/xref/onnv, including
http://cvs.opensolaris.org/source/history/onnv/
onnv-gate/usr/src/uts/common/syscall/uucopy.c and
http://cvs.opensolaris.org/source/history/onnv/
onnv-gate/usr/src/uts/common/brand/; and also as archived at http://hg.genunix.org/onnv-gate.hg/; including
http://hg.genunix.org/onnv-gate.hg/rev/4c5722bc28dc