The parties agree no case addresses directly whether the Copyright Act protects a computer programming language. However, the most analogous case law, general copyright principles, and the statutory purposes of the Copyright Act support protection. More importantly, none of the arguments advanced for denying protection to a programming language apply to the API specifications and class libraries at issue here.

The specifications and implementations of the APIs are not a method of operation or system.

Computer programming languages are not copyrightable, and neither are Oracle’s APIs. Oracle accuses Google of infringement for doing what the Oracle API specifications describe. That is a classic attempt to improperly assert copyright over an idea rather than expression. The Court should hold that the structure, selection and organization of the APIs are uncopyrightable.

Oracle also provides a list of what it views as the allegedly infringed materials. Oracle's list starts out with accusing Google's *documentation* of the Android class files that implement the accused 37 API packages (which they list here by name), go on to include the actual Android source code and object code that implement the 37 API packages, and several files that are not part of the 37 API packages. Is that the list you thought they were talking about? Or does it seem to have grown?

Also the parties have filed their trial briefs, presumably the final ones. Note that the court says there will be limited seating on the first day, while they pick the jury, so you may not be able to enter until that process is over. Also the judge has ordered that the parties "please place five copies of each admitted exhibit in the press room after trial adjourns each day. This applies only to hard-paper copies. Exceptions can be made in extraordinary circumstances." That's a lovely idea.

Jump To Comments

04/12/2012 - 897 - TRIAL BRIEF Google's 4/12/12 Copyright Liability Trial Brief by Google Inc.. (Van Nest, Robert) (Filed on 4/12/2012) (Entered: 04/12/2012)

04/12/2012 - 898 - Statement re 877 Order Google's Proposed Findings of Fact Regarding the Copyrightability of the Structure, Selection and Organization of the 37 APIs by Google Inc.. (Van Nest, Robert) (Filed on 4/12/2012) (Entered: 04/12/2012)

04/12/2012 - 899 - NOTICE by Oracle America, Inc. re 854 Order Submission of Oracle's Statement of Issues Regarding Copyright (Attachments: # 1 Exhibit A - Oracle statement of copyright issues)(Peters, Marc) (Filed on 4/12/2012) (Entered: 04/12/2012)

04/12/2012 - 900 - Brief re 852 Trial Brief ORACLES APRIL 12, 2012 BRIEF REGARDING COPYRIGHT ISSUES filed by Oracle America, Inc.. (Related document(s) 852 ) (Jacobs, Michael) (Filed on 4/12/2012) (Entered: 04/12/2012)

04/12/2012 - 901 - Statement re 854 Order Google's Proposed Statement of Issues Regarding Copyright by Google Inc.. (Van Nest, Robert) (Filed on 4/12/2012) (Entered: 04/12/2012)

04/12/2012 - 902 - Proposed Findings of Fact by Oracle America, Inc.. (Jacobs, Michael) (Filed on 4/12/2012) (Entered: 04/12/2012)

04/12/2012 - 903 - NOTICE TO PRESS AND PUBLIC RE LIMITED SEATING ON FIRST DAY. Signed by Judge Alsup on April 12, 2012. (whalc1, COURT STAFF) (Filed on 4/12/2012) (Entered: 04/12/2012)

04/12/2012 - 904 - ORDER FOR PARTIES TO ACCOMMODATE THE PRESS. Signed by Judge Alsup on April 12, 2012. (whalc1, COURT STAFF) (Filed on 4/12/2012) (Entered: 04/12/2012)

04/12/2012 - 905 - STIPULATION WITH PROPOSED ORDER Second Stipulation and Proposed Order Regarding Trial Procedures filed by Oracle America, Inc.. (Muino, Daniel) (Filed on 4/12/2012) (Entered: 04/12/2012)

One half of the public seating will be needed for the venire during jury selection. When the other half fills up, the marshals and court security officers will not permit the press or public to enter the courtroom until adequate space opens up. There will be no overflow courtroom with video or audio. Once the jury is sworn, there should be adequate room for all. The press and public should plan accordingly.

David Boies is quoted as stating why Oracle is asking for an injunction:

Oracle is seeking an injunction not to shut Android down, Boies said, but to force Google to pay for a license and make Android compatible with the rest of Java. Google spokesman Jim Prosser said Oracle's claims are without merit.

