The parties have responded to the Court's request for supplemental briefs on certain copyright issues. The Google brief addresses the issue of whether Apache Harmony, and its incorporated APIs, are subject to a field-of-use restriction imposed by Sun. (831 [PDF; Text]) Oracle's brief addresses the applicability of Baker v. Selden. (833 [PDF; Text])

Google asserts that Sun's field-of-use restriction only arose if you licensed the Java technology development kit (TDK) to assure compatibility between your version of Java and the standard version produced by Sun, and if you took that license and assured compatibility, you were then licensed to use Sun's Java trademark to reference your compatible version. The Apache Foundation was never willing to license the TDK under those conditions, never did so, and refrained from calling or referencing Harmony as Java. As a consequence, Harmony has never been subject to the TDK field-of-use restrictions, and Sun never attempted to enforce those restrictions against Apache. Assuming the API implementations used by Google are those found in Apache, and given that Google does not refer to Android as Java or Java-compatible, this would appear to be a compelling argument.

Oracle, in turn, draws a distinction between the facts and findings in Baker v. Selden and subsequent cases pertaining to computer software which would appear to run counter to Baker. It is these subsequent cases, suggests Oracle, that control, not Baker. This, again, is a point where I get confused (and based on Judge Alsup's questions noted below, I am not alone), and I think I get confused because Oracle continues to try to confuse.

On one hand, Oracle has argued that the implementation of the API's are protected by copyright as derivative works of the API specifications, the documents that tell one how to build the code implementation of the API. On the other, (and in this case, in support of their argument against Baker) Oracle appears to argue that the content of the APIs is, in its own right, protected by copyright. I disagree as to the first of these arguments because it is that which I believe is knocked out by Baker, i.e., you cannot extend the copyright protection of one work (the specification) to the implementation of the idea of that work in a second work (the API implemented in code). As to the second argument, that the API implemented in code is independently protected by copyright, you have to separate out those portions of the code that are protectable under copyright from those that are not, the abstraction-filtration-comparison test that even Oracle acknowledges (although they have previously argued that it should not be applied). To me, a significant question with respect to the implementations is whether their structure, arrangement, and selection is driven by the choice of the implementer or by direction of the specification. In any case, Oracle has previously raised most of the points advanced in this supplement.

The Court has also now asked the parties to address a number of additional questions with respect to the copyright issues. (829 [PDF; Text]) Those questions or requests and the party(ies) directed to respond to them are:

Illustrate the interdependencies and relationships between and among the 37 APIs in suit and other packages. [Both]

How many APIs does Java contain beyond the 37 asserted APIs? [Both, although principally Oracle]

How many APIs does Android contain beyond the 37 asserted APIs? [Both, although principally Google]

Can the "structure, arrangement, and selection" of APIs be protected by patent law? [Both]

If the "structure, arrangement, and selection" of APIs was not copyrightable under Section 102(b) [of the Copyright Act], what is left for the jury to decide at trial regarding the API claims (specifications and implementation)? [Both]

Are the 37 APIs necessary (theoretically or practically) for using the Java programming language? [Both]

Are the 11 copied code files part of the 37 accused APIs? [Both]

Is Oracle asserting that Google copied the source code implementing the APIs? [Oracle]

Is Oracle claiming that Google's source code implementation of the Android APIs is a derivative work of the Java API specifications? [Oracle]

What is Oracle's answer to Google's point in reply that the copyright registrations do not create a presumption as to the copyrightability of the APIs? [Oracle]

Are there any aspects of the APIs that Oracle concedes are unprotectable by copyright? [Oracle]

Does Google admit to copying the structure, arrangement, and selection of the Java APIs? [Google]

Are the 11 copied source code files now removed from Android? [Google]

Some of these questions have been answered before, such as the last one (Google has said on numerous occasions that those 11 copied files have been removed). The parties are to address these questions today at the final pretrial conference.

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF CALIFORNIA

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

No. C 10-03561 WHA

NOTICE RE DISCUSSION ITEMS AT
FINAL PRETRIAL CONFERENCE

At the final pretrial conference on Wednesday, March 28, both sides should be prepared
to address the following.

A. Questions For Both Parties.

Illustrate the extent to which the 37 APIs in suit actually have “an elaborate set of
interdependencies and relationship within and across different packages,” as argued by Oracle.
Specific examples and charts showing how API X ties into API Y will help. A list of all such
interdependencies from each API to all others (of the 37) will be appreciated. In addition to
the 37 APIs in suit, how many more official Java APIs are available? Relatedly, how many more
official Android APIs are available? Can the “structure, arrangement, and selection” of APIs be
protected by patent law? If the “structure, arrangement, and selection” of APIs was not
copyrightable under Section 102(b), what is left for the jury to decide at trial regarding the API
claims (specifications and implementation)? Are the 37 APIs necessary (theoretically or
practically) for using the Java programming language? Are the 11 copied code files part of the
37 accused APIs?

B. Questions For Oracle.

By claiming that Google infringes the API implementation, is Oracle alleging that
Google copied the source code implementing the APIs? Is Oracle also claiming that Google’s
source code implementation of the Android APIs is a derivative work of the Java API
specifications? What is Oracle’s answer to Google’s point in reply that the copyright
registrations do not create a presumption as to the copyrightability of the APIs? Are there any
aspects of the APIs that Oracle concedes are unprotectable by copyright?

C. Questions For Google.

Does Google admit to copying the structure, arrangement, and selection of the Java
APIs? Are these 11 source code file removed from Android?

IT IS SO ORDERED.

Dated: March 27, 2012.

/s/William Alsup
WILLIAM ALSUP
UNITED STATES DISTRICT JUDGE

831

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

The Court has asked Google to address Oracle's contentions regarding an alleged field-of-use restriction and its purported applicability to the Apache Harmony project. As explained below, the Apache Software Foundation ("Apache") licenses Apache Harmony to the public without any field-of-use restrictions, and rejected Sun's attempt to impose such a limit on the use of Apache Harmony. Notwithstanding these facts, Sun has never sued Apache, and has never asserted that the use of the Apache Harmony libraries is conditioned on a field-of-use limitation. To the contrary, Jonathan Schwartz, Sun's CEO at the relevant times, has testified that Apache Harmony can be used for any purpose so long as the resulting product is not called "Java." There is no field-of-use restriction on the use of Apache Harmony. Oracle's field-of-use restriction argument is a red herring.

I. The Apache Harmony project was launched in August 2005, and licensed without
any field-of-use restrictions.

In August 2005, Apache announced the Apache Harmony project, the goal of which was to create an open-source product compatible with J2SE. This project followed open-source efforts by other groups to achieve the same goal, such as GNU Classpath from the Free Software Foundation. Apache licenses Apache Harmony to the public for free under version 2 of the open source Apache License. This license does not have any field-of-use restrictions.1

II. Apache never agreed to a field-of-use restriction, and Sun never objected to the use
by Apache and others of the Hava language APIs.

1See, Apache License, Version 2.0, available athttp://www.apache.org/licenses/LICENSE-2.0.html. Version 2. of the General Public License, the open source license that governs use of GNU Classpath, similarly has no field0of0use restriction. See General Public License, Version 2.0, available at http://www.gnu.org/licenses/gpl-2.0.html.

1

[REDACTED]

Schwartz Dep. at 49:11-50:10; see also id at 47:17-23 [REDACTED] However, "In order to call your product Java, and in order to feature to the marketplace that you were a Java phone or a Java device and to get that brand, you needed to pass that the -- the TCKs, the Testing [sic] Compatibility Kits." Id. at 46:17-21.

Starting in August 2006, Apache attempted to obtain from Sun a license to the J2SE 5.0 technology compatibility kit ("TCK"). The license to the TCK (i.e., to the suite of compatibility tests) that Sun offered to Apache would have limited the use of Apache Harmony to certain fields of use. Apache, however, never agreed to such a limitation.

In May 2007, with no TCK license in place for Apache Harmony, Schwartz publicly stated, "there is no reason that Apache cannot ship Harmony today." Trial Ex. 2341; Schwartz Depl. at 51:15-22. According to Schwartz, however, Apache, "wanted, in fact, to be able to call Harmony Java. And we held firm and said no, that's our core value. If you want to call it Java, you can pay, you know, the fee to go run the test and compatibility kits, and that enable you to tell your customers that you actually had a licensed Java runtime. But absent that statement, they, you know, couldn't say that, and they were frustrated by it." Schwartz Dep. at 52:16-23.

In June 2007, Apache wrote an open letter to Sun, requesting a TCK license without a field-of-use restriction. That same month, in an effort spearheaded by Oracle Corporation, twelve signatories, including a Google Engineering VP, urged Schwartz to grant Apache an unencumbered TCK license. See Trial Ex. 2347. Sun, however, refused. Because Apache was unwilling to agree any field-of-use restriction, it did not license the TCK. As a result, Apache did not agree to -- and never has agreed to -- a field-of-use limitation for Apache Harmony.

The lack of a TCK license, however, did not prevent others from use Apache Harmony:

[REDACTED]

2

[REDACTED]

Schwartz Dep. at 83:15-84:7. Even without at TCK license, "[a]nybody else who wanted to go create their own runtime, whether it was Apache Harmony or GNU Classpath, was free to do so; they just couldn't call it Java." Id. at 182:2-5. Mr. Schwartz will testify that commercial products from IBM and Hewlett-Packard used the Apache Harmony implementation fo the Java language APIs without objection from Sun.

III. There is no field-of-use restriction for Apache Harmony.

The dispute between Apache and Sun was about branding, and the ability to say that Apache Harmony is Java compatible. The end result was that Apache did not agree to a field-of-use restriction. Notwithstanding Apache's refusal to limit the field of use for Apache Harmony, Sun never sued Apache. In fact, Sun's CEO has testified that anyone can use the Apache Harmony code (and thus its implementation of the Java language API specifications) -- so long as it does not call its product "Java."

Finally, Google in any event does not call Android "Java." Google has used the term "Java" in its nominative, non-brand sense to describe, for example, how developers can use the free and open Java programming language to write applications for the Android platform. That, however, is not an attempt to brand the Android product "Java." Indeed, Oracle's complaint does not include a trademark infringement count. Oracle's field-of-use restriction argument is irrelevant and should be rejected.

Dated: March 27, 2012

KEKER & VAN NEXT LLP

/s/Robert A. Van Nest
By: ROBERT A. VAN NEST

Attorneys for Defendant
GOOGLE INC.

3

833

NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

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

Case No. CV 10-03561 WHA

ORACLE’S MARCH 27, 2012
SUPPLEMENTAL BRIEF
REGARDING COPYRIGHT ISSUES

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

The Court has asked Oracle to address the applicability of Baker v. Selden, 101 U.S. 99
(1879). (ECF No. 827.) The short answer is that Baker provides at most a starting point for the
general idea/expression dichotomy in copyright law. This case is fundamentally different, and
Baker was decided in a different legal context. Google stretches Baker far beyond its holding.

The Copied Works In Baker Contained Very Little Expression. The copied works at
issue here and in Baker lie at opposite ends of the factual spectrum. In Baker, the defendant used
forms containing “ruled lines and headings” similar to those in a book-keeping system described
in plaintiff’s copyrighted book. Baker, 101 U.S. 101. The Court described its holding as follows:

The conclusion to which we have come is, that blank account-books are not the
subject of copyright; and that the mere copyright of Selden’s book did not confer
upon him the exclusive right to make and use account-books, ruled and arranged
as designated by him and described and illustrated in said book.

Id. at 107. These “blank account-books” could hardly be more simple. Seehttp://lcweb2.loc.gov/service/rbc/rbc0001/2011/2011gen155867/2011gen155867.pdf (displaying
forms from files of Baker case). Even so, the defendant used “a different arrangement of the
columns, and use[d] different headings.” Baker, 101 U.S. at 100. The Court found that the forms
were “necessarily incident” to the plaintiff’s book-keeping system. Id. at 103.

