Copyright in Computer Software

JUSTICE BREYER, delivered the opinion of the Court.

Oracle America, Inc., is the current owner of a copyright in Java SE, a computer program that uses the popular Java computer programming language. Google, without permission, has copied a portion of that program, a portion that enables a programmer to call up prewritten software that, together with the computer’s hardware, will carry out a large number of specific tasks. The lower courts have considered (1) whether Java SE’s owner could copyright the portion that Google copied, and (2) if so, whether Google’s copying nonetheless constituted a “fair use” of that material, thereby freeing Google from copyright liability. The Federal Circuit held in Oracle’s favor (i.e., that the portion is copyrightable and Google’s copying did not constitute a “fair use”). In reviewing that decision, we assume, for argument’s sake, that the material was copyrightable. But we hold that the copying here at issue nonetheless constituted a fair use. Hence, Google’s copying did not violate the copyright law.

In 2005, Google acquired Android, Inc., a startup firm that hoped to become involved in smartphone software. Google sought, through Android, to develop a software platform for mobile devices like smartphones. A platform provides the necessary infrastructure for computer programmers to develop new programs and applications. One might think of a software platform as a kind of factory floor where computer programmers (analogous to autoworkers, designers, or manufacturers) might come, use sets of tools found there, and create new applications for use in, say, smartphones.

Google envisioned an Android platform that was free and open, such that software developers could use the tools found there free of charge. Its idea was that more and more developers using its Android platform would develop ever more Android-based applications, all of which would make Google’s Android-based smartphones more attractive to ultimate consumers. Consumers would then buy and use ever more of those phones. Oracle America, Inc. v. Google Inc., 872 F. Supp. 2d 974, 978 (ND Cal. 2012). That vision required attracting a sizeable number of skilled programmers.

At that time, many software developers understood and wrote programs using the Java programming language, a language invented by Sun Microsystems (Oracle’s predecessor). About six million programmers had spent considerable time learning, and then using, the Java language. Many of those programmers used Sun’s own popular Java SE platform to develop new programs primarily for use in desktop and laptop computers. That platform allowed developers using the Java language to write programs that were able to run on any desktop or laptop computer, regardless of the underlying hardware (i.e., the programs were in large part “interoperable”). Indeed, one of Sun’s slogans was “write once, run anywhere.”

Shortly after acquiring the Android firm, Google began talks with Sun about the possibility of licensing the entire Java platform for its new smartphone technology. But Google did not want to insist that all programs written on the Android platform be interoperable. As Android’s founder explained, “the whole idea about [an] open source [platform] is to have very, very few restrictions on what people can do with it,” and Sun’s interoperability policy would have undermined that free and open business model. Apparently, for reasons related to this disagreement, Google’s negotiations with Sun broke down. Google then built its own platform.

The record indicates that roughly 100 Google engineers worked for more than three years to create Google’s Android platform software. In doing so, Google tailored the Android platform to smartphone technology, which differs from desktop and laptop computers in important ways. A smartphone, for instance, may run on a more limited battery or take advantage of GPS technology. The Android platform offered programmers the ability to program for that environment. To build the platform, Google wrote millions of lines of new code. Because Google wanted millions of programmers, familiar with Java, to be able easily to work with its new Android platform, it also copied roughly 11,500 lines of code from the Java SE program. The copied lines of code are part of a tool called an Application Programming Interface, or API.

What is an API? The Federal Circuit described an API as a tool that “allow[s] programmers to use … prewritten code to build certain functions into their own programs, rather than write their own code to perform those functions from scratch.” Oracle America, Inc. v. Google, Inc., 750 F. 3d 1339, 1349 (2014). Through an API, a programmer can draw upon a vast library of prewritten code to carry out complex tasks. For lay persons, including judges, juries, and many others, some elaboration of this description may prove useful.

Consider in more detail just what an API does. A computer can perform thousands, perhaps millions, of different tasks that a programmer may wish to use. These tasks range from the most basic to the enormously complex. Ask the computer, for example, to tell you which of two numbers is the higher number or to sort one thousand numbers in ascending order, and it will instantly give you the right answer. An API divides and organizes the world of computing tasks in a particular way. Programmers can then use the API to select the particular task that they need for their programs. In Sun’s API (which we refer to as the Sun Java API), each individual task is known as a “method.” The API groups somewhat similar methods into larger “classes,” and groups somewhat similar classes into larger “packages.” This method-class-package organizational structure is referred to as the Sun Java API’s “structure, sequence, and organization,” or SSO.

For each task, there is computer code, known as “implementing code,” that in effect tells the computer how to execute the particular task you have asked it to perform (such as telling you, of two numbers, which is the higher). The implementing code (which Google independently wrote) is not at issue here. For a single task, the implementing code may be hundreds of lines long. It would be difficult, perhaps impossible, for a programmer to create complex software programs without drawing on prewritten task-implementing programs to execute discrete tasks.

But how do you as the programmer tell the computer which of the implementing code programs it should choose, i.e., which task it should carry out? You do so by entering into your own program a command that corresponds to the specific task and calls it up. Those commands, known as “method calls,” help you carry out the task by choosing those programs written in implementing code that will do the trick, i.e., that will instruct the computer so that your program will find the higher of two numbers. If a particular computer might perform, say, a million different tasks, different method calls will tell the computer which of those tasks to choose. Those familiar with the Java language already know countless method calls that allow them to invoke countless tasks.

And how does the method call (which a programmer types) actually locate and invoke the particular implementing code that it needs to instruct the computer how to carry out a particular task? It does so through another type of code, which the parties have labeled “declaring code.” Declaring code is part of the API. For each task, the specific command entered by the programmer matches up with specific declaring code inside the API. That declaring code provides both the name for each task and the location of each task within the API’s overall organizational system (i.e., the placement of a method within a particular class and the placement of a class within a particular package). In this sense, the declaring code and the method call form a link, allowing the programmer to draw upon the thousands of prewritten tasks, written in implementing code. Without that declaring code, the method calls entered by the programmer would not call up the implementing code.

The declaring code therefore performs at least two important functions in the Sun Java API. The first, more obvious, function is that the declaring code enables a set of shortcuts for programmers. By connecting complex implementing code with method calls, it allows a programmer to pick out from the API’s task library a particular task without having to learn anything more than a simple command. For example, a programmer building a new application for personal banking may wish to use various tasks to, say, calculate a user’s balance or authenticate a password. To do so, she need only learn the method calls associated with those tasks. In this way, the declaring code’s shortcut function is similar to a gas pedal in a car that tells the car to move faster or the QWERTY keyboard on a typewriter that calls up a certain letter when you press a particular key. As those analogies demonstrate, one can think of the declaring code as part of an interface between human beings and a machine.