We'll work on getting more of these documents into text form for you -- and I'd appreciate any help, if you can, because I have to read them and think before I explain them to you [Update: we're done] -- but for now, to get things started, here's Google's 4/12/2012 Copyright Liability Trial Brief [#897], then Oracle's equivalent, Oracle's April 12, 2012 Brief Regarding Copyright Issues [#900], followed by each parties' proposed findings of fact, where they debate the API issue more specifically, as text.

So, Google's first, #897, minus the Table of Contents and Cases, which I'll add later -- meanwhile look to the PDF:

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

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

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

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

Attorneys for Defendant
GOOGLE INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

_________________

ORACLE AMERICA, INC.,

Plaintiff,

v.

GOOGLE INC.,

Defendant.

___________________

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

GOOGLE’S 4/12/12 COPYRIGHT
LIABILITY TRIAL BRIEF

Dept.: Courtroom 8, 19th Floor Judge: Hon. William H. Alsup

I. INTRODUCTION

The Court has asked for a “firm yes or no position on whether computer programming languages are copyrightable.” Order [Dkt 874] at 1. No, computer programming languages are not copyrightable. Google has never taken any other position. In addition, as requested, Google offers below a summary of some of the evidence it intends to present at trial relating to the copyrightability issues the Court has identified. See Order [Dkt. 865] at 1.

II. ARGUMENT

A. Computer programming languages are not copyrightable.

The Copyright Act defines a computer program as “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. A computer programming language is thus simply a language one can use to create a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.¹ Without a computer programming language, the set of statements or instructions cannot be understood by the computer. As such, a computer language is inherently a utilitarian, nonprotectable means by which computers operate.

This commonsense approach to the statute makes the very distinction Congress itself drew: the protectable material is the computer program (the set of statements or instructions); the unprotectable material is the method or system (the language). So understood, original computer programs may be protected, but the medium for expression in which they are created is not.

1. Computer programming languages are systems for expression, or
methods of operation for communication.

The Copyright Act bars copyright protection for an “idea, procedure, process, system, method of operation, concept, principle, or discovery,” even if it is in an “original work of authorship.” 17 U.S.C. § 102(b). This is what the Supreme Court meant when it stated that “no one would contend that the copyright of the treatise would give the exclusive right to the art or manufacture described therein.” Baker v. Selden, 101 U.S. 99, 102 (1879); see also Publications

1

Int’l v. Meredith Corp., 88 F.3d 473, 481 (7th Cir. 1996) (“The recipes at issue here describe a procedure by which the reader may produce many dishes featuring Dannon yogurt. As such, they are excluded from copyright protection as either a ‘procedure, process, [or] system.’”) (quoting 17 U.S.C. § 102(b)).

In the case of computer programs, this means that a given set of statements or instructions may be protected, but the protection does not extend to the method of operation or system—the programming language—by which they are understood by the computer. In copyright terms, the set of statements or instructions is the expression and the language used to make that expression intelligible to the machine is the method of operation or system. See Google 4/3/12 Br. [Dkt. 852] at 6, 14 (explaining that the APIs are a “system that can be used to express,” and that computer languages are uncopyrightable for the same reason).² In its reply brief, Oracle did not—and could not—dispute this point. See Oracle 4/5/12 Br. [Dkt. 859] at 3-4, 8. Oracle’s expert, too, agrees: “Programming languages are the medium of expression in the art of computer programming.” JOHN C. MITCHELL, CONCEPTS IN PROGRAMMING LANGUAGES (Cambridge Univ. Press, 2003), Trial Ex. 2507 at 3 (emphasis added).

Oracle has no response to the common sense conclusion that a computer language is a system for expression, except to argue that Section 102(b) must mean something else when it says “system.”³ Oracle’s own expert, however, has described programming languages as abstractions.

2

See id. at ix (“Programming languages provide the abstractions, organizing principles, and control structures that programmers use to write good programs.”) (emphases added).⁴ Thus even Oracle’s own expert places programming languages firmly on the unprotectable “idea” side of the idea/expression dichotomy.

2. By the same token, the APIs are not copyrightable.

The APIs at issue are integral to and part of the Java programming language. See infra Part II.B. But whether that is the case, or whether they can be separated from the Java programming language (as Oracle argues), it is undeniable that these APIs extend the language by increasing its vocabulary. See Steele at 7 (“A true library does not change the rules of meaning for the language; it just adds new words.”). Whether the collective set is called “the Java programming language” (adopting Google’s view) or perhaps “the Java programming language supercharged” (adopting Oracle’s view), it is, to use Guy Steele’s definition, “a vocabulary and rules for what a string of words might mean to a person or a machine that hears them.” Steele at 2. The whole of this collective set is thus as uncopyrightable as any programming language. The APIs, as a subset of this uncopyrightable whole, are themselves uncopyrightable. See 17 U.S.C. § 102(b).

In its April 5th brief, Oracle argues that the opinion of the ECJ Advocate General suggests that “interfaces” can be copyrighted, at least in some circumstances. See Advocate General’s Opinion, SAS Institute Inc. v. World Programming Ltd., Case C-406/10, ¶ 85 (Nov. 29, 2011). The opinion, however, uses “interface” in two senses, first referring to a file format (which it concludes is an uncopyrightable idea) and later referring to specific source code in a computer program, authored by the developer, that implements a file format (which it concludes may be copyrighted). This is entirely consistent with Google’s position.

3

The opinion first calls the file format used by SAS for data files a “logic interface.” See id. ¶¶ 77-78. “Those formats may be regarded as blank forms which are to be filled with the customer’s data by the SAS System and which contain specific locations in which particular information must be written in order for the system to be read and write the file correctly.” Id. ¶ 79. Blank forms are per se uncopyrightable under the Copyright Act. Baker, 101 U.S. at 107; 37 C.F.R. § 202.1(c).

Next, the opinion discusses how this logic interface—the file format—could be made part of a computer program, explaining that “interface” could also refer to “the elements which create, write and read the format of said SAS data files” which are “expressed in source code in the program.” SAS, Case C-406/10, op. at ¶ 82. The opinion concludes that the SAS source code that implements the file format could be protected by copyright. See id. ¶¶ 81, 82. The Advocate General opines that under EU law, WPL was nonetheless allowed to decompile this code to reverse engineer the file format, so long as WPL wrote its own code to implement the file format. See id. ¶¶ 83-90. In short, the opinion is consistent with Google’s view, and distinguishes between the idea represented by an interface, which is not copyrightable, and the source code implementing an interface, which may be protected by copyright.

That these APIs are an uncopyrightable idea, system or method of operation becomes clearer still when one focuses on precisely what Oracle claims is copyrightable: the structure, selection and organization of the APIs. A set of nonsensical APIs could be created that had exactly the same structure, selection and organization as the Oracle APIs, but that did different things. For example, the sqrt() method could always return zero—indeed, every method that returns a number could always return zero, while those that return text could always return the letter a, those that return true or false could always return true, and so on, with a default result being used for every variable type. This set of APIs would serve no useful purpose, but would have exactly the same structure, selection and organization as the Oracle APIs. No reasonable jury could ever conclude that the “expression” in this hypothetical set of APIs is substantially similar to the “expression” in the Oracle APIs, notwithstanding the “copied” structure, selection and organization. Thus, Oracle’s infringement theory fails unless it accuses not just the structure,

4

selection and organization, but also the purpose of the APIs. In other words, Oracle’s infringement claim fails unless it is allowed to copyright ideas, which it cannot do. 17 U.S.C. § 102(b); see also Anti-Monopoly, Inc. v. General Mills Fun Group, 611 F.2d 296, 300 n.1 (9th Cir. 1979) (“business ideas, such as a game concept, cannot be copyrighted”); Chamberlin v. Uris Sales Corp., 150 F.2d 512, 513 (2d Cir. 1945) (“Precisely, however, because it is the form of expression and not the idea that is copyrightable, we hold that the defendant did not infringe on the plaintiff’s statement of the rules. The similarities of the two sets of rules derive from the fact that they were necessarily drawn from the same source.”); Whist Club v. Foster, 42 F.2d 782 (S.D.N.Y. 1929) (“In the conventional laws or rules of a game, as distinguished from the forms or modes of expression in which they may be stated, there can be no literary property susceptible of copyright.”).

Indeed, Oracle now—on the eve of trial—candidly states that it claims Google’s implementing source code is a derivative work of Oracle’s English-language descriptions because Google’s source code does the things that the English descriptions describe. See Oracle 4/5/12 Br. [Dkt. 859] at 10 (Oracle is claiming infringement based on “Google’s creation of derivative works from the English-language descriptions of the elements of the API specifications”). That is nothing but an assertion that Google’s expression infringes Oracle’s ideas. Oracle thus stands as an exception to the Supreme Court’s statement that “no one would contend that the copyright of the treatise would give the exclusive right to the art or manufacture described therein.” Baker, 101 U.S. at 102.

While Oracle argues the “extremity” of Google’s position, the truly extreme position would be to allow a party to devise a system (the Java language APIs), and then enforce copyrights in descriptions of that system (Oracle’s specifications) and implementations (expressions) of that system (Oracle’s libraries) to preclude others from practicing the system. Oracle’s approach is barred by Baker v. Selden:

To give to the author of the book an exclusive property in the art described therein, when no examination of its novelty has ever been officially made, would be a surprise and a fraud upon the public. That is the province of letters-patent, not of copyright. The claim to an invention or discovery of an art or manufacture must be subjected to the examination of the Patent Office before an exclusive right

5

therein can be obtained; and it can only be secured by a patent from the government.

101 U.S. at 102. It is barred by Mazer v. Stein: “Unlike a patent, a copyright gives no exclusive right to the art disclosed; protection is given only to the expression of the idea—not the idea itself.” 347 U.S. 201, 217 (1954). It is barred by Sega Enters. Ltd. v. Accolade, Inc., under which “functional requirements for compatibility” with a system described by or implemented in a copyrighted work cannot be protected by copyright law. 977 F.2d 1510, 1522 (9th Cir. 1992).

3. Google has never taken the position that a computer programming
language can be copyrighted.

Google has never taken the position, before a court or agency or otherwise, that a programming language was or is copyrightable. Google does believe that computer source code implementing a language can be copyrighted. Google has, for example, created programming languages called “GO” and “Dart.” Google has encouraged others to use these languages for free, and has also provided an open source license for others to use Google’s source code and object code that implements these languages. This is consistent with the positions Google has taken in this case.

Google notes that Sun (now known as Oracle America) organized, formed and led the American Committee for Interoperable Systems (“ACIS”),⁵ the chairperson of which was Sun’s Deputy General Counsel, Peter M.C. Choy. In a press release after the First Circuit’s decision in Lotus v. Borland, Mr. Choy “noted that the decision will make it more difficult for vendors to attempt to lock out competitors and lock in consumers by asserting proprietary rights in certain ‘building blocks’ of software, such as programming languages, program interfaces, and the functional aspects of user interfaces.” First Circuit Lotus v. Borland decision supports interoperability, Business Wire, Mar. 10, 1995 (emphasis added).⁶ Mr. Choy was also counsel of record for an ACIS amicus brief filed with the Supreme Court, urging the Court to affirm the First Circuit’s judgment that the Lotus menu hierarchy was not copyrightable. ACIS argued that “[t]he

6

decisive issue in [the Lotus] case is whether copyright law can protect the rules that enable two elements of a computer system to work together.” 1995 WL 728487, at *3. ACIS further argued:

The 1-2-3 command structure is more than a user interface; it is the interface between the Lotus program and programs—referred to as “macros”—that are written by users at their own considerable expense for execution in connection with the 1-2-3 program. Because the 1-2-3 command structure provides the template for the macros and because the macros are the key to compatibility, the First Circuit, consistent with holdings in other circuits, ruled that those elements necessary to macro compatibility are not protected by copyright.

Id. (emphases added). Thus, while not directly taking a position on whether programming languages can be copyrighted, the brief implies that they cannot.

B. The APIs are integral to the Java programming language.

As Google has previously noted, Java’s own books describing the APIs state that they are available “to all Java programs . . . .” Trial Ex. 980 at xviii. Those books describe four of the APIs (out of eight that then existed) as “the foundation of the Java language.” Id. (back cover).

1. Without the APIs, the Java programming language is deaf, dumb and
blind.

The APIs are so fundamental that without them the Java programming language has no ability to provide any output to the user. Similarly, without the APIs, the Java programming language has no ability to accept input from the user.⁷ When Mark Reinhold, Oracle’s Chief Architect of the Java Platform, was asked why the Java language APIs exist, he testified:

Well, if there were no APIs, we would only have a language. You would be able to write basic computations that never did any IO, had any communication with the outside world or the underlying platform.

You could write—you know, you could do computations on numbers and strings and generate them, but you wouldn’t be able to do anything with them.

Reinhold 8/5/11 Depo. at 115:10-17.⁸ He further explained, “But even doing that, even just to manipulate a string requires the string API, so you’re—you’re, actually, pretty much just limited to numbers, which are pretty boring.” Id. at 115:19-22.

7

In this respect, the Java language APIs are similar to libraries associated with some older languages in the history of programming. In C, for example, input and output facilities are part of what the designers of the C language called “the standard library, a set of functions that provide input, output, string handling, storage management, mathematical routines, and a variety of other services for C programs.” BRIAN W. KERNIGHAN & DENNIS M. RITCHIE, THE C PROGRAMMING LANGUAGE (Prentice Hall, 2d ed., 1988), Trial Ex. 3002 at 151.⁹ Even the basic “hello, world”¹⁰ C program in their book requires using the standard library in order to display the words “hello, world” to the user. See id. at 6.¹¹ Similarly, Oracle’s “hello, world” program in the Java programming language includes the following source code:

System.out.println("Hello World!");¹²

“System” refers to a class that is part of the java.lang API package, and “out” is a field defined in the System class. The System class defines the “out” field as belonging to the “PrintStream” class, which is part of the java.io API package. Thus, even implementing this most basic of programs in the Java programming language requires using two of the accused APIs.

2. The APIs are fundamental to the Java programming language.

In its April 5th brief, Oracle conceded that the Java language specification requires the defineClass() method from the ClassLoader class in the java.lang package. See Oracle 4/5/12 Br. [Dkt. 859] at 7. In J2SE 5.0, the defineClass() method is an “overloaded” method; there are four versions of the defineClass() method, the fourth of which has the following method declaration:

protected Class defineClass(String name, ByteBuffer b, ProtectionDomain
protection Domain)

8

As indicated in the parentheses, the method accepts three arguments, of types “String,” “ByteBuffer” and “ProtectionDomain.” String, ByteBuffer and ProtectionDomain are classes defined, respectively, in the java.lang, java.nio and java.security APIs. Implementing this single example of a single required class thus requires implementing elements of three of the 37 APIs.¹³

This is only a single example—a single example that Oracle chose to highlight. Due to the interdependencies between classes in the APIs, expressly requiring one element often will necessarily require many others, just as the defineClass() method implicates the String, ByteBuffer and ProtectionDomain classes from java.lang, java.nio¹⁴ and java.security. Based on the classes expressly required by the Java language specification and interdependencies in the APIs, thousands of elements from the accused APIs are required in order to implement the Java programming language.¹⁵ In fact, the first edition of the Java language specification devotes over 300 pages to documentation for the java.lang, java.io and java.net packages. See Trial Ex. 4027 at 455-765. The documentation of the APIs was removed from later editions of the Java language specification only for space reasons. See Trial Ex. 984 at xxvi (“The specifications of the libraries are now far too large to fit into this volume, and they continue to evolve. Consequently, API specifications have been removed from this book.”).

9

In addition, witnesses at trial will testify that developers expect the APIs to be available when they program in the Java programming language, that the APIs are routinely taught in beginning courses regarding use of the language, and that no developer can credibly claim to be proficient in the Java programming language unless he or she knows the APIs. And, in addition to statements highlighted in prior briefs, Sun also stated, for example, that the java.lang API “provides the classes and interfaces that form the core of the Java language and the Java Virtual Machine,” and that several objects defined in java.lang are “closely intertwined with the Java language definition.” Trial Ex. 980 at xix. Oracle’s expert has testified that the Java programming language cannot be implemented without including at least some of the APIs.

Indeed, Sun described the Java programming language as follows:

The Java programming language is a general-purpose concurrent class-based object-oriented programming language, specifically designed to have as few implementation dependencies as possible. It allows application developers to write a program once and then be able to run it everywhere on the Internet.

Trial Ex. 984 at xxi (emphasis added). Because any useful program in the Java programming language requires the APIs, “the Java programming language” only allows a developer to write a program once and run it everywhere if the “language” is understood to include the APIs.

III. CONCLUSION

Computer programming languages are not copyrightable, and neither are Oracle’s APIs. Oracle accuses Google of infringement for doing what the Oracle API specifications describe. That is a classic attempt to improperly assert copyright over an idea rather than expression. The Court should hold that the structure, selection and organization of the APIs are uncopyrightable.

______________
¹ Guy Steele, an early member of the Java team at Sun, and now an Oracle Software Architect, defines a language as “a vocabulary and rules for what a string of words might mean to a person or a machine that hears them.” Guy Steele, Growing a Language (Sun Microsystems, Oct. 1998) (“Steele”) at 2, available at http://labs.oracle.com/features/ tenyears/volcd/papers/14Steele.pdf.

² Similarly, fictional languages such as Na’vi and Dothraki cannot be copyrighted. While the film Avatar and the television series Game of Thrones are copyrightable (including the portions in the fictional Na’vi and Dothraki languages), and while, for example, a dictionary or grammar textbook for either language would be copyrightable, the languages themselves are not. Oracle asks why copyright should not protect such languages, see Oracle 4/5/12 Br. [Dkt. 859] at 9; the answer is that Section 102(b) says that they are not protected. Moreover, there is no reason to believe that allowing copyright owners to control who can express themselves in these languages would further the aims of copyright law.

³ Oracle also argues that a computer language can be “original, text-based, and capable of fixation,” and thus that it must be copyrightable. See Oracle 4/5/12 Br. [Dkt. 859] at 9. First, Section 102(b) bars copyright protection for “original works of authorship” that fall within its enumerated classes of exclusion. See 17 U.S.C. § 102(b). Thus, the fact that a system is original, text-based and fixed does not mean that Section 102(b) does not apply.

Second, a language cannot be fixed. Certainly, a description of a language (e.g., a specification) can be fixed. A computer program written using the language (e.g., the Gmail application on Android phones) or an implementation of a language (e.g., a compiler or interpreter) can be fixed. But none of those things is “the language,” any more than a dictionary “is” English, Das Boot “is” German, or a C compiler “is” the C programming language. See Baker, 101 U.S. at 102 (“But there is a clear distinction between the book, as such, and the art which it is intended to illustrate. The mere statement of the proposition is so evident, that it requires hardly any argument to support it.”); cf. René Magritte, La trahison des images.

⁴ Oracle’s expert has further described designing a programming language as requiring decisions regarding what ideas to leave out. See id at 3 (“A single application also helps with one of the most difficult parts of language design: leaving good ideas out.”). And he has described studying programming languages as requiring “the study of conceptual frameworks for problem solving, software construction, and development.” Id. at 5 (emphasis added).

⁵ The organization had the same mailing address as Sun’s headquarters. At the time of the Lotus case, the ACIS website was located at http://www.sun.com/ACIS/.

⁶ Available via LEXIS-NEXIS. Sun also distributed this press release by other means. See, e.g., http://www3.wcl.american.edu/cni/9503/4860.html.

⁷ There is one minor exception. A Java language program can be written to accept arguments from the “command line” at runtime. Even this facility, however, is limited to accepting a single set of arguments at the beginning of the program.

⁸ This testimony is subject to an objection, but only that the testimony is outside the scope of the Rule 30(b)(6) topics for which Dr. Reinhold was designated.

⁹The “Standard Template Library” is a similar library that has been incorporated into the standard C++ specification.

¹⁰ The authors explain that a “hello, world” program—a program that prints the words “hello, world”—is typically the first program a developer writes when learning a language. See id. at 5.

¹¹ The authors state that “[i]nput and output facilities,” which are part of the standard library, “are not part of the C language itself . . . .” Id. 151. Even the basic “hello, world” C program they introduce, however, requires the standard library. All that is meant by their distinction between the “language” and the library is that “higher-level mechanisms must be provided in explicitly- called functions.” Id. at 2. That is, they require APIs. Notably, the authors discuss the C standard library as part of their book about the “C programming language.”

¹² See http://docs.oracle.com/javase/tutorial/ getStarted/application/index.html.

¹³ In its April 5th brief, Oracle also suggests that one could implement the defineClass() method without implementing the rest of the ClassLoader class. See Oracle 4/5/12 Br. [Dkt. 859] at 7. Oracle has repeatedly claimed that it is being irreparably harmed by alleged “fragmentation” because Google did not fully implement all of the J2SE API packages. Here, however, it appears to argue that to implement the free and open Java programming language, one should implement only part of the APIs. To the extent that Android “fragments” Java at all—and witnesses at trial will dispute this point—the approach Oracle appears to suggest would “fragment” Java far more. Further, the evidence at trial will show that Java, and particularly Java ME, was “fragmented” long before Android, and that Sun condoned this “fragmentation.”

¹⁴ Oracle argues that because some of the accused packages were not part of the initial release of Java, they cannot be fundamental or integral to the Java programming language. Languages, however, are not static. See Trial Ex. 984 at xxv (“This specification defines the language as it exists today. The language is likely to continue to evolve.”); Steele at 5 (“I now think that I, as a language designer who helps out with the design of the Java programming language, need to ask not ‘Should the Java programming language grow?’ but ‘How should the Java programming language grow?’”).

¹⁵ Oracle argues that when the Java language specification refers to APIs that are fully defined elsewhere, that means that the referenced definitions are not part of the language. See Oracle 4/12/12 Br. [Dkt 859] at 7. This is backwards. When the Java language specification “does not provide a complete specification” but refers the reader to the APIs for details, see Trial Ex. 984 at 6, the only fair conclusion is that the language specification is incorporating material by reference from the API specifications.

MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
[email]
KENNETH A. KUWAYTI (Bar No. 145384)
[email]
MARC DAVID PETERS (Bar No. 211725)
[email]
DANIEL P. MUINO (Bar No. 209624)
[email]
[address]
[phone]
[fax]

BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
[email]
[address]
[phone]
[fax]
STEVEN C. HOLTZMAN (Bar No. 144177)
[email]
[address]
[phone]
[fax]

ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email]
[address]
[phone]
[fax]

