Source: http://www.groklaw.net/articlebasic.php?story=2011091011343331
Timestamp: 2019-04-20 23:16:08+00:00

Document:
Google has a pending motion for summary judgment 260 [PDF] on the issue of the copyright claims asserted by Oracle, which we first discussed here. The parties have been filing their respective positions on this motion starting with Google.
the specifications for thirty-seven Android Java language API packages (the "Accused Packages") "are unauthorized derivative work" and are "derived from or substantially similar to" the corresponding Java language API specifications contained in the Oracle's asserted works.
Google argues that any similarity between these Android specifications and Oracle's Java specifications are unprotected by copyright because they relate to functional elements.
APIs are unprotectable methods of operation.
As long ago as 1879, the Supreme Court made clear that publication of a book that explains a particular accounting system gives the author no rights under the copyright laws to prevent others from using the system, as long as no protectable expression from the book is copied. Baker v. Selden, 101 U.S. 99 (1879); see also 17 U.S.C. § 102(b) ("In no case does copyright protection . . . extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."). Oracle's Java language books and API specifications give Oracle no greater rights to prevent implementation by others of the APIs using original code.
This principle applies equally in the computer context. In Lotus Development Corp. v. Borland Int'l, Inc., the court reversed a summary judgment against a defendant that developed a competing program that copied the words and structure of Lotus's menu command hierarchy in its spreadsheet program (but not the underlying source code). 49 F.3d 807 (1st Cir. 1995), aff'd by an evenly divided court, 516 U.S. 233 (1996). The court found the menu command hierarchy to be functional and uncopyrightable. Id.
files. Id. at 817-18. "The fact that there may be many different ways to operate a computer program, or even many different ways to operate a computer program using a set of hierarchically arranged command terms, does not make the actual method of operation chosen copyrightable; it still functions as a method for operating the computer and as such is uncopyrightable." Id. at 818; see also 17 U.S.C. § 102(b) (method of operation is unprotectable "regardless of the form in which it is described, explained, illustrated, or embodied").
The same reasoning applies to APIs for a programming language. See Astrachan Decl., Ex. 1 ¶¶ 91-98 (explaining why the Java language APIs are methods of operation). By providing Android API packages addressing many of the same common methods that are provided by Oracle's Java language API packages, Google has ensured that programmers using the Java language need not learn a new way to call these methods when writing programs for both the Java and the Android platforms. See id. ¶¶ 129-33. For example, to make use of the functionalities of the java.lang.Math class in the java.lang API package, a programmer would use the appropriate method name from the java.lang.Math class, such as "sqrt()," to calculate the square root of a number. Id. ¶ 25. When the program is run by the user, the underlying platform will then perform the "sqrt()" functionality and return the appropriate data. Id. This is no different from executing a menu command to perform a spreadsheet function. See Lotus, 49 F.3d at 816 ("If specific words are essential to operating something, then they are part of a 'method of operation' and, as such, are unprotectable."). Oracle has not even tried to allege that the underlying program logic in Android that performs this function was copied from the Asserted Works. See supra, Part II.D. It would be "absurd" to require that Android use, for example, different names than Oracle did for common mathematical methods, or for Android to group mathematical methods in different packages than Oracle did. "[F]orcing the user to cause the computer to perform the same operation in a different way ignores Congress's direction in § 102(b) that 'methods of operation' are not copyrightable." Lotus, 49 F.3d at 818.
methods of operation. "If, arguably, the command codes are considered part of the computer program in the call controller then their sole purpose is to provide access to the functions available in the call controller. Thus, they provide the means to access or operate the program contained in the software." Id. at 1055. Like the command codes in Mitel, the Java language APIs at issue constitute unprotectable methods of operation. At their most abstract level, their purpose is to provide access to common functions of language that are frequently used by programmers consistent with a published and familiar Java language API specification. See Astrachan Decl., Ex. 1 ¶¶ 129-33.
The purpose of the Copyright Act is "[to promote the Progress of Science and useful Arts . . . ." U.S. CONST. art. I, § 8, cl. 8. To accomplish this goal, others must be allowed "to build freely upon the ideas and information conveyed by a work." Feist, 499 U.S. at 350. As the Lotus court recognized, "[i]n the context of methods of operation, . . . 'building' requires the use of the precise method of operation already employed; otherwise, 'building' would require dismantling, too." 49 F.3d at 818; see also Sega, 977 F.2d at 1522 (citing § 102(b) for the proposition that "functional requirements for compatibility" are not protected by copyright).16 It is undisputed that the program logic (other than elements of the 12 files addressed below in Part III.B) for the Accused Packages was not copied. Because the API specifications are methods of operation, they are not protected by copyright.
While Google makes other relevant arguments with respect to the alleged infringement (some, like their argument with respect to file naming, stronger than others, such as their arguments with respect to scenes a faire and fair use), this is the key argument on the issue of infringement.
No court has ever found that the APIs for a complex software platform like Java are ineligible for copyright protection. Google asks this Court to find that all application programming interfaces are uncopyrightable as a matter of law ─ regardless of their expressive content ─ because they are supposedly “methods of operation” that are simply “functional requirements for compatibility.” (See, e.g., Google Mot. at 1, 13-14.) Google’s request is not just unprecedented, it is contrary to Ninth Circuit law, which calls for an examination of the particular facts of each case, to distinguish unprotectable ideas from copyrightable expression. The Java APIs that Google copied are complex, creative, and expressive. They are not simply dictated by functionality or compatibility requirements. They pass the test for copyrightability in this Circuit.
The burden is on Google to show the APIs it copied do not contain copyrightable expression because Oracle registered the copyrighted works at issue, which include the API specifications and the code.
This is absolutely wrong. The mere fact that you register a copyright in your work does not give rise to copyright protection in every line of code in your work. You still have to work your way through the work to eliminate that which is purely functional (or otherwise not protected by copyright) before determining whether copying has occurred.
C. The Java language APIs are methods of operation.
The Java language APIs are the means by which developers can access the functionality of the Java language libraries. They are, in a very literal sense, methods for operating portions of the only works that Oracle pleaded in its Amended Complaint, namely versions 1.4 and 5.0 of the Java 2 Standard Edition platform (the “Asserted Works”). The APIs define the precise statements that must used for developers to access the functionalities in the Java language libraries. The APIs are thus unprotectable methods of operating the Java language libraries. 17 U.S.C. § 102(b); see also PAUL GOLDSTEIN, GOLDSTEIN ON COPYRIGHT § 10.5.1 (3d ed. 2011) (courts have “categorically excluded copyright protection for interface specifications”).
expression where there is none.
Oracle repeatedly mischaracterizes the APIs, implying that they contain creative expression. Oracle is wrong.
According to Oracle, the APIs “tell” how to use the libraries. Opp. at 2:27. Oracle is wrong. The APIs do not “tell” how to use the libraries, they are the means by which one uses the libraries; the documentation for the APIs “tells” how to use the libraries.
According to Oracle, the APIs are the “blueprint” for the libraries. Id. at 3:5-6. Oracle is wrong. Unlike a blueprint, which states in detail how to build a structure, the APIs merely define the functions that the libraries implement. The proper analogy would be to a summary building plan that identifies the rooms that are to be included and other functional requirements, but does not describe implementation details. As Oracle’s expert acknowledges, the APIs are an “abstraction.” Mitchell Decl., Ex. 2 ¶ 23.
According to Oracle, the APIs “describe” the fields and methods in the library classes. Id. at 3:11. Oracle is wrong. The documentation might “describe” the fields and methods, but an API merely identifies the fields and methods that are included.
In short, the APIs are not the libraries themselves, and they do not “describe” or “tell” how to operate the libraries. Instead, the APIs are the methods of operating the libraries. And, by definition, methods of operation are not creative expression within the meaning of the Copyright Act. See 17 U.S.C. § 102(b).
2. Oracle’s examples of “creativity” in the design of APIs are examples of form following function, and thus militate against copyrightability.
Oracle argues that the design of good APIs requires skill and creativity, and that as a result its APIs are copyrightable. But that is not the law: “Original and creative ideas . . . are not copyrightable . . . .” ATC Distribution Group, Inc. v. Whatever It Takes Transmissions & Parts,Inc., 402 F.3d 700, 707 (6th Cir. 2005) (citing 17 U.S.C. § 102(b)). Moreover, functional aspects of a work are not copyrightable. Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1524 (9th Cir. 1993) (citing 17 U.S.C. § 102(b)). The functional and factual aspects of a work may be copied, “as may those expressive elements of the work that ‘must necessarily be used as incident to’ expression of the underlying ideas, functional concepts, or facts.” Id. (quoting Baker v. Selden, 101 U.S. 99, 104 (1879)). Consistent with these core copyright principles, a work that is “largely functional” receives only weak protection under the Copyright Act. 977 F.2d at 1527.
The aspects of API design that Oracle points to in support of its claim of creativity all focus on enhancing the functionality of APIs. Oracle argues that well-designed APIs are “easier to learn and use” (Opp. at 3:23-24), and “almost disappear from sight” (id. at 4:1, quoting Swoopes Decl., Ex. 21). Oracle argues, in effect, that form follows function in well-designed APIs. But designing for functionality is the very antithesis of creative expression.
a. The selection of elements to include in a set of APIs is not copyrightable.
Oracle argues that its selection of API elements is protected. Opp. at 12:23-25 (“If the designer includes too little, the developers will not have the tools and flexibility they prefer. If the designer includes too much, the APIs become overwhelming and difficult to use.”). These arguments are immaterial because they do not make the APIs protectable. Determining what features are “must have” features may well require creative insights into the needs of programmers. Determining the point at which the cost of increasing difficulty of use outweighs the benefits of increased options may require refined judgment calls. But the feature set that results from this process is not a creative expression. Instead, it is a designer’s best guess at the optimal feature set for a product. Whether that notion is called an idea, a system, or a method of operation, it is not protected by copyright. See 17 U.S.C. § 102(b); see also Matthew Bender & Co., Inc. v. West Pub. Co., 158 F.3d 674, 682 (2d Cir. 1998) (finding “[t]he creative spark is missing where . . . the author made obvious, garden-variety, or routine selections . . . .”).
Oracle’s theory would lead to absurd results. If feature sets in software were copyrightable, then competitors could not include the same feature set in their software. Moreover, Oracle concedes that the Android class libraries do not include all of the Oracle API elements, and that Android includes many API elements that the Oracle APIs lack. See Opp. at 20:27-21:1. Thus, under Oracle’s theory, merely having a partially overlapping feature set would constitute infringement. Such a result would allow developers to misuse copyright to claim monopoly control over entire product areas. This is precisely what the idea-expression dichotomy, on which copyright law is premised, is designed to prevent.
Because the Java language APIs and their elements are functional, Google (and others) could have freely implemented all of the Java language APIs. But those elements are functional (and thus unprotectable) regardless of whether Google implemented all of them, or only some. Google’s decision to implement only a subset of the APIs cannot transform those APIs into protectable expression. Similarly, the presence in Android of additional APIs that are not part of the Java platform cannot change the unprotectable nature of the Java language APIs, and does nothing to detract from Google’s non-infringement argument. The Borland spreadsheet, for example, included commands not present in the Lotus 1-2-3 spreadsheet. See Lotus v. Borland, 49 F.3d 807, 810 (1st Cir. 1995), aff’d by an evenly divided court, 516 U.S. 233 (1996).
b. The structure for a set of APIs is not copyrightable.
Oracle also argues that “designing the appropriate structure” for a set of APIs results in creative expression. Opp. at 12:17. Oracle claims that the structure “is critical to the programmer,” and that, depending on the structure chosen, an API can be “your organization’s biggest asset” or can “even turn your users toward your competitor.” Id. at 13:6-19. These arguments are irrelevant to copyrightability. Not everything of value or competitive advantage is protected by copyright. Copyright protection is limited to original and creative expression of the types eligible for protection under the Copyright Act.
The structure chosen by the designers of Oracle’s APIs is functional, not creative expression. To make use of the APIs, developers must know, among other things, the package, class, and subclass to which the methods belong; the parameters the methods take; the order of the parameters; the fields the data structures use; and how those fields are arranged. All of those features are necessary elements of the methods by which developers access the functionality in the libraries. Astrachan Decl., Ex. 1 ¶¶ 129-33; Reply Astrachan Decl., Ex. 4 ¶ 26.
What Oracle has now filed is an unredacted version of its response and opposition to the motion for summary judgment on the issue of copyright. 396 [PDF] Although we reproduce the document and Dr. Mitchell's supporting declaration in their entirety below, the essential arguments in the earlier redacted version are the same, and quite frankly, in my opinion not made any stronger here.
The copyright infringement issue is ripe for summary judgment. There appears to be little, if any, dispute on the facts, only on the application of the law to those facts.
whether the copyright protection of a specification extends to an implementation of that specification.
This last point has always been critical to Sun's business model around JAVA, and to my knowledge it has never been fully tested in court. This may be the time.
The copying in this case is undisputed. Over a period of many months, Google employees and contractors sat down and duplicated, line by line, the specifications for Oracle’s application programming interfaces (“APIs”) for Java. When they were finished, they had reproduced specifications for 37 APIs from Java’s core libraries that were identical, or nearly identical to Oracle’s, and they had copied those specifications into Android code.
APIs are one of the most important aspects of a complex modern software program like Java. The Java APIs, in particular, serve as the guide to, and set forth the structure of, an extensive set of class libraries that provide developers with pre-packaged code they call upon during their programming. The choice of what to include in the APIs and how to arrange them requires creativity and skill. The 37 APIs contain thousands of different elements, arranged in a unique structure, with many interdependent relationships. They readily meet the standard for copyright protection. Google, in fact, claims copyright protection for its own APIs.
Google nonetheless urges the Court to hold that all APIs are not copyrightable as a matter of law. No court has ever done so. Google’s request is contrary to Ninth Circuit law, which provides that the copyrightability of the non-literal components of a computer program is to be examined on the particular facts of each case.
Google also asks the Court to excuse its copying on the ground that it was required for compatibility. But Google undermined the compatibility of Java. It took the APIs it wanted, to attract developers to Android and gain market share quickly, and left those it did not &#1048902; fragmenting Java and its “write once, run anywhere” promise.
Google also engaged in line-for-line copying of Oracle’s source code, object code and comments in 12 separate programs. Google says it should be given a pass, claiming the copying is de minimis. It is not. Each program is entitled to protection as a separate work, and Google copied a substantial portion of each – and in most cases the entire program. And when combined with the copying of the APIs, Google’s copying is significant even for Java as a whole.
Google’s motion does not dispute copyright ownership or that copying took place. And the parties’ experts agree that copying the APIs had great value to Google – Google’s expert goes so far as to say that Google’s copying was “essentially required.” (ECF No. 262-1, Astrachan Ex. 1 ¶¶ 130-136.) But the parties dispute many other points, including: whether the APIs contain copyrightable expression; the substantial similarity of the API specifications; the significance of Google’s copying of the APIs and code; whether Google was required to copy the APIs for compatibility purposes; whether Android should be considered a transformative use; the impact on the potential market for and value of, Oracle’s copyrighted work; and the propriety of Google’s conduct. These disputed issues preclude summary judgment.
The APIs in question support Java’s “class libraries.” The class libraries Sun wrote help developers program more quickly and efficiently by enabling them to call upon certain prewritten “classes,” so that they do not have to write them from scratch. (Mitchell Opening Report ¶¶ 51-52.) The APIs tell the programmer how to use the library, and include a set of names that can be used to access different features of the library, together with conventions about their use.
Java’s class libraries include thousands of “methods” that are accessible through the APIs. Java’s APIs and class libraries were designed to be extensive from the start. In 1996, for example, the libraries were documented in a 1650 page book called The JavaTM Class Libraries: An Annotated Reference. (Id. ¶ 51.) These libraries have been become even larger over time.
The APIs Contain Many Original and Creative Elements. The Java APIs are the blueprint to the class libraries. They are not just a list of names and methods, but an extraordinarily complex structure of hierarchy and interdepency.
Good APIs are hard. We all recognize a good API when we get to use one. Good APIs are a joy to use. They work without friction and almost disappear from sight: the right call for a particular job is available at just the right time, can be found and memorized easily, is well documented, has an interface that is intuitive to use, and deals correctly with boundary conditions.
Google decided to roll the dice and push ahead with Java.
1 Oracle is not asserting infringement of 14 other packages that appear in both Java and Android that were copied by Google because Oracle uses these packages under license from third parties, or allows third parties to use these packages under permissive terms.
Android’s Source Code Is Derived From The Copied API Specifications. Google also implemented the copied API specifications into Android source code. Google tries to downplay the significance of this, acknowledging only that it copied the “names of packages and methods and definitions.” (Google Mot. at 16:15-17.) In fact, Google copied the entire hierarchical and organizational structure of the APIs into the Android source code.
Google copied Oracle’s copyrighted Java object code in 8 additional files in their entirety. Using a decompiler, Google used the Java object code to generate source code for Android. (Mitchell Opp. Report ¶¶ 89-90; Mitchell Opening Report ¶ 242.) The source code for these eight Android programs is nearly identical on a line-by-line basis to files decompiled from Oracle files JDK5, which is available for download from Oracle’s website. (Mitchell Opening Report ¶¶ 241- 243, Exs. Copyright-J-Q (side by side comparison of 8 files).
The copying did not stop there. Two more Android files contain a series of comments that are nearly identical to comments in corresponding Java files. (Mitchell Opening Report ¶ 249.) The comments are compared side-by-side at Mitchell Opening Report Exhibits Copyright R-S.
Notably, Google requires its OEMs to maintain the full set of Android APIs – including the 37 APIs it copied from Oracle - to prevent fragmentation of the Android platform. Android’s license is similar to Java’s providing, among other things, that “[d]evice implementations MUST NOT omit any managed APIs,” “MUST NOT modify the publicly exposed APIs on the Android platform,” and “MUST NOT add any publicly exposed elements…to the APIs.” (Mitchell Opp. Report ¶ 115.) Google itself, of course, has done all of these things to the Java APIs.
I. GOOGLE’S WHOLESALE COPYING AND IMPLEMENTATION OF JAVA API SPECIFICATIONS IS COPYRIGHT INFRINGEMENT.
requirements for compatibility.” (See, e.g., Google Mot. at 1, 13-14.) Google’s request is not just unprecedented, it is contrary to Ninth Circuit law, which calls for an examination of the particular facts of each case, to distinguish unprotectable ideas from copyrightable expression. The Java APIs that Google copied are complex, creative, and expressive. They are not simply dictated by functionality or compatibility requirements. They pass the test for copyrightability in this Circuit.
A. Ninth Circuit Law Requires An Analysis Of The Particular Expressive Content Of A Copyrighted Computer Program.
Whether the nonliteral components of a program, including the structure, sequence and organization and user interface, are protected depends on whether, on the particular facts of each case, the component in question qualifies as the expression of an idea, or an idea itself.
Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2d 1173, 1175 (9th Cir. 1989).
In analyzing the “particular facts,” the Ninth Circuit stated in Apple Computer, Inc. v. Microsoft Corp. (“Apple I”) that “[u]sing analytic dissection and, if necessary, expert testimony,” the court should separate protectable expression from unprotectable ideas to determine whether a work is entitled to copyright protection. 35 F.3d 1435, 1443 (9th Cir. 1994).
that, even if code is expressive, it is unprotectable if it can be characterized as a “method of operation.” The Ninth Circuit has never adopted Lotus’ approach, and other circuits have refused to follow it. Moreover, Lotus is factually distinguishable.
Lotus addressed the copyrightablity of the menu in Lotus 1-2-3. See Lotus Dev. Corp. v. Borland Int’l, Inc., 49 F.3d 807 (1st Cir. 1995), aff’d by an evenly divided court, 516 U.S. 233 (1996).2 “Accepting” the district court’s finding that Lotus made expressive choices in designing the menu, the court concluded nonetheless that the menu was uncopyrightable because it was a “method of operation” under 17 U.S.C. § 102(b). Id. at 816. The court defined “method of operation” broadly, as “the means by which a person operates something.” Id. at 815.
The Lotus court’s definition of an unprotectable “method of operation” is perilously close to the definition of a computer program under the Copyright Act, which “is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” 17 U.S.C. § 101. The exception proposed by Lotus threatens to swallow the rule whole.
In Apple Computer, Inc. v. Formula Int’l, Inc., 725 F.2d 521, 523-24 (9th Cir. 1984), the Ninth Circuit rejected the argument that computer operating systems programs - programs “designed to manage the computer system” - are uncopyrightable because they are only “ideas” or “processes” under 17 U.S.C. § 102(b). Examining the Copyright Act and its legislative history, the court upheld the district court’s finding that the Copyright Act “extends protection to all computer programs regardless of the function which those programs perform.” Id. at 523.
The copyright status of the written rules for a game or a system for the operation of a machine is unaffected by the fact that those rules direct the actions of those who play the game or carry out the process. Nor has copyright been denied to works simply because of their utilitarian aspects. . . .
2 The affirmance of a decision by an equally divided Supreme Court is not precedential. See Exxon Shipping Co. v. Baker, 554 U.S. 471, 484 (2008).
That the words of a program are used ultimately in the implementation of a process should in no way affect their copyrightability.
Id. at 524 (quoting CONTU Report at 21 (emphasis in Ninth Circuit opinion)). See also Toro Co. v. R & R Prods. Co., 787 F.2d 1208, 1210-11 (8th Cir. 1986) (citing House Report); 1 Nimmer on Copyright § 2.03[D] (same).
We conclude that although an element of a work may be characterized as a method of operation, that element may nevertheless contain expression that is eligible for copyright protection. Section 102(b) does not extinguish the protection accorded a particular expression of an idea merely because that expression is embodied in a method of operation at a higher level of abstraction.
Mitel, 124 F.3d at 1372. The court went on to analyze whether the plaintiff’s 4-digit code hardware interface contained original, protectable expression and concluded it did not. Id. at 1373-76; see also Brown Bag Software v. Symantec Corp., 960 F.2d 1465, 1477 (9th Cir. 1992) (suggesting “screens, menus and keystrokes” may be copyrightable); Gen. Universal, 379 F.3d at 142 (stating “menu structures” are copyrightable).
The Lotus case is also factually distinguishable. It concerned a consumer-friendly set of 50 menus with a simple hierarchy. 49 F.3d at 809. This type of simple user menu cannot compare to the Java APIs, which are “designed for programmers and are designed to provide and describe a very rich development environment.” (Mitchell Opp. Report ¶ 18.) They contain thousands of elements, layers of complex interdepencies, data structures, and numerous expressive choices that are not dictated by function.
are among the most complex artifacts ever created by man, and the use of APIs is the core structuring concept that software designers use to manage their complexity.” (Id. ¶ 18.) They cannot be dismissed as “non-expressive” methods of operation.
B. Google Cannot Meet Its Burden Of Showing That The Java APIs Do Not Contain Copyrightable Expression.
The burden is on Google to show the APIs it copied do not contain copyrightable expression because Oracle registered the copyrighted works at issue, which include the API specifications and the code. (See Swoopes Decl. Ex. 18.) “In judicial proceedings, a certificate of copyright registration constitutes prima facie evidence of copyrightability and shifts the burden to the defendant to demonstrate why the copyright is not valid.” Biberro Sys., Inc. v. Colwell, Inc., 893 F.2d 1104, 1106 (9th Cir. 1990); see also Swirsky, 376 F.3d at 851 (“Because [the work] has a valid certificate of registration with the copyright office…[plaintiff] is entitled to a presumption of originality.”). Google cannot meet this burden.
1. Copyright Law Protects the Original Expression in the Selection, Coordination and Arrangement Of the Java APIs.
Copyright law protects expression in software design, including the selection and structure of software elements. Google’s motion glosses over this issue, but selecting what to include in an API, and designing the appropriate structure to contain it, takes a great deal of creativity and skill.
exec() that differ only in their parameter lists. (Mitchell Opening Report ¶¶ 185-186.) While giving developers as many parameters as possible provides for greater flexibility, often the better choice is to establish a set order and limit the options. (Mitchell Opp. Report ¶ 22.) The API designer must make this type of creative choice at every level of the API.
These design choices are handled differently by different API designers. Even for ideas such as storing and manipulating collections of data as a single unit - ideas common across many programming platforms - there are many expressive choices. (See Mitchell Opening Report ¶¶ 193-199.) The collections hierarchies for Java, C++, and Smalltalk, for example, all of which have the same purpose, follow very different organizational schemes and use different language to describe their elements, as is illustrated pictorially in Exhibit 4 to the Mitchell Declaration. (Id.; see also Mitchell Decl. Ex. 4 (comparative diagram).) The differences between the collections hierarchies represent the different expressive choices made by the API designers.
Google has cited no decision holding that the structure of a computer program with this level of complexity and interdepency is precluded from copyright protection. Decisions have, however, recognized the copyrightability of programs with much simpler structures. For example, in Autoskill, the Tenth Circuit upheld a district court’s finding of likelihood of success on copyrightability of the “organization, structure and sequence” of a computer program designed to teach reading skills, including a “keying procedure” that required students to respond by pressing the 1, 2 or 3 keys. Autoskill, Inc. v. Nat’l Educ. Support Sys., Inc., 994 F.2d 1476, 1492, 1495 n. 23 (10th Cir. 1993). Similarly, in CMAX/Cleveland, Inc. v. UCR, Inc., 804 F. Supp. 337, 355 (M.D. Ga. 1992), the court held that the file structures for a software program design for companies in the “rent to own” business constituted copyrightable expression. See also Eng’g Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335, 1345-46 (5th Cir. 1994) (rejecting argument that input data formats in structural engineering software program did not contain original expression because they were purportedly “organized in a particular fashion to effectuate the performance of mathematical calculations”).
Google understands the creativity and importance of APIs. It asserts copyright and other intellectual property rights over its own APIs. (Swoopes Decl. Exs. 23-25.) These rights were applied for and maintained during the tenure of long time Google CEO and current Chairman Eric Schmidt. Google quotes extensively from Mr. Schmidt’s 1994 testimony advocating against copyrightability, identifying him only as the “Sun CTO.” (See, e.g., Google Mot. at 1.) As this shows, there is a distinction between what a person advocates the law should be and what it is.
2,427 methods, 893 fields, and other elements (see Purdy Decl. Ex. A, Purdy Opening Report ¶¶ 13-17) did not come about due to the existence of limited language.
Google cites Merchant for the proposition that “isolated field names” are not entitled to individual protection. (Google Mot. at 17:22-26 (quoting Merchant, 2009 U.S. Dist. LEXIS 25663, at *44).) But in that case the court denied summary judgment, holding that “the coordination, selection, and arrangement of these field names, as well as the fields and field types themselves . . . may be entitled to protection as a compilation so long as they ‘are numerous enough and their selection and arrangement original enough that their combination constitutes an original work of authorship.” Merchant, 2009 U.S. Dist. LEXIS 25663, at *46 (citation omitted).
Similarly, in CMAX/Cleveland, the plaintiff accused the defendant of copying file layouts and file names, among other elements. 804 F. Supp. at 337. After trial, the court ruled for the plaintiff, rejecting the argument that “the programs are only similar in their file names and the sequence of the field names within each file,” holding that “selection and arrangement of the field definitions within the files . . . are the expression of an idea.” Id. at 354. The selection and arrangement of the fields in the Java APIs are likewise expressive.
to satisfy originality is for the author to contribute ‘something more than a merely trivial variation.’” Swirsky, 376 F.3d 841 at 851 (internal citation and quotation omitted).
Moreover, even if this Court were to find that some of Google’s cherry picked examples of names are unoriginal, “a claim of copyright infringement can be based on infringement of a combination of unprotected elements.” Dream Games of Ariz., Inc. v. PC Onsite, 561 F.3d 983, 988 (9th Cir. 2009). At a minimum, the issue of whether the thousands of names that Google copied were original is a triable issue of fact. See id. (triable issue as to originality of song).
C. The Scenes A Faire And Merger Doctrines Do Not Apply Here.
Google misapplies the scenes a faire and merger doctrines. The merger doctrine provides that when there are so few ways of expressing an idea that “an idea and its expression are indistinguishable, or ‘merged,’ the expression will only be protected against nearly identical copying.” Apple I, 35 F.3d at 1444 (citations omitted). The “closely related” scenes a faire doctrine provides that when certain features are “as a practical matter indispensable, or at least standard, in the treatment of a given [idea], they are treated like ideas and are therefore not protected by copyright.” Id. (internal quotation and citations omitted).
Google nonetheless argues that courts “have routinely emphasized that compatibility is a legitimate aim, and can override claims for infringement under either the scenes a faire or fair use doctrines.” (Google Mot. at 15.) But Google’s scenes a faire argument is backwards. The proper test under scenes a faire or merger is whether Oracle was constrained in its choice of design because of the need to be compatible with some other product or standard, not Google. See Control Data Sys., Inc. v. Infoware, Inc., 903 F. Supp. 1316, 1323 (D. Minn. 1995) (question is whether external factors limited choices available to plaintiff’s programmers, not defendant’s).
Google argues the APIs are not expressive because it decided to copy certain features from them in order to be compatible. (Google Mot. at 16). But Google’s choice to copy does not alter the APIs’ expressive nature. Google cites the lower court’s decision in Mitel, holding that the defendant’s copying was justified by “efficiency reasons” and “dictated by external factors” because its technicians were used to the plaintiff’s code. (Id.) But in upholding the lower court’s decision for other reasons, the Tenth Circuit chastised the court for incorrectly applying the law, stating that the proper focus “should have remained upon the external factors that dictated [plaintiff’s] selection of registers, descriptions, and values,” rather than on whether external factors “justified [defendant’s] copying.” Mitel, 124 F.3d at 1375.
Baystate Techs. v. Bentley Sys., 946 F. Supp. 1079 (D. Mass. 1996) does take Google’s approach, but cannot be squared with Ninth Circuit law on the scenes a faire and merger doctrine. See Apple I, 35 F.3d at 1444. Moreover that court is in the First Circuit, and was bound by the Lotus decision. Just as importantly, Baystate, and the other case Google cites, Bateman v. Mnemonics, 79 F.3d 1532 (11th Cir. 1996), are factually distinguishable. Baystate involved a much simpler data translator that converted between different file formats, thus requiring an identical data organization to plaintiff’s program. See 946 F. Supp. at 1088. Bateman involved reverse engineering to create a new platform that was compatible with preexisting hardware and applications. See 79 F.3d at 1540. Google did not need to copy the APIs for compatibility with Java, nor did it do so. Rather, Google took the APIs it wanted and wrote its own in place of the rest, destroying compatibility through fragmentation. Bateman held that any finding relating to compatibility “will depend on the particular facts of a case,” and remanded the district court’s decision so that a jury could consider whether compatibility constrained expression. 79 F.3d at 1547 n.32 (11th Cir. 1996). Notably, the court held: “It is an incorrect statement of the law that interface specifications are not copyrightable as a matter of law.” Id. at 1547.
D. Google Copied The APIs.
following their complex design to the letter. (See Swoopes Decl. Ex. 3 at 14:7-11, 65:8-66:16, 64:8-20; Mitchell Opening Report ¶¶ 209-29; Mitchell Opp. Report ¶¶ 77-81.) 17 U.S.C. §§ 101, 106(2).
Google claims that “some” of the Android core libraries “were in part derived” from Apache Harmony, an open source project. (Google Mot. at 5:14-6:8.) Even if true, they were also derived from Oracle. Android’s lead core library developer has admitted that he “consulted Sun’s website for the API specifications when doing the work for Google.” (See Swoopes Decl. Ex. 3 at 65:8-66:16; see also Ex. 2 at 161:12-20.) In addition, Google was well aware of Sun and Apache’s highly publicized dispute over whether Harmony code would be licensed for use in mobile devices, and so could not have believed using the Harmony code gave it any kind of mobile device license from Sun. (See, e.g., Ex. 1 at 119:13-122:4.) But it does not matter in any event. A defendant is liable when he copies, with or without a license, from a third party who copied from the plaintiff. See, e.g., Pye v. Mitchell, 574 F.2d 476, 481 (9th Cir. 1978).
Oracle prevails under either standard. Google copied the 37 Java API specifications verbatim or nearly verbatim, incorporating their same hierarchical structure. (See Mitchell Opening Report ¶¶ 200-208, Exs. Copyright-A-F.) Google apparently disputes the substantial similarity between the specifications. (See Google Mot. at 24.) If Oracle presents “‘indicia of a sufficient disagreement concerning the substantial similarity of [the] two works,’ then the case must be submitted to a trier of fact.” Swirsky, 376 F.3d at 844. The expert testimony and documentation submitted by Oracle in support of this opposition more than satisfy that standard.
Google also gets the law wrong, comparing the copyrighted works with Android as a whole. (See Google Mot. at 24-25.) It does not matter what else Google added. “No plagiarist can excuse the wrong by showing how much of his work he did not pirate.” Shaw v. Lindheim, 919 F.2d 1353, 1362 (9th Cir 1990) (quoting 4 Nimmer on Copyright § 13.03[B][a])).
E. Google’s Copying Was Not Fair Use.
Google’s copying cannot be excused as fair use. At best, Google’s defense raises material questions of fact that cannot be decided on summary judgment.
Google’s fair use argument relies heavily on the Ninth Circuit’s decisions in Sony and Sega - two cases with very different facts that raise very different policy concerns. The focus of the court’s inquiry in both cases was whether it was fair use to reverse engineer a copyrighted product where “disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted [work].” See Sega Enters., Ltd. v. Accolade, Inc., 977 F.2d 1510, 1527-28 (9th Cir. 1993); Sony Computer Entm’t, Inc v. Connectix, 203 F.3d 596, 603-04 (9th Cir. 2000). But here, Oracle’s APIs were in plain view for anyone to see, so there was no need to copy them to discover their functional elements.
Another key to both decisions was that they concern intermediate copying only. The final product was not alleged to infringe the copyright. See Sega, 977 F.2d at 1527-28; Sony, 203 F.3d at 604 n.7. As the Ninth Circuit noted in Sega, “[o]ur conclusion does not, of course, insulate [defendant] from a claim of copyright infringement with respect to its finished products.” 977 F.2d at 1528. Here, of course, Oracles accuses the final Android APIs and code of infringement. The reasoning in Sega and Sony does not apply. The four statutory factors are discussed below.
Purpose and Character of Use – An express part of this first factor, which Google fails to address, is “whether [the] use is of a commercial nature or is for nonprofit educational purposes.” 17 U.S.C. § 107(1). (See Google Mot. at 19-20.) Google’s use is clearly commercial. This “tends to weigh against a finding of fair use.” Campbell v. Acuff-Rose, 510 U.S. 569, 585 (1994) (citation omitted).
medium – the personal computer – the court found the work to be only “modestly transformative.” 203 F.3d at 606. Google copied the Java APIs to use them the same way Oracle does by licensing an operating system to computer and mobile device manufacturers. The use has no transformative value. But if it has any at all, it is even less than the “modest” value in Sony.
When the allegedly transformative nature of Android is weighed against commercial use, this case comes out on the opposite side from Sony. In Sony, the Ninth Circuit concluded that the modestly transformative use was not outweighed by the fact that the use was commercial because: (1) there was no copyright infringement in the final product, so commercial use was only “indirect or derivative” and (2) it produced a product that “would be compatible” with Sony Playstation games. Id. at 607 (quoting Sega, 977 F.2d at 1522). Neither factor is present here.
First, the final product infringes here, so commercial use is not “indirect or derivative.” See Atari Games Corp. v. Nintendo of America, Inc., 975 F.2d 832, 843 (Fed. Cir. 1992) (fair use copying “must not exceed what is necessary to understand the protected elements” and “does not justify extensive efforts to profit from replicating expression”) (applying Ninth Circuit law).
From the start, Sun and Oracle have offered licenses to the Java APIs for parties who agree to completely implement the APIs in a compatible way. That is a key reason why Java is so successful. But the only way to enforce this type of licensing regime is if courts enforce the copyright. Google claims it conferred a “public benefit” because it took the copyrighted works and incorporated them into the “open source Android platform.” (Google Mot. at 19-20). This self-serving argument is untenable. If a party can freely ignore the copyright and fragment the platform, as Google has, compatibility in the marketplace will be severely undermined. Allowing copying that creates an incompatible end product is against the public interest.
The purpose and character of Google’s use weighs strongly against it. At a minimum, it raises factual issues that should go to a jury.
Nature of the Copyrighted Work – Google cites Sega for the proposition that “computer programs are ‘essentially utilitarian’” in nature, and that, “if a work is largely functional, it receives only weak protection.” (Google Mot. at 20 (citing Sega, 977 F.2d at 1527).) Google leaves out the line immediately above, which states: “To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer’s choice of program structure and design may be highly creative and idiosyncratic.” Sega, 977 F.2d at 1524. That is the case with the Java APIs. Moreover, Sega found the work deserved a lower degree of protection was because it contained “unprotected aspects that cannot be examined without copying.” Sega, 977 F.2d at 1526. There is no such issue here.
Google also contends that because Apache Harmony and GNU Classpath offer open source versions of the Java APIs, the inclusion of the Java APIs in Android could not be harmful. (Google Mot. at 22.) But Google knows that Harmony did not obtain a needed license from Sun (see, e.g., Swoopes Decl. Ex. 1 at 119:12-122:4), and that Classpath is licensed to others under the GPL, which has important restrictions that limit its commercial application.
II. GOOGLE AND ITS AGENTS LITERALLY COPIED MULTIPLE PROGRAMS, SOURCE CODE SECTIONS, AND COMMENTS.
extend to each constituent part of that work.”). If this were not so, programmers could steal files at will from large software programs, hiding under the de minimis cover.
First, Google copied eight machine code files in their entirety. (Mitchell Opening Report ¶¶ 241-248, Exs. Copyright-J-Q.) There is no question of significance to the work as a whole. Google copied the entire work. Moreover, Google’s quotations from Newton are taken from a portion of the opinion analyzing infringement under the “fragmented literal similarity” test, which is only applied when “the defendant copies a portion of the plaintiff's work exactly or nearly exactly, without appropriating the work’s overall essence or structure.” Newton, 388 F.3d at 1195. (See also Google Mot. at 22-23.) That is not the case here. The whole work was taken.
Second, two Android source code files include a copied method that is identical right down to the spacing of the “rangeCheck” method in Oracle’s Arrays.java. (Mitchell Opening Report ¶¶ 233-240.) rangeCheck is only nine lines long, but it is qualitatively significant to Arrays.java, the Oracle file in which it is located, and which is a separate work. While Arrays.java comprises 3,180 lines of code, rangeCheck “is called nine times” by other methods in the class, showing this small piece of code is important. (Id. ¶ 235.) In contrast, in Newton, the accused infringer had sampled a qualitatively insignificant portion of a four-and-a-half-minute composition &#1048902; just three notes. Newton, 388 F.3d at 1191. Dr. Astrachan dismisses rangeCheck as a mundane “sanity check,” but it appears to make some atypical choices in its reporting of error conditions. (See Mitchell Opp. Report ¶ 86.) A reasonable juror could find it is not as “common, trite, and generic” as a three-note sequence (C-D flat-C) was in Newton.
they are not “functional,” can represent one of the most expressive elements of a computer program. (Id. ¶ 249.) They are significant to the works from which they were taken.
But even if the Court were to look beyond the individual works to measure the significance of Google’s copying, summary judgment would still be inappropriate. A “use is de minimis only if the average audience would not recognize the appropriation.” Newton, 388 F.3d at 1193. Given Google’s nearly identical line-by-line copying of hundreds of lines of code, there is at least a triable issue of fact as to whether the average audience would recognize the appropriation. Id. at 1189. And in evaluating whether the copying was de minimis, all the copied works would have to be considered collectively, including the 37 APIs, which are “an extremely important part of the Java platform, and are key to its organizational structure.” (Mitchell Opp. Report ¶ 96.) Google does not get to separate out one part of its infringement from another for the purpose of evaluating the significance of its copying.
The importance of the test code is also a disputed material fact. Dr. Mitchell rejects Dr. Astrachan’s conclusion that some of these files are merely “dummy files” for testing. (Mitchell Opp. Report ¶¶ 91-95.) These files were not contained in the “test” area on Oracle’s directory. But even if Google used them as test files, test files are still valuable: “testing software often requires more time and effort in software companies than writing the code initially.” (Id. ¶ 95.) Google paid a software engineering firm $900,000 to develop a software test suite for the Java core libraries. (See Swoopes Decl. Ex. 15, Google-Noser Statement of Work: CTS, GOOGLE-00392183-94.) A jury could reasonably conclude that the copying of entire copyrighted files into Google’s test suite was qualitatively significant.
For all the above reasons, this motion should be denied.
1. This report covers my review, analysis, and opinions regarding the copyrights asserted by Oracle against Google in the case known as Oracle America, Inc. v. Google, Inc., pending in the United States District Court for the Northern District of California, Case No. 10-03561-WHA.
2. I will submit my review, analysis, and opinions regarding the patents-in-suit under separate cover on the due date agreed to by the Parties.
3. I have been retained to consult with counsel, review documents and other information, prepare expert reports, and be available to testify regarding my opinions on behalf of Oracle in connection with litigation brought by Oracle against Google.
Google's acts of direct and indirect infringement of the patents and copyrights in suit.
I also expect to testify at trial with respect to matters addressed by experts testifying on behalf of Google. I may also testify on other matters relevant to this case, if asked by the Court or by the Parties' counsel.
various versions of the accused software, systems, and applications is not publicly available. For example, I have not been able to examine the source code for Honeycomb, and I understand that Google plans to release future versions of Android software. None of these have been made available for my review. As such, my investigation into the specifics and extent of Google's infringement is ongoing. My report is based on the materials that have been available to me up to the date of this report.
6. My opinions are based on my education and my work experience as set forth in Exhibit A of this Report, the materials listed in Exhibit B of this Report, and the materials cited to in my Opening Copyright Report.
7. I am being compensated for my work in connection with this matter at the rate of $800 per hour. I have used this rate in the past for other cases.
8. My compensation is not conditioned on the outcome of this matter. Neither the amount of my compensation nor my hourly billing rate depends on whether I am obligated to testify at deposition or trial.
9. Information detailing my qualifications is included in my Curriculum Vitae, attached as Exhibit A.
10. I received my Ph.D. in Computer Science from MIT in 1984. I hold a Master's degree in Computer Science from MIT, and a Bachelors of Science in Mathematics with Distinction from Stanford University, which I received in 1982 and 1978 respectively.
11. My Ph.D. thesis was on topics related to the design and analysis of programming languages.
12. Between Stanford and MIT, I worked for two years as a research programmer for the University of Wisconsin.
13. Before I joined the faculty of Stanford, from 1984 until 1988, I was a Member of the Technical Staff at the Computing Science Research Center of AT&T Bell Laboratories.
14. I am currently the Mary and Gordon Crary Family Professor of Computer Science and (by courtesy) Electrical Engineering at Stanford University. From 1990 until 1997, I was an Associate Professor of Computer Science at Stanford University and from 1988 to 1990 I was an Assistant Professor of Computer Science.
15. At Stanford, my research has covered a variety of topics, including the design and analysis of programming languages, computer security, and mathematical logic. For example, I wrote research papers on type systems for object-oriented programming languages and developed principles that were adopted in the designs of the Java and .NET programming languages.
16. With my former Ph.D. student Stephen Freund, I wrote a series of papers studying properties of the Java bytecode verifier. With an additional former student, we designed, implemented and tested a form of Java generics, a concept that was subsequently added to the Java programming language.
17. My publications include three books on aspects of programming languages and over 140 research articles. A list of my publications is included in my Curriculum Vitae (Exhibit A).
19. I am Editor-in-Chief of the Journal of Computer Security and I have served on the editorial board of ten other professional journals. I have also served as program committee chair or program committee member of many professional conferences on programming languages, computer security, and other areas of computer science.
20. The courses I have taught at Stanford include programming languages, programming language theory, computer and network security, web security, logic, and algorithms.
21. My research activities have been funded by U.S. Government agencies and gifts to Stanford from private companies. For example, I am currently the Principal Investigator (PI) of a project on secure information sharing that is funded by the Air Force Office of Scientific Research and the PI of a DARPA-funded project developing a programming language for computing on encrypted data. I am also a co-PI on the National Science Foundation Science and Technology Center called TRUST and a co-PI and Chief Computer Scientist of a project on security and privacy for healthcare information systems funded by the U.S. Department of Health and Human Services.
22. My research has also been partially funded over the last several years by gifts from private companies. While such gifts are often designated as intended to support a specific research project, they are gifts to Stanford University and not gifts to me personally.
23. In collaboration with Stanford faculty Dan Boneh and David Mazieres, I applied for a small research gift from Google to support research on "security for cloud clients with rich controlled sharing." I believe that the final version of the application for funding was sent to Google by their deadline of October 15, 2010. Support for my research from this application has been placed on hold by Google for the duration of this litigation. 24. I am co-inventor of U.S. Patent No. 7,870,610, titled "Detection of Malicious Programs."
25. I have served as an expert witness or consultant in connection with a number of litigations. A list of prior cases in which I have testified or consulted as an expert over the past years is included in my Curriculum Vitae (Exhibit A).
26. With particular relevance to my copyright analysis conducted in this case, I previously assisted with a copyright dispute for which I analyzed and prepared an expert report covering copyrightable elements of user interfaces.
27. In my 30 years of experience with computer software, I have reviewed a large amount of source code written by different programmers. Moreover, I teach programming language classes and assign programming projects that are graded as part of the class. As a result, I am generally familiar with the variations of code expression that arise when a set of programmers (including students) are asked to solve a programming problem. I should note that even on exam questions, when I've tried to narrow the question to limit the set of possible correct answers, students usually find many ways to write source code to express solutions.
Stanford's Judicial Affairs Office, I've discussed principles for detecting and determining plagiarism and how they apply to computer programming assignments.
29. Like every other person with programming experience with whom I have discussed this, I personally find programming a creative experience, analogous to technical writing, for example. In both cases, although there is a purpose to be served, there are many ways to accomplish the goal, and a wide range of expressive choices in doing so.
30. In arriving at my opinions provided in this report, I have considered a number of different sources of information that are identified in attached Exhibit B and referenced in my Opening Copyright Report.
31. In particular, I have reviewed the copyrighted works asserted in this lawsuit; Android source code, videos, and documentation made publicly available and produced by Google during the course of discovery.
32. In support of my analysis and rendered opinions, I intend to rely on the summary and report of Marc Visnick comparing Sun Microsystems's (now Oracle's) JDK 1.5 to Android Froyo and Apache Harmony, submitted to Google with my Opening Copyright Report. Likewise, I intend to rely on the summary report of Alan Purdy comparing Sun Microsystems's (now Oracle's) Java library API specifications to Android's library API specifications, also submitted to Google with my Opening Copyright Report.
33. In addition to the materials specifically identified, I may provide further exhibits to be used as a summary of or support for my opinions.
34. I believe a background and tutorial on Java and Android will aid the jury in understanding and appreciating the technology at issue in this case. I will cite to Google documents where appropriate.
35. There are several interesting features and components of Java that have marked its unprecedented technological success: the programming language, bytecode instruction set specification, virtual machine, execution paradigm and execution platform, programming tools, and class libraries and application programming interface (API) specifications.
36. To be clear on vocabulary, the Java development platform comprises the Java compiler, class libraries, development environment and associated tools, and the Java execution platform. The Java execution platform comprises the Java Virtual Machine and other components associated with processing and executing compiled Java source code, including executable class libraries and the class file format.
37. The Android platform incorporates various features of Java, as detailed below.
38. The Java programming language was designed by James Gosling and others at Sun Microsystems in the early 1990s.
39. Java is an object-oriented language. In object-oriented languages, an object is a way of combining data and functions. For example, an Integer object would have an integer value, such as 3, together with functions on integers, such as addition and multiplication.
methods, but each object may have different data values. In Java, data values associated with an object are called fields of the object.
41. Object-oriented programming began in the 1960s and developed with the early programming language Simula. James Gosling credits the influence of Simula on Java in this statement that I quote in my programming languages textbook: "One of the most important influences on the design of Java was a much earlier language called Simula. It is the first OO language I ever used (on a CDC 6400!). ... [and] where the concept of a 'class' was invented." In this statement, OO means "object-oriented." 42. Java was developed and distributed with a novel execution platform. As documented in the original press release (see http://web.archive.org/web/20080205101616/ http://www.sun.com/smi/Press/sunflash/1996-01/ sunflash.960123.10561.xml), the Java execution platform allows software developers to write programs that, once compiled, may be transported and run on a variety of computers without recompiling or rewriting them. This feature of Java is described as "write once, run anywhere."
not the first to use bytecode and a virtual machine, I believe that it was the first to support separate transport and incremental loading, verification, and execution of bytecode files stored in a standardized portable format. Source code, compilers, bytecode, class files, and the Java loader, verifier and bytecode interpreter are described in the following paragraphs.
44. Since approximately 1960, computer programs have been written in human-readable programming languages, such as Fortran, Algol, C and C++. Code written in these human-readable languages, called source code, is not directly executable by computer hardware. Instead, it must be converted to machine code in some way. As the name suggests, machine code uses the set of instructions that are understood and executed by a specific hardware processor. Different computer chips may execute different sets of rudimentary machine code instructions.
45. There are two traditional ways of converting source code into machine code. The first method uses a program called a compiler to convert an input file of source code to an output file of machine code that can be executed later. This machine code file can then be executed later, on a separate platform that does not have the source code or compiler. The second method uses a different kind of program called an interpreter. An interpreter processes source code instructions from an input file and executes corresponding machine instructions step-by-step, based on the source code instructions. Unlike a compiler, an interpreter continues to run as the source code program is interpreted. In other words, the source code and interpreter must be present on any platform where the program is interpreted.
runs on. However, it is not common to distribute software programs in their source code form. Source code represents the creative work of software designers and developers in a form that could expose a company's intellectual property to competitors.

References: v. 
 § 102
 v. 
 § 102
 § 102
 § 8
 § 102
 § 102
 § 10
 § 102
 v. 
 § 102
 v. 
 § 102
 v. 
 § 102
 v. 
 v. 
 v. 
 v. 
 v. 
 § 102
 § 101
 v. 
 § 102
 v. 
 v. 
 § 2
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 § 13
 v. 
 v. 
 § 107
 v. 
 v. 
 v.