The second, less obvious, function is to reflect the way in which Java’s creators have divided the potential world of different tasks into an actual world, i.e., precisely which set of potentially millions of different tasks we want to have our Java-based computer systems perform and how we want those tasks arranged and grouped. In this sense, the declaring code performs an organizational function. It determines the structure of the task library that Java’s creators have decided to build. To understand this organizational system, think of the Dewey Decimal System that categorizes books into an accessible system or a travel guide that arranges a city’s attractions into different categories. Language itself provides a rough analogy to the declaring code’s organizational feature, for language itself divides into sets of concepts a world that in certain respects other languages might have divided differently. The developers of Java, for example, decided to place a method called “draw image” inside of a class called “graphics.”

Consider a comprehensive, albeit farfetched, analogy that illustrates how the API is actually used by a programmer. Imagine that you can, via certain keystrokes, instruct a robot to move to a particular file cabinet, to open a certain drawer, and to pick out a specific recipe. With the proper recipe in hand, the robot then moves to your kitchen and gives it to a cook to prepare the dish. This example mirrors the API’s task-related organizational system. Through your simple command, the robot locates the right recipe and hands it off to the cook. In the same way, typing in a method call prompts the API to locate the correct implementing code and hand it off to your computer. And importantly, to select the dish that you want for your meal, you do not need to know the recipe’s contents, just as a programmer using an API does not need to learn the implementing code. In both situations, learning the simple command is enough.

Now let us consider the example that the District Court used to explain the precise technology here. A programmer wishes, as part of her program, to determine which of two integers is the larger. To do so in the Java language, she will first write java.lang. Those words (which we have put in bold type) refer to the “package” (or by analogy to the file cabinet). She will then write Math. That word refers to the “class” (or by analogy to the drawer). She will then write max. That word refers to the “method” (or by analogy to the recipe). She will then make two parentheses (). And, in between the parentheses she will put two integers, say 4 and 6, that she wishes to compare. The whole expression—the method call—will look like this: “java.lang.Math.max(4, 6).” The use of this expression will, by means of the API, call up a task-implementing program that will determine the higher number.

In writing this program, the programmer will use the very symbols we have placed in bold in the precise order we have placed them. But the symbols by themselves do nothing. She must also use software that connects the symbols to the equivalent of file cabinets, drawers, and files. The API is that software. It includes both the declaring code that links each part of the method call to the particular task-implementing program, and the implementing code that actually carries it out.

Now we can return to the copying at issue in this case. Google did not copy the task-implementing programs, or implementing code, from the Sun Java API. It wrote its own task-implementing programs, such as those that would determine which of two integers is the greater or carry out any other desired (normally far more complex) task. This implementing code constitutes the vast majority of both the Sun Java API and the API that Google created for Android. For most of the packages in its new API, Google also wrote its own declaring code. For 37 packages, however, Google copied the declaring code from the Sun Java API. As just explained, that means that, for those 37 packages, Google necessarily copied both the names given to particular tasks and the grouping of those tasks into classes and packages.

In doing so, Google copied that portion of the Sun Java API that allowed programmers expert in the Java programming language to use the “task calling” system that they had already learned. As Google saw it, the 37 packages at issue included those tasks that were likely to prove most useful to programmers working on applications for mobile devices. In fact, “three of these packages were … fundamental to being able to use the Java language at all.” Oracle, 872 F. Supp. 2d, at 982. By using the same declaring code for those packages, programmers using the Android platform can rely on the method calls that they are already familiar with to call up particular tasks (e.g., determining which of two integers is the greater); but Google’s own implementing programs carry out those tasks. Without that copying, programmers would need to learn an entirely new system to call up the same tasks.

We add that the Android platform has been successful. Within five years of its release in 2007, Android-based devices claimed a large share of the United States market. As of 2015, Android sales produced more than $42 billion in revenue.

In 2010 Oracle Corporation bought Sun. Soon thereafter Oracle brought this lawsuit in the United States District Court for the Northern District of California.

The case has a complex and lengthy history. At the outset Oracle complained that Google’s use of the Sun Java API violated both copyright and patent laws. For its copyright claim, Oracle alleged that Google infringed its copyright by copying, for 37 packages, both the literal declaring code and the nonliteral organizational structure (or SSO) of the API, i.e., the grouping of certain methods into classes and certain classes into packages. For trial purposes the District Court organized three proceedings. The first would cover the copyright issues, the second would cover the patent issues, and the third would, if necessary, calculate damages. The court also determined that a judge should decide whether copyright law could protect an API and that the jury should decide whether Google’s use of Oracle’s API infringed its copyright and, if so, whether a fair use defense nonetheless applied. Ibid.

After six weeks of hearing evidence, the jury rejected Oracle’s patent claims (which have since dropped out of the case). It also found a limited copyright infringement. It deadlocked as to whether Google could successfully assert a fair use defense. The judge then decided that, regardless, the API’s declaring code was not the kind of creation to which copyright law extended its protection. The court noted that Google had written its own implementing code, which constituted the vast majority of its API. It wrote that “anyone is free under the Copyright Act to write his or her own code to carry out exactly the same” tasks that the Sun Java API picks out or specifies. Google copied only the declaring code and organizational structure that was necessary for Java-trained programmers to activate familiar tasks (while, as we said, writing its own implementing code). Hence the copied material, in the judge’s view, was a “system or method of operation,” which copyright law specifically states cannot be copyrighted. Id., at 977 (citing 17 U. S. C. § 102(b)).

On appeal, the Federal Circuit reversed. That court held that both the API’s declaring code and its organizational structure could be copyrighted. Oracle, 750 F. 3d, at 1354. It pointed out that Google could have written its own declaring code just as it wrote its own implementing code. And because in principle Google might have created a whole new system of dividing and labeling tasks that could be called up by programmers, the declaring code (and the system) that made up the Sun Java API was copyrightable. Id., at 1361.

The Federal Circuit also rejected Oracle’s plea that it decide whether Google had the right to use the Sun Java API because doing so was a “fair use,” immune from copyright liability [and] it remanded the case for another trial on that question. On remand the District Court, sitting with a jury, heard evidence for a week. The court instructed the jury to answer one question: Has Google “shown by a preponderance of the evidence that its use in Android” of the declaring code and organizational structure contained in the 37 Sun Java API packages that it copied “constitutes a ‘fair use’ under the Copyright Act?” After three days of deliberation the jury answered the question in the affirmative. Google had shown fair use.