Attorneys for Plaintiff
ORACLE AMERICA, INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

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

Case No. CV 10-03561 WHA

ORACLE'S APRIL 12, 2012 BRIEF
REGARDING COPYRIGHT ISSUES

Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup

(1)

I. THE COPYRIGHT ACT PROTECTS A COMPUTER PROGRAMMING
LANGUAGE THAT MEETS THE ORIGINALITY REQUIREMENT

The parties agree no case addresses directly whether the Copyright Act protects a computer programming language. However, the most analogous case law, general copyright principles, and the statutory purposes of the Copyright Act support protection. More importantly, none of the arguments advanced for denying protection to a programming language apply to the API specifications and class libraries at issue here.

The cases that have considered works most similar to a computer programming language are those involving codes or compilations of symbols. Courts have upheld copyright protection for codes or compilations of symbols that meet the originality requirement.

In Reiss v. National Quotation Bureau, Inc., 276 F. 717 (S.D.N.Y. 1921), Learned Hand upheld copyright protection for a code book containing coined words that could be given an agreed meaning for the purpose of cable correspondence. Judge Hand compared the code to a language — "a set of words or symbols to form a new abstract speech, with inflections, but as yet with no meaning, a kind of blank Esperanto." 276 F. at 718. He saw "no reason" why the code's set of coined words could not be a "writing" protected by copyright simply "because they communicate nothing," given that "[t]hey may have their uses for all that, aesthetic or practical, and they may be the productions of high ingenuity, or even genius." Id. at 719; see also Lotus Dev. Corp. v. Paperback Software Int., 740 F. Supp. 37, 72 (D. Mass. 1990) (rejecting argument "[t]hat not only languages such as English and French but all other languages as well — including Esperanto, and Reiss' coined words, 276 F. at 718, and Pascal — are automatically ineligible for copyright protection").

Similarly, in Hatfield v. Peterson, 91 F.2d 998, 1000 (2d Cir. 1937), the Second Circuit upheld copyright protection for a telegraphic code that was a compilation of non-original words and phrases, holding "the copyright is valid because of the originality of the combination."

Courts have denied copyright protection to codes or systems of symbols only where they lack originality, not because they are inherently uncopyrightable. In Toro Company v. R & R Products, 787 F.2d 1208 (8th Cir. 1986), the Eighth Circuit rejected protection for a machine

(2)

parts numbering system because of lack of originality. But far from finding a set of symbols or a language per se an uncopyrightable system, the court explained that: "A system that uses symbols in some sort of meaningful pattern, something by which one could distinguish effort or content, would be an original work." 787 F.2d at 1213. Similarly, in Brief English Systems, Inc. v. Owen, 48 F.2d 555 (2d Cir. 1931), the court rejected a claim for exclusive right to use a published system of shorthand not because a code or language is inherently not copyrightable but only because "[t]here is no literary merit in a mere system of condensing written words into less than the number of letters usually used to spell them out." 48 F.2d at 558.

Like the code of coined words in Reiss, a computer language may qualify for copyright protection if it is sufficiently original. Indeed, to a much greater degree than the Reiss coined words, it may and typically does represent very substantial creative work of exactly the kind that copyright is intended to protect and promote, with "enough definite expression so that one may distinguish authorship." Toro, 787 F.2d at 1212.

Google argues that a programming language is "an uncopyrightable system or method of operation," "an idea, not expression." Google 4/3 Br. at 14-15. But a work that represents only one of many ways to perform a function is "the expression of a particular idea, not the idea itself." Toro, 787 F.2d at 1212; see Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240, 1253 (3rd Cir. 1983) ("If other programs can be written or created which perform the same function as Apple's operating system program, then that program is an expression of an idea and hence copyrightable.") As the Eighth Circuit explained in Toro:

All that the idea/expression dichotomy embodied in § 102(b) means in the parts numbering context is that appellant could not copyright the idea of using numbers to designate replacement parts. Section 102(b) does not answer the question of whether appellant's particular expression of the idea is copyrightable.

787 F.2d at 1212.

The fundamental "idea" of a computer programming language is to permit the user to create an arrangement of symbolic commands that will direct a computer to perform specified tasks. There may be lower-level ideas that are unprotectable as well, like a programming language directed to a special purpose, or the idea of an object-oriented language. But these ideas

(3)

can be expressed in a wide variety of specific forms. While copyrighting a computer language cannot prevent others from designing programming languages that serve the same functions, the detailed vocabulary and written expression of the computer language should be protectable elements if sufficiently original and creative.

Adobe, for example, has asserted copyright protection for its PostScript computer language, and explains:

The general idea of using a page description language is in the public domain. Anyone is free to devise his or her own set of unique commands that constitute a page description language. However, Adobe Systems Incorporated owns the copyright for the list of operators and the written specification for Adobe's Post-Script language. Thus, these elements of the PostScript language may not be copied without Adobe's permission.

Adobe Systems Inc., POSTSCRIPT LANGUAGE REFERENCE xiii and 9 (3d ed. 1999), available at http://www.scribd.com/doc/202357/PostScript-Language-Reference-Third-Edition. In asserting its copyright, Adobe has stated that one of its objectives is to "[m]aintain the integrity of the PostScript language standard." Id. at 9.

Google relies primarily on preliminary opinions in a pending English case recently referred to the European Court of Justice ("ECJ"). The ECJ has not yet responded to that referral. SAS Institute, Inc. v. World Programming Ltd., [2010] EWHC (Ch) 1829. The ECJ will not interpret the U.S. Copyright Act; it will decide the case under the extensive relevant provisions of European treaty law and the EEC Software Directive and related case law (id. at ¶¶ 149-95), as well as the legislative history of the Directive and its adoption by the European Parliament (see id. at ¶¶ 211-227). The English court referred the programming language question to the ECJ for the very reason that its resolution was not "acte clair," that is, free from reasonable doubt.

Google relies, in particular, on the opinion to the ECJ by Advocate General Opinion. Opinion of Advocate General Bot, SAS Institute v. World Programming Ltd., Case C-406/10 ("SAS Advocate General Opinion"). Google cites the following passage:

It seems to me, therefore, that programming language is a functional element which allows instructions to be given to the computer. As we have seen with SAS language, programming language is made up of words and phrases known to everyone and lacking originality. In my opinion, programming language must be regarded as comparable to the language by the author of a novel. It is therefore the means which permits expression to be given, not the expression itself.

(4)

Id. at ¶ 71 (emphasis added). This analysis ignores the obvious difference that the language used by a novelist, unlike an original computer language, is not itself the author's work of original creative expression. The novelist does not create the language in which she writes.

In concluding that a computer language is "lacking originality," Advocate General Bot's opinion is also at odds with U.S. case law. Even "[a] factual compilation is eligible for copyright if it features an original selection or arrangement of facts." Feist Publications, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 350 (1991). Copyright protection is denied based on lack of originality only to "a narrow category of works in which the creative spark is utterly lacking or so trivial as to be virtually nonexistent." Id. at 359. Unlike the white pages at issue in Feist, a typical computer programming language represents creative work in its selection and arrangement of symbols that may be sufficient to meet the "originality" requirement.

Moreover, and of more significance to this case, despite opining that a computer programming language may not be copyrightable, Advocate General Bot concluded that an interface may be. He found that the Directive "does not exclude interfaces from copyright protection" and that "if the expression of the interface constitutes a substantial part of the expression of the computer program . . . it is eligible for protection under the Directive." SAS Advocate General Opinion, at ¶¶ 81-82; see also id. at ¶ 60 (elements of a program enjoy protection "provided that they contain some of the elements which are the expression of the intellectual creation of the author of the work").