The 37 APIs at issue are the opposite of blank forms. They encompass an enormous
amount of creative expression. (See, e.g., ECF No. 780 at 1-2.) Google copied from them
verbatim, and they are not “necessarily incident” to anything. Google’s expert admits it was not
technically necessary for Google to copy them. In fact, Google designed many of its own APIs.

The distinction in the level of expression of the works at issue is critical. Even cases that
cite Baker recognize it is only a starting point for analyzing this issue. In Computer Assocs. Int’l,
Inc. v. Altai, Inc., for example, the Second Circuit stated: “While Baker v. Selden provides a
sound analytical foundation, it offers scant guidance on how to separate idea or process from
expression, and moreover, on how to further distinguish protectable expression from that
expression which ‘must necessarily be used as incident to’ the work’s underlying concept. 982
F.2d 693, 705 (2d Cir. 1992) (quoting Baker, 101 U.S. at 104). The court then applied a detailed
abstraction-filtration-comparison test. See id. at 706-11.

1

In applying a similar analysis to determine the copyrightability of a computer user
interface, the Fifth Circuit also emphasized that the key issue is expression:

A user interface may often shade into the “blank form” that epitomizes an
uncopyrightable idea, Baker v. Selden, 101 U.S. 99, 25 L. Ed. 841 (1880), or it can
partake of high expression, like that found in some computerized video games.

Eng’g Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335, 1344 (5th Cir. 1994). The court
distinguished the input/output formats in the user interface from the forms in Baker, finding they
could have been structured in “numerous ways,” and that plaintiff had “proved original
expressive content in the selection, sequence and coordination of inputs.” Id. at 1344-46.

Baker Was Decided In A Different Legal Context.Baker was also decided in a
fundamentally different legal context. The forms at issue related to a book-keeping system,
which did not itself enjoy protection under copyright law:

It cannot be pretended, and indeed it is not seriously urged, that the ruled lines of
the complainant’s account-book can be claimed under any special class of objects,
other than books, named in the law of copyright existing in 1859. The law then in
force was that of 1831, and specified only books, maps, charts, musical
compositions, prints and engravings. An account-book, consisting of ruled lines
and blank columns, cannot be called by any of these names unless by that of a
book.

Baker, 101 U.S. at 101. The Court drew a distinction between the plaintiff’s book, which was
copyrightable, and the book-keeping system it described, which was not. Id. at 102 (“But there is
a clear distinction between the book, as such, and the art which it is intended to illustrate.”).

Here, the API specifications are part of the documentation of a computer program, which
is expressly subject to protection under the Copyright Act. 17 U.S.C. § 101. They describe the
structure of that computer program in great detail, and the Ninth Circuit has held that the structure
of a computer program is copyrightable. Johnson Controls, Inc. v. Phoenix Control Sys., Inc.,
886 F.2d 1173, 1175 (9th Cir. 1989) (“Whether the non-literal 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.”). Google cannot simply rely on Baker to contend that
“any person may practice and use” the APIs. (ECF No. 823 at 3.) Nimmer sharply criticizes
trying to use Baker for this type of blanket statement, emphasizing that the focus must always

The APIs Are Not An Uncopyrightable “System.” The APIs are also not a “system,”
as Google now argues. Google never even explains what it means by “system.” In Am. Dental
Ass’n v. Delta Dental Plans Ass’n, Judge Easterbrook rejected the notion that a code for dental
procedures was a system: “A dictionary cannot be called a ‘system’ just because new novels are
written using words, all of which appear in the dictionary. Nor is word-processing software a
‘system’ just because it has a command structure for producing paragraphs.” 126 F.3d 977, 980
(7th Cir. 1997). The court found the dental code copyrightable, after discussing Baker v. Selden.
See id. at 981. But regardless of how Google labels them, the APIs are copyrightable because of
their expressive content. Far less creative structures are entitled to copyright protection in this
Circuit. See, e.g., CDN Inc. v. Kapes, 197 F.3d 1256, 1262 (9th Cir. 1999) (prices in guide for
collectible coins); Practice Mmgt. Info. Corp. v. Am. Med. Ass’n, 877 F. Supp. 1386, 1390 (C.D.
Cal. 1994), aff’d in relevant part, 121 F.3d 516 (9th Cir. 1997) (numerical codes for medical
procedures); Jacobsen v. Katzer, 2009 U.S. Dist. LEXIS 115204, at *9-10 (N.D. Cal. Dec. 10,
2009) (text files reflecting decoder information from model railroad manufacturers).