Full opinion text
O’MALLEY, Circuit Judge. This copyright dispute involves 37 packages of computer source code. The parties have often referred to these groups of computer programs, individually or collectively, as “application programming interfaces,” or API packages, but it is their content, not their name, that matters. The predecessor of Oracle America, Inc. (“Oracle”) wrote these and other API packages in the Java programming language, and Oracle licenses them on various terms for others to use. Many software developers use the Java language, as well as Oracle’s API packages, to write applications (commonly referred to as “apps”) for desktop and laptop computers, tablets, smartphones, and other devices. Oracle filed suit against Google Inc. (“Google”) in the United States District Court for the Northern District of California, alleging that Google’s Android mobile operating system infringed Oracle’s patents and copyrights. The jury found no patent infringement, and the patent claims are not at issue in this appeal. As to the copyright claims, the parties agreed that the jury would decide infringement, fair use, and whether any copying was de minimis, while the district judge would decide eopyrightability and Google’s equitable defenses. The jury found that Google infringed Oracle’s copyrights in the 37 Java packages and a specific computer routine called “rangeCheck,” but returned a noninfringement verdict as to eight decompiled security files. The jury deadlocked on Google’s fair use defense. After the jury verdict, the district court denied Oracle’s motion for judgment as a matter of law (“JMOL”) regarding fair use as well as Google’s motion for JMOL with respect to the rangeCheck files. Order on Motions for Judgment as a Matter of Law, Oracle Am., Inc. v. Google Inc., No. 3:10-cv-3561 (N.D.Cal. May 10, 2012), ECF No. 1119. Oracle also moved for JMOL of infringement with respect to the eight decompiled security files. In granting that motion, the court found that: (1) Google admitted to copying the eight files; and (2) no reasonable jury could find that the copying was de minimis. Oracle Am., Inc. v. Google Inc., No. C 10-3561, 2012 U.S. Dist. LEXIS 66417 (N.D.Cal. May 11, 2012) (“Order Granting JMOL on Decompiled Files ”). Shortly thereafter, the district court issued its decision on copyrightability, finding that the replicated elements of the 37 API packages — including the declaring code and the structure, sequence, and organization — -were not subject to copyright protection. Oracle Am., Inc. v. Google Inc., 872 F.Supp.2d 974 (N.D.Cal.2012) (“Copyrightability Decision ”). Accordingly, the district court entered final judgment in favor of Google on Oracle’s copyright infringement claims, except with respect to the rangeCheck code and the eight decompiled files. Final Judgment, Oracle Am., Inc. v. Google Inc., No. 3:10-cv3561, 2012 WL 9028839 (N.D.Cal. June 20, 2012), EOF No. 1211. Oracle appeals from the portion of the final judgment entered against it, and Google cross-appeals from the portion of that same judgment entered in favor of Oracle as to the rangeCheck code and eight decompiled files. Because we conclude that the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection, we reverse the district court’s copyrightability determination with instructions to reinstate the jury’s infringement finding as to the 37 Java packages. Because the jury deadlocked on fair use, we remand for further consideration of Google’s fair use defense in light of this decision. With respect to Google’s cross-appeal, we affirm the district court’s decisions: (1) granting Oracle’s motion for JMOL as to the eight decompiled Java files that Google copied into Android; and (2) denying Google’s motion for JMOL with respect to the rangeCheck function. Accordingly, we affirm-in-part, reverse-in-part, and remand for further proceedings. Background A. The Technology Sun Microsystems, Inc. (“Sun”) developed the Java “platform” for computer programming and released it in 1996. The aim was to relieve programmers from the burden of writing different versions of their computer programs for different operating systems or devices. “The Java platform, through the use of a virtual machine, enable[d] software developers to write programs that [wejre able to run on different types of computer hardware without having to rewrite them for each different type.” Copyrightability Decision, 872 F.Supp.2d at 977. With Java, a software programmer could “write once, run anywhere.” The Java virtual machine (“JVM”) plays a central role in the overall Java platform. The Java programming language itself— which includes words, symbols, and other units, together with syntax rules for using them to create instructions — is the language in which a Java programmer writes source code, the version of a program that is “in a human-readable language.” Id. For the instructions to be executed, they must be converted (or compiled) into binary machine code (object code) consisting of 0s and Is understandable by the particular computing device. In the Java system, “source code is first converted into ‘bytecode,’ an intermediate form, before it is then converted into binary machine code by the Java virtual machine” that has been designed for that device. Id. The Java platform includes the “Java development kit (JDK), javac compiler, tools and utilities, runtime programs, class libraries (API packages), and the Java virtual machine.” Id. at 977 n. 2. Sun wrote a number of ready-to-use Java programs to perform common eomputer functions and organized those programs into groups it called “packages.” These packages, which are the application programming interfaces at issue in this appeal, allow programmers to use the prewritten code to build certain functions into their own programs, rather than write their own code to perform those functions from scratch. They are shortcuts. Sun called the code for a specific operation (function) a “method.” It defined “classes” so that each class consists of specified methods plus variables and other elements on which the methods operate. To organize the classes for users, then, it grouped classes (along with certain related “interfaces”) into “packages.” See id. at 982 (describing organization: “[e]ach package [i]s broken into classes and those in turn [are] broken into methods”). The parties have not disputed the district court’s analogy: Oracle’s collection of API packages is like a library, each package is like a bookshelf in the library, each class is like a book on the shelf, and each method is like a how-to chapter in a book. Id. at 977. The original Java Standard Edition Platform (“Java SE”) included “eight packages of pre-written programs.” Id. at 982. The district court found, and Oracle concedes to some extent, that three of those packages — java.lang,java.io, and java.util— were “core” packages, meaning that programmers using the Java language had to use them “in order to make any worthwhile use of the language.” Id. By 2008, the Java platform had more than 6,000 methods making up more than 600 classes grouped into 166 API packages. There are 37 Java API packages at issue in this appeal, three of which are the core packages identified by the district court. These packages contain thousands of individual elements, including classes, subclasses, methods, and interfaces. Every package consists of two types of source code — what the parties call (1) declaring code; and (2) implementing code. Declaring code is the expression that identifies the prewritten function and is sometimes referred to as the “declaration” or “header.” As the district court explained, the “main point is that this header line of code introduces the method body and specifies very precisely the inputs, name and other functionality.” Id. at 979-80. The expressions used by the programmer from the declaring code command the computer to execute the associated implementing code, which gives the computer the step-by-step instructions for carrying out the declared function. To use the district court’s example, one of the Java API packages at issue is “java, lang.” Within that package is a class called “math,” and within “math” there are several methods, including one that is designed to find the larger of two numbers: “max.” The declaration for the “max” method, as defined for integers, is: “public static int maxfint x, int y),” where the word “public” means that the method is generally accessible, “static” means that no specific instance of the class is needed to call the method, the first “int” indicates that the method returns an integer, and “int x” and “int y” are the two numbers (inputs) being compared. Copyrightability Decision, 872 F.Supp.2d at 980-82. A programmer calls the “max” method by typing the name of the method stated in the declaring code and providing unique inputs for the variables “x” and “y.” The expressions used command the computer to execute the implementing code that carries out the operation of returning the larger number. Although Oracle owns the copyright on Java SE and the API packages, it offers three different licenses to those who want to make use of them. The first is the General Public License, which is free of charge and provides that the licensee can use the packages — both the declaring and implementing code — but must “contribute back” its innovations to the public. This arrangement is referred to as an “open source” license. The second option is the Specification License, which provides that the licensee can use the declaring code and organization of Oracle’s API packages but must write its own implementing code. The third option is the Commercial License, which is for businesses that “want to use and customize the full Java code in their commercial products and keep their code secret.” Appellant Br. 14. Oracle offers the Commercial License in exchange for royalties. To maintain Java’s “write once, run anywhere” motto, the Specification and Commercial Licenses require that the licensees’ programs pass certain tests to ensure compatibility with the Java platform. The testimony at trial also revealed that Sun was licensing a derivative version of the Java platform for use on mobile devices: the Java Micro Edition (“Java ME”). Oracle licensed Java ME for use on feature phones and smartphones. Sun/Oracle has never successfully developed its own smartphone platform using Java. B. Google’s Accused Product: Android The accused product is Android, a software platform that was designed for mobile devices and competes with Java in that market. Google acquired Android, Inc. in 2005 as part of a plan to develop a smartphone platform. Later that same year, Google and Sun began discussing the possibility of Google “taking a license to use and to adapt the entire Java platform for mobile devices.” Copyrightability Decision, 872 F.Supp.2d at 978. They also discussed a “possible co-development partnership deal with Sun under which Java technology would become an open-source part of the Android platform, adapted for mobile devices.” Id. The parties negotiated for months but were unable to reach an agreement. The point of contention between the parties was Google’s refusal to make the implementation of its programs compatible with the Java virtual machine or interoperable with other Java programs. Because Sun/Oracle found that position to be anathema to the “write once, run anywhere” philosophy, it did not grant Google a license to use the Java API packages. When the parties’ negotiations reached an impasse, Google decided to use the Java programming language to design its own virtual machine — the Dalvik virtual machine (“Dalvik VM”) — and “to write its own implementations for the functions in the Java API that were key to mobile devices.” Id. Google developed the Android platform, which grew to include 168 API packages — 37 of which correspond to the Java API packages at issue in this appeal. With respect to the 37 packages at issue, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.” Id. To achieve this result, Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages — the “overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods.” Copyrightability Decision, 872 F.Supp.2d at 999. The parties and district court referred to this taxonomy of expressions as the “structure, sequence, and organization” or “SSO” of the 37 packages. It is undisputed, however, that Google wrote its own implementing code, except with respect to: (1) the rangeCheck function, which consisted of nine lines of code; and (2) eight decompiled security files. As to rangeCheck, the court found that the Sun engineer who wrote it later worked for Google and contributed two files he created containing the rangeCheck function — “Timsort.java” and “ComparableTimsort” — to the Android platform. In doing so, the nine-line rangeCheck function was copied directly into Android. As to the eight decompiled files, the district court found that they were copied and used as test files but “never found their way into Android or any handset.” Id. at 983. Google released the Android platform in 2007, and the first Android phones went on sale the following year. Although it is undisputed that certain Android software contains copies of the 37 API packages’ declaring code at issue, neither the district court nor the parties specify in which programs those copies appear. Oracle indicated at oral argument, however, that all Android phones contain copies of the accused portions of the Android software. Oral Argument at 1:35, available at http:// www.cafc.uscourts.gov/oral-argumenN recordings/2013-1021/all. Android smart-phones “rapidly grew in popularity and now comprise a large share of the United States market.” Copyrightability Decision, 872 F.Supp.2d at 978. Google provides the Android platform free of charge to smartphone manufacturers and receives revenue when customers use particular functions on the Android phone. Although Android uses the Java programming language, it is undisputed that Android is not generally Java compatible. As Oracle explains, “Google ultimately designed Android to be incompatible with the Java platform, so that apps written for one will not work on the other.” Appellant Br. 29. C. Trial and PosNTrial Rulings Beginning on April 16, 2012, the district court and the jury — on parallel tracks-viewed documents and heard testimony from twenty — four witnesses on copyright-ability, infringement, fair use, and Google’s other defenses. Because the parties agreed the district court would decide copyrightability, the court instructed the jury to assume that the structure, sequence, and organization of the 37 API packages was copyrightable. And, the court informed the jury that Google conceded that it copied the declaring code used in the 37 packages verbatim. The court also instructed the jury that Google conceded copying the rangeCheck function and the eight decompiled security files, but that Google maintained that its use of those lines of code was de minimis. See Final Charge to the Jury (Phase One), Oracle Am., Inc. v. Google Inc., 3:10-cv-3561 (N.D.Cal. Apr. 30, 2012), ECF No. 1018 at 14 (“With respect to the infringement issues concerning the rangeCheck and other similar files, Google agrees that the accused lines of code and comments came from the copyrighted material but contends that the amounts involved were so negligible as to be de minimis and thus should be excused.”). On May 7, 2012, the jury returned a verdict finding that Google infringed Oracle’s copyright in the 37 Java API packages and in the nine lines of rangeCheck code, but returned a noninfringement verdict as to eight decompiled security files. The jury hung on Google’s fair use defense. The parties filed a number of post-trial motions, most of which were ultimately denied. In relevant part, the district court denied Oracle’s motion for JMOL regarding fair use and Google’s motion for JMOL as to the rangeCheck files. Order on Motions for Judgment as a Matter of Law, Oracle Am., Inc. v. Google Inc., No. 3:10-cv-3561 (N.D.Cal. May 10, 2012), ECF No. 1119. The district court granted Oracle’s motion for JMOL of infringement as to the eight decompiled files, however. In its order, the court explained that: (1) Google copied the files in their entirety; (2) the trial testimony revealed that the use of those files was “significant”; and (3) no reasonable jury could find the copying de minimis. Order Granting JMOL on Decompiled Files, 2012 U.S. Dist. LEXIS 66417, at *6. On May 31, 2012, the district court issued the primary decision at issue in this appeal, finding that the replicated elements of the Java API packages — including the declarations and their structure, sequence, and organization' — -were not copyrightable. As to the declaring code, the court concluded that “there is only one way to write” it, and thus the “merger doctrine bars anyone from claiming exclusive copyright ownership of that expression.” Copyrightability Decision, 872 F.Supp.2d at 998. The court further found that the declaring code was not protectable because “names and short phrases cannot be copyrighted.” Id. As such, the court determined that “there can be no copyright violation in using the identical declarations.” Id. As to the overall structure, sequence, and organization of the Java API packages, the court recognized that “nothing in the rules of the Java language ... required that Google replicate the same groupings even if Google was free to replicate the same functionality.” Id. at 999. Therefore, the court determined that “Oracle’s best argument ... is that while no single name is copyrightable, Java’s overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods — is a ‘taxonomy’ and, therefore, copyrightable.” Id. Although it acknowledged that the overall structure of Oracle’s API packages is creative, original, and “resembles a taxonomy,” the district court found that it “is nevertheless a command structure, a system or method of operation — a long hierarchy of over six thousand commands to carry out pre-assigned functions” — that is not entitled to copyright protection under Section 102(b) of the Copyright Act. Id. at 999-1000. In reaching this conclusion, the court emphasized that, “[o]f the 166 Java packages, 129 were not violated in any way.” Id. at 1001. And, of the 37 Java API packages at issue, “97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines.” Id. On these grounds, the court dismissed Oracle’s copyright claims, concluding that “the particular elements replicated by Google were free for all to use under the Copyright Act.” Id. On June 20, 2012, the district court entered final judgment in favor of Google and against Oracle on its claim for copyright infringement, except with respect to the rangeCheck function and the eight decompiled files. As to rangeCheck and the decompiled files, the court entered judgment for Oracle and against Google in the amount of zero dollars, per the parties’ stipulation. Final Judgment, Oracle Am., Inc. v. Google Inc., No. 3:10-cv3561 (N.D.Cal. June 20, 2012), ECF No. 1211. Oracle timely appealed from the portion of the district court’s final judgment entered against it and Google timely cross-appealed with respect to rangeCheck and the eight decompiled files. Because this action included patent claims, we have jurisdiction pursuant to 28 U.S.C. § 1295(a)(1). Discussion I. Oracle’s Appeal It is undisputed that the Java programming language is open and free for anyone to use. Except to the limited extent noted below regarding three of the API packages, it is also undisputed that Google could have written its own API packages using the Java language. Google chose not to do that. Instead, it is undisputed that Google copied 7,000 lines of declaring code and generally replicated the overall structure, sequence, and organization of Oracle’s 37 Java API packages. The central question before us is whether these elements of the Java platform are entitled to copyright protection. The district court concluded that they are not, and Oracle challenges that determination on appeal. Oracle also argues that the district court should have dismissed Google’s fair use defense as a matter of law. According to Google, however, the district court correctly determined that: (1) there was only one way to write the Java method declarations and remain “interoperable” with Java; and (2) the organization and structure of the 37 Java API packages is a “command structure” excluded from copyright protection under Section 102(b). Google also argues that, if we reverse the district court’s copyrightability determination, we should direct the district court to retry its fair use defense. “When the questions on appeal involve law and precedent on subjects not exclusively assigned to the Federal Circuit, the court applies the law which would be applied by the regional circuit.” Atari Games Corp. v. Nintendo of Am., Inc., 897 F.2d 1572, 1575 (Fed.Cir.1990). Copyright issues are not exclusively assigned to the Federal Circuit. See 28 U.S.C. § 1295. The parties agree that Ninth Circuit law applies and that, in the Ninth Circuit, whether particular expression is protected by copyright law is “subject to de novo review.” Ets-Hokin v. Skyy Spirits, Inc., 225 F.3d 1068, 1073 (9th Cir.2000). We are mindful that the application of copyright law in the computer context is often a difficult task. See Lotus Dev. Corp. v. Borland Int’l, Inc., 49 F.3d 807, 820 (1st Cir.1995) (Boudin, J., concurring) (“Applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit”). On this record, however, we find that the district court failed to distinguish between the threshold question of what is copyrightable — which presents a low bar — and the scope of conduct that constitutes infringing activity. The court also erred by importing fair use principles, including interoperability concerns, into its copyrightability analysis. For the reasons that follow, we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection. Because there is an insufficient record as to the relevant fair use factors, we remand for further proceedings on Google’s fair use defense. A. Copyrightability The Copyright Act provides protection to “original works of authorship fixed in any tangible medium of expression,” including “literary works.” 17 U.S.C. § 102(a). It is undisputed that computer programs — defined in the Copyright Act 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 — can be subject to copyright protection as “literary works.” See Atari Games Corp. v. Nintendo of Am., Inc., 975 F.2d 832, 838 (Fed.Cir.1992) (“As literary works, copyright protection extends to computer programs.”). Indeed, the legislative history explains that “literary works” includes “computer programs to the extent that they incorporate authorship in the programmer’s expression of original ideas, as distinguished from the ideas themselves.” H.R.Rep. No. 1476, 94th Cong., 2d Sess. 54, reprinted in 1976 U.S.C.C.A.N. 5659, 5667. By statute, a work must be “original” to qualify for copyright protection. 17 U.S.C. § 102(a). This “originality requirement is not particularly stringent,” however. Feist Publ’ns, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 358, 111 S.Ct. 1282, 113 L.Ed.2d 358 (1991). “Original, as the term is used in copyright, means only that the work was independently created by the author (as opposed to copied from other works), and that it possesses at least some minimal degree of creativity.” Id. at 345, 111 S.Ct. 1282. Copyright protection extends only to the expression of an idea — not to the underlying idea itself. Mazer v. Stein, 347 U.S. 201, 217, 74 S.Ct. 460, 98 L.Ed. 630 (1954) (“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.”). This distinction — commonly referred to as the “idea/expression dichotomy” — is codified in Section 102(b) of the Copyright Act, which provides: In no case does copyright protection for an original work of authorship 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. 17 U.S.C. § 102(b); see Golan v. Holder, — U.S. -, 132 S.Ct. 873, 890, 181 L.Ed.2d 835 (2012) (“The idea/expression dichotomy is codified at 17 U.S.C. § 102(b).”). The idea/expression dichotomy traces back to the Supreme Court’s decision in Baker v. Selden, 101 U.S. 99, 101, 11 Otto 99, 25 L.Ed. 841 (1879). In Baker, the plaintiff Selden wrote and obtained copyrights on a series of books setting out a new system of bookkeeping. Id. at 100. The books included an introductory essay explaining the system and blank forms with ruled lines and headings designed for use with that system. Id. Baker published account books employing a system with similar forms, and Selden filed suit alleging copyright infringement. According to Selden, the “ruled lines and headings, given to illustrate the system, are a part of the book” and “no one can make or use similar ruled lines and headings, or ruled lines and headings made and arranged on substantially the same system, without violating the copyright.” Id. at 101. The Supreme Court framed the issue on appeal in Baker as “whether the exclusive property in a system of book-keeping can be claimed, under the law of copyright, by means of a book in which that system is explained.” Id. In reversing the circuit court’s decision, the Court concluded that the “copyright of a book on book-keeping cannot secure the exclusive right to make, sell, and use account-books prepared upon the plan set forth in such book.” Id. at 104. Likewise, the “copyright of a work on mathematical science cannot give to the author an exclusive right to the methods of operation which he propounds.” Id. at 103. The Court found that, although the copyright protects the way Selden “explained and described a peculiar system of book-keeping,” it does not prevent others from using the system described therein. Id. at 104.- The Court further indicated that, if it is necessary to use the forms Selden included in his books to make use of the accounting system, that use would not amount to copyright infringement. See id. (noting that the public has the right to use the account-books and that, “in using the art, the ruled lines and headings of accounts must necessarily be used as incident to it”). Courts routinely cite Baker as the source of several principles incorporated into Section 102(b) that relate to this appeal, including that: (1) copyright protection extends only to expression, not to ideas, systems, or processes; and (2) “those elements of a computer program that are necessarily incidental to its function are ... unprotectable.” See Computer Assocs. Int’l v. Altai, Inc., 982 F.2d 693, 704-05 (2d Cir.1992) {“Altai ”) (discussing Baker, 101 U.S. at 103-04). It is well established that copyright protection can extend to both literal and non-literal elements of a computer program. See Altai 982 F.2d at 702. The literal elements of a computer program are the source code and object code. See Johnson Controls, Inc. v. Phoenix Control Sys., Inc., 886 F.2d 1173, 1175 (9th Cir.1989). Courts have defined source code as “the spelled-out program commands that humans can read.” Lexmark Int’l, Inc. v. Static Control Components, Inc., 387 F.3d 522, 533 (6th Cir.2004). Object code refers to “the binary language comprised of zeros and ones through which the computer directly receives its instructions.” Altai 982 F.2d at 698. Both source and object code “are consistently held protected by a copyright on the program.” Johnson Controls, 886 F.2d at 1175; see also Altai, 982 F.2d at 702 (“It is now well settled that the literal elements of computer programs, i.e., their source and object codes, are the subject of copyright protection.”). Google nowhere disputes that premise. See, e.g., Oral Argument at 57:38. The non-literal components of a computer program include, among other things, the program’s sequence, structure, and organization, as well as the program’s user interface. Johnson Controls, 886 F.2d at 1175. As discussed below, whether the non-literal elements of a program “are protected depends on whether, on the particular facts of each case, the component in question qualifies as an expression of an idea, or an idea itself.” Id. In this case, Oracle claims copyright protection with respect to both: (1) literal elements of its API packages — the 7,000 lines of declaring source code; and (2) non-literal elements — the structure, sequence, and organization of each of the 37 Java API packages. The distinction between literal and non-literal aspects of a computer program is separate from the distinction between literal and non-literal copying. See Altai, 982 F.2d at 701-02. “Literal” copying is verbatim copying of original expression. “Non-literal” copying is “paraphrased or loosely paraphrased rather than word for word.” Lotus Dev. Corp. v. Borland Int’l, 49 F.3d 807, 814 (1st Cir.1995). Here, Google concedes that it copied the declaring code verbatim. Oracle explains that the lines of declaring code “embody the structure of each [API] package, just as the chapter titles and topic sentences represent the structure of a novel.” Appellant Br. 45. As Oracle explains, when Google copied the declaring code in these packages “it also copied the ‘sequence and organization’ of the packages (i.e., the three-dimensional structure with all the chutes and ladders)” employed by Sun/Oracle in the packages. Appellant Br. 27. Oracle also argues that the nonliteral elements of the API packages — the structure, sequence, and organization that led naturally to the implementing code Google created — are entitled to protection. Oracle does not assert “literal” copying of the entire SSO, but, rather, that Google literally copied the declaring code and then paraphrased the remainder of the SSO by writing its own implementing code. It therefore asserts non-literal copying with respect to the entirety of the SSO. At this stage, it is undisputed that the declaring code and the structure and organization of the Java API packages are original. The testimony at trial revealed that designing the Java API packages was a creative process and that the Sun/Oracle developers had a vast range of options for the structure and organization. In its copyrightability decision, the district court specifically found that the API packages are both creative and original, and Google concedes on appeal that the originality requirements are met. See Copyrightability Decision, 872 F.Supp.2d at 976 (“The overall name tree, of course, has creative elements----”); Id. at 999 (“Yes, it is creative. Yes, it is original.”); Appellee Br. 5 (“Google does not dispute” the district court’s finding that “the Java API clears the low originality threshold.”). The court found, however, that neither the declaring code nor the SSO was entitled to copyright protection under the Copyright Act. Although the parties agree that Oracle’s API packages meet the originality requirement under Section 102(a), they disagree as to the proper interpretation and application of Section 102(b). For its part, Google suggests that there is a two-step copyrightability analysis, wherein Section 102(a) grants copyright protection to original works, while Section 102(b) takes it away if the work has a functional component. To the contrary, however, Congress emphasized that Section 102(b) “in no way enlarges or contracts the scope of copyright protection” and that its “purpose is to restate ... that the basic dichotomy between expression and idea remains unchanged.” Feist, 499 U.S. at 356, 111 S.Ct. 1282 (quoting H.R.Rep. No. 1476, 94th Cong., 2d Sess. 54, reprinted in 1976 U.S.C.C.A.N. 5659, 5670). “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.” Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366, 1372 (10th Cir.1997). Section 102(a) and 102(b) are to be considered collectively so that certain expressions are subject to greater scrutiny. Id. In assessing copyrightability, the district court is required to ferret out apparent expressive aspects of a work and then separate protectable expression from “unprotectable ideas, facts, processes, and methods of operation.” See Atari, 975 F.2d at 839. Of course, as with many things, in defining this task, the devil is in the details. Circuit courts have struggled with, and disagree over, the tests to be employed when attempting to draw the fine between what is protectable expression and what is not. Compare Whelan Assocs., Inc. v. Jaslow Dental Lab., Inc., 797 F.2d 1222, 1236 (3d Cir.1986) (everything not necessary to the purpose or function of a work is expression), with Lotus, 49 F.3d at 815 (methods of operation are means by which a user operates something and any words used to effectuate that operation are unprotected expression). When assessing whether the non-literal elements of a computer program constitute protectable expression, the Ninth Circuit has endorsed an “abstraction-filtration-comparison” test formulated by the Second Circuit and expressly adopted by several other circuits. Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1525 (9th Cir.1992) (“In our view, in light of the essentially utilitarian nature of computer programs, the Second Circuit’s approach is an appropriate one.”). This test rejects the notion that anything that performs a function is necessarily uncopyrightable. See Mitel, 124 F.3d at 1372 (rejecting the Lotus court’s formulation, and concluding 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.”). And it also rejects as flawed the Whelan assumption that, once any separable idea can be identified in a computer program everything else must be protectable expression, on grounds that more than one idea may be embodied in any particular program. Altai, 982 F.2d at 705-06. Thus, this test eschews bright line approaches and requires a more nuanced assessment of the particular program at issue in order to determine what expression is protectable and infringed. As the Second Circuit explains, this test has three steps. In the abstraction step, the court “first break[s] down the allegedly infringed program into its constituent structural parts.” Id. at 706. In the filtration step, the court “sift[s] out all nonprotectable material,” including ideas and “expression that is necessarily incidental to those ideas.” Id. In the final step, the court compares the remaining creative expression with the allegedly infringing program. In the second step, the court is first to assess whether the expression is original to the programmer or author. Atari, 975 F.2d at 839. The court must then determine whether the particular inclusion of any level of abstraction is dictated by considerations of efficiency, required by factors already external to the program itself, or taken from the public domain — all of which would render the expression unprotectable. Id. These conclusions are to be informed by traditional copyright principles of originality, merger, and scenes a faire. See Mitel, 124 F.3d at 1372 (“Although this core of expression is eligible for copyright protection, it is subject to the rigors of filtration analysis which excludes from protection expression that is in the public domain, otherwise unoriginal, or subject to the doctrines of merger and scenes a faire.”). In all circuits, it is clear that the first step is part of the copyrightability analysis and that the third is an infringement question. It is at the second step of this analysis where the circuits are in less accord. Some treat all aspects of this second step as part of the copyrightability analysis, while others divide questions of originality from the other inquiries, treating the former as a question of copyrightability and the latter as part of the infringement inquiry. Compare Lexmark, 387 F.3d at 537-38 (finding that the district court erred in assessing principles of merger and scenes a faire in the infringement analysis, rather than as a component of copyrightability), with Kregos, 937 F.2d at 705 (noting that the Second Circuit has considered the merger doctrine “in determining whether actionable infringement has occurred, rather than whether a copyright is valid”); see also Lexmark, 387 F.3d at 557 (Feikens, J., dissenting-in-part) (noting the circuit split and concluding that, where a court is assessing merger of an expression with a method of operation, “I would find the merger doctrine can operate only as a defense to infringement in that context, and as such has no bearing on the question of copyrightability.”). We need not assess the wisdom of these respective views because there is no doubt on which side of this circuit split the Ninth Circuit falls. In the Ninth Circuit, while questions regarding originality are considered questions of copyrightability, concepts of merger and scenes a faire are affirmative defenses to claims of infringement. Ets-Hokin, 225 F.3d at 1082; Satava v. Lowry, 323 F.3d 805, 810 n. 3 (9th Cir.2003) (“The Ninth Circuit treats scenes a faire as a defense to infringement rather than as a barrier to copyrightability.”). The Ninth Circuit has acknowledged that “there is some disagreement among courts as to whether these two doctrines figure into the issue of copyrightability or are more properly defenses to infringement.” Ets-Hokin, 225 F.3d at 1082 (citations omitted). It, nonetheless, has made clear that, in that circuit, these concepts are to be treated as defenses to infringement. Id. (citing Kregos, 937 F.2d at 705 (holding that the merger doctrine relates to infringement, not copyrightability); Reed-Union Corp. v. Turtle Wax, Inc., 77 F.3d 909, 914 (7th Cir.1996) (explaining why the doctrine of scenes a faire is separate from the validity of a copyright)). With these principles in mind, we turn to the trial court’s analysis and judgment and to Oracle’s objections thereto. While the trial court mentioned the abstraction-filtration-comparison test when describing the development of relevant law, it did not purport to actually apply that test. Instead, it moved directly to application of familiar principles of copyright law when assessing the copyrightability of the declaring code and interpreted Section 102(b) to preclude copyrightability for any functional element “essential for interoperability” “regardless of its form.” Copyrightability Decision, 872 F.Supp.2d at 997. Oracle asserts that all of the trial court’s conclusions regarding copyrightability are erroneous. Oracle argues that its Java API packages are entitled to protection under the Copyright Act because they are expressive and could have been written and organized in any number of ways to achieve the same functions. Specifically, Oracle argues that the district court erred when it: (1) concluded that each line of declaring code is uncopyrightable because the idea and expression have merged; (2) found the declaring code uncopyrightable because it employs short phrases; (3) found all aspects of the SSO devoid of protection as a “method of operation” under 17 U.S.C. § 102(b); and (4) invoked Google’s “interoperability” concerns in the copyrightability analysis. For the reasons explained below, we agree with Oracle on each point. 1. Declaring Source Code First, Oracle argues that the district court erred in concluding that each line of declaring source code is completely unprotected under the merger and short phrases doctrines. Google responds that Oracle waived its right to assert copyrightability based on the 7,000 lines of declaring code by failing “to object to instructions and a verdict form that effectively eliminated that theory from the case.” Appellee Br. 67. Even if not waived, moreover, Google argues that, because there is only one way to write the names and declarations, the merger doctrine bars copyright protection. We find that Oracle did not waive arguments based on Google’s literal copying of the declaring code. Prior to trial, both parties informed the court that Oracle’s copyright infringement claims included the declarations of the API elements in the Android class library source code. See Oracle’s Statement of Issues Regarding Copyright, Oracle Am., Inc. v. Google Inc., No. 3:10-cv-3561 (N.D.Cal. Apr. 12, 2012), ECF No. 899-1, at 3 (Oracle accuses the “declarations of the API elements in the Android class library source code and object code that implements the 37 API packages” of copyright infringement.); see also Google’s Proposed Statement of Issues Regarding Copyright, Oracle Am., Inc. v. Google Inc., No. 3:10-cv-3561 (N.D.Cal. Apr. 12, 2012), ECF No. 901, at 2 (Oracle accuses the “declarations of the API elements in Android class library source code and object code that implements the 37 API packages.”). While Google is correct that the jury instructions and verdict form focused on the structure and organization of the packages, we agree with Oracle that there was no need for the jury to address copying of the declaring code because Google conceded that it copied it verbatim. Indeed, the district court specifically instructed the jury that “Google agrees that it uses the same names and declarations” in Android. Final Charge to the Jury at 10. That the district court addressed the declaring code in its post-jury verdict copyrightability decision further confirms that the verbatim copying of declaring code remained in the case. The court explained that the “identical lines” that Google copied into Android “are those lines that specify the names, parameters and functionality of the methods and classes, lines called ‘declarations’ or ‘headers.’ ” Copyrightability Decision, 872 F.Supp.2d at 979. The court specifically found that the declaring code was not entitled to copyright protection under the merger and short phrases doctrines. We address each in turn. a. Merger The merger doctrine functions as an exception to the idea/expression dichotomy. It provides that, when there are a limited number of ways to express an idea, the idea is said to “merge” with its expression, and the expression becomes unprotected. Altai 982 F.2d at 707-08. As noted, the Ninth Circuit treats this concept as an affirmative defense to infringement. Ets-Hokin, 225 F.3d at 1082. Accordingly, it appears that the district court’s merger analysis is irrelevant to the question of whether Oracle’s API packages are copyrightable in the first instance. Regardless of when the analysis occurs, we conclude that merger does not apply on the record before us. Under the merger doctrine, a court will not protect a copyrighted work from infringement if the idea contained therein can be expressed in only one way. Satava v. Lowry, 323 F.3d 805, 812 n. 5 (9th Cir.2003). For computer programs, “this means that when specific [parts of the code], even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.” Altai 982 F.2d at 708 (citation omitted). We have recognized, however, applying Ninth Circuit law, that the “unique arrangement of computer program expression ... does not merge with the process so long as alternate expressions are available.” Atari, 975 F.2d at 840. In Atari for example, Nintendo designed a program — the IONES — to prevent its video game system from accepting unauthorized game cartridges. 975 F.2d at 836. Nintendo “chose arbitrary programming instructions and arranged them in a unique sequence to create a purely arbitrary data stream” which “serves as the key to unlock the NES.” Id. at 840. Because Nintendo produced expert testimony “showing a multitude of different ways to generate a data stream which unlocks the NES console,” we concluded that Nintendo’s specific choice of code did not merge with the process. Id. Here, the district court found that, “no matter how creative or imaginative a Java method specification may be, the entire world is entitled to use the same method specification (inputs, outputs, parameters) so long as the line-by-line implementations are different.” Copyrightability Decision, 872 F.Supp.2d at 998. In its analysis, the court identified the method declaration as the idea and found that the implementation is the expression. Id. (“The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.”) (emphases in original). The court explained that, under the rules of Java, a programmer must use the identical “declaration or method header lines” to “declare a method specifying the same functionality.” Id. at 976. Because the district court found that there was only one way to write the declaring code for each of the Java packages, it concluded that “the merger doctrine bars anyone from claiming exclusive copyright ownership” of it. Id. at 998. Accordingly, the court held there could be “no copyright violation in using the identical declarations.” Id. Google agrees with the district court that the implementing code is the expression entitled to protection — not the declaring code. Indeed, at oral argument, counsel for Google explained that, “it is not our position that none of Java is copyrightable. Obviously, Google spent two and a half years ... to write from scratch all of the implementing code.” Oral Argument at 33:16. Because it is undisputed that Google wrote its own implementing code, the copyrightability of the precise language of that code is not at issue on appeal. Instead, our focus is on the declaring code and structure of the API packages. On appeal, Oracle argues that the district court: (1) misapplied the merger doctrine; and (2) failed to focus its analysis on the options available to the original author. We agree with Oracle on both points. First, we agree that merger cannot bar copyright protection for any lines of declaring source code unless Sun/Oracle had only one way, or a limited number of ways, to write them. See Satava, 323 F.3d at 812 n. 5 (“Under the merger doctrine, courts will not protect a copyrighted work from infringement if the idea underlying the copyrighted work can be expressed in only one way, lest there be a monopoly on the underlying idea.”). The evidence showed that Oracle had “unlimited options as to the selection and arrangement of the 7000 lines Google copied.” Appellant Br. 50. Using the district court’s “javadang. Math.max” example, Oracle explains that the developers could have called it any number of things, including “Math, maximum” or “Arith.larger.” This was not a situation where Oracle was selecting among preordained names and phrases to create its packages. As the district court recognized, moreover, “the Android method and class names could have been different from the names of their counterparts in Java and still have worked.” Copyrightability Decision, 872 F.Supp.2d at 976. Because “alternative expressions [we]re available,” there is no merger. See Atari, 975 F.2d at 840. We further find that the district court erred in focusing its merger analysis on the options available to Google at the time of copying. It is well-established that copyrightability and the scope of protectable activity are to be evaluated at the time of creation, not at the time of infringement. See Apple Computer, Inc. v. Formula Int’l, Inc., 725 F.2d 521, 524 (9th Cir.1984) (quoting National Commission on New Technological Uses of Copyrighted Works, Final Report at 21 (1979) (“CON-TU Report”) (recognizing that the Copyright Act was designed “to protect all works of authorship from the moment of their fixation in any tangible medium of expression”)). The focus is, therefore, on the options that were available to Sun/Oracle at the time it created the API packages. Of course, once Sun/Oracle created “java.lang.Math.max,” programmers who want to use that particular package have to call it by that name. But, as the court acknowledged, nothing prevented Google from writing its own declaring code, along with its own implementing code, to achieve the same result. In such circumstances, the chosen expression simply does not merge with the idea being expressed. It seems possible that the merger doctrine, when properly analyzed, would exclude the three packages identified by the district court as core packages from the scope of actionable infringing conduct. This would be so if the Java authors, at the time these packages were created, had only a limited number of ways to express the methods and classes therein if they wanted to write in the Java language. In that instance, the idea may well be merged with the expression in these three packages. Google did not present its merger argument in this way below and does not do so here, however. Indeed, Google does not try to differentiate among the packages for purposes of its copyrightability analysis and does not appeal the infringement verdict as to the packages. For these reasons, we reject the trial court’s merger analysis. b. Short Phrases The district court also found that Oracle’s declaring code consists of uncopyrightable short phrases. Specifically, the court concluded that, “while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.” Copyrightability Decision, 872 F.Supp.2d at 976. The district court is correct that “[w]ords and short phrases such as names, titles, and slogans” are not subject to copyright protection. 37 C.F.R. § 202.1(a). The court failed to recognize, however, that the relevant question for copyright-ability purposes is not whether the work at issue contains short phrases — as literary works often do — but, rather, whether those phrases are creative. See Soc’y of Holy Transfiguration Monastery, Inc. v. Gregory, 689 F.3d 29, 52 (1st Cir.2012) (noting that “not all short phrases will automatically be deemed uncopyrightable”); see also 1 Melville B. Nimmer & David Nimmer, Nimmer on Copyright § 2.01 [B] (2013) (“[E]ven a short phrase may command copyright protection if it exhibits sufficient creativity.”). And, by dissecting the individual lines of declaring code at issue into short phrases, the district court further failed to recognize that an original combination of elements can be copyrightable. See Softel, Inc. v. Dragon Med. & Scientific Commc’ns, 118 F.3d 955, 964 (2d Cir.1997) (noting that, in Feist, “the Court made quite clear that a compilation of nonprotectible elements can enjoy copyright protection even though its constituent elements do not”). By analogy, the opening of Charles Dickens’ A Tale of Two Cities is nothing but a string of short phrases. Yet no one could contend that this portion of Dickens’ work is unworthy of copyright protection because it can be broken into those shorter constituent components. The question is not whether a short phrase or series of short phrases can be extracted from the work, but whether the manner in which they are used or strung together exhibits creativity. Although the district court apparently focused on individual lines of code, Oracle is not seeking copyright protection for a specific short phrase or word. Instead, the portion of declaring code at issue is 7,000 lines, and Google’s own “Java guru” conceded that there can be “creativity and artistry even in a single method declaration.” Joint Appendix (“J.A.”) 20,970. Because Oracle “exercised creativity in the selection and arrangement” of the method declarations when it created the API packages and wrote the relevant declaring code, they contain protectable expression that is entitled to copyright protection. See Atari, 975 F.2d at 840; see also 17 U.S.C. §§ 101, 103 (recognizing copyright protection for “compilations” which are defined as work that is “selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship”). Accordingly, we conclude that the district court erred in applying the short phrases doctrine to find the declaring code not copyrightable. c. Scenes a Faire The scenes a faire doctrine, which is related to the merger doctrine, operates to bar certain otherwise creative expression from copyright protection. Apple Computer; Inc. v. Microsoft Corp., 35 F.3d 1435, 1444 (9th Cir.1994). It provides that “expressive elements of a work of authorship are not entitled to protection against infringement if they are standard, stock, or common to a topic, or if they necessarily follow from a common theme or setting.” Mitel, 124 F.3d at 1374. Under this doctrine, “when certain commonplace expressions are indispensable and naturally associated -with the treatment of a given idea, those expressions are treated like ideas and therefore [are] not protected by copyright.” Swirsky v. Carey, 376 F.3d 841, 850 (9th Cir.2004). In the computer context, “the scene a faire doctrine denies protection to program elements that are dictated by external factors such as ‘the mechanical specifications of the computer on which a particular program is intended to run’ or ‘widely accepted programming practices within the computer industry.’ ” Softel, 118 F.3d at 963 (citation omitted). The trial court rejected Google’s reliance on the scenes a faire doctrine. It did so in a footnote, finding that Google had failed to present evidence to support the claim that either the grouping of methods within the classes or the code chosen for them “would be so expected and customary as to be permissible under the scenes a faire doctrine.” Copyrightability Decision, 872 F.Supp.2d at 999 n. 9. Specifically, the trial court found that “it is impossible to say on this record that all of the classes and their contents are typical of such classes and, on this record, this order rejects Google’s global argument based on scenes a faire.” Id. On appeal, Google refers to scenes a faire concepts briefly, as do some amici, apparently contending that, because programmers have become accustomed to and comfortable using the groupings in the Java API packages, those groupings are so commonplace as to be indispensable to the expression of an acceptable programming platform. As such, the argument goes, they are so associated with the “idea” of what the packages are accomplishing that they should be treated as ideas rather than expression. See Br. of Amici Curiae Rackspace US, Inc., et al. at 19-22. Google cannot rely on the scenes a faire doctrine as an alternative ground upon which we might affirm the copyright-ability judgment of the district court. This is so for several reasons. First, as noted, like merger, in the Ninth Circuit, the scenes a faire doctrine is a component of the infringement analysis. “[Similarity of expression, whether literal or non-literal, which necessarily results from the fact that the common idea is only capable of expression in more or less stereotyped form, will preclude a finding of actionable similarity.” 4 Nimmer on Copyright § 13.08[B][3]. Thus, the expression is not excluded from copyright protection; it is just that certain copying is forgiven as a necessary incident of any expression of the underlying idea. See Satava, 323 F.3d at 810 n. 3 (“The Ninth Circuit treats scenes a faire as a defense to infringement rather than as a barrier to copyrightability.”). Second, Google has not objected to the trial court’s conclusion that Google failed to make a sufficient factual record to support its contention that the groupings and code chosen for the 37 Java API packages were driven by external factors or premised on features that were either commonplace or essential to the idea being expressed. Google provides no record citations indicating that such a showing was made and does not contend that the trial court erred when it expressly found it was not. Indeed, Google does not even make this argument with respect to the core packages. Finally, Google’s reliance on the doctrine below and the amici reference to it here are premised on a fundamental misunderstanding of the doctrine. Like merger, the focus of the scenes a faire doctrine is on the circumstances presented to the creator, not the copier. See Mitel, 124 F.3d at 1375 (finding error to the extent the trial court discussed “whether external factors such as market forces and efficiency considerations justified Iqtel’s copying of the command codes”). The court’s analytical focus must be upon the external factors that dictated Sun’s selection of classes, methods, and code — not upon what Google encountered at the time it chose to copy those groupings and that code. See id. “[T]he scenes a faire doctrine identifies and excludes from protection against infringement expression whose creation ‘flowed naturally from considerations external to the author’s creativity.’” Id. (quoting Nimmer § 13.03[F][3], at 13-131 (1997)). It is this showing the trial court found Google failed to make, and Google cites to nothing in the record which indicates otherwise. For these reasons, the trial court was correct to conclude that the scenes a faire doctrine does not affect the copyrightability of either the declaring code in, or the SSO of, the Java API packages at issue. 2. The Structure, Sequence, and Organization of the API Packages The district court found that the SSO of the Java API packages is creative and original, but nevertheless held that it is a “system or method of operation ... and, therefore, cannot be copyrighted” under 17 U.S.C. § 102(b). Copyrightability Decision, 872 F.Supp.2d at 976-77. In reaching this conclusion, the district court seems to have relied upon language contained in a First Circuit decision: Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807 (1st Cir.1995), aff'd without opinion by equally divided court, 516 U.S. 233, 116 S.Ct. 804, 133 L.Ed.2d 610 (1996). In Lotus, it was undisputed that the defendant copied the menu command hierarchy and interface from Lotus 1-2-3, a computer spreadsheet program “that enables users to perform accounting functions electronically on a computer.” 49 F.3d at 809. The menu command hierarchy referred to a series of commands— such as “Copy,” “Print,” and “Quit”— which were arranged into more than 50 menus and submenus. Id. Although the defendant did not copy any Lotus source code, it copied the menu command hierarchy into its rival program. The question before the court was “whether a computer menu command hierarchy is copyrightable subject matter.” Id. Although it accepted the district court’s finding that Lotus developers made some expressive choices in selecting and arranging the command terms, the First Circuit found that the command hierarchy was not c