Copyright protection of a computer language is also consistent with the Copyright Act's statutory purpose to "promote the creation and publication of free expression" by rewarding authors. Eldred v. Ashcroft, 537 U.S. 186, 219 (2003) (emphasis in original). Developing an original, never-before-written language — whether a computer programming language or a newly coined language for a dramatic production such as Na'vi (from the film Avatar) and Dothraki (from the HBO series Game of Thrones) — may represent years of creative work. Copyright protection rewards and promotes those creative efforts. The estate of J.R.R. Tolkien, for example, has asserted copyright protection for Elvish and other languages used in his works. http://www.theodoramichaels.com/articles/fan-fic.php#Languages

(5)

The policy balance to apply to the idea/expression dichotomy was described by the Ninth Circuit in CDN Inc. v. Kapes, which affirmed copyrightability of a collectable coin pricing guide:

As Judge Hand noted, the difference between idea and expression is one of degree. This circuit has held that "[t]he guiding consideration in drawing the line is the preservation of the balance between competition and protection reflected in the patent and copyright laws." Rosenthal, 446 F.2d at 742. In this case, the prices fall on the expression side of the line. CDN does not, nor could it, claim protection for its idea of creating a wholesale price guide, but it can use the copyright laws to protect its idea of what those prices are. . . . Drawing this line preserves the balance between competition and protection: it allows CDN's competitors to create their own price guides and thus furthers competition, but protects CDN's creation, thus giving it an incentive to create such a guide.

197 F.3d 1256, 1262 (9th Cir. 1999) (citations omitted). Protecting the expression embodied in a computer language while allowing competitors to create their own languages with parallel purpose and function preserves the balance between competition and protection.

As demonstrated above, the best view of U.S. copyright law is that an original and creative computer language is subject to copyright protection as an "original work[] of authorship." 17 U.S.C. § 102. As far as Oracle has been able to determine, neither Oracle nor Sun has taken a contrary position on the copyrightability of computer languages.

II. HISTORY OF API DEVELOPMENT

Modern APIs owe their origins to the development of modular programming. Subroutines, first invented in 1951, divided programs into units with specific tasks. The first software libraries were collections of common, general-purpose subroutines that could be re-used in different programs. These libraries were not considered part of the language in which they were written. They were sets of reusable program modules, expressed in particular languages.

The use of an API as a specification of how software modules interact arose during the 1970s. One example from that time is prototypes written in the C programming language. Prototypes are fragments of code describing the sets of parameters to be passed to different subroutines and the types of their return values. Developers combined these code fragments with English prose specifying the behavior of the subroutines, creating API specifications similar to those written today. Other developers could learn from the API specifications how different libraries worked without having to study their underlying implementations.

(6)

The techniques of modular program development are more relevant today than ever. Professor Mitchell will testify that today's software systems are among the most complex products ever created by human beings, and APIs are the core structuring concepts software designers use to manage this complexity. (Mitchell Opp. Rep., ECF No. 397-1 ¶ 18.) Software developers often collaborate on projects from different cities or countries. (Id. ¶ 25.) They use APIs to understand the potential dependencies between different sections of code without having to know how the code for an entire project works. A developer in San Francisco, for example, can design an API for a library and then design and implement the library. A colleague in Paris need only consult the API in order to make use of that library; there is no need to know the inner workings of the library.

III. THE JAVA APIS ARE NOT PART OF THE PROGRAMMING LANGUAGE

A. A programming language and an API are distinct things with different
purposes

The evidence will show that a programming language and an API are two very different things. A programming language is an artificial language used to create programs that control the behavior of a machine. An API implementation (often referred to as a "class library") is a computer program component that consists of pre-written code. The API specification is the blueprint to the class library. It is a detailed written description of the programs that explains how the programs are structured, how they are to be used, and what they will do. For example, a library implementing a database API will provide database functions, a library implementing a networking API will provide networking functions, a library implementing a mathematics API will provide arithmetic and trigonometric functions, and so forth.

Google was never confused about the distinction between an API and a programming language when this case began or for long afterwards. Google is now straining to change course to take a position it knows is factually incorrect. At the outset, Google acknowledged that the class libraries are distinct from the Java programming language. (See ECF No. 51 at 13-14.) Google's expert stated that the Java programming language and the Java APIs are "very different things." (Astrachan Opening Rep., ECF No. 262-1 ¶ 7.) He defined an API as "a particular set of

(7)

rules and specifications that software programs can follow to communicate with each other. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers." (Id. ¶ 24.)

One area where the parties' experts agree is that there are very few classes within the Java APIs that must be present for the Java language to function. Oracle's expert will testify that "it was not necessary to include any particular class or package (beyond perhaps a very few classes like Object and Class that are tied closely to the Java language) for the Java language to function." (Mitchell Opp. Rep., ECF No. 397-1 ¶ 20.) Google's expert testified in deposition that he agrees:

Q. Paragraph 20. And Dr. Mitchell says, in around the middle of the paragraph, "It is important to realize that while the robust and elegant API specification and class libraries that implement them have been important to Java's success, it was not necessary to include any particular class or package beyond perhaps a very few classes like object and class that are tied closely to the Java language for the Java language to function." And maybe that's the missing piece here. I mean, do you have an opinion on what classes were required to be included in order for the Java language to function?

A. I think this accurately reflects what the Java language needs to function.

(9/9/11 Astrachan Dep. 230:19-231:8.)

The Java Language Specification defines what is in the Java programming language. That definition includes those few classes, but otherwise does not include these 37 API packages.

B. The Java APIs Are Deliberately Maintained Separately From The
Java Programming Language

The Java APIs are deliberately from the Java programming language. This was done very deliberately. They should not be regarded as part of the language.

One example of how the Java APIs are distinct from the Java programming language is that, while the Java programming language has changed very little since it was first released in 1996, the Java APIs have grown explosively. In 1996, there were only 7 API packages. There are now 209 API packages for Java Standard Edition ("SE") alone.

Since developers could program in Java from the time of its first release, it is obvious that these additional 202 APIs are not required to use the programming language. Many of these APIs contain highly specialized functions that would be neither expected nor, in many cases, desirable

(8)

in a general purpose programming language. This is true of most of the 37 API packages at issue in the case. Javax.net, for example, concerns a group of methods relating to creating a secure web connection. Javax.crypto, javax.crypto.interfaces, and javax.crypto.spec all relate to methods of encrypting and decrypting data. Java.text is an API package containing methods to help make a computer program usable in multiple natural languages.

The Java APIs are kept separate from the programming language for good reasons. When a programming language is created no one can predict all the ways it will be used. No one can foresee all the APIs that will be needed, and it is a mistake to build too much into the language. For example, there is no reason to build a database API into a general-purpose language like Java. As database technology improves and evolves, developers can create new APIs as needed, but the language should not also have to evolve. The C programming language is one of the most powerful and widely used languages, and it is still recognizable to programmers who used it in the 1970's, even though the uses to which the language is put have changed dramatically.

If a particular API were part of the language, then every change or addition to the API would have a ripple effect through everyone who uses or depends on the language, and would be required to implement the new features. It is for this reason that the Java language has changed only three times since it was first released and the process for changing the language is extremely deliberate and slow. Changes to the language require a super-majority vote of the entire Executive Committee of the Java Community Process and have only occurred after a lengthy public approval process. Changes to API's can be made much more quickly.

