|Oracle v. Google - Oracle's Unredacted Opposition to Motion for Summary Judgment & Expert Mitchell's Report - Copyright
Tuesday, September 13 2011 @ 08:30 AM EDT
Google has a pending motion for summary judgment 260 [PDF] on the issue of the copyright claims asserted by Oracle, which we first discussed here. The parties have been filing their respective positions on this motion starting with Google.
Although there are some other minor copyright issues, none of which should be problematic to Google on an on-going basis because they have removed the allegedly offending lines of code, the heart of the copyright dispute centers around
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.
Google argues that any similarity between these Android specifications and Oracle's Java specifications are unprotected by copyright because they relate to functional elements.
While Google makes other relevant arguments with respect to the alleged infringement (some, like their argument with respect to file naming, stronger than others, such as their arguments with respect to scenes a faire and fair use), this is the key argument on the issue of infringement.
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
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
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
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.
Oracle filed its initial response 339 [PDF] a few weeks later, which we discussed
here. Oracle asserts that the APIs are not purely functional. More specifically, Oracle claims its APIs "[c]ontain [m]any [o]riginal and [c]reative [e]lements. The Java APIs are the blueprint to the class libraries. They are not just a list of names and methods, but an extraordinarily complex structure of hierarchy and interdepency." But in this context Oracle is talking about all of the APIs in Java, not merely the 37 at issue here, and on that broad basis Oracle's claim may be true. Oracle almost seems to go out of its way to misconstrue Google's argument when it states:
No court has ever found that the APIs for a complex software platform like Java are ineligible for copyright protection. Google asks this Court to find that all application programming interfaces are uncopyrightable as a matter of law ─ regardless of their expressive content ─ because they are supposedly “methods of operation” that are simply “functional
requirements for compatibility.” (See, e.g., Google Mot. at 1, 13-14.) Google’s request is not just unprecedented, it is contrary to Ninth Circuit law, which calls for an examination of the particular facts of each case, to distinguish unprotectable ideas from copyrightable expression. The Java APIs that Google copied are complex, creative, and expressive. They are not simply dictated by functionality or compatibility requirements. They pass the test for copyrightability in this Circuit.
Google is in fact arguing that you need to look at these 37 specific APIs and determine whether they contain anything but functional elements. Google has never asserted that JAVA, in its entirety, is a work unprotected by copyright. Quite frankly, I had to laugh when I read this Oracle argument:
The burden is on Google to show the APIs it copied do not contain copyrightable expression because Oracle registered the copyrighted works at issue, which include the API specifications and the code.
This is absolutely wrong. The mere fact that you register a copyright in your work does not give rise to copyright protection in every line of code in your work. You still have to work your way through the work to eliminate that which is purely functional (or otherwise not protected by copyright) before determining whether copying has occurred.
Ten days later Google filed its reply to the Oracle response,
368 [PDF] which we discussed
here. The heart of that reply lies in this section:
C. The Java language APIs are methods of operation.
What Oracle has now filed is an unredacted version of its response and opposition to the motion for summary judgment on the issue of copyright. 396 [PDF] Although we reproduce the document and Dr. Mitchell's supporting declaration in their entirety below, the essential arguments in the earlier redacted version are the same, and quite frankly, in my opinion not made any stronger here.
The Java language APIs are the means by which developers can access the functionality
of the Java language libraries. They are, in a very literal sense, methods for operating portions of the only works that Oracle pleaded in its Amended Complaint, namely versions 1.4 and 5.0 of the Java 2 Standard Edition platform (the “Asserted Works”). The APIs define the precise
statements that must used for developers to access the functionalities in the Java language
libraries. The APIs are thus unprotectable methods of operating the Java language libraries.
17 U.S.C. § 102(b); see also PAUL GOLDSTEIN, GOLDSTEIN ON COPYRIGHT § 10.5.1 (3d ed. 2011) (courts have “categorically excluded copyright protection for interface specifications”).
1. Oracle repeatedly mischaracterizes the APIs in an attempt to show creative
Oracle repeatedly mischaracterizes the APIs, implying that they contain creative expression. Oracle is wrong.
expression where there is none.
According to Oracle, the APIs “tell” how to use the libraries. Opp. at 2:27. Oracle is
wrong. The APIs do not “tell” how to use the libraries, they are the means by which one uses the libraries; the documentation for the APIs “tells” how to use the libraries.
According to Oracle, the APIs are the “blueprint” for the libraries. Id. at 3:5-6. Oracle is
wrong. Unlike a blueprint, which states in detail how to build a structure, the APIs merely define
the functions that the libraries implement. The proper analogy would be to a summary building plan that identifies the rooms that are to be included and other functional requirements, but does
not describe implementation details. As Oracle’s expert acknowledges, the APIs are an
“abstraction.” Mitchell Decl., Ex. 2 ¶ 23.
According to Oracle, the APIs “describe” the fields and methods in the library classes.
Id. at 3:11. Oracle is wrong. The documentation might “describe” the fields and methods, but an API merely identifies the fields and methods that are included.
In short, the APIs are not the libraries themselves, and they do not “describe” or “tell”
how to operate the libraries. Instead, the APIs are the methods of operating the libraries. And, by definition, methods of operation are not creative expression within the meaning of the Copyright Act. See 17 U.S.C. § 102(b).
2. Oracle’s examples of “creativity” in the design of APIs are examples of form
following function, and thus militate against copyrightability.
Oracle argues that the design of good APIs requires skill and creativity, and that as a
result its APIs are copyrightable. But that is not the law: “Original and creative ideas . . . are not copyrightable . . . .” ATC Distribution Group, Inc. v. Whatever It Takes Transmissions & Parts,Inc., 402 F.3d 700, 707 (6th Cir. 2005) (citing 17 U.S.C. § 102(b)). Moreover, functional aspects of a work are not copyrightable. Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1524 (9th Cir. 1993) (citing 17 U.S.C. § 102(b)). The functional and factual aspects of a work may be copied, “as may those expressive elements of the work that ‘must necessarily be used as incident to’ expression of the underlying ideas, functional concepts, or facts.” Id. (quoting Baker v. Selden, 101 U.S. 99, 104 (1879)). Consistent with these core copyright principles, a work that is “largely functional” receives only weak protection under the Copyright Act. 977 F.2d at 1527.
The aspects of API design that Oracle points to in support of its claim of creativity all
focus on enhancing the functionality of APIs. Oracle argues that well-designed APIs are “easier to learn and use” (Opp. at 3:23-24), and “almost disappear from sight” (id. at 4:1, quoting
Swoopes Decl., Ex. 21). Oracle argues, in effect, that form follows function in well-designed
APIs. But designing for functionality is the very antithesis of creative expression.
Oracle argues that its selection of API elements is protected. Opp. at 12:23-25 (“If the
designer includes too little, the developers will not have the tools and flexibility they prefer. If
the designer includes too much, the APIs become overwhelming and difficult to use.”). These
arguments are immaterial because they do not make the APIs protectable. Determining what features are “must have” features may well require creative insights into the needs of programmers. Determining the point at which the cost of increasing difficulty of use outweighs the benefits of increased options may require refined judgment calls. But the feature set that results from this process is not a creative expression. Instead, it is a designer’s best guess at the optimal feature set for a product. Whether that notion is called an idea, a system, or a method of operation, it is not protected by copyright. See 17 U.S.C. § 102(b); see also Matthew Bender & Co., Inc. v. West Pub. Co., 158 F.3d 674, 682 (2d Cir. 1998) (finding “[t]he creative spark is missing where . . . the author made obvious, garden-variety, or routine selections . . . .”).
a. The selection of elements to include in a set of APIs is not
Oracle’s theory would lead to absurd results. If feature sets in software were copyrightable, then competitors could not include the same feature set in their software. Moreover, Oracle concedes that the Android class libraries do not include all of the Oracle API elements, and that Android includes many API elements that the Oracle APIs lack. See Opp. at 20:27-21:1. Thus, under Oracle’s theory, merely having a partially overlapping feature set would constitute infringement. Such a result would allow developers to misuse copyright to
claim monopoly control over entire product areas. This is precisely what the idea-expression
dichotomy, on which copyright law is premised, is designed to prevent.
Because the Java language APIs and their elements are functional, Google (and others)
could have freely implemented all of the Java language APIs. But those elements are functional
(and thus unprotectable) regardless of whether Google implemented all of them, or only some.
Google’s decision to implement only a subset of the APIs cannot transform those APIs into
protectable expression. Similarly, the presence in Android of additional APIs that are not part of
the Java platform cannot change the unprotectable nature of the Java language APIs, and does
nothing to detract from Google’s non-infringement argument. The Borland spreadsheet, for
example, included commands not present in the Lotus 1-2-3 spreadsheet. See Lotus v. Borland, 49 F.3d 807, 810 (1st Cir. 1995), aff’d by an evenly divided court, 516 U.S. 233 (1996).
Oracle also argues that “designing the appropriate structure” for a set of APIs results in
creative expression. Opp. at 12:17. Oracle claims that the structure “is critical to the
programmer,” and that, depending on the structure chosen, an API can be “your organization’s
biggest asset” or can “even turn your users toward your competitor.” Id. at 13:6-19. These arguments are irrelevant to copyrightability. Not everything of value or competitive advantage is protected by copyright. Copyright protection is limited to original and creative expression of the types eligible for protection under the Copyright Act.
b. The structure for a set of APIs is not copyrightable.
The structure chosen by the designers of Oracle’s APIs is functional, not creative
expression. To make use of the APIs, developers must know, among other things, the package, class, and subclass to which the methods belong; the parameters the methods take; the order of
the parameters; the fields the data structures use; and how those fields are arranged. All of those
features are necessary elements of the methods by which developers access the functionality in
the libraries. Astrachan Decl., Ex. 1 ¶¶ 129-33; Reply Astrachan Decl., Ex. 4 ¶ 26.
[Footnotes and paging removed.]
In summary, I offer these observations:
This last point has always been critical to Sun's business model around JAVA, and to my knowledge it has never been fully tested in court. This may be the time.
- The copyright infringement issue is ripe for summary judgment. There appears to be little, if any, dispute on the facts, only on the application of the law to those facts.
- This issue will turn principally on two points:
- whether the court finds the APIs specifically in dispute to be, ultimately, functional in character; and
- whether the copyright protection of a specification extends to an implementation of that specification.
MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
MARC DAVID PETERS (Bar No. 211725)
DANIEL P. MUINO (Bar No. 209624)
[address, phone, fax]
BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
[address, phone fax]
STEVEN C. HOLTZMAN (Bar No. 144177)
[address, phone fax]
DORIAN DALEY (Bar No. 129049)
DEBORAH K. MILLER (Bar No. 95527)
MATTHEW M. SARBORARIA (Bar No. 211600)
[address, phone, fax]
Attorneys for Plaintiff
ORACLE AMERICA, INC.
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
ORACLE AMERICA, INC.
Case No. CV 10-03561 WHA
ORACLE AMERICA, INC.’S
OPPOSITION TO GOOGLE’S
MOTION FOR SUMMARY
JUDGMENT ON COUNT VIII OF
Date: September 15, 2011
Time: 2:00 p.m.
Dept.: Courtroom 9, 19th Floor
Judge: Honorable William H. Alsup
TABLE OF CONTENTS
INTRODUCTION .................. 1
STATEMENT OF FACTS ............... 2
ARGUMENT .................... 8
I. GOOGLE’S WHOLESALE COPYING AND IMPLEMENTATION OF JAVA
CONCLUSION ............. 25
API SPECIFICATIONS IS COPYRIGHT INFRINGEMENT ............... 8
A. Ninth Circuit Law Requires An Analysis Of The Particular Expressive
II. GOOGLE AND ITS AGENTS LITERALLY COPIED MULTIPLE PROGRAMS,
Content Of A Copyrighted Computer Program ............... 9
B. Google Cannot Meet Its Burden Of Showing That The Java APIs Do Not
Contain Copyrightable Expression ................... 12
1. Copyright Law Protects the Original Expression in the Selection,
C. The Scenes A Faire And Merger Doctrines Do Not Apply Here - 16
Coordination and Arrangement Of the Java APIs ............... 12
2. Copyright Law Protects the Names of the Packages, Classes,
Interfaces, Fields, and Other Elements in the Java APIs ............ 14
D. Google Copied The APIs ............... 17
E. Google’s Copying Was Not Fair Use ............... 19
SOURCE CODE SECTIONS, AND COMMENTS ................. 23
TABLE OF AUTHORITIES
9, 16, 17
Apple Computer, Inc. v. Formula Int’l, Inc.,
725 F.2d 521 (9th Cir. 1984) ................... 10, 11
Apple Computer, Inc. v. Microsoft Corp. (“Apple I”)
35 F.3d 1435 (9th Cir. 1994) .................. 9
Atari Games Corp. v. Nintendo of America, Inc.,
975 F.2d 832 (Fed. Cir. 1992) ................. 20
Autoskill, Inc. v. Nat’l Educ. Support Sys., Inc.,
994 F.2d 1476 (10th Cir. 1993) ................ 14
Bateman v. Mnemonics,
79 F.3d 1532 (11th Cir. 1996) ................. 17
Baystate Techs. v. Bentley Sys.,
946 F. Supp. 1079 (D. Mass. 1996) ................ 17
Bean v. Littell,
669 F. Supp. 2d 1031 (D. Ariz. 2008) ............. 23
Biberro Sys., Inc. v. Colwell, Inc.,
893 F.2d 1104 (9th Cir. 1990) ............... 12
Boisson v. Banian, Ltd.,
273 F.3d 262 (2d Cir. 2001) ................. 15
Brown Bag Software v. Symantec Corp.,
960 F.2d 1465 (9th Cir. 1992) ................. 11
Campbell v. Acuff-Rose,
510 U.S. 569 (1994) ................ 19
CMAX/Cleveland, Inc. v. UCR, Inc.,
804 F. Supp. 337 (M.D. Ga. 1992) ............. 14, 15
Control Data Sys., Inc. v. Infoware, Inc.,
903 F. Supp. 1316 (D. Minn. 1995) ............ 16
Dream Games of Ariz., Inc. v. PC Onsite,
561 F.3d 983 (9th Cir. 2009) ............... 16
Eng’g Dynamics, Inc. v. Structural Software, Inc.,
26 F.3d 1335 (5th Cir. 1994) ................. 14
Exxon Shipping Co. v. Baker,
554 U.S. 471 (2008) ................... 10
Gen. Universal Sys., Inc. v. Lee,
379 F.3d 131 (5th Cir. 2004) ................ 11
Harper & Row Publishers, Inc. v. Nation Enters.,
471 U.S. 539 (1985) .................. 21, 22
Johnson Controls, Inc. v. Phoenix Control Sys., Inc.,
886 F.2d 1173 (9th Cir. 1989) ................. 9
Lotus Dev. Corp. v. Borland Int’l, Inc.,
49 F.3d 807 (1st Cir. 1995), aff’d by an evenly divided court,
516 U.S. 233 (1996) ................ 9, 10, 11, 17
Merchant Transaction Sys., Inc. v. Nelcela, Inc.,
2009 U.S. Dist. LEXIS 25663 (D. Ariz. Mar. 17, 2009) .............. 9, 15
Miller v. Facebook,
2010 U.S. Dist. LEXIS 61715 (N.D. Cal. May 27, 2010) ............. 9
Mitel, Inc. v. Iqtel, Inc.,
124 F.3d 1366 (10th Cir. 1997) .................. 11, 17
Newton v. Diamond,
388 F.3d 1189 (9th Cir. 2004) .............. 24, 25
Pye v. Mitchell,
574 F.2d 476 (9th Cir. 1978) ............... 18
Sega Enters., Ltd. v. Accolade, Inc.,
977 F.2d 1510 (9th Cir. 1993) ............. 19, 20, 22
Shaw v. Lindheim,
919 F.2d 1353 (9th Cir 1990) ........... 18
Sony Computer Entm’t, Inc v. Connectix,
203 F.3d 596 (9th Cir. 2000) ............. 19, 20
Swirsky v. Carey,
376 F. 3d 841 (9th Cir. 2001) ............. 12
Toro Co. v. R & R Prods. Co.,
787 F.2d 1208 (8th Cir. 1986) ............. 11
17 U.S.C. § 101 ............. 9, 10
17 U.S.C. § 102(b) .............. 10
17 U.S.C. § 106(1) ................ 17
17 U.S.C. § 107(1) ................... 19
37 C.F.R. § 202.3(b)(4)(A) .................. 23
1 Nimmer on Copyright § 2.03[D] ........... 11
3 Nimmer on Copyright § 13.05[A], at 13-72 ........... 21
4 Nimmer on Copyright § 13.03[B][a] ........... 18
The copying in this case is undisputed. Over a period of many months, Google employees
and contractors sat down and duplicated, line by line, the specifications for Oracle’s application
programming interfaces (“APIs”) for Java. When they were finished, they had reproduced
specifications for 37 APIs from Java’s core libraries that were identical, or nearly identical to
Oracle’s, and they had copied those specifications into Android code.
APIs are one of the most important aspects of a complex modern software program like
Java. The Java APIs, in particular, serve as the guide to, and set forth the structure of, an
extensive set of class libraries that provide developers with pre-packaged code they call upon
during their programming. The choice of what to include in the APIs and how to arrange them
requires creativity and skill. The 37 APIs contain thousands of different elements, arranged in a
unique structure, with many interdependent relationships. They readily meet the standard for
copyright protection. Google, in fact, claims copyright protection for its own APIs.
Google nonetheless urges the Court to hold that all APIs are not copyrightable as a matter
of law. No court has ever done so. Google’s request is contrary to Ninth Circuit law, which
provides that the copyrightability of the non-literal components of a computer program is to be
examined on the particular facts of each case.
Google also asks the Court to excuse its copying on the ground that it was required for
compatibility. But Google undermined the compatibility of Java. It took the APIs it wanted, to
attract developers to Android and gain market share quickly, and left those it did not 􀅆
fragmenting Java and its “write once, run anywhere” promise.
Google also engaged in line-for-line copying of Oracle’s source code, object code and
comments in 12 separate programs. Google says it should be given a pass, claiming the copying
is de minimis. It is not. Each program is entitled to protection as a separate work, and Google
copied a substantial portion of each – and in most cases the entire program. And when combined
with the copying of the APIs, Google’s copying is significant even for Java as a whole.
STATEMENT OF FACTS
Google’s motion does not dispute copyright ownership or that copying took place. And
the parties’ experts agree that copying the APIs had great value to Google – Google’s expert goes
so far as to say that Google’s copying was “essentially required.” (ECF No. 262-1, Astrachan
Ex. 1 ¶¶ 130-136.) But the parties dispute many other points, including: whether the APIs
contain copyrightable expression; the substantial similarity of the API specifications; the
significance of Google’s copying of the APIs and code; whether Google was required to copy the
APIs for compatibility purposes; whether Android should be considered a transformative use; the
impact on the potential market for and value of, Oracle’s copyrighted work; and the propriety of
Google’s conduct. These disputed issues preclude summary judgment.
The Importance of APIs and Class Libraries. The Java programming language has been
consistently ranked among the leading programming languages since its release in 1996.
According to one widely used index, Java has been the top programming language since at least
2002. (See Mitchell Decl. Ex. 1 (“Mitchell Opening Report”) ¶¶ 56-62.) There are over 6.5
million Java programmers worldwide. (See Swoopes Decl. Ex. 20,)
The Java platform’s success is in part due to the popularity of the Java programming
language. But along with the programming language, Sun developers wrote extensive, wellcrafted
APIs for many different functions. Another important factor in Java’s success has been
the “robust and elegant API specifications and class libraries that implement them.” (Mitchell
Decl. Ex. 2 (“Mitchell Opp. Report”) ¶ 20.) As Joshua Bloch, a former Sun engineer now
working for Google, who designed many of the Java APIs at issue, put it: “I find it very
rewarding to design great APIs and have people come to me years later and say, wow, you know,
the collections framework changed my life.” (Swoopes Decl. Ex. 1 at 92:13-23.)
The APIs in question support Java’s “class libraries.” The class libraries Sun wrote help
developers program more quickly and efficiently by enabling them to call upon certain prewritten
“classes,” so that they do not have to write them from scratch. (Mitchell Opening Report
¶¶ 51-52.) The APIs tell the programmer how to use the library, and include a set of names that
can be used to access different features of the library, together with conventions about their use.
Java’s class libraries include thousands of “methods” that are accessible through the APIs.
Java’s APIs and class libraries were designed to be extensive from the start. In 1996, for
example, the libraries were documented in a 1650 page book called The JavaTM Class Libraries:
An Annotated Reference. (Id. ¶ 51.) These libraries have been become even larger over time.
The APIs Contain Many Original and Creative Elements. The Java APIs are the
blueprint to the class libraries. They are not just a list of names and methods, but an
extraordinarily complex structure of hierarchy and interdepency.
The design of the Java APIs includes methods, and “method signatures,” which include
the parameters associated with the method. There are also, in many cases, “fields,” which are
structures for storing data. These methods and fields are organized into classes, and the classes
are organized into packages. For each class in the library, the API describes the fields and
methods within it and identifies those that are exposed to other classes. (See, e.g., id. ¶ 171;
Mitchell Opp. Report ¶¶ 20-28.) The API also defines the relationship of each class to other
classes and packages of classes. The API designer must decide which packages, classes, methods
and fields to include in the API, as well as the relationships and interdependencies among the
thousands of individual elements. (See id.)
Designing the APIs for a complex structure like the Java platform requires a great deal of
creativity and skill. In the words of Joshua Bloch: “API design is an art, not a science.”
(Swoopes Decl. Ex. 19. See also Ex. 1 at 235:3-20 (discussing “aesthetic” nature of API design).)
Robert Lee, the leader of Android’s core library development team, concurs that designing APIs
is “absolutely” a creative activity. (Ex. 3 at 13:9-14:11.) Many articles and books are dedicated
to the techniques and considerations involved in writing APIs. (Mitchell Opp. Report ¶¶ 6-9.) If
APIs are written well, they create a beneficial cycle. A well-designed API is easier to learn and
use, so developers will be more likely to adopt the platform and write more applications, creating
more appeal to the platform for end users, which in turn attracts more developers. (Id. ¶ 172.)
A recent article in “Communications of the ACM,” a pre-eminent journal, describes the
creative challenges in API design: “There seems to be something elusive about API design that,
despite years of progress, we have yet to master.” It continues:
Good APIs are hard. We all recognize a good API when we get to use one. Good
APIs are a joy to use. They work without friction and almost disappear from sight:
the right call for a particular job is available at just the right time, can be found and
memorized easily, is well documented, has an interface that is intuitive to use, and
deals correctly with boundary conditions.
(Swoopes Decl. Ex. 21, M. Henning, “API Design Matters,” Communications of the ACM,
Vol. 52 No. 5 at 46-47 (emphasis in original); Mitchell Opp. Report ¶ 6.)
Google Makes The Strategic Decision To Center Android On Java. Google decided that
Java was by far the best choice for Android. It knew that Android’s success would depend on
providing consumers with a wide variety of user-installable applications, many of which would
be developed by third parties. Allowing developers to program in Java would immediately give
Google access to millions of developers. (See, e.g., Ex. 10, GOOGLE-01-00025376 at 419
(“Strategy: Leverage Java for its existing base of developers”).)
Attracting a pre-existing developer community was all the more important to Google
because it was late to market and time was of the essence. (See Ex. 9, GOOGLE-01-00019529 at
530.) Google believed using Java would greatly shorten its time to market and “[d]ramatically
accelerates our schedule.” (Ex. 12, GOOGLE-14-00042244 at 246; Ex. 4 at 172:7-173:14, 176:5-177:11.) Copying the core Java APIs saved Google “an enormous amount of time.” (Mitchell
Opp. Report ¶ 80.) And Google’s expert opines that it would have been “very difficult for
Google” to persuade developers to switch to different APIs. (Astrachan Ex. 1 ¶ 135.)
Google Chooses To Base Its Android Platform On Java Without Taking A License.
Oracle offers to license developers to make their own independent implementations of the Java
API specifications provided they are fully compatible and do not fragment the platform. (See,
e.g., Swoopes Decl. Ex. 22; Ex. 27 at 21:14-22:13, 70:19-71:17.)
Google could have taken the standard license, or it could have negotiated to obtain a
special license. It did neither. Google recognized internally it had two alternatives to working
with Sun: abandon the work on “making Java central to our solution” and instead use the
Microsoft platform and the C# language, or “Do Java anyway and defend our decision, perhaps
making enemies along the way.” (Ex. 8, GOOGLE-01-00019527 at 527-528 (emphasis added).)
Google decided to roll the dice and push ahead with Java.
Google Copied The Java API Specifications. Google got down to work and began
implementing not only the Java programming language and overall “write once, run anywhere”
architecture, but also copying the core Java API specifications, including the 37 asserted here.1
Google admits that Android developers had access to the API specifications for Java 2
Standard Edition Version 5.0. (Ex. 7, Google Resp. to Pl.’s Req. for Admission No. 168.) Robert
Lee, the lead developer for the Android core libraries, testified that he “consulted Sun’s website
for the API specifications when doing the work for Google” and that he assumed Google’s
contractor, Noser Engineering, did as well. (Ex. 3 at 65:8-66:16.) Mr. Lee saw that there were
copyright notices on the specifications, but proceeded anyway, without consulting an attorney.
(Id. at 66:17-67:5.; see also Ex. 2 at 161:5-20.)
Google does not deny that it deliberately copied 37 APIs from Java’s core libraries. The
APIs are extensive. They include thousands of elements. When fully printed out, they extend to
more than 10,000 pages. (Swoopes Decl. ¶ 28.) When Google finished its copying, it proclaimed
on the Android developer website: “Android includes a set of core libraries that provides most of
the functionality available in the core libraries of the Java programming language.” (Ex. 26.)
Java and Android organize the 37 packages and classes identically. These 37 packages
have identical names and identical or nearly identical structures. (Mitchell Opening Report
¶ 203.) For example, in both Java and in Android, the package java.nio contains the same ten
classes, with identical names. (Id. ¶ 204.) Drilling down a level further into just one of these ten
classes, java.nio.IntBuffer, shows that of the 25 individual methods that are included, 24 are also
present in Android. Fifteen of the methods are identical, five make minor changes to the names
but are otherwise identical, and four merely add the keyword “final” but are otherwise identical.
(Id. ¶¶ 205-206; see also Exs. Copyright-A-D (side-by-side comparisons of 4 packages).)
Google does not deny that it intentionally chose its names and organizational structure to match
the Java APIs. (See Google Mot. at 16:15-22; Astrachan Ex. 1 ¶ 130.)
1 Oracle is not asserting infringement of 14 other packages that appear in both Java and
Android that were copied by Google because Oracle uses these packages under license from third
parties, or allows third parties to use these packages under permissive terms.
The Java API specifications also include explanatory comments describing each method.
Dr. Mitchell found that these comments are also substantially similar in two files in the Java and
Android documentation. (Mitchell Opening Report ¶ 207.) A side-by-side comparison is
included as exhibits E and F to Dr. Mitchell’s opening report. (See id. at Exs. Copyright-E-F.)
Android’s Source Code Is Derived From The Copied API Specifications. Google also
implemented the copied API specifications into Android source code. Google tries to downplay
the significance of this, acknowledging only that it copied the “names of packages and methods
and definitions.” (Google Mot. at 16:15-17.) In fact, Google copied the entire hierarchical and
organizational structure of the APIs into the Android source code.
Mr. Lee, Android’s lead core library developer, wrote in a 2008 document that he was
tasked with “re-implementing” the Java APIs. (Swoopes Decl. Ex. 14, GOOGLE-40-00034698.)
Mr. Lee testified that Google worked to “implement core libraries according to the Java APIs.”
(Ex. 3 at 14:7-11, 64:8-20, 65:8-66:16.) Google copied Java API specifications verbatim, or
nearly verbatim, into its source code and then included code that implemented what was called
for by the specification. (See Mitchell Opening Report ¶¶ 209-219.) Google repeated this
thousands of times, until it had replicated all, or nearly all, of the methods contained in the 37 API
specifications, in accordance with the same design. (Mitchell Opp. Report ¶ 77.) Instead of
determining for itself what to include in the APIs and class libraries, and their associated
interdependencies, Google simply copied the Java APIs and wrote code to carry out each of the
specified functions, saving an enormous amount of time. (Id. ¶ 80.) The source code derived
from the API specifications can also be found on Android devices, compiled into executable form
by Google and device manufacturers. (See Mitchell Opening Report ¶¶ 220-223.)
Google Literally Copied Oracle’s Source Code, Object Code and Comments. Two
Android source code files contain lines of code for a method called “rangeCheck” that are
identical to those in Oracle’s copyrighted java.util.Arrays.java program. (Mitchell Opening
Report ¶ 233.) The table below shows a side-by-side comparison:
Id. The author of Oracle’s Arrays.java code is former Sun engineer Joshua Bloch, who also wrote
the code for Android’s rangeCheck. (See Swoopes Decl. Ex. 1 at 39:3-5, 162:8-163:7, 174:1-12.)
When asked whether he accessed the Oracle source code while working on TimSort, Bloch
testified that there “is a strong indication that it is likely that I did.” (Id. at 181:7-14.)
Google copied Oracle’s copyrighted Java object code in 8 additional files in their entirety.
Using a decompiler, Google used the Java object code to generate source code for Android.
(Mitchell Opp. Report ¶¶ 89-90; Mitchell Opening Report ¶ 242.) The source code for these eight
Android programs is nearly identical on a line-by-line basis to files decompiled from Oracle files
JDK5, which is available for download from Oracle’s website. (Mitchell Opening Report ¶¶ 241-
243, Exs. Copyright-J-Q (side by side comparison of 8 files).
Google does not dispute the copying. But the parties have a factual dispute over its
significance. Google’s expert, Dr. Astrachan, states that the 8 copied files are insignificant “test”
files that are in part “dummy files.” (Astrachan Ex. 1 ¶¶ 163-165.) Oracle’s expert, Dr. Mitchell,
compared these files to the Oracle code and concluded they are not simply dummy test files. The
Oracle code is not in the “test” portion of Oracle’s directories. To the extent Google does them
for testing, test files are significant too. (Mitchell Opp. Report ¶¶ 91-95.)
The copying did not stop there. Two more Android files contain a series of comments that
are nearly identical to comments in corresponding Java files. (Mitchell Opening Report ¶ 249.)
The comments are compared side-by-side at Mitchell Opening Report Exhibits Copyright R-S.
Android Gained Rapid Market Acceptance At Oracle’s Expense. Google’s strategy of
centering Android on Java has been phenomenally successful. Android’s share of the U.S.
Smartphone market has jumped from just below 4% in Q4 ’09, a year after its release, to about
30% of the market by early 2011. (See Mitchell Opening Report ¶¶ 70, 72-73.)
Google’s success has come at Oracle’s expense. Oracle’s Chief Corporate Architect,
Edward Screven, testified that “Android has basically foreclosed” Oracle’s strategy for
succeeding in the Smartphone market and that Java is “pretty well locked out of the smartphone
market because of Android.” (Swoopes Decl. Ex. 6 at 71:13-72:4, 111:10-112:2.)
In addition, Oracle has been harmed because Google fragmented the Java APIs, severely
undercutting Java’s “write once, run anywhere” promise. Though Google copied 37 Java APIs
from Java’s core libraries, there were many other APIs it did not implement. Despite its claim
that its copying was required for compatibility, the reality is Google took only the parts it wanted
and created many other, incompatible APIs for Android. As a result, many programs written in
Java for other platforms will not run on Android, and many programs written for Android will not
run on Java platforms and devices. (See Mitchell Opp. Report ¶¶ 101-113.)
Notably, Google requires its OEMs to maintain the full set of Android APIs – including
the 37 APIs it copied from Oracle - to prevent fragmentation of the Android platform. Android’s
license is similar to Java’s providing, among other things, that “[d]evice implementations MUST
NOT omit any managed APIs,” “MUST NOT modify the publicly exposed APIs on the Android
platform,” and “MUST NOT add any publicly exposed elements…to the APIs.” (Mitchell Opp.
Report ¶ 115.) Google itself, of course, has done all of these things to the Java APIs.
I. GOOGLE’S WHOLESALE COPYING AND IMPLEMENTATION OF
JAVA API SPECIFICATIONS IS COPYRIGHT INFRINGEMENT.
No court has ever found that the APIs for a complex software platform like Java are
ineligible for copyright protection. Google asks this Court to find that all application
programming interfaces are uncopyrightable as a matter of law - regardless of their expressive
content - because they are supposedly “methods of operation” that are simply “functional
requirements for compatibility.” (See, e.g., Google Mot. at 1, 13-14.) Google’s request is not just
unprecedented, it is contrary to Ninth Circuit law, which calls for an examination of the particular
facts of each case, to distinguish unprotectable ideas from copyrightable expression. The Java
APIs that Google copied are complex, creative, and expressive. They are not simply dictated by
functionality or compatibility requirements. They pass the test for copyrightability in this Circuit.
A. Ninth Circuit Law Requires An Analysis Of The Particular Expressive
Content Of A Copyrighted Computer Program.
Computer software is expressly subject to copyright protection. 17 U.S.C. § 101.
“[C]opyright protection extends not only to the ‘literal’ elements of computer software – the
source and object code – but also to a program’s nonliteral elements, including its structure,
sequence, organization, user interface, screen displays and menu structures.” Merchant
Transaction Sys., Inc. v. Nelcela, Inc., No. CV 02-1954, 2009 U.S. Dist. LEXIS 25663, at *29
(D. Ariz. Mar. 17, 2009) (quoting Gen. Universal Sys., Inc. v. Lee, 379 F.3d 131, 142 (5th Cir.
2004)). The Ninth Circuit does not automatically disqualify any of these elements of software
from copyright protection. To the contrary, the Ninth Circuit has held:
Whether the nonliteral components of a program, including the structure, sequence
and organization and user interface, are protected depends on whether, on the
particular facts of each case, the component in question qualifies as the expression
of an idea, or an idea itself.
Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2d 1173, 1175 (9th Cir. 1989).
In analyzing the “particular facts,” the Ninth Circuit stated in Apple Computer, Inc. v.
Microsoft Corp. (“Apple I”) that “[u]sing analytic dissection and, if necessary, expert testimony,”
the court should separate protectable expression from unprotectable ideas to determine whether a
work is entitled to copyright protection. 35 F.3d 1435, 1443 (9th Cir. 1994).
This Court has recognized that, “[T]he scope of protection given to copyrighted software
is still a developing area of law.” Miller v. Facebook, No. C 10-00264 WHA, 2010 U.S. Dist.
LEXIS 61715, at *13 (N.D. Cal. May 27, 2010). Google would have the Court skip analysis of
whether the APIs contain copyrightable expression, and instead hold that APIs are not eligible for
copyright protection because they are “unprotectable methods of operation.” (See Google Mot. at
13-14.) Google’s argument relies on the First Circuit’s approach in Lotus v. Borland, suggesting
that, even if code is expressive, it is unprotectable if it can be characterized as a “method of
operation.” The Ninth Circuit has never adopted Lotus’ approach, and other circuits have refused
to follow it. Moreover, Lotus is factually distinguishable.
Lotus addressed the copyrightablity of the menu in Lotus 1-2-3. See Lotus Dev. Corp. v.
Borland Int’l, Inc., 49 F.3d 807 (1st Cir. 1995), aff’d by an evenly divided court, 516 U.S. 233
(1996).2 “Accepting” the district court’s finding that Lotus made expressive choices in designing
the menu, the court concluded nonetheless that the menu was uncopyrightable because it was a
“method of operation” under 17 U.S.C. § 102(b). Id. at 816. The court defined “method of
operation” broadly, as “the means by which a person operates something.” Id. at 815.
The Lotus court’s definition of an unprotectable “method of operation” is perilously close
to the definition of a computer program under the Copyright Act, which “is a set of statements or
instructions to be used directly or indirectly in a computer in order to bring about a certain result.”
17 U.S.C. § 101. The exception proposed by Lotus threatens to swallow the rule whole.
In Apple Computer, Inc. v. Formula Int’l, Inc., 725 F.2d 521, 523-24 (9th Cir. 1984), the
Ninth Circuit rejected the argument that computer operating systems programs - programs
“designed to manage the computer system” - are uncopyrightable because they are only “ideas”
or “processes” under 17 U.S.C. § 102(b). Examining the Copyright Act and its legislative
history, the court upheld the district court’s finding that the Copyright Act “extends protection to
all computer programs regardless of the function which those programs perform.” Id. at 523.
The Ninth Circuit cited to the Final Report of the National Commission on New
Technological Uses of Copyright Works (CONTU), which “was established by Congress to
consider, inter alia, to what extent computer programs should be protected by copyright law,” and
whose recommended statutory changes were adopted “verbatim” by Congress:
The copyright status of the written rules for a game or a system for the operation
of a machine is unaffected by the fact that those rules direct the actions of those
who play the game or carry out the process. Nor has copyright been denied to
works simply because of their utilitarian aspects. . . .
2 The affirmance of a decision by an equally divided Supreme Court is not precedential.
See Exxon Shipping Co. v. Baker, 554 U.S. 471, 484 (2008).
That the words of a program are used ultimately in the implementation of a
process should in no way affect their copyrightability.
Id. at 524 (quoting CONTU Report at 21 (emphasis in Ninth Circuit opinion)). See also Toro
Co. v. R & R Prods. Co., 787 F.2d 1208, 1210-11 (8th Cir. 1986) (citing House Report);
1 Nimmer on Copyright § 2.03[D] (same).
Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997), the only other case Google cites
in support of its “method of operation” argument, explicitly rejects the Lotus approach. (Google
Mot. at 13:26-14:8.) After discussing the Lotus decision at length, the Tenth Circuit stated:
We conclude that although an element of a work may be characterized as a method
of operation, that element may nevertheless contain expression that is eligible for
copyright protection. Section 102(b) does not extinguish the protection accorded a
particular expression of an idea merely because that expression is embodied in a
method of operation at a higher level of abstraction.
Mitel, 124 F.3d at 1372. The court went on to analyze whether the plaintiff’s 4-digit code
hardware interface contained original, protectable expression and concluded it did not. Id. at
1373-76; see also Brown Bag Software v. Symantec Corp., 960 F.2d 1465, 1477 (9th Cir. 1992)
(suggesting “screens, menus and keystrokes” may be copyrightable); Gen. Universal, 379 F.3d at
142 (stating “menu structures” are copyrightable).
The Lotus case is also factually distinguishable. It concerned a consumer-friendly set of
50 menus with a simple hierarchy. 49 F.3d at 809. This type of simple user menu cannot
compare to the Java APIs, which are “designed for programmers and are designed to provide and
describe a very rich development environment.” (Mitchell Opp. Report ¶ 18.) They contain
thousands of elements, layers of complex interdepencies, data structures, and numerous
expressive choices that are not dictated by function.
Moreover, even under the Lotus definition, the APIs are not “methods of operation”
because a fundamental purpose of the APIs is not just to call a function, but to “impose a level of
abstraction and structure on top of the underlying software development program” to help
programmers understand its complexities. (Id. ¶ 23.) The computer does not care about this
organizational structure. But humans need some form of order to handle complex programming
tasks and work efficiently. (Id.) As Dr. Mitchell explains, “Some of today’s software systems
are among the most complex artifacts ever created by man, and the use of APIs is the core
structuring concept that software designers use to manage their complexity.” (Id. ¶ 18.) They
cannot be dismissed as “non-expressive” methods of operation.
B. Google Cannot Meet Its Burden Of Showing That The Java APIs Do
Not Contain Copyrightable Expression.
The burden is on Google to show the APIs it copied do not contain copyrightable
expression because Oracle registered the copyrighted works at issue, which include the API
specifications and the code. (See Swoopes Decl. Ex. 18.) “In judicial proceedings, a certificate
of copyright registration constitutes prima facie evidence of copyrightability and shifts the burden
to the defendant to demonstrate why the copyright is not valid.” Biberro Sys., Inc. v. Colwell,
Inc., 893 F.2d 1104, 1106 (9th Cir. 1990); see also Swirsky, 376 F.3d at 851 (“Because [the work]
has a valid certificate of registration with the copyright office…[plaintiff] is entitled to a
presumption of originality.”). Google cannot meet this burden.
Copyright law protects expression in software design, including the selection and structure
of software elements. Google’s motion glosses over this issue, but selecting what to include in an
API, and designing the appropriate structure to contain it, takes a great deal of creativity and skill.
1. Copyright Law Protects the Original Expression in the
Selection, Coordination and Arrangement Of the Java APIs.
The purpose of the Java APIs is to provide developers with access to prewritten code in
various areas to save them the time of having to write the code themselves. The APIs need not
include any particular method, class or package (with the exception of a few classes closely tied
to the Java language) for the Java language to function. (Mitchell Opp. Report ¶ 20.) The
decision to include these elements is therefore not dictated by function, and allows for a great deal
of creativity. If the designer includes too little, the developers will not have the tools and
flexibility they prefer. If the designer includes too much, the APIs become overwhelming and
difficult to use. (Id. ¶ 21.)
This creative process extends from the big decision of which packages and classes to
include all the way to how many parameters to include with a particular method and what order to
list them in. For example, the Java APIs provide six versions of the method java.lang.Runtime
exec() that differ only in their parameter lists. (Mitchell Opening Report ¶¶ 185-186.) While
giving developers as many parameters as possible provides for greater flexibility, often the better
choice is to establish a set order and limit the options. (Mitchell Opp. Report ¶ 22.) The API
designer must make this type of creative choice at every level of the API.
In addition, the complex organizational structure of the API, while not important to the
computer, is critical to the programmer. A key design choice is which classes of objects will
inherit characteristics from others. Java classes are arranged hierarchically, so that a subclass
may inherit characteristics from its parent. The API designer must choose this hierarchical
structure and decide whether a class will be independent or should be defined from or exposed to
another class. Classes can also call on other classes outside of their hierarchical structure. There
are even more complicated types of interrelationships in the Java APIs. One example is an
internal construct called Interface, which is essentially a form of class that relies on other classes
to implement its objects. (Id. ¶ 19.) Interfaces are often used to “group classes that are similar in
some respect but need not share implementation.” (Id. ¶¶ 23-27.) Another important design
feature of the APIs is “fields,” which store data associated with the class, and which can
themselves be made accessible to other methods or classes. (Id. ¶ 19.)
These design choices have important implications. As one author explains, “A welldesigned
API can be your organization’s biggest asset. Conversely, a poor API can create a
support nightmare and even turn your users toward your competitor.” (Swoopes Decl. Ex. 17,
M. Reddy, API Design for C++ 4 (2011). See also Mitchell Opp. Report ¶ 25.)
These design choices are handled differently by different API designers. Even for ideas
such as storing and manipulating collections of data as a single unit - ideas common across many
programming platforms - there are many expressive choices. (See Mitchell Opening Report
¶¶ 193-199.) The collections hierarchies for Java, C++, and Smalltalk, for example, all of which
have the same purpose, follow very different organizational schemes and use different language
to describe their elements, as is illustrated pictorially in Exhibit 4 to the Mitchell Declaration.
(Id.; see also Mitchell Decl. Ex. 4 (comparative diagram).) The differences between the
collections hierarchies represent the different expressive choices made by the API designers.
Google has cited no decision holding that the structure of a computer program with this
level of complexity and interdepency is precluded from copyright protection. Decisions have,
however, recognized the copyrightability of programs with much simpler structures. For
example, in Autoskill, the Tenth Circuit upheld a district court’s finding of likelihood of success
on copyrightability of the “organization, structure and sequence” of a computer program
designed to teach reading skills, including a “keying procedure” that required students to respond
by pressing the 1, 2 or 3 keys. Autoskill, Inc. v. Nat’l Educ. Support Sys., Inc., 994 F.2d 1476,
1492, 1495 n. 23 (10th Cir. 1993). Similarly, in CMAX/Cleveland, Inc. v. UCR, Inc., 804 F.
Supp. 337, 355 (M.D. Ga. 1992), the court held that the file structures for a software program
design for companies in the “rent to own” business constituted copyrightable expression. See
also Eng’g Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335, 1345-46 (5th Cir. 1994)
(rejecting argument that input data formats in structural engineering software program did not
contain original expression because they were purportedly “organized in a particular fashion to
effectuate the performance of mathematical calculations”).
Google understands the creativity and importance of APIs. It asserts copyright and other
intellectual property rights over its own APIs. (Swoopes Decl. Exs. 23-25.) These rights were
applied for and maintained during the tenure of long time Google CEO and current Chairman Eric
Schmidt. Google quotes extensively from Mr. Schmidt’s 1994 testimony advocating against
copyrightability, identifying him only as the “Sun CTO.” (See, e.g., Google Mot. at 1.) As this
shows, there is a distinction between what a person advocates the law should be and what it is.
Oracle is also entitled to copyright protection in the names of the many different elements
that make up the Java APIs. Google argues there is no copyright protection in the thousands of
names it copied by pointing to isolated examples. (Google Mot. at 17:16-19:2.) This cannot
defeat the presumption that the names in the Java API specifications are original. See Swirsky,
376 F.3d at 851. Google’s copying of the names of 37 packages, 458 classes, 158 Interfaces,
2. Copyright Law Protects the Names of the Packages, Classes,
Interfaces, Fields, and Other Elements in the Java APIs
2,427 methods, 893 fields, and other elements (see Purdy Decl. Ex. A, Purdy Opening Report
¶¶ 13-17) did not come about due to the existence of limited language.
Dr. Mitchell has provided numerous counterexamples of names that are not dictated by
compatibility or programming practices. (See, e.g., Mitchell Opp. Report ¶¶ 40-41 (describing
java.beans.Customizer, java.beans.Introspector and other examples).) Java’s API designers often
chose names according to style rules they themselves created, but frequently departed from those
rules, choosing names for aesthetic reasons. (Id.; see also Mitchell Opening Report ¶¶ 179-187.)
Google cites Merchant for the proposition that “isolated field names” are not entitled to
individual protection. (Google Mot. at 17:22-26 (quoting Merchant, 2009 U.S. Dist. LEXIS
25663, at *44).) But in that case the court denied summary judgment, holding that “the
coordination, selection, and arrangement of these field names, as well as the fields and field types
themselves . . . may be entitled to protection as a compilation so long as they ‘are numerous
enough and their selection and arrangement original enough that their combination constitutes an
original work of authorship.” Merchant, 2009 U.S. Dist. LEXIS 25663, at *46 (citation omitted).
Similarly, in CMAX/Cleveland, the plaintiff accused the defendant of copying file layouts
and file names, among other elements. 804 F. Supp. at 337. After trial, the court ruled for the
plaintiff, rejecting the argument that “the programs are only similar in their file names and the
sequence of the field names within each file,” holding that “selection and arrangement of the field
definitions within the files . . . are the expression of an idea.” Id. at 354. The selection and
arrangement of the fields in the Java APIs are likewise expressive.
Applying the kind of microscopic focus Google does here would “result in almost nothing
being copyrightable because original works broken down into their composite parts would usually
be little more than basic unprotectable elements like letters, colors and symbols.” Boisson v.
Banian, Ltd., 273 F.3d 262, 272 (2d Cir. 2001). Google’s expert engages in just such an analysis,
trying to calculate the average word length of 7,796 method names to claim they are not original.
(See Astrachan Ex. 1 ¶ 114.) Claiming there is no originality in the selection of almost 8000
names borders on absurd. That is particularly true since, in the Ninth Circuit, “[a]ll that is needed
to satisfy originality is for the author to contribute ‘something more than a merely trivial
variation.’” Swirsky, 376 F.3d 841 at 851 (internal citation and quotation omitted).
Moreover, even if this Court were to find that some of Google’s cherry picked examples
of names are unoriginal, “a claim of copyright infringement can be based on infringement of a
combination of unprotected elements.” Dream Games of Ariz., Inc. v. PC Onsite, 561 F.3d 983,
988 (9th Cir. 2009). At a minimum, the issue of whether the thousands of names that Google
copied were original is a triable issue of fact. See id. (triable issue as to originality of song).
C. The Scenes A Faire And Merger Doctrines Do Not Apply Here.
Google misapplies the scenes a faire and merger doctrines. The merger doctrine provides
that when there are so few ways of expressing an idea that “an idea and its expression are
indistinguishable, or ‘merged,’ the expression will only be protected against nearly identical
copying.” Apple I, 35 F.3d at 1444 (citations omitted). The “closely related” scenes a faire
doctrine provides that when certain features are “as a practical matter indispensable, or at least
standard, in the treatment of a given [idea], they are treated like ideas and are therefore not
protected by copyright.” Id. (internal quotation and citations omitted).
Neither doctrine applies here. The API designer has great liberty to choose what to
include in the APIs; it is not necessary to include any particular method, field, class or package.
(Mitchell Opp. Report ¶ 20.) The API designer also is at complete liberty to choose how to
structure the APIs, because that is designed for the benefit of the programmer. (Id. ¶ 23.)
Google cannot claim all the features of the APIs are “as a practical matter indispensable” or that
the idea behind the APIs and the myriad ways of expressing them are “merged.”
Google nonetheless argues that 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.” (Google Mot. at 15.) But Google’s scenes a faire argument is backwards. The
proper test under scenes a faire or merger is whether Oracle was constrained in its choice of
design because of the need to be compatible with some other product or standard, not Google.
See Control Data Sys., Inc. v. Infoware, Inc., 903 F. Supp. 1316, 1323 (D. Minn. 1995) (question
is whether external factors limited choices available to plaintiff’s programmers, not defendant’s).
Google argues the APIs are not expressive because it decided to copy certain features
from them in order to be compatible. (Google Mot. at 16). But Google’s choice to copy does not
alter the APIs’ expressive nature. Google cites the lower court’s decision in Mitel, holding that
the defendant’s copying was justified by “efficiency reasons” and “dictated by external factors”
because its technicians were used to the plaintiff’s code. (Id.) But in upholding the lower court’s
decision for other reasons, the Tenth Circuit chastised the court for incorrectly applying the law,
stating that the proper focus “should have remained upon the external factors that dictated
[plaintiff’s] selection of registers, descriptions, and values,” rather than on whether external
factors “justified [defendant’s] copying.” Mitel, 124 F.3d at 1375.
Baystate Techs. v. Bentley Sys., 946 F. Supp. 1079 (D. Mass. 1996) does take Google’s
approach, but cannot be squared with Ninth Circuit law on the scenes a faire and merger doctrine.
See Apple I, 35 F.3d at 1444. Moreover that court is in the First Circuit, and was bound by the
Lotus decision. Just as importantly, Baystate, and the other case Google cites, Bateman v.
Mnemonics, 79 F.3d 1532 (11th Cir. 1996), are factually distinguishable. Baystate involved a
much simpler data translator that converted between different file formats, thus requiring an
identical data organization to plaintiff’s program. See 946 F. Supp. at 1088. Bateman involved
reverse engineering to create a new platform that was compatible with preexisting hardware and
applications. See 79 F.3d at 1540. Google did not need to copy the APIs for compatibility with
Java, nor did it do so. Rather, Google took the APIs it wanted and wrote its own in place of the
rest, destroying compatibility through fragmentation. Bateman held that any finding relating to
compatibility “will depend on the particular facts of a case,” and remanded the district court’s
decision so that a jury could consider whether compatibility constrained expression. 79 F.3d at
1547 n.32 (11th Cir. 1996). Notably, the court held: “It is an incorrect statement of the law that
interface specifications are not copyrightable as a matter of law.” Id. at 1547.
D. Google Copied The APIs.
Google does not dispute that it copied the 37 Java API specifications into Android’s API
specifications. This violated Oracle’s reproduction right. See 17 U.S.C. § 106(1). It then created
a derivative work by deliberately copying the API specifications into the Android source code,
following their complex design to the letter. (See Swoopes Decl. Ex. 3 at 14:7-11, 65:8-66:16,
64:8-20; Mitchell Opening Report ¶¶ 209-29; Mitchell Opp. Report ¶¶ 77-81.) 17 U.S.C. §§ 101,
Google claims that “some” of the Android core libraries “were in part derived” from
Apache Harmony, an open source project. (Google Mot. at 5:14-6:8.) Even if true, they were
also derived from Oracle. Android’s lead core library developer has admitted that he “consulted
Sun’s website for the API specifications when doing the work for Google.” (See Swoopes Decl.
Ex. 3 at 65:8-66:16; see also Ex. 2 at 161:12-20.) In addition, Google was well aware of Sun and
Apache’s highly publicized dispute over whether Harmony code would be licensed for use in
mobile devices, and so could not have believed using the Harmony code gave it any kind of
mobile device license from Sun. (See, e.g., Ex. 1 at 119:13-122:4.) But it does not matter in any
event. A defendant is liable when he copies, with or without a license, from a third party who
copied from the plaintiff. See, e.g., Pye v. Mitchell, 574 F.2d 476, 481 (9th Cir. 1978).
Google argues the standard of comparison should be “virtual identity” because the range
of protectable expression is “narrow.” (Google Mot. at 12:3-5 (quoting Apple I, 35 F.3d at
1439).) But the Java APIs have many highly creative and expressive elements and are not
dictated by function. The appropriate standard is accordingly “substantial similarity.”
Oracle prevails under either standard. Google copied the 37 Java API specifications
verbatim or nearly verbatim, incorporating their same hierarchical structure. (See Mitchell
Opening Report ¶¶ 200-208, Exs. Copyright-A-F.) Google apparently disputes the substantial
similarity between the specifications. (See Google Mot. at 24.) If Oracle presents “‘indicia of a
sufficient disagreement concerning the substantial similarity of [the] two works,’ then the case
must be submitted to a trier of fact.” Swirsky, 376 F.3d at 844. The expert testimony and
documentation submitted by Oracle in support of this opposition more than satisfy that standard.
Google also gets the law wrong, comparing the copyrighted works with Android as a
whole. (See Google Mot. at 24-25.) It does not matter what else Google added. “No plagiarist
can excuse the wrong by showing how much of his work he did not pirate.” Shaw v. Lindheim,
919 F.2d 1353, 1362 (9th Cir 1990) (quoting 4 Nimmer on Copyright § 13.03[B][a])).
E. Google’s Copying Was Not Fair Use.
Google’s copying cannot be excused as fair use. At best, Google’s defense raises material
questions of fact that cannot be decided on summary judgment.
Google’s fair use argument relies heavily on the Ninth Circuit’s decisions in Sony and
Sega - two cases with very different facts that raise very different policy concerns. The focus of
the court’s inquiry in both cases was whether it was fair use to reverse engineer a copyrighted
product where “disassembly is the only way to gain access to the ideas and functional elements
embodied in a copyrighted [work].” See Sega Enters., Ltd. v. Accolade, Inc., 977 F.2d 1510,
1527-28 (9th Cir. 1993); Sony Computer Entm’t, Inc v. Connectix, 203 F.3d 596, 603-04 (9th Cir.
2000). But here, Oracle’s APIs were in plain view for anyone to see, so there was no need to
copy them to discover their functional elements.
Another key to both decisions was that they concern intermediate copying only. The final
product was not alleged to infringe the copyright. See Sega, 977 F.2d at 1527-28; Sony, 203 F.3d
at 604 n.7. As the Ninth Circuit noted in Sega, “[o]ur conclusion does not, of course, insulate
[defendant] from a claim of copyright infringement with respect to its finished products.” 977
F.2d at 1528. Here, of course, Oracles accuses the final Android APIs and code of infringement.
The reasoning in Sega and Sony does not apply. The four statutory factors are discussed below.
Purpose and Character of Use – An express part of this first factor, which Google fails
to address, is “whether [the] use is of a commercial nature or is for nonprofit educational
purposes.” 17 U.S.C. § 107(1). (See Google Mot. at 19-20.) Google’s use is clearly commercial.
This “tends to weigh against a finding of fair use.” Campbell v. Acuff-Rose, 510 U.S. 569, 585
(1994) (citation omitted).
Citing Sony, Google argues that this factor nonetheless weighs in its favor because
Android was a new smartphone platform so its work is “transformative.” It is not. The relevant
inquiry is whether the use “merely supersedes the objects of the original creation, or instead adds
something new, with a further purpose or differing character, altering the first with new
expression, meaning or message.” Campbell, 510 U.S. at 579. In Sony, even though the
defendant’s product allowed users to play games designed for the Sony Playstation on a different
medium – the personal computer – the court found the work to be only “modestly
transformative.” 203 F.3d at 606. Google copied the Java APIs to use them the same way Oracle
does by licensing an operating system to computer and mobile device manufacturers. The use has
no transformative value. But if it has any at all, it is even less than the “modest” value in Sony.
When the allegedly transformative nature of Android is weighed against commercial use,
this case comes out on the opposite side from Sony. In Sony, the Ninth Circuit concluded that the
modestly transformative use was not outweighed by the fact that the use was commercial
because: (1) there was no copyright infringement in the final product, so commercial use was
only “indirect or derivative” and (2) it produced a product that “would be compatible” with Sony
Playstation games. Id. at 607 (quoting Sega, 977 F.2d at 1522). Neither factor is present here.
First, the final product infringes here, so commercial use is not “indirect or derivative.”
See Atari Games Corp. v. Nintendo of America, Inc., 975 F.2d 832, 843 (Fed. Cir. 1992) (fair use
copying “must not exceed what is necessary to understand the protected elements” and “does not
justify extensive efforts to profit from replicating expression”) (applying Ninth Circuit law).
Second, unlike in Sega and Sony, Google did not need to copy to achieve compatibility,
and did not produce a compatible product. In Sega and Sony the only way for defendants’
programs to run was to copy the manufacturer’s functional interface. See, e.g., Sega, 977 F.2d at
1515 (need to input four letter initialization code). Here, Google could have used the Java
language without copying Oracle’s APIs. With the exception of a very few classes, the Java APIs
are not required to use Java at all. (Mitchell Opp. Report ¶¶ 57-60.) There are many examples of
individuals or organizations writing their own APIs for other languages, like C++, as well as for
Java. Google could have written its own APIs, and the proof of that is that Google did. Google
wrote new APIs for the Android user interface, and many other new packages. (See id. ¶¶ 61-68,
101-113; Google Mot. at 25 (only “about one-quarter” of APIs were copied).)
This case is not about Google creating a compatible platform. It is about Google picking
and choosing some Java APIs, but not others, knowing it would create an incompatible platform.
Google fragmented Java by implementing less than the full number of the Java APIs
(“subsetting”), adding its own APIs (“supersetting”) and, in some cases, only supporting some of
the classes within a Java API. (See Mitchell Opp. Report ¶¶ 61-68, 101-113.) As a result,
Google’s copying undermines compatibility and interoperability. Java developers have to learn
new APIs to make their programs work with Android, many existing and future Java programs
cannot run on Android, and many applications built for Android will not run on the Java platform
or devices built to support Java. (Id. ¶¶ 62-68, 113.) Google’s fragmentation of Java has violated
the “write once, run anywhere” creed. While there had been some minor fragmentation in the
past, Google recognized it was slight. (See, e.g., Swoopes Decl. Ex. 11, GOOGLE-02-00111218
(“Java has very little fragmentation, and it’s adoptable.”).)
From the start, Sun and Oracle have offered licenses to the Java APIs for parties who
agree to completely implement the APIs in a compatible way. That is a key reason why Java is so
successful. But the only way to enforce this type of licensing regime is if courts enforce the
copyright. Google claims it conferred a “public benefit” because it took the copyrighted works
and incorporated them into the “open source Android platform.” (Google Mot. at 19-20). This
self-serving argument is untenable. If a party can freely ignore the copyright and fragment the
platform, as Google has, compatibility in the marketplace will be severely undermined. Allowing
copying that creates an incompatible end product is against the public interest.
The Supreme Court has emphasized that in evaluating the "character" of the use, the court
should look to “‘the propriety of the defendant's conduct’…because [f]air use presupposes
‘good faith’ and ‘fair dealing.” Harper & Row Publishers, Inc. v. Nation Enters., 471 U.S. 539,
562 (1985) (citing 3 Nimmer on Copyright § 13.05[A], at 13-72). Here Google had the chance to
take a license, but decided to push forward without one and “[d]o Java anyway and defend our
decision, perhaps making enemies along the way.” (Swoopes Decl. Ex. 8, GOOGLE-01-
00019527 at 527-528; Ex. 5 at 37:1-38:23.) Google knew this was likely to hurt the licensing
market for Java. (See, e.g., Ex. 13, GOOGLE 26-00007930 (by creating open source platform,
Sun would essentially “walk away from a $100M annual J2ME licensing business.”).)
The purpose and character of Google’s use weighs strongly against it. At a minimum, it
raises factual issues that should go to a jury.
Nature of the Copyrighted Work – Google cites Sega for the proposition that “computer
programs are ‘essentially utilitarian’” in nature, and that, “if a work is largely functional, it
receives only weak protection.” (Google Mot. at 20 (citing Sega, 977 F.2d at 1527).) Google
leaves out the line immediately above, which states: “To the extent that there are many possible
ways of accomplishing a given task or fulfilling a particular market demand, the programmer’s
choice of program structure and design may be highly creative and idiosyncratic.” Sega, 977
F.2d at 1524. That is the case with the Java APIs. Moreover, Sega found the work deserved a
lower degree of protection was because it contained “unprotected aspects that cannot be examined
without copying.” Sega, 977 F.2d at 1526. There is no such issue here.
Amount and Substantiality Of The Work Used – Google argues that, quantitatively, it
only used “approximately one-quarter of the API packages in the Asserted Works.” (Google
Mot. at 20-21.) This is a sizeable percentage and is significant quantitatively. In addition, the
Supreme Court has emphasized the need to look at the “qualitative” aspect of what was used.
Harper, 471 U.S. at 545 (copying of 300 words of quotation from unauthorized manuscript of
Gerald Ford memoir was not fair use). Both parties’ experts recognize the significance of the
APIs. Dr. Mitchell states they are “an extremely important part of the Java platform, and are key
to its organizational structure.” (Mitchell Opp. Report ¶ 96; Mitchell Opening Report ¶¶ 170-
173.) Dr. Astrachan claims the APIs were so important that, once Google decided to use Java, it
was “essentially required” to use the APIs. (Astrachan Ex. 1 ¶¶ 130, 134-36.)
Effect Upon The Potential Market For, Or Value Of The Copyrighted Work – The
Supreme Court has said that, “This last factor is undoubtedly the single most important element
of fair use.” Harper, 471 U.S. at 566-67 (citation omitted). It is also highly factual. Google asks
the Court to decide this issue in its favor, as a matter of law, based on two public relations quotes
from former Sun executives in 2007, when Android was first released. (Google Mot. at 21.)
“Fair use, when properly applied, is limited to copying by others which does not
materially impair the marketability of the work which is copied.” Harper, 471 U.S. at 566-67
(citation omitted). Google cannot meet this standard. It is hardly surprising that by creating a
free competing platform in the mobile device arena, that gives developers the advantages of many
of Java’s core APIs, Google impaired the value of the Java platform that implements them.
Google substantially undermined Oracle’s efforts to generate revenues. (See Swoopes Decl.
Ex. 6 at 71:13-72:4, 111:10-112:2 (Java is “pretty well locked out of the smartphone market
because of Android.”). Google expected this would occur. (See, e.g., Ex. 13, GOOGLE 26-
In addition, as discussed above, Google has significantly harmed the value of the APIs by
fragmenting Java and undercutting its “write once, run anywhere” capability. (See, e.g., Mitchell
Opp. Report ¶¶ 101-115.) Google knows this is harmful. Google itself imposes licensing terms
requiring Android users to refrain from fragmenting its APIs. (See Swoopes Decl. Exs. 23-25.)
Google also contends that because Apache Harmony and GNU Classpath offer open
source versions of the Java APIs, the inclusion of the Java APIs in Android could not be harmful.
(Google Mot. at 22.) But Google knows that Harmony did not obtain a needed license from Sun
(see, e.g., Swoopes Decl. Ex. 1 at 119:12-122:4), and that Classpath is licensed to others under
the GPL, which has important restrictions that limit its commercial application.
II. GOOGLE AND ITS AGENTS LITERALLY COPIED MULTIPLE
PROGRAMS, SOURCE CODE SECTIONS, AND COMMENTS.
Google does not deny that it literally copied source code, object code and comments from
12 separate files. Google’s only defense is to claim its copying is de minimis because it is
insignificant in relation to Oracle’s “work as a whole.” (Google Mot. at 22-23 (quoting Newton v.
Diamond, 388 F.3d 1189, 1195 (9th Cir. 2004) (emphasis supplied by Google).)
Google treats all of J2SE 5.0 as a single work, and compares the files to J2SE 5.0 in its
entirety. (Id. at 23.) But each of the source code files is a separate work under copyright law.
Copyright regulations allow for a single application for a “single work,” which for published
works is defined as “all copyrightable elements that are otherwise recognizable as self-contained
works, that are included in a single unit of publication, and in which the copyright claimant is the
same.” 37 C.F.R. § 202.3(b)(4)(A); see, e.g., Bean v. Littell, 669 F. Supp. 2d 1031, 1034
(D. Ariz. 2008) (“When a claimant registers a collective work, the copyright protection can also
extend to each constituent part of that work.”). If this were not so, programmers could steal files
at will from large software programs, hiding under the de minimis cover.
Here, each of the twelve source code files is an individual program file and is
recognizable as a self-contained work that was included within J2SE 5.0, the single unit of
publication. Put in its proper frame of reference, the copying is undeniably significant
First, Google copied eight machine code files in their entirety. (Mitchell Opening Report
¶¶ 241-248, Exs. Copyright-J-Q.) There is no question of significance to the work as a whole.
Google copied the entire work. Moreover, Google’s quotations from Newton are taken from a
portion of the opinion analyzing infringement under the “fragmented literal similarity” test, which
is only applied when “the defendant copies a portion of the plaintiff's work exactly or nearly
exactly, without appropriating the work’s overall essence or structure.” Newton, 388 F.3d at
1195. (See also Google Mot. at 22-23.) That is not the case here. The whole work was taken.
Second, two Android source code files include a copied method that is identical right
down to the spacing of the “rangeCheck” method in Oracle’s Arrays.java. (Mitchell Opening
Report ¶¶ 233-240.) rangeCheck is only nine lines long, but it is qualitatively significant to
Arrays.java, the Oracle file in which it is located, and which is a separate work. While
Arrays.java comprises 3,180 lines of code, rangeCheck “is called nine times” by other methods in
the class, showing this small piece of code is important. (Id. ¶ 235.) In contrast, in Newton, the
accused infringer had sampled a qualitatively insignificant portion of a four-and-a-half-minute
composition 􀅆 just three notes. Newton, 388 F.3d at 1191. Dr. Astrachan dismisses rangeCheck
as a mundane “sanity check,” but it appears to make some atypical choices in its reporting of
error conditions. (See Mitchell Opp. Report ¶ 86.) A reasonable juror could find it is not as
“common, trite, and generic” as a three-note sequence (C-D flat-C) was in Newton.
Third, two other Android files contain comments that are nearly identical to comments in
corresponding Java files that are again separate works. (Mitchell Opening Report ¶¶ 249-251.)
These two Android test programs were written to test the functionality of Android’s
implementations of two classes from the java.security API. The comments explain how the code
tests the functionality of Android’s implementation of java.security API. Comments, because
they are not “functional,” can represent one of the most expressive elements of a computer
program. (Id. ¶ 249.) They are significant to the works from which they were taken.
But even if the Court were to look beyond the individual works to measure the
significance of Google’s copying, summary judgment would still be inappropriate. A “use is de
minimis only if the average audience would not recognize the appropriation.” Newton, 388 F.3d
at 1193. Given Google’s nearly identical line-by-line copying of hundreds of lines of code, there
is at least a triable issue of fact as to whether the average audience would recognize the
appropriation. Id. at 1189. And in evaluating whether the copying was de minimis, all the copied
works would have to be considered collectively, including the 37 APIs, which are “an extremely
important part of the Java platform, and are key to its organizational structure.” (Mitchell Opp.
Report ¶ 96.) Google does not get to separate out one part of its infringement from another for
the purpose of evaluating the significance of its copying.
The importance of the test code is also a disputed material fact. Dr. Mitchell rejects
Dr. Astrachan’s conclusion that some of these files are merely “dummy files” for testing.
(Mitchell Opp. Report ¶¶ 91-95.) These files were not contained in the “test” area on Oracle’s
directory. But even if Google used them as test files, test files are still valuable: “testing software
often requires more time and effort in software companies than writing the code initially.” (Id. ¶
95.) Google paid a software engineering firm $900,000 to develop a software test suite for the
Java core libraries. (See Swoopes Decl. Ex. 15, Google-Noser Statement of Work: CTS,
GOOGLE-00392183-94.) A jury could reasonably conclude that the copying of entire
copyrighted files into Google’s test suite was qualitatively significant.
For all the above reasons, this motion should be denied.
Dated: August 19, 2011
MORRISON & FOERSTER LLP
By: /s/ Kenneth A. Kuwayti
Kenneth A. Kuwayti
Attorneys for Plaintiff
ORACLE AMERICA, INC.
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
ORACLE AMERICA, INC.,
Case No. 3:10-cv-03561-WHA
OPENING EXPERT REPORT OF JOHN C. MITCHELL
SUBMITTED ON BEHALF OF PLAINTIFF
ORACLE AMERICA, INC.
CONFIDENTIAL PURSUANT TO PROTECTIVE ORDER
Highly Confidential Attorneys Eyes Only
TABLE OF CONTENTS
I. INTRODUCTION ....................................... 1
A. Retention .......................... 1
II. BACKGROUND AND QUALIFICATIONS .............................. 4
B. Scope of Work Performed and Expected Testimony................... 1
C. Compensation .................................. 3
A. General................................. 4
III. MATERIALS CONSIDERED AND RELIED ON........................... 8
B. Copyright .......................................... 6
IV. BACKGROUND: JAVA AND ANDROID............................... 9
A. The Java Platform: Technical Benefits and Consequences of Adopting the
V. THE COPYRIGHTS IN SUIT AND DETAILED OPINIONS ............. 45
Java Programming Language.......................... 9
B. The Java Class Libraries ........................... 13
C. Success of Java and the Java Ecosystem ................. 16
D. Java Platform Inventions........................... 19
E. Google Android Products ........................... 20
F. Android Marke...................................... 23
G. The Android Platform on End-User Devices............... 25
H. Android Application Development........................... 27
I. Android's Adoption of the Java Platform.................. 30
J. Google's Decision to Adopt Java for Android and Why Alternatives Are
Suboptimal ................................... 32
A. Statement of Opinions and Findings............ 45
B. Principles of Law ................................... 45
C. Ownership ....................................... 47
D. Access ............................................. 48
E. Refresher on Object-Oriented Programming and the Java Language... 49
F. The Value of Application Program Interfaces ............. 51
G. Copyrightable Expression in the Java Platform.............. 53
H. The Android APIs Compared to the Java APIs ........... 60
I. Android Source Code Compared to the Java APIs............ 63
J. Android Source Code Compared to Java Source Code ......... 69
VI. COPYRIGHTED FEATURES FORM BASIS FOR CUSTOMER DEMAND
FOR ANDROID .......................................... 75
A. Google Understood that Applications Would Drive Consumer Demand for
VII. CONCLUSION......................................... 82
Android and Java Would Play a Central Role ........... 75
B. Google Recognized that Sun Microsystems's (now Oracle's) Copyrighted
Features Would Be the Key to Attracting Millions of Application
Developers to Android and OEMs.................. 77
C. Google Made Sun Microsystems's (now Oracle's) Copyrighted Features
Necessary to Android............................... 80
D. Conclusion ............................................... 81
I, John C. Mitchell, Ph.D., submit the following expert report ("Opening Copyright
Report") on behalf of plaintiff Oracle America, Inc. ("Oracle"):
1. This report covers my review, analysis, and opinions regarding the copyrights
asserted by Oracle against Google in the case known as Oracle America, Inc. v. Google, Inc.,
pending in the United States District Court for the Northern District of California, Case No. 10-03561-WHA.
2. I will submit my review, analysis, and opinions regarding the patents-in-suit
under separate cover on the due date agreed to by the Parties.
3. I have been retained to consult with counsel, review documents and other
information, prepare expert reports, and be available to testify regarding my opinions on behalf
of Oracle in connection with litigation brought by Oracle against Google.
B. Scope of Work Performed and Expected Testimony
4. In general I have reviewed materials to provide technical teaching and opinions
regarding the patent and copyright infringement by Google in this case of the asserted claims of
the patents and copyrights in suit. As stated in Oracle's list of issues for expert testimony in
Oracle's case-in-chief, I expect to testify at trial regarding:
Problem of application development and distribution for heterogeneous
- Origins, components, and versatility of the Java platform;
- The success of the Java platform, including technical accomplishments, attraction
to developers, software development tools, and the Java ecosystem;
- Importance of compatibility to the Java platform;
- State of the art, subject matter, novelty, and significance of the claimed inventions
in relation to the patents-in-suit;
- Priority dates of the patents-in-suit;
- Definition of a person of ordinary skill in the art for the patents-in-suit;
I also expect to testify at trial with respect to matters addressed by experts testifying on behalf of
Google. I may also testify on other matters relevant to this case, if asked by the Court or by the
- Subject matter of the copyrights-in-suit, including the significance of Oracle's
copyrighted works and the expressive choices available to Java and Android
application programming interface (API) developers;
- Components of the Android platform;
- Components of the Android ecosystem;
- Modes of Google's distribution, control over Android source code, and likelihood
of third parties modifying portions of Android alleged to infringe the intellectual
property in suit;
- Infringement of the patents-in-suit, including direct and indirect infringement, and
literal infringement and infringement under the doctrine of equivalents;
- Infringement of the copyrights-in-suit, including substantial similarity as between
Java and Android APIs, Java APIs and Android source code, and Java source
code and Android source code;
- Demand for and significance of the patents-and copyrights-in-suit to Android,
including improved performance, improved security, widespread adoption, and
speed to market;
- The absence of design-arounds and non-infringing alternatives to the Android
technologies alleged to infringe the patents-in-suit and copyrights-in-suit;
- Whether the Android technologies alleged to infringe the patents-in-suit are
specially made or adapted for use in infringement or have any substantial non-infringing uses;
- Performance benchmark tests, results, and analysis demonstrating the significance
of the patents-in-suit to Android and the Java platform with respect to execution
speed, memory savings, and architectural impact;
- Relevance of Oracle's Java patent portfolio to Android in the context of a
hypothetical negotiation between Oracle and Google; and
- Google's acts of direct and indirect infringement of the patents and copyrights in
5. I reserve the right to supplement or amend this report, if additional facts and
information that affect my opinions become available. In particular, I understand that fact
discovery closes on August 15, 2011. I have been informed that Google has yet to complete
production of information that may affect my infringement analysis. Some information about
various versions of the accused software, systems, and applications is not publicly available. For
example, I have not been able to examine the source code for Honeycomb, and I understand that
Google plans to release future versions of Android software. None of these have been made
available for my review. As such, my investigation into the specifics and extent of Google's
infringement is ongoing. My report is based on the materials that have been available to me up
to the date of this report.
6. My opinions are based on my education and my work experience as set forth in
Exhibit A of this Report, the materials listed in Exhibit B of this Report, and the materials cited
to in my Opening Copyright Report.
7. I am being compensated for my work in connection with this matter at the rate of
$800 per hour. I have used this rate in the past for other cases.
8. My compensation is not conditioned on the outcome of this matter. Neither the
amount of my compensation nor my hourly billing rate depends on whether I am obligated to
testify at deposition or trial.
II. BACKGROUND AND QUALIFICATIONS
9. Information detailing my qualifications is included in my Curriculum Vitae,
attached as Exhibit A.
10. I received my Ph.D. in Computer Science from MIT in 1984. I hold a Master's
degree in Computer Science from MIT, and a Bachelors of Science in Mathematics with
Distinction from Stanford University, which I received in 1982 and 1978 respectively.
11. My Ph.D. thesis was on topics related to the design and analysis of programming
12. Between Stanford and MIT, I worked for two years as a research programmer for
the University of Wisconsin.
13. Before I joined the faculty of Stanford, from 1984 until 1988, I was a Member of
the Technical Staff at the Computing Science Research Center of AT&T Bell Laboratories.
14. I am currently the Mary and Gordon Crary Family Professor of Computer Science
and (by courtesy) Electrical Engineering at Stanford University. From 1990 until 1997, I was an
Associate Professor of Computer Science at Stanford University and from 1988 to 1990 I was an
Assistant Professor of Computer Science.
15. At Stanford, my research has covered a variety of topics, including the design and
analysis of programming languages, computer security, and mathematical logic. For example, I
wrote research papers on type systems for object-oriented programming languages and
developed principles that were adopted in the designs of the Java and .NET programming
16. With my former Ph.D. student Stephen Freund, I wrote a series of papers studying
properties of the Java bytecode verifier. With an additional former student, we designed,
implemented and tested a form of Java generics, a concept that was subsequently added to the
Java programming language.
17. My publications include three books on aspects of programming languages and
over 140 research articles. A list of my publications is included in my Curriculum Vitae
18. I was elected as a Fellow of the Association for Computing Machinery in 2008.
As explained on ACM's website: "The ACM Fellows Program was established by Council in
1993 to recognize and honor outstanding ACM members for their achievements in computer
science and information technology and for their significant contributions to the mission of the
ACM. The ACM Fellows serve as distinguished colleagues to whom the ACM and its members
look for guidance and leadership as the world of information technology evolves." (See
19. I am Editor-in-Chief of the Journal of Computer Security and I have served on the
editorial board of ten other professional journals. I have also served as program committee chair
or program committee member of many professional conferences on programming languages,
computer security, and other areas of computer science.
20. The courses I have taught at Stanford include programming languages,
programming language theory, computer and network security, web security, logic, and
21. My research activities have been funded by U.S. Government agencies and gifts
to Stanford from private companies. For example, I am currently the Principal Investigator (PI)
of a project on secure information sharing that is funded by the Air Force Office of Scientific
Research and the PI of a DARPA-funded project developing a programming language for
computing on encrypted data. I am also a co-PI on the National Science Foundation Science and
Technology Center called TRUST and a co-PI and Chief Computer Scientist of a project on
security and privacy for healthcare information systems funded by the U.S. Department of
Health and Human Services.
22. My research has also been partially funded over the last several years by gifts
from private companies. While such gifts are often designated as intended to support a specific
research project, they are gifts to Stanford University and not gifts to me personally.
23. In collaboration with Stanford faculty Dan Boneh and David Mazieres, I applied
for a small research gift from Google to support research on "security for cloud clients with rich
controlled sharing." I believe that the final version of the application for funding was sent to
Google by their deadline of October 15, 2010. Support for my research from this application has
been placed on hold by Google for the duration of this litigation.
24. I am co-inventor of U.S. Patent No. 7,870,610, titled "Detection of Malicious
25. I have served as an expert witness or consultant in connection with a number of
litigations. A list of prior cases in which I have testified or consulted as an expert over the past
years is included in my Curriculum Vitae (Exhibit A).
26. With particular relevance to my copyright analysis conducted in this case, I
previously assisted with a copyright dispute for which I analyzed and prepared an expert report
covering copyrightable elements of user interfaces.
27. In my 30 years of experience with computer software, I have reviewed a large
amount of source code written by different programmers. Moreover, I teach programming
language classes and assign programming projects that are graded as part of the class. As a
result, I am generally familiar with the variations of code expression that arise when a set of
programmers (including students) are asked to solve a programming problem. I should note that
even on exam questions, when I've tried to narrow the question to limit the set of possible
correct answers, students usually find many ways to write source code to express solutions.
28. I am also familiar with tools used to detect plagiarism or source code copying in a
university setting. I have served on a juror pool on Stanford's Judicial Affairs, which handles
plagiarism cases, including plagiarism in programming courses. In my interactions with
Stanford's Judicial Affairs Office, I've discussed principles for detecting and determining
plagiarism and how they apply to computer programming assignments.
29. Like every other person with programming experience with whom I have
discussed this, I personally find programming a creative experience, analogous to technical
writing, for example. In both cases, although there is a purpose to be served, there are many
ways to accomplish the goal, and a wide range of expressive choices in doing so.
III. MATERIALS CONSIDERED AND RELIED ON
30. In arriving at my opinions provided in this report, I have considered a number of
different sources of information that are identified in attached Exhibit B and referenced in my
Opening Copyright Report.
31. In particular, I have reviewed the copyrighted works asserted in this lawsuit;
Android source code, videos, and documentation made publicly available and produced by
Google during the course of discovery.
32. In support of my analysis and rendered opinions, I intend to rely on the summary
and report of Marc Visnick comparing Sun Microsystems's (now Oracle's) JDK 1.5 to Android
Froyo and Apache Harmony, submitted to Google with my Opening Copyright Report.
Likewise, I intend to rely on the summary report of Alan Purdy comparing Sun Microsystems's
(now Oracle's) Java library API specifications to Android's library API specifications, also
submitted to Google with my Opening Copyright Report.
33. In addition to the materials specifically identified, I may provide further exhibits
to be used as a summary of or support for my opinions.
IV. BACKGROUND: JAVA AND ANDROID
34. I believe a background and tutorial on Java and Android will aid the jury in
understanding and appreciating the technology at issue in this case. I will cite to Google
documents where appropriate.
35. There are several interesting features and components of Java that have marked its
unprecedented technological success: the programming language, bytecode instruction set
specification, virtual machine, execution paradigm and execution platform, programming tools,
and class libraries and application programming interface (API) specifications.
36. To be clear on vocabulary, the Java development platform comprises the Java
compiler, class libraries, development environment and associated tools, and the Java execution
platform. The Java execution platform comprises the Java Virtual Machine and other
components associated with processing and executing compiled Java source code, including
executable class libraries and the class file format.
37. The Android platform incorporates various features of Java, as detailed below.
A. The Java Platform: Technical Benefits and Consequences of Adopting the
38. The Java programming language was designed by James Gosling and others at
Sun Microsystems in the early 1990s.
Java Programming Language
39. Java is an object-oriented language. In object-oriented languages, an object is a
way of combining data and functions. For example, an Integer object would have an integer
value, such as 3, together with functions on integers, such as addition and multiplication.
40. In most common object-oriented languages, programmers define classes. Each
class provides a way for programs to create objects that have the functions defined in the class.
For example, in an object-oriented program with an Integer class, a programmer can use this
class to create several Integer objects in her program. In Java and other class-based object-oriented languages, all objects created from the same class have the same functions, also called
methods, but each object may have different data values. In Java, data values associated with an
object are called fields of the object.
41. Object-oriented programming began in the 1960s and developed with the early
programming language Simula. James Gosling credits the influence of Simula on Java in this
statement that I quote in my programming languages textbook: "One of the most important
influences on the design of Java was a much earlier language called Simula. It is the first OO
language I ever used (on a CDC 6400!). ... [and] where the concept of a 'class' was invented."
In this statement, OO means "object-oriented."
42. Java was developed and distributed with a novel execution platform. As
documented in the original press release (see
sunflash.960123.10561.xml), the Java execution platform allows software developers to write
programs that, once compiled, may be transported and run on a variety of computers without recompiling or rewriting them. This feature of Java is described as "write once, run anywhere."
43. The key innovation of Java that supports "write once, run anywhere" is a
combination of interrelated design decisions. First, Java source code programs are compiled into
an intermediate executable form called bytecode that is stored in class files. Second, the virtual
machine that is used to execute Java bytecode has specific functions that allow separately
compiled class files to be incrementally loaded, verified, and then executed on any hardware
platform that is equipped with a Java virtual machine. While the Java execution platform was
not the first to use bytecode and a virtual machine, I believe that it was the first to support
separate transport and incremental loading, verification, and execution of bytecode files stored in
a standardized portable format. Source code, compilers, bytecode, class files, and the Java
loader, verifier and bytecode interpreter are described in the following paragraphs.
44. Since approximately 1960, computer programs have been written in human-readable programming languages, such as Fortran, Algol, C and C++. Code written in these
human-readable languages, called source code, is not directly executable by computer hardware.
Instead, it must be converted to machine code in some way. As the name suggests, machine
code uses the set of instructions that are understood and executed by a specific hardware
processor. Different computer chips may execute different sets of rudimentary machine code
45. There are two traditional ways of converting source code into machine code. The
first method uses a program called a compiler to convert an input file of source code to an output
file of machine code that can be executed later. This machine code file can then be executed
later, on a separate platform that does not have the source code or compiler. The second method
uses a different kind of program called an interpreter. An interpreter processes source code
instructions from an input file and executes corresponding machine instructions step-by-step,
based on the source code instructions. Unlike a compiler, an interpreter continues to run as the
source code program is interpreted. In other words, the source code and interpreter must be
present on any platform where the program is interpreted.
46. Because a compiler converts source code to machine code for a specific machine,
a traditional Apple Mac compiler, for example, produces compiled machine code that runs only
on an Apple Mac and cannot be run on an IBM PC. (For many years, including early Java years,
Apple used chips manufactured by Motorola and IBM PCs used incompatible chips
manufactured by Intel.) In contrast, the same source code for an interpreted programming
language can be run on different interpreters on different machines because each interpreter
performs step-by-step execution using the appropriate machine instructions of the hardware it
runs on. However, it is not common to distribute software programs in their source code form.
Source code represents the creative work of software designers and developers in a form that
could expose a company's intellectual property to competitors.
47. The Java execution platform uses an intermediate form
|Authored by: feldegast on Tuesday, September 13 2011 @ 08:37 AM EDT|
|So they can be fixed|
My posts are ©2004-2011 and released under the Creative Commons License
P.J. has permission for commercial use.
[ Reply to This | # ]
|Authored by: Anonymous on Tuesday, September 13 2011 @ 08:41 AM EDT|
[ Reply to This | # ]
|Authored by: feldegast on Tuesday, September 13 2011 @ 08:45 AM EDT|
|Please make links clickable and use the preview if using HTML|
My posts are ©2004-2011 and released under the Creative Commons License
P.J. has permission for commercial use.
[ Reply to This | # ]
|Authored by: feldegast on Tuesday, September 13 2011 @ 08:47 AM EDT|
|Please make links clickable and use the preview if using HTML|
My posts are ©2004-2011 and released under the Creative Commons License
P.J. has permission for commercial use.
[ Reply to This | # ]
- CNN/Tea Party GOP debate transcript PJ comment - Authored by: Anonymous on Tuesday, September 13 2011 @ 01:36 PM EDT
- PJ, I think you may have stepped over you own line. - Authored by: deck2 on Tuesday, September 13 2011 @ 03:01 PM EDT
- PJ, I think you may have stepped over you own line. - Authored by: Wol on Tuesday, September 13 2011 @ 03:45 PM EDT
- PJ, I think you may have stepped over you own line. - Authored by: Anonymous on Tuesday, September 13 2011 @ 04:51 PM EDT
- PJ, I think you may have stepped over you own line. - Authored by: jonathon on Tuesday, September 13 2011 @ 07:01 PM EDT
- ^^^ This - Authored by: Bernard on Tuesday, September 13 2011 @ 08:41 PM EDT
- ^^^ This - Authored by: Anonymous on Monday, September 19 2011 @ 01:32 PM EDT
- PJ, I think you may have stepped over you own line. - Authored by: PJ on Wednesday, September 14 2011 @ 02:47 AM EDT
- Political vs Reporting - Authored by: Anonymous on Tuesday, September 13 2011 @ 06:16 PM EDT
- CNN/Tea Party GOP debate transcript PJ comment - Authored by: jonathon on Tuesday, September 13 2011 @ 06:38 PM EDT
- CNN/Tea Party GOP debate transcript PJ comment - Authored by: Anonymous on Tuesday, September 13 2011 @ 09:09 PM EDT
- Here's something no-one wants to admit: - Authored by: Illiander on Wednesday, September 14 2011 @ 02:51 AM EDT
- Libertarian Think Tanks Oppose Patents on Abstract Ideas - Authored by: RFD on Tuesday, September 13 2011 @ 02:37 PM EDT
- BYU professor's critique of climate change model contributes to journal editor's resignation - Authored by: joel on Tuesday, September 13 2011 @ 03:23 PM EDT
- This is Windows 8: Hands-on... - Authored by: Anonymous on Tuesday, September 13 2011 @ 04:27 PM EDT
- Writers sue US university libraries for copyright infringement - Authored by: Anonymous on Tuesday, September 13 2011 @ 05:18 PM EDT
- Heeding the Lessons of SCO, or Not - Authored by: Anonymous on Tuesday, September 13 2011 @ 05:33 PM EDT
- Google Gives Oracle a Tutorial on API Copyright Law - Authored by: Ian Al on Wednesday, September 14 2011 @ 03:00 AM EDT
|Authored by: Anonymous on Tuesday, September 13 2011 @ 08:50 AM EDT|
|What I find strange is that Google hasn't pointed out Oracle themselves (through|
their "Unbreakable Linux") has been distributing GNU Classpath. Which
is a complete alternative implementation of the standard core java libraries as
part of the GNU Compiler Collection (GCC) distributed under the GPL (plus
standard gcc runtime linking exception statement) from the FSF. One of the
components of GCC is the GNU Compiler for Java (GCJ), which contains a runtime
library (libgcj), which is based on GNU Classpath.
Clearly they must approve of alternative implementations of the standard core
APIs if they redistribute those themselves under free software licenses.
[ Reply to This | # ]
|Authored by: SLi on Tuesday, September 13 2011 @ 10:07 AM EDT|
Oracle filed its initial response 339 [PDF] a few
which we discussed here. Oracle asserts that the
APIs are not purely
functional. More specifically, Oracle claims
its APIs "[c]ontain [m]any
[o]riginal and [c]reative [e]lements.
The Java APIs are the blueprint to the
class libraries. They are
not just a list of names and methods, but an
complex structure of hierarchy and interdepency." But in this
context Oracle is talking about all of the APIs in Java, not
merely the 37 at
issue here, and on that broad basis Oracle's
claim may be
I don't think any experienced programmer would object to
idea that designing the API is definitely a major, perhaps the
of library design. I have no issue with Oracle's
contention that the copied
APIs "contain many original and
But then, the user
interface of a car also definitely contains
original and creative elements. The
arrangement of the different
controls in a car is the result of refinement that
years of time and lots of thinking and research. In the case of a
car Oracle's claim should actually have a bigger chance of
humans are able to adapt, but computers are not.
If you change the API, that
will break Java programs. If
you change the order of pedals in a car,
you will annoy people
but most of them could eventually adapt. The situation is
analogous to communication protocols and file formats. If you
want to be
compatible, you simply will have to use the same
protocol and same file format
with everyone else.
It certainly is true that the API reflects a lot of the
structure of the code. It's even more true in "shallow" libraries
do much magic but just provide a huge toolbox of
individual small things like
the Java class libraries (i.e. you
have lots of simple operations like "extract
a number from this
character string", not few complex ones like "figure out
the person in this given photograph is smiling"). Show me or any
experienced programmer the API of such a library, and we
quite certainly can
tell you the rest of the story about how it's
probably implemented, except for
the most small details.
It makes no sense to say that programming languages
unprotected but APIs can be copyrighted. If APIs are
definitely means there is a monopoly to
programming languages. You cannot make
anything compatible with
Java without using the same API.
So, I would grant
that APIs are the major part of library
design, and making a good API
definitely is a creative process
and an art, not a science.
I think the
discussion about whether APIs are "functional" is
a bit confused. The
initial design of the API is very
much creative work and involves lot
of human judgment. If that
results in them being copyrightable, then I think
the law is
broken. In any case it seems to me like putting the cart before
horse to argue that "they contain expressive elements,
should be copyrightable". That may (or
may not) be the law, that
sufficient expressiveness conveys
copyrightability; whether APIs
should be copyrightable
is entirely a different question from whether
they are under the
law, a policy question in fact - and I'm happy the courts
recognized that as a policy API copyright would be stupid.
contrast to the initial design of a library, if you
want to write code that is
compatible, then the fact that you
have to use that very API whose design took
lots of creative
power is dictated solely by functionality. You simply have no
choice. Even if it's a bad API (and most mature APIs have their
cannot fix this; you will have to stick to what you
are given if you want to
So, I would propose this distinction: The
an API is expressive, creative work; using the API,
the development of a compatible system or API, is necessarily
functional concerns. Yes, in the latter case you
incidentally necessarily save
a lot of work too because you don't
have to design a good API, but given the
compatibility it's a choice you could not make even if you
[ Reply to This | # ]
|Authored by: artp on Tuesday, September 13 2011 @ 10:41 AM EDT|
|For those hard working volunteers who are putting HTML mark |
up documents in text mode from the boundless Comes v.
Microsoft document archive. Take that, billg!
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
[ Reply to This | # ]
|Authored by: artp on Tuesday, September 13 2011 @ 10:58 AM EDT|
|Pardon me for being an engineer, but it sometimes seems to |
me that the courts value the process of the legal system
over plain old common sense.
In any technical enterprise, nobody could afford to carry
such nonsense through the system as we have here with
clearly ineligible APIs being contested in court. These
things should have been thrown out immediately, or even
sooner. Preferably sooner. It's on the order of someone
complaining because they can't use their hydraulic excavator
to load their dishwasher. You just have to tell them that
they are NOT supposed to be doing that! Diagnosis and
treatment of the underlying problem is not the
responsibility of tech support, but they are NOT supposed to
be doing that!
If there are clear-cut precedents, why aren't they being
used? Why should anybody be able to file so easily, and
waste the time of the court in an exercise like this?
Common sense seems to have been litigated out of the system.
The legal system wants a specific law for every activity
before something can be attempted to be outlawed, and then
they can't take care of something as simple as APIs.
Please do not tell me that attorneys and judges are not
technically trained. That doesn't wash (hydraulic excavator
or not) with me. If the existing cadre can't handle it, get
someone who can. There are patent attorneys out there, some
of whom know what they are doing. If the Constitution says
that I deserve a jury of my peers, then I want a jury of my
peers, who can understand what I am talking about without
dumbing it down.
What a mess! And we wonder why the courts are bogged down.
We wouldn't have this mess if we hadn't turned the courts
over to people who could profit from them - attorneys and
Excellent article, by the way, and a painstakingly thorough
explanation in the filing.
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
[ Reply to This | # ]
|Authored by: Anonymous on Tuesday, September 13 2011 @ 12:04 PM EDT|
Suppose there is a book on the best seller's list called
"The Art of Foo",
and I wrote a companion guide to it,
"Companion Guide to the Art of Foo",
wherein I critique it
or add original supplemental or background material
My question is, if my book is laid out exactly like
first, listing each chapter using the same title as the
the content under each heading is totally
original), am I going to run afoul of
It seems to me that there would be a broad parallel here
to what Google has done with Java.
[ Reply to This | # ]
|Authored by: Anonymous on Tuesday, September 13 2011 @ 01:18 PM EDT|
|I do not know if this point makes legally any sense, but logically I think there|
may be a conflict between claiming money for the fragmentation of Java and in
the same time implying that Google should have used an other API.
As far as I know about programming, if you want to be source code compatible
with Java, you have to use the same function calls, the same data structures,
and even the same variable names. And if you are source code compatible, you are
not really fragmenting.
[ Reply to This | # ]
|Authored by: David on Tuesday, September 13 2011 @ 02:11 PM EDT|
|Heh. I read, "the specifications for thirty-seven Android Java language|
API packages (the "Accused Packages")"...
...as "the Accursed Packages"
WARNING: You are logged in to reality as root....
[ Reply to This | # ]
|Authored by: Anonymous on Tuesday, September 13 2011 @ 03:09 PM EDT|
|> I believe that it was the first to support separate |
> transport and incremental loading, verification, and
> execution of bytecode files stored in a standardized
> portable format.
UCSD Pascal pcode (a bytecode system) was output by the compiler and then could
be executed on any computer with the UCSD 'virtual machine' regardless of which
CPU it used.
Several COBOL systems, such as Microfocus, RM and ACCU each used a portable
bytecode format that would run on any computer that had a 'runtime' bytecode
executor. These certainly did "separate transport and incremental loading,
verification, and execution of bytecode files". COBOL has dynamic loading
and unloading methods CALL and CANCEL.
Microfocus dates from 1978, others are similar.
[ Reply to This | # ]
|Authored by: Anonymous on Tuesday, September 13 2011 @ 03:31 PM EDT|
A good reference for what other courts have ruled concerning copyright
protection for software interfaces can be found in the revised book by Jonathan
Band and Masanobu Katoh, Interfaces on Trial 2.0, that is available as a
free digital download.
terfaces on Trial 2.0
Chapter 2 covers Copyright Cases in U.S.
Courts. The authors discuss many of the important cases in different circuit
courts that have defined the law to now on software interface copyright
The take-away from the different cases presented seems to be
that while most courts have favored keeping software interfaces mostly free in
order to preserve desired interoperability, they have sometimes struggled to
find a consistent legal justification for the preferred result.
authors describe how in the first software copyright case in front of the U.S.
Supreme Court, Lotus v. Borland, it was hoped the scope of copyright protection
for software might be more fully resolved. Instead, after hearing oral
arguments, the Justices issued a "two-sentence per curiam order affirming the
First Circuit’s decision with a vote of 4–4". After that, it remained for the
individual circuit courts to shape the law in their respective circuits. The
Had the Supreme Court decided the case on the
merits, we would have definitive answers to whether copyright protects interface
specifications, and, if it doesn’t, under what theory it doesn’t. But the Court
did not reach the merits, and thus the law continued to evolve in the lower
courts. Four courts subsequently refused, under a variety of different theories,
to extend protection to interface specifications. They continued the lower
courts’ pro- interoperability tilt, but did so in a way that did not endanger
protection for those program elements that deserve it under law. The
Third Circuit, however, found that the reproduction necessary for
interoperability infringed copyright.
The cases they point out
include: Bateman v. Mnemonics (1995, Eleventh Circuit), Compaq v. Procom (1995,
S.D. Texas), Softel v. Dragon Medical (1996, Second Circuit), Mitel v. Iqtel
(1997, Tenth Circuit), Dun & Bradstreet v. Grace Consulting (2002, Third
Circuit), and Lexmark v. Static Control Components (2004, Sixth
The authors make an interesting observation about the way in
which the different courts reached their decisions. They
Long before the emergence of the Law and Economics
movement at the University of Chicago Law School or the emergence of Critical
Legal Theory at the Harvard Law School, professors at the Yale Law School taught
Legal Realism.100 The Legal Realists argued that judges typically reached a
result in a case on the basis of their idiosyncratic notion of which side
deserved to win, and then found a legal rationale justifying that
The decisions concerning the protectability
of interface specifications discussed above—Lotus v. Borland, Bateman v.
Mnemonics, Compaq v. Procom, Mitel v. Iqtel, and Lexmark v. SCC—can be best
explained by Legal Realism. In all five decisions, the courts concluded that the
defendant software developers should be permitted to make copies of the
plaintiffs’ programs to the extent necessary to achieve interoperability. Once
they had reached that same conclusion, they selected different legal theories
justifying how they got there.
If that observation is true,
then one of Oracle's goals in arguing its side of the issue should be to
emphasize the question of whether Google's copying of a large part of the Java
API was really necessary for legitimate interoperability reasons. They may point
out the Android does not claim to be interoperable with Java or Java
applications. Google could and did make conscious decisions about which Java
specs to support and which not to support, leading to the situation that Android
and Java applications are generally not interoperable with each other. They
could argue that any copying done by Android was done more for reasons of
convenience rather than for interoperability.
Given the differences in
how so many different courts have interpreted the legal points up to now (even
as they often reached similar conclusions in the end) and the high bar Google
has to meet to prevail on a motion for Summary Judgement, I think Oracle has a
good chance to get by on this one.
[ Reply to This | # ]
|Authored by: Maot on Tuesday, September 13 2011 @ 03:56 PM EDT|
|What I find interesting about this is the discussion of the code of the API not|
describing the API and that the documentation, or description is separate.
There is a popular concept amongst programmers that well written code should be
self-commenting and thus not require commenting - I've often heard the mantra,
"write code, not comments" in my time as a programmer and teacher of
programming. It's not something I 100% agree with, however is a commonly held
opinion and blurs the line between API and documentation.
In my humble opinion, the Java API isn't self commenting, however, once familiar
with the design patterns applied throughout it becomes easily navigable without
documentation. If it were, why would Sun have created JavaDoc?
I'm fairly sure the patterns used cannot be protected by law, and if so, the
Java API invented none of them. To me, it follows that any API designed with a
given functionality and a consistent set of patterns should also not be afforded
protection. As such I'd say no API should be afforded protection, it is, after
all, an interface, or abstraction.
Two independent designers, given the same functional needs, the same patterns
and the same programming conventions would produce very similar API's.
[ Reply to This | # ]
|Authored by: jesse on Tuesday, September 13 2011 @ 04:44 PM EDT|
43. ... I believe that it was the first to support separate
transport and incremental loading, verification, and execution of bytecode files
stored in a standardized portable format. Source code, compilers, bytecode,
class files, and the Java loader, verifier and bytecode interpreter are
described in the following paragraphs.
Nope. The first I know
of was the Concurrent Pascal system that did this.
Each application or
module could be compiled separately, but when the system was run, they would
load dynamically as required.
This applied to the device drivers, the
kernel, kernel interfaces, and user applications.
[ Reply to This | # ]
|Authored by: jesse on Tuesday, September 13 2011 @ 04:52 PM EDT|
46. Because a compiler converts source code to machine code for a
specific machine, a traditional Apple Mac compiler, for example, produces
compiled machine code that runs only on an Apple Mac and cannot be run on an IBM
PC. (For many years, including early Java years, Apple used chips manufactured
by Motorola and IBM PCs used incompatible chips manufactured by Intel.) In
contrast, the same source code for an interpreted programming language can be
run on different interpreters on different machines because each interpreter
performs step-by-step execution using the appropriate machine instructions of
the hardware it
Forgot about emulators/virtual
machines didn't they. This allows the PowerPC to run Intel binaries, ARM
binaries to run on PowerPC or intel.
QEMU works quite well and support a
number of different hardware architectures.
However, it is not
common to distribute software programs in their source code form. Source code
represents the creative work of software designers and developers in a form that
could expose a company's intellectual property to
And forgot about open source and the GPL as well.
I think I can safely say that there is more open source than proprietary code in
Even forgot that Oracle itself distributes Java as GPL.
[ Reply to This | # ]
|Authored by: Anonymous on Tuesday, September 13 2011 @ 07:01 PM EDT|
|Every Java Programming book I have ever seen publishes at the |
very least the main APIs used in programming Java...(example:
public FileInputStream(String path))
Without which you wouldn't be able to program in Java.
So did all of these people writing these books get a license
from Sun/Oracle to publish the APIs?
[ Reply to This | # ]
|Authored by: Anonymous on Tuesday, September 13 2011 @ 07:32 PM EDT|
|Surely this is time for Friends of the court filings from other parties. (EFF,|
Linux foundation, IBM and others perhaps) that would not want to see APIs
copyrightable. Im not really sure Oracle would really want that either - long
term.... this would bite them eventually...
[ Reply to This | # ]
|Authored by: Anonymous on Wednesday, September 14 2011 @ 03:28 AM EDT|
|Why are we seeing this document filed in underacted form? Did the judge see the|
original filing underacted, and if so, what is the point of this new filing?
[ Reply to This | # ]
|Authored by: Ian Al on Wednesday, September 14 2011 @ 03:45 AM EDT|
Allowing developers to program in Java would immediately give Google
access to millions of developers.
And Google’s expert
opines that it would have been “very difficult for Google” to persuade
developers to switch to different APIs.
The Java API
specifications also include explanatory comments describing each method. Dr.
Mitchell found that these comments are also substantially similar in two files
in the Java and Android documentation
implemented the copied API specifications into Android source code. Google tries
to downplay the significance of this, acknowledging only that it copied the
“names of packages and methods and definitions.
argues that well-designed APIs are “easier to learn and use”
you read a book or listen to a musical performance, it is the author's creative
expression that you value. That is even true of history books. It is hardly true
at all for recipe books. It is rarely true for math books: it's the math,
If the Java APIs were laced with haiku and iambic pentameter
then developers would not use them. Same for recipe books. It is “very difficult
for Google” to persuade developers to switch to different APIs because the math
functions and symbols are clearly and logically defined.
If the Java
API book contained creative expression it would be a joy to read in its own
right. So, lets try a little test: would you consider that the 10,000 page tome
'Java APIs, Edition 6' would make good bedtime reading if you did not have to
program in Java the following day?
Those millions of Java programmers
only program in Java because the APIs and their uses are made evident by the
lack of creative expression in the text.
I_An Algorithm is free speech.
[ Reply to This | # ]
|Authored by: BitOBear on Wednesday, September 14 2011 @ 05:24 AM EDT|
|One thing that is particularly true of Java that is not true of most other|
computer languages: the actual words naming the functions remain in full force
when the function is executed.
There is a point when, in "linking" compiled languages, the names for
functions are discarded in favor of actual (numerical) addresses. At this point,
for example in C, the address of the "printf" function becomes its
nominal "name of use". That is, I can take the address of the printf
function and pass it around and such. The language stops caring that it was ever
In purely interpreted languages all text remains in full force for the lifetime
of the program, including the names of functions.
In both cases above an implementer could (with great difficulty) rename all the
functions of an API and produce the same effective code, and having done so,
could also produce a translator to allow code written to one version of the API
to undergo active adaptation to the other using "aliasing",
"macro expansion" or one of several similar techniques.
Java lies somewhere in the middle of the continuum between compiled and
interpreted languages. It is compiled to byte code.
The thing is, in the design of the byte code system the Sun guys decided that
the function call (method invocation) system would be based on "method
signatures"(*) instead of dispatch tables or any other system. That means
that all the functional invocations of the API are done by name even though the
language is compiled to byte code.
In sort the Java developers decided that the principle names in the API are
promoted to first-class language internals, and so not subject to meaningful
aliasing without literally turning the resultant code into "not java at
Further, since Java, to be Java, requires all classes to be based on the class
named "Object", and similarly reserves other class names such as those
for exceptions and tasks and various containers, the design decisions central to
the "is it or isn't it java" definitions _require_ the APIs to
overwhelmingly use the same names.
The names of the arguments to a particular function don't matter per se. The
argument names are not part of the signatures, only the numbers, types, and
their order matters in the signature. But the names typically used in the
argument lists are typically informative, being words like "endpoint"
So for exampe Java.net.Socket has a method "void connect(SocketAddress
endpoint, int timeout)". In this example only the words
"endpoint" and "timeout" are _not_ mandated to be exactly as
provided by the language internals. "endpoint" and "timeout"
could be removed completely or replaced with synonyms, but as-is they are
concise documentation as to the exact purpose of the two arguments they
In C++, by contrast, the runtime (discounting debugging symbols or optional
RTTI) would be unaware that any of these words were ever as extant.
So Java APIs are even more heavily bound to their exact word choice than is
typical for other non-interpreted computer languages.
Or more exactly, the API specification for the utility functions/classes of the
Java language is tightly bound to the definition of the language itself. An
implementer _must_, by definition, use more than 50% the words exactly as
defined by Sun to allow the language, or anything compatible with the language,
to even function.
Of the remaining 50%, the punctuation is required by the syntax of the language
Of what remains after that, the word choice for the argument names needs to
clearly and consistently communicate the purpose for each element to the
programmer. Since all the how-to books and existing know-how all use the
"god copy" language changing, for example, the word
"timeout" to "delay" would reduce the understandings and
increase the confusion on the part of a programmer working from any common
reference including their own memory of similar skill sets.
Requiring a compatible product to substitute out a word like "timeout"
and replace it with "delay" is tanamount to requiring one machine tool
manufacturer to rename their implementation of a "lathe" as a
"rotor" because the another company used "lathe" in their
descriptive text on woodworking.
Super Short Version: Java APIs are actually more functional, when viewed as a
language implementation artifact, than APIs in other languages because most of
it must be literal for the langage, and the rest almost always must be literal
for the programmers and operators.
I don't think what I read above makes clear the absolute non-optional nature of
the wording of each and every Java API element.
(*)see http://en.wikipedia.org/wiki/Method_signature for more.
[ Reply to This | # ]