Oracle again appealed to the Federal Circuit. And the Circuit again reversed the District Court. The Federal Circuit assumed all factual questions in Google’s favor. But, it said, the question whether those facts constitute a “fair use” is a question of law. Deciding that question of law, the court held that Google’s use of the Sun Java API was not a fair use. It wrote that “there is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform.” It remanded the case again, this time for a trial on damages.

Google then filed a petition for certiorari in this Court. It asked us to review the Federal Circuit’s determinations as to both copyrightability and fair use. We granted its petition.

Four provisions of the current Copyright Act are of particular relevance in this case. First, a definitional provision sets forth three basic conditions for obtaining a copyright. There must be a “work of authorship,” that work must be “original,” and the work must be “fixed in any tangible medium of expression.” 17 U. S. C. § 102(a); see also Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340, 345 (1991) (explaining that copyright requires some original “creative spark” and therefore does not reach the facts that a particular expression describes).

Second, the statute lists certain kinds of works that copyright can protect. They include “literary,” “musical,” “dramatic,” “motion picture,” “architectural,” and certain other works. § 102(a). In 1980, Congress expanded the reach of the Copyright Act to include computer programs. And it defined “computer program” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.”

Third, the statute sets forth limitations on the works that can be copyrighted, including works that the definitional provisions might otherwise include. It says, for example, that copyright protection cannot be extended to “any idea, procedure, process, system, method of operation, concept, principle, or discovery. …” § 102(b). These limitations, along with the need to “fix” a work in a “tangible medium of expression,” have often led courts to say, in shorthand form, that, unlike patents, which protect novel and useful ideas, copyrights protect “expression” but not the “ideas” that lie behind it.

Fourth, Congress, together with the courts, has imposed limitations upon the scope of copyright protection even in respect to works that are entitled to a copyright. … And directly relevant here, a copyright holder cannot prevent another person from making a “fair use” of copyrighted material. § 107. …

Google’s petition for certiorari poses two questions. The first asks whether Java’s API is copyrightable. It asks us to examine two of the statutory provisions just mentioned, one that permits copyrighting computer programs and the other that forbids copyrighting, e.g., “processes,” “systems,” and “methods of operation.” Google believes that the API’s declaring code and organization fall into these latter categories and are expressly excluded from copyright protection. The second question asks us to determine whether Google’s use of the API was a “fair use.” Google believes that it was.

A holding for Google on either question presented would dispense with Oracle’s copyright claims. Given the rapidly changing technological, economic, and business-related circumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute. We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted. We shall ask instead whether Google’s use of part of that API was a “fair use.” Unlike the Federal Circuit, we conclude that it was.

The language of § 107, the “fair use” provision, reflects its judge-made origins. It is similar to that used by Justice Story in Folsom v. Marsh, 9 F. Cas. 342, 348 (No. 4,901) (CC Mass. 1841). See Campbell, 510 U. S., at 576 (noting how “Justice Story’s summary [of fair use considerations] is discernable” in § 107). That background, as well as modern courts’ use of the doctrine, makes clear that the concept is flexible, that courts must apply it in light of the sometimes conflicting aims of copyright law, and that its application may well vary depending upon context. Thus, copyright’s protection may be stronger where the copyrighted material is fiction, not fact, where it consists of a motion picture rather than a news broadcast, or where it serves an artistic rather than a utilitarian function. See, e.g., Stewart, 495 U.S., at 237-238; Harper & Row, 471 U.S., at 563; see also Nimmer on Copyright (“Copyright protection is narrower, and the corresponding application of the fair use defense greater, in the case of factual works than in the case of works of fiction or fantasy”). Similarly, courts have held that in some circumstances, say, where copyrightable material is bound up with uncopyrightable material, copyright protection is “thin.” See Feist, 499 U.S., at 349 (noting that “the copyright in a factual compilation is thin”); see also Experian Information Solutions, Inc. v. Nationwide Marketing Servs. Inc., 893 F. 3d 1176, 1186 (CA9 2018) (“In the context of factual compilations, … there can be no infringement unless the works are virtually identical”).

Generically speaking, computer programs differ from books, films, and many other “literary works” in that such programs almost always serve functional purposes. These and other differences have led at least some judges to complain that “applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.” Lotus Development Corp. v. Borland Int’l, Inc., 49 F. 3d 807, 820 (CA1 1995) (Boudin, J., concurring).

These differences also led Congress to think long and hard about whether to grant computer programs copyright protection. In 1974, Congress established a National Commission on New Technological Uses of Copyrighted Works (CONTU) to look into the matter. §§ 201-208, 88 Stat. 1873-1875. After several years of research, CONTU concluded that the “availability of copyright protection for computer programs is desirable.” Final Report 11 (July 31, 1978). At the same time, it recognized that computer programs had unique features. Mindful of not “unduly burdening users of programs and the general public,” it wrote that copyright “should not grant anyone more economic power than is necessary to achieve the incentive to create.” Id., at 12. And it believed that copyright’s existing doctrines (e.g., fair use), applied by courts on a case-by-case basis, could prevent holders from using copyright to stifle innovation. Ibid. (“Relatively few changes in the Copyright Act of 1976 are required to attain these objectives”). Congress then wrote computer program protection into the law.

The upshot, in our view, is that fair use can play an important role in determining the lawful scope of a computer program copyright, such as the copyright at issue here. It can help to distinguish among technologies. It can distinguish between expressive and functional features of computer code where those features are mixed. It can focus on the legitimate need to provide incentives to produce copyrighted material while examining the extent to which yet further protection creates unrelated or illegitimate harms in other markets or to the development of other products. In a word, it can carry out its basic purpose of providing a context-based check that can help to keep a copyright monopoly within its lawful bounds. See House Report pp. 65-66 (1976) (explaining that courts are to “adapt the doctrine [of fair use] to particular situations on a case-by-case basis” and in light of “rapid technological change”); see, e.g., Lexmark Int’l, Inc. v. Static Control Components, Inc., 387 F. 3d 522, 543-545 (CA6 2004) (discussing fair use in the context of copying to preserve compatibility); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F. 3d 596, 603-608 (CA9 2000) (applying fair use to intermediate copying necessary to reverse engineer access to unprotected functional elements within a program); Sega Enterprises Ltd. v. Accolade, Inc., 977 F. 2d 1510, 1521-1527 (CA9 1992) (holding that wholesale copying of copyrighted code as a preliminary step to develop a competing product was a fair use).

