decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
Oracle v. Google - You Name It, You'll Find It In This Story
Friday, August 05 2011 @ 08:00 AM EDT

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:

Some Android package API specifications are substantially similar to selected portions of some of the Oracle Java API package specifications (e.g., java.awt.font, java.beans) while other Android package API specifications are substantially similar to complete portions of other Oracle Java API package specifications (e.g., java.io, java.lang, java.net, java.nio, java.security, java.sql, java.text). Exhibits A-E are illustrative examples.10

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:

Moreover, Google admits that Android incorporates a subset of Apache Harmony, which it asserts is “an implementation of Sun’s Java.” (See, e.g., Google’s Amended Counterclaims ¶¶ 6-7, 13.)
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:
07/13/2011 - 214 - Amended MOTION for Leave to File Supplement Invalidity Contentions filed by Google Inc.. (Attachments: # 1 Affidavit Declaration of Mark Francis in support of Amended Motion for Leave to Supplement Invalidity Contentions, # 2 Proposed Order Proposed Order Granting Google Inc's Amended Motion for Leave to Supplement Invalidity Contentions)(Banner, Brian) (Filed on 7/13/2011) (Entered: 07/13/2011)
From Exhibit 1 to this earlier filing comes the following potential blockbuster with respect to the patent claims:
30. Attached to this declaration as Exhibit L is a true and correct copy of a May 29, 1996 press release from JavaSoft, a subsidiary of Oracle (then named Sun Microsystems Inc.), announcing the release of JavaOS more than a year before the October 31, 1997 filing date of the application which issued as the ‘702 patent, available at http://web.archive.org/web/19961220110704/http://www.sun.com/ smi/Press/sunflash/9605/sunflash.960529.11819.html.
If this is accurate, it raises serious questions about the original '702 patent application.

This could all get very interesting.


***************

Docket Update:

07/29/2011 - 249 - Joint Administrative Motion to File Under Seal KEY TO JOINT FILING RE RULE 706 EXPERT WITNESSES (DKT. NO. 234) filed by Oracle America, Inc.. (Attachments: # 1 Proposed Order SEALING KEY TO JOINT FILING RE RULE 706 EXPERT WITNESSES)(Dearborn, Meredith) (Filed on 7/29/2011) (Entered: 07/29/2011)

07/29/2011 - 250 - Letter from Robert Van Nest in response to 247 Oracle's opposition to Google's precis letter. (Van Nest, Robert) (Filed on 7/29/2011) Modified on 8/1/2011 (wsn, COURT STAFF). (Entered: 07/29/2011)

07/29/2011 - 251 - NOTICE of Change of Address by Robert Addy Van Nest (Van Nest, Robert) (Filed on 7/29/2011) (Entered: 07/29/2011)

07/29/2011 - 252 - Order by Magistrate Judge Donna M. Ryu granting 241 Administrative Motion to File Under Seal.(dmrlc1S, COURT STAFF) (Filed on 7/29/2011) (Entered: 07/29/2011)

07/29/2011 - 253 - DOCUMENT E-FILED UNDER SEAL re 252 Order on Administrative Motion to File Under Seal Joint letter by Oracle America, Inc.. (Holtzman, Steven) (Filed on 7/29/2011) (Entered: 07/29/2011)

08/01/2011 - 254 - ORDER SEALING KEY TO JOINT FILING RE RULE 706 EXPERT WITNESS, Order by Hon. William Alsup granting 249 Administrative Motion to File Under Seal.(whalc1, COURT STAFF) (Filed on 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 255 - ORDER DENYING LEAVE TO FILE MOTIONS TO SEAL AND REDACT DAUBERT RECORD re 247 Letter filed by Google Inc.. Signed by Judge Alsup on August 1, 2011. (whalc1, COURT STAFF) (Filed on 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 256 - *** FILED IN ERROR. PLEASE SEE DKT No. 257 . ***
ORDER EXTENDING FACT DISCOVERY CUT-OFF AND DUE DATES FOR EXPERT REPORTS re 246 Stipulation filed by Oracle America, Inc.. Signed by Judge Alsup on August 1, 2011. (whalc1, COURT STAFF) (Filed on 8/1/2011) Modified on 8/1/2011 (whalc1, COURT STAFF). (Entered: 08/01/2011)

08/01/2011 - 257 - ORDER EXTENDING FACT DISCOVERY CUT-OFF AND DUE DATES FOR EXPERT REPORTS re 246 Stipulation filed by Oracle America, Inc.. Signed by Judge Alsup on August 1, 2011. (whalc1, COURT STAFF) (Filed on 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 258 - Minute Entry: Discovery Hearing held on 8/1/2011 before Magistrate Judge Donna M. Ryu (Date Filed: 8/1/2011). (Court Reporter Raynee Mercado.) (fs, COURT STAFF) (Date Filed: 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 259 - DOCUMENT E-FILED UNDER SEAL re 254 Order on Administrative Motion to File Under Seal KEY TO JOINT FILING RE RULE 706 EXPERT WITNESSES by Oracle America, Inc.. (Dearborn, Meredith) (Filed on 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 260 - MOTION for Summary Judgment on Count VIII of Plaintiff Oracle America's Amended Complaint filed by Google Inc.. Motion Hearing set for 9/15/2011 02:00 PM in Courtroom 9, 19th Floor, San Francisco before Hon. William Alsup. Responses due by 8/15/2011. Replies due by 8/22/2011. (Kwun, Michael) (Filed on 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 261 - Declaration of DANIEL BORNSTEIN in Support of 260 MOTION for Summary Judgment on Count VIII of Plaintiff Oracle America's Amended Complaint filed byGoogle Inc.. (Attachments: # 1 Exhibit A)(Related document(s) 260 ) (Kwun, Michael) (Filed on 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 262 - Declaration of OWEN ASTRACHAN in Support of 260 MOTION for Summary Judgment on Count VIII of Plaintiff Oracle America's Amended Complaint filed byGoogle Inc.. (Attachments: # 1 Exhibit 1, # 2 Exhibit 2)(Related document(s) 260 ) (Kwun, Michael) (Filed on 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 263 - Declaration of MICHAEL S. KWUN in Support of 260 MOTION for Summary Judgment on Count VIII of Plaintiff Oracle America's Amended Complaint filed byGoogle Inc.. (Attachments: # 1 Exhibit A, # 2 Exhibit B, # 3 Exhibit C, # 4 Exhibit D, # 5 Exhibit E, # 6 Exhibit F, # 7 Exhibit G, # 8 Exhibit H, # 9 Exhibit I, # 10 Exhibit J, # 11 Exhibit K, # 12 Exhibit L, # 13 Exhibit M, # 14 Exhibit N, # 15 Exhibit O)(Related document(s) 260 ) (Kwun, Michael) (Filed on 8/1/2011) (Entered: 08/01/2011)

08/01/2011 - 264 - Proposed Order re 260 MOTION for Summary Judgment on Count VIII of Plaintiff Oracle America's Amended Complaint by Google Inc.. (Kwun, Michael) (Filed on 8/1/2011) (Entered: 08/01/2011)


The Documents:

******************

KEKER & VAN NEST LLP
ROBERT A. VAN NEST - #84065
[email]
CHRISTA M. ANDERSON - #184325
[email]
[address, phone, fax]

KING & SPALDING LLP
SCOTT T. WEINGAERTNER (Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[email]
[address, phone, fax]

KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
[email]
CHERYL A. SABNIS - #224323
[email]
[address, phone, fax]

GREENBERG TRAURIG, LLP
IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
[email]
[address, phone, fax]

Attorneys for Defendant
GOOGLE INC.

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

DEFENDANT GOOGLE INC.’S NOTICE
OF MOTION AND 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

TABLE OF CONTENTS

Page

I. INTRODUCTION...............................................................................................................1

II. FACTUAL BACKGROUND ..............................................................................................2

A, A brief history of Java and Android. .......................................................................2
1. The Java language and the Java platform. ...................................................2

2. The Android platform. .................................................................................4

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

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

D. Oracle’s copyright infringement claim. ...................................................................9

III. ARGUMENT ………………………………………………………………………………………………………11
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

E. Oracle’s secondary infringement claims fail for lack of proof of direct
infringement. ..........................................................................................................25

IV. CONCLUSION ..................................................................................................................25

i

TABLE OF AUTHORITIES

Page(s)

Federal Cases

Apple Computer, Inc. v. Microsoft Corp.
35 F.3d 1435 (9th Cir. 1994) ...................................................................................11, 12, 24, 25

Baker v. Selden
101 U.S. 99 (1879).....................................................................................................................12

Bateman v. Mnemonics, Inc.
79 F.3d 1532 (11th Cir. 1996) .............................................................................................15, 19

Baystate Techs. v. Bentley Sys.
946 F. Supp. 1079 (D. Mass. 1996) ...............................................................................15, 16, 18

Brown Bag Software v. Symantec Corp.
960 F.2d 1465 (9th Cir. 1992) .....................................................................................................4

CMM Cable Rep, Inc. v. Ocean Coast Props.
97 F.3d 1504 (1st Cir. 1996)......................................................................................................17

Computer Assocs. Int'l, Inc. v. Altai
982 F.2d 693 (2d Cir. 1992) ....................................................................................14, 15, 18, 22

Data East USA, Inc. v. Epyx, Inc.
862 F.2d 204 (9th Cir. 1988) .....................................................................................................11

Feist Publ'ns, Inc. v. Rural Tel. Serv. Co.
499 U.S. 340 (1991).............................................................................................................11, 14

Fisher v. Dees
794 F.2d 432 (9th Cir. 1986) .....................................................................................................23

Jada Toys, Inc. v. Mattel, Inc.
518 F.3d 628 (9th Cir. 2008) .....................................................................................................11

Kelly v. Arriba Soft Corp.
336 F.3d 811 (9th Cir. 2003) .........................................................................................19, 21, 22

Lexmark Int'l., Inc. v. Static Control Components, Inc.
387 F.3d 522 (6th Cir. 2004) .....................................................................................................15

Lotus Dev. Corp. v. Borland Int'l, Inc. 49 F.3d 807 (1st Cir. 1995), afford by an equally divided court, 516 U.S. 233 (1996)...............................................................................................2, 4, 12, 13, 14

Matthew Bender & Co. v. West Publ'g Co.
158 F.3d 693 (2d Cir. 1998) ......................................................................................................25

Merchant Transaction Sys., Inc. v. Nelcela, Inc.
No. CV 02-1954-PHX-MHM, 2009 WL 723001 (D. Ariz. March 18, 2009) .........................................................................................................17

MiTek Holdings, Inc. v. Arce Eng'g Co., Inc.
864 F. Supp. 1568 (S.D. Fla. 1994), aff'd, 89 F.3d 1548 (11th Cir. 1996)..........................................................................................................................24

Mitel, Inc. v. Iqtel, Inc.
896 F. Supp. 1050 (D. Colo. 1995), aff'd, 124 F.3d 1366 (10th Cir. 1997)..................................................................................................13, 14, 15, 16, 19

ii

TABLE OF AUTHORITIES
(cont'd)

Page(s)

Newton v. Diamond
388 F.3d 1189 (9th Cir. 2004) .............................................................................................22, 23

Perfect 10, Inc. v. Amazon.com, Inc.
508 F.3d 1146 (9th Cir. 2007) .............................................................................................19, 22

Sega Enters. Ltd. v. Accolade, Inc.
977 F.2d 1510 (9th Cir. 1992) ………………………………………………………………………………. passim

Sony Computer Entm't, Inc. v. Connectix Corp.
203 F.3d 596 (9th Cir. 2000) .........................................................................................20, 21, 22

Subafilms, Ltd. v. MGM-Pathe Communications Co.
24 F.3d 1088 (9th Cir. 1994) .....................................................................................................25

Federal Statutes

17 U.S.C. § 102(b) .............................................................................................................11, 12, 13

Federal Regulations

37 C.F.R. § 202.1(a).......................................................................................................................17

Constitutional Provisions

U.S. CONST. art. I, § 8, cl. 8 ...........................................................................................................14

Other Authorities

Andrew Sinclair, License Profile: Apache License, Version 2.0 .....................................................4

Paul GOLDSTEIN, GOLDSTEIN ON COPYRIGHT § 2.15.3, at 2:208
(3d ed. 2011) ........................................................................................................................16, 17

iii

NOTICE OF MOTION AND STATEMENT OF RELIEF SOUGHT

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." See Sega 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.9 See 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. See Sega 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. See Lotus, 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

14

idea and the expression merge. See Computer Assocs. Int'l, Inc. v. Altai, 982 F.2d 693, 709-10 (2d Cir. 1992).

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.

E. Oracle’s secondary infringement claims fail for lack of proof of direct infringement.

Oracle cannot establish direct infringement for the reasons detailed above. Its inducement and contributory infringement claims must therefore also fail. Subafilms, Ltd. v. MGM-Pathe Communications Co., 24 F.3d 1088, 1092 (9th Cir. 1994); Matthew Bender & Co. v. West Publ’g Co., 158 F.3d 693, 706 (2d Cir. 1998).

IV. CONCLUSION

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.

Dated: August 1, 2011

KEKER & VAN NEST LLP

By: s/ Michael S. Kwun
MICHAEL S. KWUN
Attorneys for Defendant
GOOGLE INC.

____________________

1 Sun is Oracle's predecessor in interest.

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.

4 Kwun Decl., Ex. G at 2.

5 See generally Andrew Sinclair, License Profile: Apache License, Version 2.0, 2 INT'L FREE & OPEN SOURCE SOFTWARE L. REV. 107 (2010) (discussing Apache License, Version 2.0).

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.

7 See 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.

8 See id. ¶¶ 40-46 (explaining what a method "declaration" is).

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.

12 In Oracle's Responses, these files: AclEntryImpl.java; AclImpl.java; GroupImpl.java; OwnerImpl.java; PermissionImpl.java; PrincipalImpl.java; PolicyNodeImpl.java; and AclEnumerator.java. See Kwun Decl., Ex. C at 14:1-17.

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").

18 See Astrachan Decl., Ex. 1 ¶ 152 (nine lines of code at issue).

19 Where the defendant copies the "heart" of the work, a relatively smaller taking, quantitatively speaking, may exceed de minimis use. Fisher v. Dees, 794 F.2d 432, 434 n.2 (9th Cir. 1986).

25

******************************************
*****************************************

KEKER & VAN NEST LLP
ROBERT A. VAN NEST - #84065
[email]
CHRISTA M. ANDERSON - #184325
[email]
[address, phone, fax]

KING & SPALDING LLP
SCOTT T. WEINGAERTNER (Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[email]
[address, phone, fax]

KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
[email]
CHERYL A. SABNIS - #224323
[email]
[address, phone, fax]

GREENBERG TRAURIG, LLP
IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
[email]
[address, phone, fax]

Attorneys for Defendant
GOOGLE INC.

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.

Executed on August 1, 2011 in Mountain View, California.

[signature]
Daniel Bornstein

3

*****************************
******************************
******************************

KEKER & VAN NEST LLP
ROBERT A. VAN NEST - #84065
[email]
CHRISTA M. ANDERSON - #184325
[email]
[address, phone, fax]

KING & SPALDING LLP
SCOTT T. WEINGAERTNER (Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[email]
[address, phone, fax]

KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
[email]
CHERYL A. SABNIS - #224323
[email]
[address, phone, fax]

GREENBERG TRAURIG, LLP
IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
[email]
[address, phone, fax]

Attorneys for Defendant
GOOGLE INC.

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 MICHAEL S. KWUN
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, Michael S. Kwun, declare as follows:

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 A. Plaintiff’s Amended Complaint for Patent and Copyright Infringement (without exhibits), filed on October 27, 2010.

Exhibit B. Exhibit H to Plaintiff’s Amended Complaint for Patent and Copyright Infringement, filed on October 27, 2010.

Exhibit C. Excerpts from Plaintiff’s Supplemental Responses to Defendant’s Interrogatories, Set No. 1 (Interrogatories Nos. 1-10), served on July 29, 2011.

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 H. A document titled, “PROPOSAL : Apache Harmony - J2SE 5 Project,” downloaded from http://mail-

1

archives.apache.org/mod_mbox/harmony- dev/200505.mbox/%3C3923A844-DEC5-4CC2-ADED- B1F144BB6AF5@apache.org%3E.

Exhibit I. A document titled, “Apache Harmony - Compatibility goals in the Apache Harmony Classlib,” downloaded from http://harmony.apache.org/subcomponents/ classlibrary/compat.html.

Exhibit J. A document titled, “Apache Harmony - Frequently Asked Questions,” downloaded from http://harmony.apache.org/faq.html.

Exhibit K. A document titled, “GNU Classpath Hacker’s Guide: GNU Classpath Hacker’s Guide,” downloaded from http://www.gnu.org/software/classpath/ docs/cp-hacking.html.

Exhibit L. A document dated November 5, 2007, titled “Jonathan’s Blog.”

Exhibit M. A document dated November 5, 2007, titled “Is a Java power play lurking beneath Google’s Open Handset Alliance? | ZDNet,” downloaded from http://www.zdnet.com/blog/btl/is-a-java-power- play-lurking-beneath-googles-open-handset-alliance/6900.

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.

/s/ Michael S. Kwun
Michael S. Kwun

3

**************************************
**************************************
**************************************
*************************************

KEKER & VAN NEST LLP
ROBERT A. VAN NEST - #84065
[email]
CHRISTA M. ANDERSON - #184325
[email]
[address, phone, fax]

KING & SPALDING LLP
SCOTT T. WEINGAERTNER (Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[email]
[address, phone, fax]

KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
[email]
CHERYL A. SABNIS - #224323
[email]
[address, phone, fax]

GREENBERG TRAURIG, LLP
IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
[email]
[address, phone, fax]

Attorneys for Defendant
GOOGLE INC.

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?
toString194184 Converts an object to a String.
equals 157149 Tests to see if two objects are equal.

2

hashCode 147139Creates a "Hash Code" (a numeric
representation) of a class.
run139121 Runs the code in the object
read96 Reads (typically to a stream of characters).
write94Writes (typically to a stream of characters)
remove8886Removes something (exactly what is
removed depends on the class).
get74Gets the value of an object
close 72Closes 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 by
roughly 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.

[signature]
Owen Astrachan

4

***********************************
***********************************
***********************************
**********************************
************************************

EXHIBIT 1

ROBERT A. VAN NEST - #84065
[email]
CHRISTA M. ANDERSON - #184325
[email]
KEKER & VAN NEST LLP
[address, phone, fax]

DONALD F. ZIMMER, JR. - #112279
[email]
CHERYL A. SABNIS - #224323
[email]
KING & SPALDING LLP
[address, phone, fax]

SCOTT T. WEINGAERTNER (Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[email]
KING & SPALDING LLP
[address, phone, fax]

IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
[email]
GREENBERG TRAURIG, LLP
[address, phone, fax]

Attorneys for Defendant
GOOGLE INC.

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

Honorable Judge William Alsup

OPENING EXPERT REPORT OF DR.
OWEN ASTRACHAN

TABLE OF CONTENTS

I. INTRODUCTION .................................................................................... 4

II. DOCUMENTS AND INFORMATION CONSIDERED ........................ 6

III. BRIEF SUMMARY OF MY OPINIONS................................................ 6

IV. BRIEF BACKGROUND ON JAVA........................................................ 8

V. DETAILED STATEMENT OF THE BASIS FOR MY
OPINIONS ON APIs.............................................................................. 10

A. What is an API?............................................................................ 15

B. Useful Analogies .......................................................................... 16

C. Purposes of an API....................................................................... 18

D. The Elements of an API ............................................................... 20

E. The Components of a Method Declaration .................................. 23 F. Organizing Related Methods into Packages ................................ 27

G. The Distinction Between An API and Its
Implementation............................................................................. 28

H. Sun and Oracle Also have Implemented and Distributed
APIs from Other Software............................................................ 35

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

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

3. Oracle Implemented and Distributed APIs from IBM as Part of the Oracle Database Server .................... 44

I. Basic Example of Java Method Usage......................................... 46

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

A. TimSort Files................................................................................ 83

B. Security Test Files........................................................................ 85

C. Comments in CodeSourceTest.java and
CollectionCertStoreParametersTest.java ..................................... 88

EXHIBIT A: OWEN ASTRACHAN CV

EXHIBIT B: DOCUMENTS AND INFORMATION REVIEWED

2

EXHIBIT C: EXCEL AND STAROFFICE SPREADSHEET

EXHIBIT D: LX_BRAND SYSCALL TABLE

EXHIBIT E: SOURCE CODE FOR SLOCCOUNTER.PY AND
SLOCCOUNTERTOTAL.PY

3

I. INTRODUCTION

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

17

operation function (the turn signals, steering wheel, etc.), the driver need not know how the engine, light bulbs, or transmission work.

C. PURPOSES OF AN API

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 Android source code that implements the "abs" method documented above is:2

32

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.org
Calc (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

http://hub.opensolaris.org/bin/download/ Community+Group+brandz/WebHome/brandzoverview.pdf.)

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.

javax.xml

The package javax.xml and its subpackages javax.xml.datatype, javax.xml.namespace, javax.xmlparsers, javax.xml.transform, javax.xml.transform.dom, javax.xml.transform.sax, javax.xml.transform.stream, javax.xml.validation, and javax.xml.xpath deal with XML--eXtensible Markup Language.

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:
java.awt.font

The package java.awt.font allows programmers to interact with low-level font information.

java.beans

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 From
Package
What is the
Functionality?
Why is it in this
Package?
HandshakeCompletedEvent javax/net/ssl A class describing an
event that takes place
once 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 an
event that takes place
when a Preference
Changes
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 an
event that takes place
when a Preference
Node 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 From
Package
What is the
Functionality?
Why is it in this
Package?
SSLSessionBindingEvent javax/net/ssl A class describing an
event that takes place
when 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 place
when an SQL RowSet
is changed.
Because this is an SQL
Rowset, it is grouped
with the otherSQL methods.
StatementEvent javax/sql A class describing an
event 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 From
Package
What is the
Functionality?
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.
LineNumberInputStreamjava/io Adds the ability to count
the 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 From
Package
What is the
Functionality?
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, so
this class is part of the
java/security
packages.

61

Class Name From
Package
What is the
Functionality?
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 of
Times
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).
get74 Gets the value of an object.
close 72 Closes a stream.
size 68 Returns a number of items in a collection
of items.
clear61 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:

Dalvik_java_lang_Class_desiredAssertionStatus
Dalvik_java_lang_Class_classForName
Dalvik_java_lang_Class_getClassLoader
Dalvik_java_lang_Class_getComponentType
Dalvik_java_lang_Class_getDeclaredClasses
Dalvik_java_lang_Class_getDeclaredConstructors
Dalvik_java_lang_Class_getDeclaredFields
Dalvik_java_lang_Class_getDeclaredMethods
Dalvik_java_lang_Class_getInterfaces
Dalvik_java_lang_Class_getModifiers
Dalvik_java_lang_Class_getNameNative
Dalvik_java_lang_Class_getSuperclass
Dalvik_java_lang_Class_isAssignableFrom
Dalvik_java_lang_Class_isInstance

67

Dalvik_java_lang_Class_isInterface
Dalvik_java_lang_Class_isPrimitive
Dalvik_java_lang_Class_newInstance
Dalvik_java_lang_Class_getSignatureAnnotation
Dalvik_java_lang_Class_getDeclaringClass
Dalvik_java_lang_Class_getEnclosingClass
Dalvik_java_lang_Class_getEnclosingConstructor
Dalvik_java_lang_Class_getEnclosingMethod
Dalvik_java_lang_Class_getGenericInterfaces
Dalvik_java_lang_Class_getGenericSuperclass
Dalvik_java_lang_Class_getTypeParameters
Dalvik_java_lang_Class_isAnonymousClass
Dalvik_java_lang_Class_getDeclaredAnnotations
Dalvik_java_lang_Class_getInnerClassName
Dalvik_java_lang_Class_setAccessibleNoCheck
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:

Name Originated in? Java equivalent What is it?
char At least C; see C Reference
Manual, Dennis Ritchie,
1975 (available at
http://www.cs.bell-
labs.com/who/drm/cman.pdf)
charA data type holding a
character; used repeatedly
in method names, such as
C++ "getchar" and Java
"getChars." Other data
types, 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:

Line # Code
1private static void rangeCheck(int arrayLen, int fromIndex, int toIndex) {
2if (fromIndex > toIndex)
3throw new IllegalArgumentException("fromIndex(" + fromIndex +
4") > toIndex(" + toIndex+")");
5if (fromIndex
6throw new ArrayIndexOutOfBoundsException(fromIndex);
7if (toIndex > arrayLen)
8throw new ArrayIndexOutOfBoundsException(toIndex);
9}

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:

AclEntryImpl.java
AclImpl.java
GroupImpl.java
OwnerImpl.java
PermissionImpl.java

85

PrincipalImpl.java
AclEnumerator.java
PolicyNodeImpl.java
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/

6 See changes at
http://android.git.kernel.org/?p =platform/libcore.git;a=commitdiff; h=6241c067e065065098eb50a7aef35a58f78447a6 and
http://android.git.kernel.org/?p=platform/ libcore.git;a=commitdiff;h= 95d52b3b1446af2fefd46f57efc1afb6c 679e8cc

7The removal is documented here: http://android.git.kernel.org/?p=platform/libcore.git;a=commitdiff;h=a49d9caee4cd74c0d2cf83d79b8ecdc00453dff8

8 See file history available at http://svn.apache.org/viewvc/ incubator/harmony/enhanced/classlib/trunk/ java-src/security2/test/common/unit/java/security/cert/CollectionCertStoreParametersTest.java ?limit_changes=0&view= markup&pathrev=367016.

9 See file history at http://android.git.kernel.org/?p=platform/ libcore.git;a=history;f=luni/src/test/java/ org/apache/harmony/security/tests/ java/security/CodeSourceTest.java; hb=a49d9caee4cd74c0d2cf83d79b8ecdc00453dff8

153

[ Note that attached are exhibits. Page 94-115 is Exhibit A, biographical materials for Dr. Astrachan.

EXHIBIT B: DOCUMENTS AND INFORMATION REVIEWED

a. Oracle’s First Amended Complaint

b. Google’s Answer to First Amended Complaint and Counterclaims

c. Oracle’s Supplemental Responses to Google’s Interrogatories, Set No. 1

d. The Android developer website at android.com

e. The Oracle Java websites at java.sun.com and java.oracle.com, including http://java.sun.com/docs/white/platform/ javaplatform.doc1.html, http://java.sun.com/docs/ books/jls/first_edition/html/index.html, http://java.sun.com/ docs/glossary.html

f. Source code, documentation, and discussion boards and blogs for Oracle’s implementation of the APIs at issue, including http://download.oracle.com/javase/5/docs/ index.html, http://download.oracle.com/javase/1.4/docs/ index.html, and http://markmail.org/thread/xwyxemce75vvz33h#query:+page:1+mid: vnipd7bqzs5vxfjw+ state:results

g. Source code and documentation for Android’s implementation of the APIs at issue, including http://developer.android.com/ reference/packages.html and http:// android.git.kernel.org/?p=platform/libcore.git;a=history;f= luni/src/test/java/org/apache/harmony/security/ tests/ja va/security/CodeSourceTest.java;hb= a49d9caee4cd74c0d2cf83d79b8ecdc00453dff8

h. Source code and documentation for Apache Harmony’s implementation of the APIs at issue, including http://svn.apache.org, http://harmony.apache.org/faq.html and

1

http://harmony.apache.org/subcomponents/classlibrary/compat.html

i. Source code and documentation for GNU Classpath’s implementation of the APIs at issue, including http://www.gnu.org/software/classpath/docs/

j. Wikipedia, Application programming interface, http:// en.wikipedia.org/w/index.php?title= Application_programming_interface&oldid=437864024 (as of July 13, 2011, 00:30 GMT)

k. Newton’s Telecom Dictionary, 25th Edition

l. Oracle SQL: The Essential Reference,” David C. Kreines (2000)

m. C Reference Manual, Dennis Ritchie, 1975, available at http://www.cs.bell-labs.com/who/dmr/cman.pdf

n. ZLib Manual, available at http://www.zlib.net/manual.html

o. Merriam-Webster Dictionary online

p. Dictionary.com

q. “Revised Report on the Algorithmic Language ALGOL 68”, available at http://www.fh-jena.de/~kleine/ history/languages/Algol68-RevisedReport.pdf

r. “The C Family of Languages: Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling,” Java Report, 5(7), July 2000, available at http://www.gotw.ca/publications/ c_family_interview.htm

s. “The Feeling of Java,” James Gosling, Computer, Vol. 30, Issue 6, June 1997

t. Mastering Regular Expressions, Jeffrey E. F. Friedl, O'Reilly and Associates, 1997

u. “Programming Techniques: Regular expression search algorithm,” Ken Thompson,

2

Communications of the ACM, Vol. 11, Issue 6, June 1968

v. “SEQUEL: A structured English query language,” Proc. ACM SIGFIDET Workshop, May 1974, pp. 249-264

w. JDBC 3.0 Specification, available at http://jcp.org/aboutJava/communityprocess/first/ jsr054/jdbc-3_0-pfd-spec.pdf

x. X/Open: Data Management: SQL Call Level Interface (CLI), available at http://pubs.opengroup.org/onlinepubs/009654899/toc.pdf

y. Linux kernel 2.4 source code as available at
http://git.kernel.org/?p=linux/kernel/git/stable/ linux-2.4.37.y.git, including
http://git.kernel.org/?p=linux/kernel/ git/stable/linux-2.4.37.y.git;a=blob;f=fs/proc/ array.c;h=335226246dcafa18864e87c2f7be68f48a50b924; h b=HEAD

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

aa. BrandZ documentation at
http://hub.opensolaris.org/bin/view/ Community+Group+brandz/WebHome and related web pages, including
http://hub.opensolaris.org/bin/download/ Community+Group+brandz/

3

WebHome/brandzoverview.pdf and
http://hub.opensolaris.org/bin/view/ Community+Group+brandz/design

bb. “Fuss, Futexes and Furwocks: Fast Userlevel Locking in Linux,” 2002, available at
http://kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf

cc. Futex(2) manual page, available at
http://www.kernel.org/doc/man-pages/online/pages/ man2/futex.2.html

dd. “Excel functions (by category),” http://office.microsoft.com/en-us/excel-help/excel- functions-by-category-HP005204211.aspx

ee. “Calc Functions listed by category,” http:// wiki.services.openoffice.org/wiki/Documentation/ How_Tos/Calc:_Functions_listed _by_category

ff. Visicalc Reference Card, available at
http://www.bricklin.com/history/refcard1.htm

gg. “Oracle® Database Application Developer's Guide - Fundamentals,”
available at http://download.oracle.com/docs/ cd/B14117_01/appdev.101/b10795/toc.htm

hh. “System R: relational approach to database management,” M. M. Astrahan et al; ACM Transactions on Database Systems; Vol. 1, Issue 2, June 1976.

4

[Exhibit C is a chart of similar spreadsheet function names in Microsoft Excel 2003 and Oracle Open Office Calc (Today), 11 pages.]

[EXHIBIT D: LX_BRAND SYSCALL TABLE, 13 pages.]

[EXHIBIT E: SOURCE CODE FOR SLOCCOUNTER.PY AND SLOCCOUNTERTOTAL.PY, 9 double pages.]

153


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )