Source: http://www.groklaw.net/articlebasic.php?story=20120413141851964
Timestamp: 2019-04-24 04:54:51+00:00

Document:
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's position, to me, is like an admission that the elaborate license rules about Java aren't in harmony with copyright law, and never were, and never will be unless Oracle can get the court to change the law. Some of us always thought that the rules were not sustainable, by the way.
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.
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.
That process could take a couple of hours. Reuters is reporting that Michael Jacobs will be doing the opening statement for Oracle. David Boies is busy with the Oracle litigation against SAP. Reuters also says Oracle is seeking billions, but that's not the case. It also quotes a lawyer as saying most of the pretrial motions have gone Oracle's way, but I'd disagree with that. I think it's the opposite, actually, particularly as we got closer to trial.
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.
So that may explain some of the extreme positions, trying to muscle a company that doesn't respond to bullying favorably.
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.
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.
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.1	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.
methods of operation for communication.
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).2	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.”3	Oracle’s own expert, however, has described programming languages as abstractions.
See id. at ix (“Programming languages provide the abstractions, organizing principles, and control structures that programmers use to write good programs.”) (emphases added).4	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.
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.
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.
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).
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.
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).
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.8	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.
“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.
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.nio14 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.15	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.”).
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.
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.
1 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.
2 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.
3 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. René Magritte, La trahison des images.
4 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).
5 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/.
6 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.
7 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.
8 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.
9The “Standard Template Library” is a similar library that has been incorporated into the standard C++ specification.
10 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.
14 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?’”).
15 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.
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."
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.
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.
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.
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.,  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.
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.
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").
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.1 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.
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.
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.
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.
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).
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.
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 lines1 from the Java API specifications into Android’s documentation.
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.
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.
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.
1 Oracle calculated this estimate by counting the lines of a sample of the Android documentation.
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.
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. 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.

References: § 101
 v. 
 § 102
 § 102
 v. 
 § 202
 § 102
 v. 
 v. 
 v. 
 v. 
 v. 
 § 102
 v. 
 v. 
 v. 
 v. 
 § 102
 v. 
 v. 
 § 102