Justice Thomas’ thoughtful dissent offers a very different view of how (and perhaps whether) fair use has any role to play for computer programs. We are told that no attempt to distinguish among computer code is tenable when considering “the nature of the work,” even though there are important distinctions in the ways that programs are used and designed, (“The declaring code is what attracted programmers”). We are told that no reuse of code in a new program will ever have a valid “purpose and character,” even though the reasons for copying computer code may vary greatly and differ from those applicable to other sorts of works, ibid. (accepting that copying as part of “reverse engineer[ing] a system to ensure compatibility” could be a valid purpose). And we are told that our fair use analysis must prioritize certain factors over others, even though our case law instructs that fair use depends on the context, see Campbell, 510 U.S., at 577-578.

We do not understand Congress, however, to have shielded computer programs from the ordinary application of copyright’s limiting doctrines in this way. By defining computer programs in § 101, Congress chose to place this subject matter within the copyright regime. Like other protected works, that means that the owners of computer programs enjoy the exclusive rights set forth in the Act, including the right to “reproduce [a] copyrighted work” or to “prepare derivative works.” 17 U.S.C. § 106. But that also means that exclusive rights in computer programs are limited like any other works. Just as fair use distinguishes among books and films, which are indisputably subjects of copyright, so too must it draw lines among computer programs. And just as fair use takes account of the market in which scripts and paintings are bought and sold, so too must it consider the realities of how technological works are created and disseminated. We do not believe that an approach close to “all or nothing” would be faithful to the Copyright Act’s overall design.

[The majority’s fair use analysis is extracted in a previous chapter. In summary, the Court considered whether Google’s copying of the declaring code and organizational structure for 37 packages of the Sun Java API was “fair use” under copyright law. The Sun Java API serves as a user interface, allowing programmers to call up implementing programs through method calls, and consists of implementing code (written by Google for Android), method calls, and declaring code that labels and organizes tasks into packages and classes. Oracle claimed copyright over the declaring code but not the implementing code written afresh by Google. The Court emphasized that declaring code is intertwined with uncopyrightable elements such as task organization and widely known commands, and its value often stems from programmers’ investment in learning the system rather than the original author’s creative contribution. Because declaring code, if copyrightable at all, is further from the “core” of copyright protection than implementing code, the second factor favored fair use.

In assessing the “purpose and character” of the use, the Court found Google’s reimplementation transformative because it created a new smartphone platform allowing programmers to apply their existing Java skills without learning a new system. Google copied only what was necessary to achieve this and wrote new implementing code for Android. Testimony showed that reimplementation of interfaces facilitates interoperability, preserves industry practice, and can spur innovation, with Sun itself having reused preexisting interfaces and recognizing the benefits of Java’s adoption on smartphones. Although Google’s use was commercial, its transformative nature outweighed this consideration, and the Court found the first factor favored fair use.

Regarding “amount and substantiality,” Google copied 11,500 lines—0.4% of the API’s total code—which the Court deemed proportionate to its transformative purpose, rejecting the view that only 170 lines were needed. On “market effects,” evidence showed Android did not harm Java SE’s actual or potential markets, as Sun’s mobile efforts were unsuccessful, its products targeted different segments, and Android operated in a distinct market. Much of Android’s benefit came from programmers’ prior investment in learning Java, not from Sun’s original creative work. The Court concluded that allowing Oracle to control the declaring code risked locking in programmer skills and restricting creativity.]

The fact that computer programs are primarily functional makes it difficult to apply traditional copyright concepts in that technological world. See Lotus Development Corp., 49 F. 3d, at 820 (Boudin, J., concurring). In doing so here, we have not changed the nature of those concepts. We do not overturn or modify our earlier cases involving fair use—cases, for example, that involve “knockoff” products, journalistic writings, and parodies. Rather, we here recognize that application of a copyright doctrine such as fair use has long proved a cooperative effort of Legislatures and courts, and that Congress, in our view, intended that it so continue. As such, we have looked to the principles set forth in the fair use statute, § 107, and set forth in our earlier cases, and applied them to this different kind of copyrighted work.

We reach the conclusion that in this case, where Google reimplemented a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, Google’s copying of the Sun Java API was a fair use of that material as a matter of law. The Federal Circuit’s contrary judgment is reversed, and the case is remanded for further proceedings in conformity with this opinion.

It is so ordered.

JUSTICE THOMAS, with whom JUSTICE ALITO joins, dissenting.

Oracle spent years developing a programming library that successfully attracted software developers, thus enhancing the value of Oracle’s products.¹

Google sought a license to use the library in Android, the operating system it was developing for mobile phones. But when the companies could not agree on terms, Google simply copied verbatim 11,500 lines of code from the library. As a result, it erased 97.5% of the value of Oracle’s partnership with Amazon, made tens of billions of dollars, and established its position as the owner of the largest mobile operating system in the world. Despite this, the majority holds that this copying was fair use.

The Court reaches this unlikely result in large part because it bypasses the antecedent question clearly before us: Is the software code at issue here protected by the Copyright Act? The majority purports to assume, without deciding, that the code is protected. But its fair-use analysis is wholly inconsistent with the substantial protection Congress gave to computer code. By skipping over the copyrightability question, the majority disregards half the relevant statutory text and distorts its fair-use analysis. Properly considering that statutory text, Oracle’s code at issue here is copyrightable, and Google’s use of that copyrighted code was anything but fair.

In the 1990s, Oracle created a programming language called Java. Like many programming languages, Java allows developers to prewrite small subprograms called “methods.” Methods form the building blocks of more complex programs. This process is not unlike what legislatures do with statutes. To save space and time, legislatures define terms and then use those definitions as a shorthand. For example, the legal definition for “refugee” is more than 300 words long. 8 U.S.C. § 1101(42). Rather than repeat all those words every time they are relevant, the U.S. Code encapsulates them all with a single term that it then inserts into each relevant section. Java methods work similarly. Once a method has been defined, a developer need only type a few characters (the method name and relevant inputs) to invoke everything contained in the subprogram. A programmer familiar with prewritten methods can string many of them together to quickly develop complicated programs without having to write from scratch all the basic subprograms.

To create Java methods, developers use two kinds of code. The first, “declaring code,” names the method, defines what information it can process, and defines what kind of data it can output. It is like the defined term in a statute. The second, “implementing code,” includes the step-by-step instructions that make those methods run.² It is like the detailed definition in a statute.