Another reason why the Java APIs are kept separate from the programming language is that Java is used to write programs for devices of very different capabilities, from powerful servers to embedded microcontrollers in single chips. Trying to implement all API elements as part of the Java language would require a heavyweight Java Virtual Machine capable of implementing every part of their functionality regardless of the device. In addition, the same API may provide different functions on different device form factors, and making every API part of the base language would make this impossible. The solution instead is to select, develop, and specify different sets of APIs suitable for different environments. This is exactly what Sun did in

(9)

the early days of Java when it divided Java into the language on the one hand and different collections of APIs on the other — Java SE (for desktops and servers), Java EE (for large scale enterprise applications), Java ME (for mobile and embedded devices).

Oracle may properly claim copyright protection over the Java APIs even if the Java programming language is freely available. The evidence at trial will show that copyright notices were prominently and consistently displayed on the API specifications. Hundreds of the world's largest companies pay to license the Java platform. Google was well aware of the requirement to license the specifications. Andy Rubin took a license to the Java specifications when he was at his predecessor company, Danger. Sun expressly rejected the notion that Danger did not require a license because Rubin had created an independent implementation, and therefore Danger paid. Rubin wrote in an internal email at Google and confirmed in his deposition that he was aware that Sun claimed copyright protection for the APIs. (TX0018; 7/27/11 Rubin Dep. 149:18-150:13.)

C. The Existence Of Java APIs And Class Libraries Besides The APIs At Issue
Shows That APIs Are Not Inherently Part Of The Language And Why
Google's Copyrightability Position Is Incorrect

The evidence will also show that there are many Java-language APIs and class libraries, available from a wide variety of sources, that are also not considered part of the Java programming language.

A good example is Android itself. Android has many APIs besides the 37 packages that give rise to copyright liability in this case. Many of them have the same purpose as some of the Java SE APIs Google did not copy.¹ Google provides compatibility test suites for its licensees to confirm that they are compatible with its APIs using those test suites. But this does not mean that any given Android API is part of the Java programming language. Oracle's Java APIs should not be analyzed differently.

Beyond Android, the world is full of Java APIs and libraries. None are considered to be part of the Java language either. The website freecode.com lists over 1,100 different Java

(10)

libraries. See http://freecode.com/tags/java-libraries. Many third parties provide class libraries and APIs for specialized Java applications like financial trading. For example, competitors IBM and BEA jointly developed a series of API specifications to create a common data programming environment for their competing server products. And scores of other companies create their own libraries and APIs internally so they can re-use code.

Google's position is that none of these APIs could ever be copyrighted because "APIs are not copyrightable, regardless of the programming language." (See ECF No.778 at 6-7 ("all API specifications, by design, describe precisely the elements of APIs that are needed for compatibility between implementations of the APIs, and with programs that use the APIs").) This does not make sense or comport with the law. The class libraries are copyrightable as a computer program, and their selection, arrangement and structure is copyrightable if sufficiently original and creative. The written description of those class libraries is copyrightable as well.

IV. HOW APIS ARE VIEWED IN OTHER LANGUAGES

The class libraries and APIs in other computer languages are generally not viewed as part of the programming language, even when a core set of APIs is specified in the same document as the programming language specification. The size and richness of these libraries varies widely. For example, C++, an object-oriented programming language similar in some ways to Java, was associated with a much smaller set of libraries. As a result, several different entities have created more comprehensive libraries and APIs, including the Standard Template Library and the Boost C++ Libraries. The Perl programming language also comes with a small set of libraries, called subroutine modules. However, over 100,000 additional modules are available separately in the CPAN Archive. See http://www.cpan.org/index.html. The Python software platform took the opposite approach and comes with an extensive set of libraries even larger than Java's, yet the Python documentation is clearly divided into separate descriptions of the language and the libraries. Even with such a large set of built-in libraries, over 20,000 additional packages are available at the Python Package Index. http://pypi.python.org/pypi.

(11)

Dated: April 12, 2012

MORRISON & FOERSTER LLP

By: /s/ Michael A. Jacobs

Attorneys for Plaintiff
ORACLE AMERICA, INC.

(12)

1	This shows the Java APIs are expression, not ideas, since there are corresponding APIs that implement the same idea (e.g., a library to handle screen displays and user interactions) but have different designs.

And here is Oracle's Proposed Findings [#902], the meat of it, minus the header and footer, as text:

Oracle submits the following proposed findings relating to the issue of the copyrightability of the selection, organization, and structure of the API specifications and associated implementations in class libraries for the 37 packages at issue in this case (collectively “APIs”). (See ECF No. 877).

Proposed Findings

1. The APIs include thousands of individual elements, organized into packages, classes, interfaces, exceptions, constructors, methods, and fields. There is an intricate relationship of hierarchies and dependencies among elements within and across packages.

2. The detailed selection, organization, and structure in the API specifications is mirrored in the source code and object code implementation in the Java class libraries.

3. The APIs represent years of creative design. The selection, organization, and structure of the elements and names in the APIs are each highly original and creative.

4. Oracle had many choices for what elements and names to include in the APIs. Other than a few classes, Oracle was not required to include any particular element or name.

5. There were many different ways to organize and structure the APIs.

6. A primary purpose of the selection, organization, and structure of the APIs is to make them more comprehensible and easier to use for programmers.

7. The selection, organization, and structure of the APIs is the detailed expression of an idea, not an idea itself. An idea for an API package may be to have a library of pre-written computer code relevant to the area of programming to which the package relates.

8. That selection, organization, and structure is not commonplace, and was not an indispensable or standard way of expressing any idea.

9. Other than a few classes, Google was not required to copy the selection, organization, and structure of the APIs to be compatible with the Java programming language.

10. It was not technically necessary for Google to copy the APIs. Google designed many of its own APIs for Android.

11. Android is not compatible with Java. Many programs written for one will not run on the other.

12. The specifications and implementations of the APIs are not a method of operation or system.

1. An API consists of a set of names that can be used to access features of a library, together with specified conventions about their use.

2. API specifications, by design, describe the structure, selection and organization (“SSO”) of API elements needed for compatibility between implementations of the APIs, and with programs using the APIs.

3. The 37 APIs are fundamental to the Java language.

4. Developers learn the 37 APIs when they learn the Java language.

5. Developers treat the 37 APIs as part of the Java language.

6. The Java language cannot be implemented without many of the 37 APIs.

7. Without the 37 APIs, the Java language cannot perform basic tasks, e.g., receiving input from and providing output to the user, or processing text strings.

8. The 37 APIs and their SSO are how developers access the implementing code in the 37 API packages, and thus the functionality provided by that code.

9. Developers cannot use the 37 APIs without relying on their SSO.

10. The SSO of the 37 APIs are functional requirements for compatibility with the 37 APIs.

11. The 37 APIs cannot be implemented without their SSO.

12. Code using different APIs with different SSO than the 37 APIs will not be compatible with the 37 APIs.