Oracle’s declaring code was central to its business model. Oracle profited financially by encouraging developers to create programs written in Java and then charging manufacturers a fee to embed in their devices the Java software platform needed to run those programs. To this end, Oracle created a work called Java 2 Platform, Standard Edition, which included a highly organized library containing about 30,000 methods. Oracle gave developers free access to these methods to encourage them to write programs for the Java platform. In return, developers were required to make their programs compatible with the Java platform on any device. Developers were encouraged to make improvements to the platform, but they were required to release beneficial modifications to the public. If a company wanted to customize the platform and keep those customizations secret for business purposes, it had to pay for a separate license.

By 2005, many companies were racing to develop operating systems for what would become modern smartphones. Oracle’s strategy had successfully encouraged millions of programmers to learn Java. As a result, Java software platforms were in the vast majority of mobile phones. Google wanted to attract those programmers to Android by including in Android the declaring code with which they were now familiar. But the founder of Android, Andrew Rubin, understood that the declaring code was copyrighted, so Google sought a custom license from Oracle. At least four times between 2005 and 2006, the two companies attempted to negotiate a license, but they were unsuccessful, in part because of “trust issues.”

When those negotiations broke down, Google simply decided to use Oracle’s code anyway. Instead of creating its own declaring code—as Apple and Microsoft chose to do— Google copied verbatim 11,500 lines of Oracle’s declaring code and arranged that code exactly as Oracle had done. It then advertised Android to device manufacturers as containing “Core Java Libraries.” Oracle predictably responded by suing Google for copyright infringement. The Federal Circuit ruled that Oracle’s declaring code is copyrightable and that Google’s copying of it was not fair use.

The Court wrongly sidesteps the principal question that we were asked to answer: Is declaring code protected by copyright? I would hold that it is.

Computer code occupies a unique space in intellectual property. Copyright law generally protects works of authorship. Patent law generally protects inventions or discoveries. A library of code straddles these two categories. It is highly functional like an invention; yet as a writing, it is also a work of authorship. Faced with something that could fit in either space, Congress chose copyright, and it included declaring code in that protection.

The Copyright Act expressly protects computer code. It recognizes that a “computer program” is protected by copyright. See 17 U.S.C. §§ 109(b), 117, 506(a). And it defines “‘computer program’” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” § 101. That definition clearly covers declaring code—sets of statements that indirectly perform computer functions by triggering prewritten implementing code.

Even without that express language, declaring code would satisfy the general test for copyrightability. “Copyright protection subsists . . . in original works of authorship fixed in any tangible medium of expression.” § 102(a). “Works of authorship include . . . literary works,” which are “works . . . expressed in words, numbers, or other verbal or numerical symbols.” §§ 101, 102(a). And a work is “original” if it is “independently created by the author” and “possesses at least some minimal degree of creativity.” Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340, 345 (1991). The lines of declaring code in the Java platform readily satisfy this “extremely low” threshold. Ibid. First, they are expressed in “words, numbers, or other verbal or numerical symbols” and are thus works of authorship. § 101. Second, as Google concedes, the lines of declaring code are original because Oracle could have created them any number of ways.

Google contends that declaring code is a “method of operation” and thus excluded from protection by § 102(b). That subsection excludes from copyright protection “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.” This provision codifies the “idea/expression dichotomy” that copyright protection covers only the “the author’s expression” of an idea, not the idea itself. Golan v. Holder, 565 U.S. 302, 328 (2012). A property right in the idea itself “can only be secured, if it can be secured at all, by letters-patent.” Baker v. Selden, 101 U. S. 99, 105 (1880). Thus, for example, a “method of book-keeping” is not protected by copyright, but the expression describing that accounting method is. Id., at 101-102. So too, a person who writes a book inventing the idea of declaring code has a copyright protection in the expression in the book, but not in the idea of declaring code itself. Google acknowledges that implementing code is protected by the Copyright Act, but it contends that declaring code is much more functional and thus is a “method of operation” outside the scope of protection.

That argument fails. As the majority correctly recognizes, declaring code and implementing code are “inextricably bound” together. Declaring code defines the scope of a set of implementing code and gives a programmer a way to use it by shortcut. Because declaring code incorporates implementing code, it has no function on its own. Implementing code is similar. Absent declaring code, developers would have to write every program from scratch, making complex programs prohibitively time consuming to create. The functionality of both declaring code and implementing code will thus typically rise and fall together.

Google’s argument also cannot account for Congress’ decision to define protected computer code as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” § 101 (emphasis added). Hence, Congress rejected any categorical distinction between declaring and implementing code. Implementing code orders a computer operation directly. Declaring code does so indirectly by incorporating implementing code. When faced with general language barring protection for “methods of operation” and specific language protecting declaring code, the specific governs the general.

This context makes clear that the phrase “method of operation” in § 102(b) does not remove protection from declaring code simply because it is functional. That interpretation does not, however, render “method of operation” meaningless. It is “given more precise content by the neighboring words with which it is associated.” United States v. Williams, 553 U.S. 285, 294 (2008). Other terms in the same subsection such as “idea,” “principle,” and “concept” suggest that “method of operation” covers the functions and ideas implemented by computer code—such as math functions, accounting methods, or the idea of declaring code— not the specific expression Oracle created. Oracle cannot copyright the idea of using declaring code, but it can copyright the specific expression of that idea found in its library.

Google also contends that declaring code is not copyrightable because the “merger doctrine” bars copyright protection when there is only one way to express an idea. That argument fails for the same reasons Google’s § 102(b) argument fails. Even if the doctrine exists, Google admits that it is merely an application of § 102(b). And, in any event, there may have been only one way for Google to copy the lines of declaring code, but there were innumerable ways for Oracle to write them. Certainly, Apple and Microsoft managed to create their own declaring code.

The Court inexplicably declines to address copyrightability. Its sole stated reason is that “technological, economic, and business-related circumstances” are “rapidly changing.” That, of course, has been a constant where computers are concerned.

Rather than address this principal question, the Court simply assumes that declaring code is protected and then concludes that every fair-use factor favors Google. I agree with the majority that Congress did not “shield computer programs from the ordinary application” of fair use. But the majority’s application of fair use is far from ordinary. By skipping copyrightability, the majority gets the methodology backward, causing the Court to sidestep a key conclusion that ineluctably affects the fair-use analysis: Congress rejected categorical distinctions between declaring and implementing code. But the majority creates just such a distinction. The result of this distorting analysis is an opinion that makes it difficult to imagine any circumstance in which declaring code will remain protected by copyright.

[Justice Thomas argued that three of the four statutory fair-use factors—market effect, purpose and character of use, and amount and substantiality—decisively favored Oracle, while the remaining factor, the nature of the work, could not by itself justify fair use. Justice Thomas thought that the majority’s analysis was flawed from the outset because it draws a distinction between declaring and implementing code that Congress has rejected, treating declaring code as less worthy of protection. Declaring code is user-facing, creative in its design and organization, and inseparable from implementing code in value, much like how a book’s structure cannot be divorced from its ideas. By undervaluing declaring code, the majority undermines Congress’s intent and improperly tilts the fair-use analysis toward Google.

Justice Thomas cites Harper & Row for the proposition that the fourth factor is the most important one, without seeming to recognize that Campbell says something quite different. He would thus fail Professor Sag’s copyright course. On the merits the dissent cites overwhelming evidence that Google’s copying caused substantial actual and potential harm to Oracle’s licensing business. On Justice Thomas’ view, by releasing Android for free, Google destroyed Oracle’s revenue model, leading to drastic drops in licensing fees from companies like Amazon and Samsung, and blocking Oracle from licensing its code to smartphone operating system developers. The dissent also notes Google’s own market dominance and antitrust violations as the more pressing competitive concern.

Regarding purpose and character of use, the dissent emphasizes Android’s massive commercial success—earning billions annually—and rejects the majority’s conclusion that Google’s use was transformative. Transformative use requires fundamentally new expression or purpose, not merely enabling others to create new products. Here, Google used Oracle’s code for the exact same function in a competing platform, making the use derivative, not transformative. On the amount and substantiality factor, Google copied verbatim the “heart” of Oracle’s work—the declaring code that attracted programmers—both qualitatively and quantitatively substantial. Taken together, these points lead the dissent to conclude that fair use is not supported under the statutory framework.]

The majority purports to save for another day the question whether declaring code is copyrightable. The only apparent reason for doing so is because the majority cannot square its fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable. The majority has used fair use to eviscerate Congress’ considered policy judgment. I respectfully dissent.

Reyna, Circuit Judge.

Appellant SAS Institute, Inc. (“SAS”) creates and sells a suite of software (“SAS System”) used for data access, data management, data analysis, and data presentation. The SAS System allows users to input user-written programs into the SAS System’s graphical user interface to complete analytics tasks. Users of the SAS System write commands in a programming language (the “SAS Language”). An earlier version of the SAS System is in the public domain. SAS has copyright registrations that cover various aspects of the SAS System.

World Programming Limited (“WPL”) created a competitor to the SAS System, the World Programming System (“WPS System”). The WPS System also uses the SAS Language to allow users to run user-written programs to complete analytics tasks such as data access, data management, data analysis, and data presentation.

On July 18, 2018, SAS filed suit against WPL in the district court for the Eastern District of Texas. The complaint alleged a number of claims, including copyright infringement of the SAS System and SAS user manuals. This appeal, however, is limited to three issues. First, SAS argues that the district court’s copyrightability determination is erroneous as a matter of law. Next, SAS asserts that the district court abused its discretion in its use of a “special hearing” to determine copyrightability. Finally, SAS argues that the district court abused its discretion when it rejected SAS’s expert report. As shown below, the resolution of the three issues rests on the question of copyrightability.

The term “copyrightability” has different meanings. A commonly accepted definition, and the one herein adopted, is whether the specific elements of a copyrighted work that are asserted in a copyright infringement action fall within the scope of protection extended to that particular work under copyright law. The fields of computer software and computer programs are recognized and addressed as a “literary work” in the U.S. Constitution and the Copyright Act.

Like the Patent and the Tariff, the Copyright enjoys a provenance stretching back to the birth of this nation. Article I, Section 8 of the U.S. Constitution secures “for limited Times to Authors and Inventors the exclusive Rights to their respective Writings and Discoveries.” For purposes of this appeal, it is generally accepted that software coders are “authors” and that their respective works are “writings.” See generally, Oracle America, Inc. v. Google Inc., 750 F.3d 1339, 1368 (Fed. Cir. 2014).

The Copyright Act protects “original works of authorship fixed in any tangible medium of expression.” 17 U.S.C. § 102(a). To explain the scope of the term “works of authorship,” the Act sets forth a non-exclusive statutory list of categories of works of authorship covered by the Act. The first category on this non-exclusive list is “literary works.” Id. at § 102(a)(1).

The statutory definition of “literary works” embraces computer programs:

17 U.S.C. § 101. Further, the House Report for the 1976 Act explicitly includes computer programs in its definition of “literary works.”

As the House Report makes clear, copyright protection extends only to the expression of an idea, not to the underlying idea itself. See also Mazer v. Stein, 347 U.S. 201, 217 (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.”). Thus, whether a particular component or element of a program is protected by a copyright depends on whether it qualifies as an expression of an idea, rather than the idea itself. Gates Rubber Co. v. Bando Chem. Indus., Ltd., 9 F.3d 823, 836 (10th Cir. 1993).

Additionally, other doctrines of copyright law detail what elements are not protectable, including scènes à faire elements, material in the public domain, factual material, and elements under the merger doctrine. Computer Assocs. Int’l, Inc. v. Altai, Inc., 982 F.2d 693, 703, 706-10 (2d Cir. 1992); Gates Rubber Co., 9 F.3d at 837.

With these doctrines in mind, the court is tasked with determining the scope of copyright protection. For computer programs, this determination often involves assessing which input and output formats of a computer program are copyrightable, and which are not. Eng’g Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335, 1347 (5th Cir. 1994). The literal elements of computer programs, for example: source and object codes, can be the subject of copyright protection. See, e.g., Altai, 982 F.2d at 702. As a general matter, and to varying degrees, copyright protection can extend beyond literal elements to nonliteral elements. Id. at 701.

This appeal involves only nonliteral elements of the SAS System. The nonliteral elements of a computer program are those aspects that are not reduced to written code. These elements include the program architecture, structure, sequence and organization, operational modules, and user interface. Using a literary novel as an analogy, the novel’s written words would be the literal elements (e.g., code) and the organization of the chapters, characters, and plot would be the nonliteral elements. But concluding that nonliteral elements of a computer program can be protected by copyright does not end a court’s analysis: it must determine the scope of such protection. Altai, 982 F.2d at 703. The scope of protection is “not constant” across all literary works. Eng’g Dynamics, 26 F.3d at 1348. Nor is it necessarily constant across all elements in a single work.

As one moves away from the literal elements to more general levels of a computer program, it becomes more difficult to distinguish between unprotectible ideas, processes, methods or functions, on the one hand, and copyrightable expression, on the other.

Court decisions vary in the methods used to identify and analyze copyrightability for nonliteral elements of computer programs. The analytical framework utilized by the courts may vary to accommodate each case’s facts.

Various circuits, including the Second, Fifth, and Tenth Circuits, have adopted the abstraction-filtration-comparison test, or method, to determine the scope of copyright protection for computer programs, including their nonliteral elements. As the name implies, the abstraction-filtration-comparison method involves three steps. First, a court breaks down the allegedly infringed program into its constituent structural parts—abstraction. This step helps a court separate ideas and processes from expression and eliminate those portions of the work that are not eligible for protection. Second, the court sifts out all non-protectable material—filtration. See also Altai, at 707-08 (describing this step as “examining the structural components at each level of abstraction” and “defining the scope of plaintiff’s copyright”). And, third, the trier of fact compares any remaining “core of protectable expression” with the allegedly infringing program to determine if there is in fact a substantial similarity—comparison. Altai at 710-11.

Although the underling suit is a copyright infringement action, this appeal does not reach the final copyright infringement analysis, or the third step of the abstraction-filtration-comparison test. Rather, the focus of the appeal is on the question of copyrightability and, in particular, the filtration step of the abstraction-filtration-comparison test.

SAS’s action initially involved multiple claims. However, the claims of patent infringement, copyright infringement of SAS user manuals, and copyright infringement as to the literal elements of the SAS System, were dismissed with prejudice by the parties’ joint stipulation. Only SAS’s claim for nonliteral copyright infringement of the SAS System remained, which is the only claim at issue on this appeal.

Both SAS and WPL moved for summary judgment on the nonliteral copyright infringement claim. As to this claim, SAS does not contend that WPL copied any line of SAS code or any other literal element of the SAS System. Instead, SAS contends that WPL infringes by copying the functions or results of its system. More specifically, SAS alleges WPL copied its “Input Formats,” which are the fundamentals (vocabulary and syntax) used in the SAS System. SAS also claims WPL copied its “Output Designs,” which are the result of applying Input Formats to user data.

Addressing the parties’ cross-motions for summary judgment, the district court concluded that it first needed to determine the copyrightability of the asserted materials to avoid “injecting copyrightability into the jury trial and unavoidably making it part of the jury’s infringement analysis.” To assist in its inquiry, the district court requested additional briefing and argument on a narrow question: what is the “core protectable expression” of the SAS System that WPL allegedly copied. To clarify this issue, the parties were asked to put forward competing evidence directed to the abstraction and filtration steps of the abstraction-filtration-comparison test.

After the parties submitted the requested briefing, the district court held a “Copyrightability Hearing.” In assessing the copyrightability of the nonliteral elements of the SAS System that SAS alleges were copied, the district court concluded that there was no clear guidance in the Fifth Circuit on the “burden of proof in the filtration analysis of copyrightability.” As a result, the district court elected to adopt the framework established by the Eleventh Circuit in Compulife Software Inc. v. Newman, 959 F.3d 1288 (11th Cir. 2020). Within that framework, once a plaintiff establishes that he or she holds a “valid copyright and that the defendant engaged in factual copying,” the defendant may come forward with evidence that the allegedly copied material is in fact copyright unprotectable. Id. at 1026-27 (citing Compulife, 959 F.3d at 1305-06). The defendant must identify the “species of unprotectability” alleged and present supporting evidence where appropriate. Id. Once done, the burden of proof shifts back to the copyright holder to establish precisely which parts of its asserted work are, in fact, protectable. Id. (citing Compulife, 959 F.3d at 1306).

Applying this framework, the district court determined that SAS satisfied its initial burden on copyrightability by presenting evidence of valid copyright registrations to the SAS System. Next, the district court determined that WPL satisfied its burden to show that elements of the SAS System were not protectable.

For example, WPL established that an earlier version of the SAS System, “SAS 76,” was in the public domain. WPL also demonstrated that many of the Input Formats and Output Designs in the current SAS System are identical, or nearly identical, to those in SAS 76, and, as such, should be filtered. WPL demonstrated that the SAS Language should be filtered because it is open and free for public use. WPL’s expert opined that the allegedly copied materials contained unprotectable open-source elements; factual and data elements; elements not original to SAS; mathematical and statistical elements; process, system, and method elements; well-known and conventional display elements, such as tables, graphs, plots, fonts, colors, and lines; material for which SAS is not the author; statistical analysis; scènes à faire elements; and short phrase elements. Accordingly, the district court found that WPL provided ample evidence to rebut SAS’s prima facie evidence of duly issued copyright registrations and required SAS to show which specific elements of the SAS System that SAS alleged were copied are protectable.

The district court concluded that SAS failed to show that the elements WPL pointed to as unprotectable are indeed entitled to protection or to show the existence and extent of any remaining protectable expression that WPL copied. The district court found that SAS refused to engage in the filtration step and chose instead to simply argue that the SAS System was “creative.” On this basis, the district court found that SAS had not met its burden to show protectability of the asserted materials.

The district court also excluded the opinion of SAS’s expert, Dr. James Storer, as unreliable because he did not filter out any of the unprotectable elements of the SAS System. The district court reasoned that, at a minimum, Dr. Storer’s failure to filter out any of the unprotectable elements resulted in an improper comparison of unprotectable elements to the accused products. The district court dismissed the case with prejudice.

SAS timely appealed. This Court has jurisdiction under 28 U.S.C. § 1295(a)(1).

When addressing questions of copyright law, this court applies the law which would be applied by the relevant regional circuit—here, the Fifth Circuit. Under Fifth Circuit law, legal issues are reviewed de novo. Copyrightability is generally treated as a legal issue, or as a legal issue that may involve subsidiary factual findings. Treating copyrightability as a question of law is consistent with case law. Here, neither the district court nor the parties dispute that copyrightability is resolved as a question of law. We also note that the resolution of copyrightability rests on interpretation of whether the asserted materials are expressions that fall within the scope of copyright law—matters that belong to the court. On this basis, we hold that in this case the ultimate issue of copyrightability can be resolved as a question of law that we review under a de novo standard. To be clear, whether copyright infringement has occurred is a factual determination that generally can be reached only after the legal determination of copyrightability has been made.

SAS raises three main issues on appeal. First, SAS contends that the district court erred when it required SAS to prove that the elements it asserted were copied by WPL are entitled to copyright protection. Second, SAS argues that the district court erred when it used a “Copyrightability Hearing” to assist it reach a copyrightability determination. Third, SAS argues that the court erred in excluding the testimony of its technical expert. We address each issue in turn.

SAS contends that the district court legally erred in its application of the abstraction-filtration-comparison test. According to SAS, it satisfied its evidentiary burden once it demonstrated that the SAS System was covered by registered copyrights. Further, SAS claims the district court erred when it shifted the burden to SAS to establish that its asserted elements are protected by copyright law. Appellant’s Br. at 38-43. Alternatively, SAS argues that the overall selection and arrangement of the Input Format and Output Design was protectable. We disagree.

We conclude that the overall analytical framework adopted by the district court is consistent with established precedent. The plaintiff in a copyright action must respond to any proof advanced by the defendant. SAS’s preliminary showing that it has valid, registered copyrights directed to aspects of the SAS System is not sufficient to establish that each nonliteral element of the SAS System is protectable. See Feist Publications, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340, 348 (1991) (“The mere fact that a work is copyrighted does not mean that every element of the work may be protected.” (emphasis added)). Evidence of a timely obtained copyright registration only creates a rebuttable presumption of copyrightability and validity. The district court correctly determined that, through evidence of valid copyright registrations, SAS established a required threshold of protectability. Consequently, it became WPL’s burden to establish what, if any, elements of the copyrighted work are not protected. WPL showed that at least a substantial portion of the allegedly infringed elements of the SAS System are not protectable by copyright. At that point, the district court correctly provided SAS with an opportunity to identify the constituent elements of the work that are protectable. But SAS apparently failed or refused to do so. Instead, SAS steadfastly asserted that the SAS works were creative and that it had provided “repeated evidence of factual copying,” but SAS failed to rebut WPL’s assertion and did not otherwise provide evidence in relation to the “filtration” step under the three-part test.

As the district court correctly explained, copyright protectability “consists of the absence of the various species of unprotectability.” Id. at 1027 (quoting Compulife, 959 F.3d at 1305). To be clear, in some instances, as in factual compilations, the selection and arrangement of unprotectable elements may exhibit creative expression and be eligible for protection. As the district court found, SAS did not show that its program was eligible for protection at any level of abstraction.

The dissent contends that the district court and majority erroneously import an infringement analysis to determine copyrightability. We disagree. As demonstrated in this opinion, a key step prior to engaging in an infringement analysis is to determine which elements of the asserted material are copyrightable.

We hold that where the court has received persuasive evidence that the asserted elements are copyright unprotectable, SAS, as the copyright holder, was obligated to identify with specificity the elements of the SAS program that it asserts as copied and to establish that those elements fall within the scope of protection extended to such elements under copyright law. Under these circumstances, the district court correctly determined that SAS did not meet its burden.

SAS contends that the district court erred by creating a novel procedure, a “Copyrightability Hearing.” More precisely, SAS contends that the adopted procedure is inconsistent with at least Federal Rules of Civil Procedure (“FRCP”) 52 and 56 because the district court was wrong to use the procedure as a basis to deny the cross motions for summary judgment and dismiss its case. We disagree.

The Copyrightability Hearing took the form of a pretrial conference, where the district court provided the parties notice and opportunity to brief, argue, and present evidence on the legal question of copyrightability. Such procedures are well-supported by the Federal Rules of Civil Procedure and within the district courts’ discretion to manage pre-trial matters under Fifth Circuit case law.

Appellate courts have long held that district courts have discretion to conduct reasonable pretrial procedures and case management to narrow the issues and simplify the mechanics. This would include where “the issue of protectability can be more efficiently addressed” before determining copying. Gates Rubber Co., 9 F.3d at 833. Since SAS failed to provide evidence on which of the challenged elements of the SAS System were copyrightable, the district court correctly found that a jury would be unable to conduct a proper infringement analysis. Accordingly, we discern no abuse of discretion in the procedural mechanism it used to understand and manage the copyrightability issue prior to trial.

SAS contends that the district court erred in excluding its experts’ testimony.

An expert report that is unreliable or unhelpful to the jury may be excluded under Federal Rule of Evidence 702(a). Throughout this case, the district court insisted that SAS identify its infringement theory with specificity. Instead of identifying and asserting specific protectable elements of the SAS System, SAS relied on abstract definitions of Input Formats and Output Designs. In addition, SAS’s expert’s analysis also included clearly unprotectable elements.

SAS does not appear to dispute that its expert did not conduct the filtration analysis that the district court adopted. Indeed, SAS’s expert either refused or was unable to assist the court in clarifying the core of protectable expression that SAS believed was entitled to copyright protection. SAS’s repeated claims that the asserted elements were creative were insufficient.

It is not enough to simply point to asserted elements and declare them protectable because they are creative or because other choices exist. Such an interpretation turns the Copyright Act on its head because it renders superfluous the requirement to prove that material a defendant is alleged to have copied constitutes protected expression. It ignores that the Act protects “original works of authorship fixed in any tangible medium of expression.” 17 U.S.C. § 102(a).

Courts typically receive guidance from the parties’ experts on the application of the abstraction-filtration-comparison test to the relevant computer programs. Gates Rubber Co., 9 F.3d at 834-35. A court may reasonably adopt an analysis to determine what the “core of protectable expression” is to provide the jury with accurate elements to compare in its role of determining whether infringement has occurred. Oracle, 750 F.3d at 1358. Here, the district court appropriately exercised its authority and discretion in finding that SAS’s expert engaged in “egregious conduct” and his report was unreliable because it failed to filter out unprotectable elements as ordered by the court, thereby rendering the opinion “unhelpful” to the jury. Under these circumstances, as to the issue of copyrightability, the expert opinion amounted to no more than theoretical speculation.

The district court was correct to exercise its authority and require SAS to articulate a legally viable theory on which it expected to base its copyright infringement claims. Conversely, it would be improper for a district court to permit a matter to proceed to trial on the basis of vague and unidentified theories. Thus, when SAS declined to make any further showing on copyrightability, the district court properly dismissed SAS’s claims. We see no basis to conclude that the district court’s decision to strike the expert report was manifest or “plain and indisputable” error.

The district court correctly determined as a matter of law that SAS failed to establish that the elements it asserted to have been infringed were copyrightable expressions. The district court acted within its authority and discretion in its reliance on the abstraction-filtration-comparison test and Copyrightability Hearing to assist it in its analysis of the scope of copyright protection. The district court did not abuse its discretion in its rejection of SAS’s expert. Accordingly, the judgment of the district court is affirmed.

AFFIRMED