13. The design of the 37 APIs and their SSO is constrained by external factors including functionality, efficiency and ease of use.

14. The 37 APIs and their SSO build on previous programming languages and long-accepted conventions.

15. The 37 APIs and their SSO are a system of expression developers use when programming in the Java language.

16. For years before this litigation, Sun was aware of, and did not object to, use of the 37 APIs and their SSO in GNU Classpath, Apache Harmony and Android.

And here's the Oracle list of what it is and isn't accusing Google of infringing, its Exhibit A, attached to filing #899:

MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
[email]
KENNETH A. KUWAYTI (Bar No. 145384)
[email]
MARC DAVID PETERS (Bar No. 211725)
[email]
DANIEL P. MUINO (Bar No. 209624)
[email]
[address]
[phone]
[fax]

BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
[email]
[address]
[phone]
[fax]
STEVEN C. HOLTZMAN (Bar No. 144177)
[email]
[address]
[phone]
[fax]

ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email]
[address]
[phone]
[fax]

Attorneys for Plaintiff
GOOGLE INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

_________________

ORACLE AMERICA, INC.,

Plaintiff,

v.

GOOGLE INC.,

Defendant.

___________________

Case No. CV 10-03561 WHA

ORACLE’S STATEMENT OF ISSUES
REGARDING COPYRIGHT

Date: April 16, 2011
Dept.: Courtroom 8, 19th Floor Judge: Hon. William H. Alsup

Pursuant to the Court’s request (ECF No. 854), Oracle America, Inc. hereby provides the following summary of its copyright infringement allegations to be tried:

What Oracle accuses of copyright infringement are:

1. The Android documentation for the 37 API packages listed below, including the selection, arrangement, and structure of all API elements (including names) in that documentation. Oracle alleges that Google copied an estimated 103,400 lines¹ from the Java API specifications into Android’s documentation.

1. java.awt.font
2. java.beans
3. java.io
4. java.lang
5. java.lang.annotation
6. java.lang.ref
7. java.lang.reflect
8. java.net
9. java.nio
10. java.nio.channels
11. java.nio.channels.spi
12. java.nio.charset
13. java.nio.charset.spi
14. java.security
15. java.security.acl
16. java.security.cert
17. java.security.interfaces
18. java.security.spec
19. java.sql
20. java.text
21. java.util
22. java.util.jar
23. java.util.logging
24. java.util.prefs
25. java.util.regex
26. java.util.zip
27. javax.crypto
28. javax.crypto.interfaces
29. javax.crypto.spec
30. javax.net
31. javax.net.ssl
32. javax.security.auth
33. javax.security.auth.callback
34. javax.security.auth.login
35. javax.security.auth.x500
36. javax.security.cert
37. javax.sql

2. The selection, arrangement, and structure of all API elements (including names) of the Android class library source code and object code that implements the 37 API packages.

3. The declarations of the API elements in the Android class library source code and object code that implements the 37 API packages.

4. The Android class library source code and object code that implements the 37 API packages as derivative works of the Java API specifications, including the English-language descriptions.

5. Two Android source code files (and corresponding object code), TimSort.java and ComparableTimSort.java, which are part of Android’s implementation of the 37 API packages.

2

6. Eight Android source code files (and corresponding object code), AclEntryImpl.java, AclImpl.java, GroupImpl.java, OwnerImpl.java, PermissionImpl.java, PrincipalImpl.java, PolicyNodeImpl.java, AclEnumerator.java, which are not part of Android’s implementation of the 37 API packages.

7. Comments contained in two Android source code files, CodeSourceTest.java and CollectionCertStoreParametersTest.java, which are not part of Android’s implementation of the 37 API packages.

The tangible medium or media of expression in which the above are fixed are electronic storage media and printed documentation.

What Oracle does not accuse of copyright infringement are:

1. Android’s use of the Java programming language.

2. Any particular name of an API element, including names for each package, class, exception, field, method, and parameter name, considered individually.

3. The Android source code implementing the APIs contained in the 37 packages at the line-by-line level, except as set forth above.

4. The idea of APIs.

5. The Dalvik virtual machine (without associated class libraries).

6. Android API packages and associated class libraries other than the 37 API packages and associated class libraries listed above.

7. Other Android source code and object code except as set forth above.

_____________
¹ Oracle calculated this estimate by counting the lines of a sample of the Android documentation.

3

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

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

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

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

Attorneys for Defendant
GOOGLE INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

_________________

ORACLE AMERICA, INC.,

Plaintiff,

v.

GOOGLE INC.,

Defendant.

___________________

Case No. CV 10-03561-WHA

GOOGLE’S PROPOSED
STATEMENT OF ISSUES
REGARDING COPYRIGHT

Date: April 16, 2011
Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup

Pursuant to the Court’s request (ECF No. 854), Google Inc. hereby provides its proposed statement of Oracle’s copyright infringement allegations:

Oracle accuses the following of copyright infringement:

1. 37 API packages in the Android class library source code, as well as the corresponding object code implementing those APIs, but only as to their selection, structure, and organization (it being conceded that the implementing source code and object code are different). Oracle claims that the tangible medium or media of expression in which the selection, structure and organization of the 37 APIs are fixed are electronic storage media and printed documentation.

2. The declarations of the API elements in Android class library source code and object code that implements the 37 API packages.

3. The English-language Android documentation for the 37 API packages, sometimes called the API “specifications.” Oracle alleges that approximately 103,400 lines in Google’s Android documentation were copied from Oracle’s Java API specifications.

4. The Android class library source and object code as derivative works of Oracle’s English-language documentation of the 37 API packages.

5. 12 Android files of source code (copied from 11 Java files):

a. The nine-line rangeCheck function and four lines of related comments in two Android source code files, TimSort.java and ComparableTimSort.java, as well as the corresponding object code. This method is part of Android’s implementation of the 37 API packages.

b. Eight Android source code files—AclEntryImpl.java, AclImpl.java, GroupImpl.java, OwnerImpl.java, PermissionImpl.java, PrincipalImpl.java, PolicyNodeImpl.java, AclEnumerator.java—which are not part of Android’s implementation of the 37 API packages.

c. Twenty English-language comments contained in two Android source code files, CodeSourceTest.java and CollectionCertStoreParametersTest.java, which are not part of Android’s implementation of the 37 API packages.

2

Oracle does not accuse the following of copyright infringement:

1. Android’s use of the Java programming language.

2. The names of the API elements, including the names of files, packages, classes, methods, fields, exceptions, and parameters.

3. The Android source code implementing the APIs contained in the 37 packages, with the exception of rangeCheck and the declarations of the API elements.

4. The ideas underlying the APIs.

5. The Dalvik virtual machine (not including the associated class libraries).

6. Android APIs and associated class libraries other than the accused 37 API packages and associated class libraries.

7. Android source and object code except as listed above.

3

Dated: April 12, 2011

KEKER & VAN NEST LLP

By: Robert Van Nest
[Attorney Name]

[See PDF for lawyer list.]

4