Note
John W. L. Ogilvie
“Defining Computer Program Parts Under Learned Hand’s Abstractions Test in Software Copyright Infringement Cases”
91 Mich. L. Rev. 526 (1992)
Copyright © 1992 by The Michigan Law Review Association. Reproduced and distributed by their permission.
Introduction
Although computer programs enjoy copyright protection as protectable “literary works” under the federal copyright statute,1 the case law governing software infringement is confused, inconsistent, and even unintelligible to those who must interpret it.2 A computer program is often viewed as a collection of different parts, just as a book or play is seen as an amalgamation of plot, characters, and other familiar parts. However, different courts recognize vastly different computer program parts for copyright infringement purposes.3 Much of the disarray in software copyright law stems from mutually incompatible and conclusory program part definitions that bear no relation to how a computer program is actually designed and created. These differing part definitions frustrate courts’ efforts to compare or reconcile claims of substantial similarity, an issue that constitutes the cornerstone of many copyright infringement cases.4
Substantial similarity between the allegedly infringing program and the copyrighted program is not the only element of a software copyright infringement case. Infringement plaintiffs must also prove ownership of a valid copyright, and must establish access by the defendant to the copyrighted and allegedly infringed program.5 However, because ownership may be shown by a certificate of copyright registration, and access to the allegedly infringed work is often either <Page 527> conceded or easily proven,6 substantial similarity is often dispositive. Judicial use of multiple discordant tests for substantial similarity therefore creates chaos at the very heart of software copyright infringement law.
Confusion is inevitable because the various substantial similarity tests employed in software copyright cases define a bewildering variety of program parts. For example, some courts seem to treat algorithms as distinct parts,7 while others simply bundle them into a program’s “structure, sequence and organization” (SSO).8 Some recognize several distinct parts9 while others concentrate on a program’s “total concept and feel.”10 Some parts are defined inconsistently,11 or not defined at all.12
Unstable definitions of software parts undermine meaningful distinctions between the ideas underlying a program and the expression of those ideas. This idea-expression dichotomy is crucial, for although copyright law may protect “expression,” it never protects an “idea.”13 Unfortunately, some courts classify certain program parts as ideas while others classify the same parts as expression, never explicitly acknowledging that parts are being treated inconsistently. One court may treat everything except a program’s main purpose as potentially protectable expression,14 while another protects only literal program code and translations thereof.15
Substantial adverse consequences arise from the resulting discord. Conflicting and incoherent rules of decision produce contrary outcomes on fundamentally identical facts. Activities clearly permitted under one infringement test may lead to liability under a conflicting test, and no principled basis exists for choosing between existing tests.16 Conflicting approaches also hinder the reasoned evolution of software copyright law by obscuring the stable foundations of software technology. Copyright law should balance software protection against progress in the programming art and development of new technologies, <Page 528> but it can only succeed if it is informed by fundamental programming concepts and accepted legal principles.
Legal commentators have only touched on issues relating to the proper definition of computer program parts. Most scholarly commentaries on software copyright law simply ignore the problem of correctly defining computer program parts, focusing instead on the proper scope of protection.17 However, the need to import fundamental programming concepts into software copyright law has been noted.18 Several commentaries19 also recognize the congruence between programming, which creates functional expression from abstract ideas, and Learned Hand’s abstractions test,20 which proposes a hierarchy of levels of abstraction in any copyrighted work, ranging from potentially protectable expression to unprotectable ideas. But even these commentaries do not provide specific, coherent part definitions that are grounded in widely recognized programming concepts.21
Learned Hand’s famous abstractions test initially appears to offer little assistance in bringing sense and consistency to software copyright infringement law. The abstractions test views literary works as a <Page 529> spectrum of patterns, ranging from concrete protectable expression up to abstract unprotectable ideas. In Nichols v. Universal Pictures Corp.,22 Hand wrote:
Upon any work, and especially upon a play, a great number of patterns of increasing generality will fit equally well, as more and more of the incident is left out. The last may perhaps be no more than the most general statement of what the play is about, and at times might consist only of its title; but there is a point in this series of abstractions where they are no longer protected, since otherwise the playwright could prevent the use of his “ideas,” to which, apart from their expression, his property is never extended.23
The abstractions test was formulated before the need arose to frame proper computer program part definitions, and even in the works that spurred its formulation the test provides only general guidance in locating the line between idea and expression. In the particular realm of computer software, “the abstractions test is not easy to apply.”24
Proper application of the abstractions test is difficult, however, because it requires an understanding of fundamental programming concepts, not because the test is inherently unsuitable. This Note argues that the abstractions test’s valuable approach25 can be adapted to the software realm by recognizing legally several fundamental program parts at different levels of abstraction. Although Learned Hand’s test is not a panacea for all the current ills of software copyright law, it provides a framework for coherent program part definitions that should increase that law’s consistency.
This Note proposes a set of computer program part definitions that develop Learned Hand’s abstractions test to make it more useful in software infringement cases. The Note takes no position on the proper scope of protection for software under copyright law, but argues that no consensus is possible on which program parts deserve copyright protection until courts recognize that computer programs are composed of components whose definition lies beyond judicial control. Program parts defined in conclusory legal terms will never provide a stable basis for reasoned debate over the conclusions presumed in the definitions.26
This Note advocates the orderly development of copyright law through harmonious software part definitions. Part I provides the technical and legal background necessary to examine the proposed <Page 530> program parts by presenting some basic software terminology, discussing computer program abstraction parts currently recognized by programmers, and examining abstraction parts defined by courts during their attempts to analyze substantial similarity in software infringement cases. Part II argues for judicial adoption of the computer program abstraction part definitions presented in Part I. This second portion of the Note first develops requirements that any set of abstraction part definitions should satisfy and argues that the proposed definitions meet these requirements. Part II then discusses the costs and benefits of change, arguing that judicial agreement on a coherent set of abstraction part definitions must precede any consensus on the proper scope of protection for software under copyright law. The Note concludes that refining Learned Hand’s abstractions test to recognize the proposed program parts will reduce the chaos presently hindering software copyright infringement law.
I. Existing Technical and Legal Part Definitions
Software begins as an abstract idea and progresses through increasingly specific stages until a literal program emerges.27 These stages are excellent candidates for refinements of the abstractions test, not merely because they arise through step by step refinement of an abstraction, but also because they rest on fundamental programming concepts. A firm understanding of both programming and existing copyright law, however, is necessary before defining these stages as program parts under the abstractions test. Section I.A therefore introduces some basic software concepts. Section I.B defines and illustrates the abstraction parts programmers use while designing, writing, and enhancing software; this Note proposes judicial recognition of these parts. Section I.C discusses abstraction parts courts have previously defined, often implicitly, in applying various tests for substantial similarity to computer programs.
A. Software Basics28
A program29 or piece of software30 is an organized set of instructions that guides a computer. Software, which “runs on” a computer, <Page 531> is distinguished from the physical computer itself, which is hardware. Familiar examples of programs include word processors, spreadsheets, and database management software.31 Programs also perform a wide variety of other tasks, from rendering graphic images to modeling weather patterns and controlling industrial robots.
The literal text comprising a program’s instructions, known as source code, is written in one or more programming languages. These languages resemble human languages such as English, but have much less room for ambiguity.32 Each programming language has a unique grammar and set of meanings.33 Two programs may perform the same functions despite differences in their source code. Conversely, two programs with nearly identical source code may perform very differently. Before source code can be used by the computer it must be translated into a form recognizable to the computer hardware. A compiler translates the source code into object code,34 a string of ones and zeros35 that controls the hardware. Because different computer hardware requires different object codes, one must translate a piece of source code once per hardware type to produce the object codes needed to run the “same” program on different types of computer.
The fundamental distinction between source code and object code illustrates software’s multifaceted nature. Programs, like novels or legal opinions, can be usefully viewed from a variety of perspectives. When the object code runs, the computer hardware interacts with aspects <Page 532> of the program that are largely ignored by programmers. A programmer’s point of view, in turn, often differs from that of the program’s ultimate user.36 One might note other differences in perspective,37 but two are particularly relevant. First, this Note focuses on algorithms and other internal aspects of software that are familiar to programmers but largely invisible to program users. Accordingly, infringement tests developed for use in comparing program user interfaces38 are relevant here mainly as limits on the applicability of the present discussion. Second, this Note describes program parts from a perspective that is more legal than technical, centering its discussion on the relationship between existing doctrines and the proposed part definitions. Sufficient material from computer science is included in the next section to define clearly and completely the proposed parts, but many points programmers would consider important are dealt with only in the footnotes, or omitted entirely.
B. Abstraction Parts Used by Programmers
Programs embody different levels of abstraction because software is best created through a method known as top-down programming, a process that starts with a concept and culminates in a particular computer program.39 A program begins as a purpose or desired function, which programmers expand into a preliminary design. Programmers make this design increasingly specific by splitting large tasks into smaller ones and defining the interaction of these tasks. Some parts of the design may organize the program’s information in convenient formats, while other parts may manipulate or transform the information. Programmers then implement the detailed design by writing source code that describes it. Finally, programmers and others test the program, document it, and release it to users. Although programming does not always proceed neatly from one stage to the next in practice,40 <Page 533> the idealization suffices for this Note.41
Most programmers42 recognize certain program parts and levels of abstraction.43 Partly because of their programming utility, these levels of abstraction are well-suited for use as refinements of Learned Hand’s abstractions test. Because these parts arise naturally from the inherent structure of software,44 they also present a coherent abstractions framework that will facilitate substantial similarity analysis in software copyright cases. These levels of abstraction include: (1) the program’s main purpose; (2) its system architecture; (3) various abstract data types; (4) various algorithms and data structures; (5) the source code; and (6) the object code.
The following description of these program parts introduces several concepts that are unfamiliar to nonprogrammers. Readers whose training is primarily in law rather than computer science will gain an increased understanding of software technology. Software copyright law should reflect the engineering realities of programming, just as the Uniform Commercial Code reflects actual mercantile practice45 and <Page 534> real property law reflects pragmatic aspects of land ownership.46 Moreover, readers familiar with programming should be able to correlate their own training and experience with the technical terms used in this Note. Although the concepts presented below are widely recognized in the programming community, individual programmers may have encountered some of these ideas under different names.
1. Level One: Main Purpose
A program’s main purpose or function is what the program is intended to do. For instance, a database manager’s purpose is to manipulate data. However, definitions of a program’s purpose may be made increasingly specific: the purpose of a database manager is also to facilitate adding, removing, modifying, reading, grouping, and summarizing individual pieces of information in a large collection of data. These purposes, or those of any other program, could in turn be described in ever greater detail. But in this Note a program’s main purpose is whatever the program does, described as specifically as possible without reference to technical aspects of the program – that is, without reference to the other levels of generality described below.
2. Level Two: System Architecture
While main purpose describes what a program does, a system architecture begins to describe how the program operates. The system architecture describes the program in terms of various modules47 and their interconnections. Programmers organize software into modules to facilitate program creation, correction, and enhancement. Each module performs a significant portion of the program’s main purpose and is eventually implemented as a distinct section of the source code. In a hypothetical database manager, three main modules might handle the user interface, data editing functions, and file management, respectively. The user interface module might in turn contain a module to handle screen display, one to read commands, and one to print reports. The system architecture is often irrelevant to the user. For example, a user would neither know nor care whether the print module lies within the user interface module or resides outside as a fourth main module.
A program’s system architecture specifies three kinds of connection between modules: nesting, control flow, and data flow.48 Module nesting is one way that programmers break large jobs into smaller ones; module B is nested inside module A when B performs part of A’s task. In the hypothetical database manager above, the screen display module is nested inside the user interface module. Control flow describes the order in which the modules run. In the database manager, control flows from the command module, which reads commands from a keyboard or other input device, to the other modules that perform the tasks specified by the user, such as printing a report or totaling a column of numbers. Data flow describes the movement of information between modules. In order to open a file, the database manager’s user interface module must pass data in the form of the desired file’s name to the file management module. Although these connections might seem useful in mapping different levels of abstraction, this Note argues against such use; connections may help delineate modules, but all modules lie within the system architecture level of abstraction.
3. Level Three: Abstract Data Types
The modules that comprise the system architecture contain abstract data types (ADTs). Every ADT is jointly defined by two components. First, ADTs contain operations, which define the set of actions one may perform using the ADT. Familiar operations on a database include adding a new piece of data and printing a summary of the current data. Second, ADTs also contain data types,49 which define the kind of item the ADT’s operations act upon. In a database of law students,50 student records might be one data type, and class enrollment records could be another.
An ADT modeling a checking account provides another example. The data type might be a dollar figure representing the current balance, while the permitted operations might include depositing funds, withdrawing funds, computing interest, and reading the current balance. Alternatively, a more elaborate ADT, which keeps track of where the money goes, might be preferred. Such an expanded ADT might include four operations – depositing funds, writing a check, <Page 536> computing interest, and reading the balance – on two types of data: individual check amounts and the current balance.
ADTs in commercial computer programs are generally more complex than the ADTs just described,51 and often have a stronger mathematical flavor.52 But the motivation behind every ADT is to associate a given data type with the operations that are useful in manipulating that type. The resulting distinction between actions – ADT operations – and things acted upon – ADT data types – reappears in the next level of abstraction, as a distinction between algorithms and data structures.
4. Level Four: Algorithms and Data Structures
Under this Note’s analysis, algorithms and data structures jointly occupy the level of abstraction below ADTs. Algorithms and data structures are more specific versions of ADT operations and data types, respectively. ADT operations are brought closer to realization as functional source code by specifying algorithms that accomplish the desired operations. Similarly, ADT data types are more precisely specified through descriptions employing data structures.
An algorithm is a series of steps that accomplishes a particular ADT operation.53 While an ADT operation merely identifies a desired result, an algorithm specifies every step necessary to accomplish that result.54 Algorithms must contain sufficient detail to permit their implementation in source code once a programming language and computer hardware are chosen.55 The operation “determine whether a number is divisible by nine” may be performed by the following algorithm: <Page 537> “Add the number’s digits, then add the digits of the result, then add the digits of that result, and so on, until a single digit remains. The original number is a multiple of 9 if and only if the final single digit is 9.”56 Different algorithms may solve the same problem, as this second algorithm,57 which also tests divisibility by nine, illustrates: “Keep subtracting 9 from the number until the result is either zero or negative. The original number is divisible by nine if and only if the final result is zero.”
Just as algorithms describe specific steps that perform ADT operations, data structures provide specific representations of ADT data types. Together with algorithms, data structures are among the most widely recognized and studied of the computer program parts discussed in this Note.58 Several concepts introduced in the upcoming description of data structures will be unfamiliar to nonprogrammers,59 but part definitions that lack sufficient engineering detail quickly degenerate into vague notions that vary widely from case to case.60 Proper understanding and identification of data structures therefore requires discussion of the following six data structure components: basic data type, value, variable, array, record, and pointer.
A basic data type describes a set of values. Zero, 1, and -1 are integer61 values. Other basic data types includecharacter and floating point. “A,” “B,” and “C” are character values. The numbers 0.0625 <Page 538> and 1/3 are floating point values. Different programming languages support different basic data types, but integer, floating point, and character types are widely available.
A Variable is a named storage location that holds values of some particular data type. One might speak of an integer variable named “Total” that presently holds the integer value 33.62
An array is a row of some predetermined number of variables of a given data type. The entire array has one name. Each individual variable in the array, or array element, is referred to by the array’s name and the variable’s relative position (its index) within the array. Suppose the array of ten characters shown in Figure 1 is named Key Word; the current value of Key Word[0] is “J,” the value of Key Word[1] is “U,” the value of Key Word[2] is “S,” and so on. Various mechanisms permit software to ignore array elements not currently needed, such as Key Word[7], Key Word[8], and Key Word[9]. The value of Key Word as a whole is “JUSTICE.” The variables that constitute an array may also themselves be arrays63 or one of the other data types described in this section, as long as every element of the array is of the same type.
Figure 1
An Array of Character Variables
A record, unlike an array, may group together variables of different basic data types. One might join two integers named Year and Day <Page 539> with an array of characters named Month to create a record named Current Date; Current Date is then said to have three fields. The fields of a record are referred to by record name and field name. If an arrow (<--) denotes assignment, one could assign a date value to the record variable Current Date by assigning values to Current Date’s fields as follows:
Current Date.Year <-- 1992
Current Date.Month <-- “August”
Current Date.Day <-- 13
A pointer is a connection between two discrete records. Pointers are helpful when a program must manipulate a different number of records each time it runs. Suppose a database program must input widely varying numbers of student records and sort them alphabetically. Any array of record variables will usually be either too large or too small because the number of records being read changes but the number of array elements does not.64 By using pointers and setting aside space to hold each record’s values just before it is read instead of allocating a fixed amount of space ahead of time in an array, the program acquires only as much storage space as it actually needs.
This understanding of the six data structure components permits the formulation of a useful definition of data structures. A data structure consists of one or more variables of the basic data types, which are organized in some specified combination of arrays, records, and pointers. A single variable, such as an integer variable Total Due, is thus the simplest data structure. Current Date is a data structure consisting of one record with two integer fields named Year and Day and one character array field named Month. Data values are irrelevant to data structures in the sense that the values stored in a data structure may change without altering the rules that govern the structure’s organization. Total Due is the same data structure no matter which integer value it contains, and Current Date is the same data structure no matter which values are stored in its fields.
Relatively simple data structures, illustrated by Total Due and Current Date, are correspondingly easy to identify in a given program, and to compare in two programs. Assessing the alleged equivalence of more complex data structures may be much harder. Complicated data structures are built by combining simpler data structures, which in turn are built from basic data type variables.65 <Page 540> One may create an array of records, or a record whose fields are arrays, or considerably more complex structures. The collection of all functionally equivalent data structures in any actual situation may be quite large and diverse. Accordingly, an ADT data type may often be represented by more than one data structure,66 just as various algorithms may be available to perform an ADT operation.
In summary, recall that ADTs consist of operations and data types; operations denote actions, and data types denote the type of item acted upon. An algorithm is a sequence of steps, not necessarily unique, that performs an ADT operation; a data structure is one possible representation of an ADT data type. Each data structure is a collection of basic data type variables combined using arrays, records, and pointers. Although data structures and algorithms are more specific than ADTs and may even depend on certain programming language features for use, they are independent of any specific programming language or piece of literal source code.
5. Levels Five and Six: Source Code and Object Code
Source code67 is the literal text of a program’s instructions, written in one or more programming languages. Source code can be read by programmers, but to run a program on a computer the program’s source code must be translated into object code.68 Object code is a string of ones and zeroes tailored to turn on and off the various electronic switches in a particular kind of computer, thereby manipulating the meanings associated by programmers with different switch settings.
Consideration of source code and object code as levels of abstraction for copyright purposes raises two definitional issues. First, it may or may not be appropriate to distinguish source code from object code. Second, it may or may not be appropriate to distinguish either type of code from the program as a whole. Source code and object code both belong in the set of abstraction part definitions only if source code and object code are distinct from each other and distinct as well from the levels of abstraction already described.
In response to the first issue, object code clearly lies at a lower level of abstraction than source code, because object code must contain significant detail not found in the corresponding source code in order to control a given computer.69 Resolution of the second issue, however, <Page 541> requires reconsideration of the abstraction parts already described. Main purpose, system architecture, ADTs, algorithms, and data structures are discussed above as if they were tangible, and to professional programmers, they are indeed no more ethereal than a character is to a novelist. In the courtroom, however, these program parts exist only as expert opinions mined from the source code and object code.70 A program’s entire range of abstraction is embedded in its code in roughly the same way a novel’s characters and plot are embedded in its text.71 Therefore, care must be taken to avoid confusing code as the embodiment of parts at every level of abstraction with code as a level of abstraction in its own right.72 This Note denotes code-as-embodiment by program or software, and code-as-a-level by code. A program consists of a main purpose, a system architecture, ADTs, algorithms, data structures, and code; code may therefore be defined as “the portion of a program that does not overlap the program’s main purpose, system architecture, ADTs, algorithms, or data structures.” Every level of abstraction but code is clearly bounded under the definitions provided above, and these other levels taken together do not exhaust the contents of a program. Code may therefore be effectively defined as a discrete program part through a process of elimination.
Programmers, then, see programs as consisting of parts lying at six <Page 542> levels of abstraction: (1) main purpose; (2) system architecture; (3) ADTs; (4) algorithms and data structures; (5) source code; and (6) object code.73 These levels arise naturally from the inherent structure of software.74 As the next section reveals, however, legal definitions of <Page 543> program abstraction parts differ substantially from programmers’ definitions.
C. Software Abstraction Parts and the Judiciary
Analysis of the abstraction part definitions employed by judges in software copyright infringement cases begins with the definitions’ somewhat muddled legal context. Because abstraction part definitions spring from substantial similarity tests, section I.C.1 first summarizes in broad terms the importance of substantial similarity to copyright infringement in general, and to computer program part definitions in particular. The section also briefly examines several overlapping and interacting copyright concepts and doctrines as they relate to substantial similarity in software infringement cases: (1) the idea-expression dichotomy; (2) Learned Hand’s abstractions test; (3) judicial definitions of computer program parts by abstraction or otherwise; and (4) various traditional copyright doctrines. Section I.C.2 dissects each of the prevailing software substantial similarity tests to reveal their abstraction part definitions, both implicit and explicit, and summarizes the merits of those definitions. This section concludes that the major existing substantial similarity tests fail to provide a coherent framework of computer program part definitions, but do shed light on what such a framework should contain.
1. Substantial Similarity and Related Analyses
To prevail, a copyright infringement plaintiff must prove both copyright ownership and copying by the defendant.75 As eyewitness testimony of copying is rare,76 plaintiffs often demonstrate copying through “circumstantial evidence of access to the copyrighted work and substantial similarity between the copyrighted work . . . and the allegedly infringing work. . . .77 However, access is often conceded or easily proven,78 so “[i]n most cases the ‘substantial similarity’ inquiry presents the heart of a copyright infringement case. . . .”79
Copyright law’s fundamental distinction between idea and expression helps shape tests for substantial similarity. Because ideas80 are not protected by copyright,81 similarity between ideas is irrelevant to proof of infringement.82 In theory, substantial similarity tests compare only the expression in two software programs.83 However, the <Page 545> Copyright Act does not define idea or expression,84 and discordant substantial similarity tests reflect judicial disagreement over where the line between idea and expression should be drawn.85
Although Learned Hand’s abstractions test86 does not specify where the idea-expression line lies,87 refinements of the test that define appropriate levels of abstraction may help courts properly draw the line during a substantial similarity analysis. Three of the four prevailing substantial similarity tests do not incorporate the abstractions test.88 Two of these tests, however, have been sharply criticized as vague or overly broad,89 and thus could benefit from the graduated distinctions made possible by the Learned Hand test.90 Furthermore, the recently adopted successive filtering test, which is the most comprehensive of the four tests, does incorporate the abstractions test.91 This Note argues that established substantial similarity tests fail to distinguish between levels of abstraction merely because Learned Hand’s <Page 546> test has never been appropriately tailored to software, not because there is any benefit in ignoring abstraction parts.
Although this Note focuses on abstraction parts, other parts also arise during substantial similarity analysis. Certain program elements serve doctrinal or evidentiary roles in assessing misappropriation. A brief discussion of these elements places abstraction parts in context and illustrates the limited nature of this Note’s proposed changes. Refining abstraction part definitions will not fundamentally alter the use of doctrinal or evidentiary elements in substantial similarity tests.
Doctrinal program elements are implicitly defined by many traditional copyright doctrines that distinguish between protectable and unprotectable material.92 For instance, the copyright statute only protects “original” works.93 This statutory originality requirement divides programs into an unprotectable portion that does not owe its origin to the author, and a potentially protectable portion that does.94 A single doctrinally defined portion of a program may cut across several levels of abstraction. Suppose a database program incorporates public domain code for sorting names alphabetically. This doctrinally delimited section of the program includes several abstraction parts, namely code that implements an algorithm for performing a sorting operation on values of a certain ADT data type. Recognizing abstraction parts under this Note’s proposal will not hinder the application of public domain and other traditional doctrines; only the idea-expression doctrine will be directly affected, and even there the intended result is to clarify rather than to change substantively the characterization of program parts under the doctrine.
Evidentiary elements are defined when courts treat particular pieces of source code as evidence of verbatim or nearly verbatim copying.95 Programmers develop various distinctive stylistic preferences <Page 547> that are loosely constrained by a program’s data structures, algorithms, and other more abstract parts.96 Similarity in such stylistic choices may therefore serve as evidence of verbatim copying.97 Under this Note’s approach, such stylistic choices often all lie within the source code level of abstraction.98 Therefore, the proposed framework is independent of evidentiary elements, just as a framework describing novels in terms of plot and character is distinct from font size or typeface choices. Accordingly, adoption of this Note’s proposed framework will not change the type of evidence used in software copyright infringement cases.
Evidentiary and doctrinal elements, as well as abstraction parts, play distinct but interrelated roles in software substantial similarity analysis. Evidentiary elements provide proof of copying, while doctrinal elements represent policy decisions about the types of copying that should be prohibited. Abstraction parts – when properly defined – illuminate the relationship between evidentiary elements and the idea-expression doctrine by clarifying which portions of a program are being categorized as idea and which are being treated as expression. This Note addresses abstraction parts rather than doctrinal or evidentiary elements because unclear and contradictory abstraction part definitions lie at the heart of the confusion over software substantial similarity analysis.
Despite the often dispositive role of substantial similarity, most judicial attempts to formulate a test applicable beyond the case at hand have failed. One court listed several “stages of development of a program,” including “a definition, in eye-legible form, of the program’s task or function; a description; a listing of the program’s steps and/or their expression in flow charts;” source code; and object code.99 The first stage, “task or function,” corresponds to section I.B’s main purpose. The meaning of the second stage, “description,” is unclear. The final three stages correspond respectively to section I.B’s algorithms, source code, and object code parts. Large sections of software are overlooked; these five stages apparently omit data structures, ADTs, and system architecture. Likewise, in Computer Associates International, Inc. v. Altai, Inc.,100 the court created an unclear and incomplete <Page 548> set of abstraction parts. In Altai, the court quoted Judge Hand’s description of the abstractions test before asserting that when “applied to computer software programs, this abstractions test would progress in order of ‘increasing generality’ from object code, to source code, to parameter lists, to services required, to general outline.”101 The Altai court’s object code and source code levels of generality correspond to this Note’s parts of the same name.102 “Parameter lists” are part of the program’s interface with other programs, and hence lie outside this Note’s scope. “Services required” may also be dictated by the interface, but this part could affect system architecture or ADTs as well. “General outline” seems to mean some combination of section I.B’s system architecture and main purpose. But nothing in the Altai court’s list seems to correspond to data structures or algorithms. Other judicial attempts to formulate a framework of abstraction parts also contain serious flaws.103
A third example shows the difficulty in evaluating abstraction parts due to unsettled terminology that complicates the extraction of part definitions from cases. In Pearl Systems, Inc. v. Competition Electronics, Inc.,104 the court referred several times to “the system level design.”105 As defined by the copyright holder’s expert, “system level design” corresponds roughly to this Note’s notion of system architecture.106 The court, however, treated “system level design” as equivalent to user interface rather than to system architecture. The court observed that the copyright holder “was able to change the subroutines so that a different sequence of buttons would be used to enter the par time and to engage the shot review function. This resulted from a change in the systems level design of the software.”107 The court continued by saying:
Moreover, the subroutines in both [plaintiff’s and defendant’s devices] were triggered by the same sequence of buttons. As there was ample testimony that alternative system level designs could have been used to avoid this similarity, we conclude that the idea did not have only one necessary form of expression, but many.108
Even when terminology is clear, however, the software substantial similarity tests conflict with each other,109 and their definitions correspond poorly with the abstraction parts employed by programmers.110 Forum shopping,111 expensive “clean room” program development,112 and other undesirable consequences113 follow from deficient part definitions. Furthermore, the difficulty of formulating legally useful and technically accurate program part definitions has apparently led to despair as well as disarray. One group of courts has seemingly abandoned even nominal pursuit of comprehensive program part definitions, essentially ignoring all but evidentiary elements.114 Another group simply refuses to dissect programs at all.115 The following subsection explores judicial efforts to analyze substantial similarity <Page 550> and compares the computer program parts these efforts explicitly or implicitly recognize with the parts recognized by programmers.
2. Current Substantial Similarity Tests
Software copyright cases utilize four major substantial similarity tests: (1) the iterative test; (2) the structure, sequence, and organization (SSO) test; (3) the “look and feel” or “total concept and feel” test; and (4) the successive filtering test. Each substantial similarity test defines program abstraction parts differently; these definitions are often implicit116 or unclear.117 At best, the definitions blur the levels of abstraction proposed insection I.B; at worst, the levels are ignored altogether.118
a. The iterative test.
Originally derived from a student law review Note,119 the iterative test for substantial similarity was first formally adopted by a court in E. F. Johnson Co. v. Uniden Corp. of America.120 The test has two prongs, but only the second prong is relevant to abstraction part definitions. The first prong merely asks whether “the defendant ‘used’ the copyrighted work in preparing the alleged copy, which may be established by proof of access and similarity sufficient to reasonably infer use of the copyrighted work. . . .”121 This prong “amounts to little more than a variation of the traditional substantial similarity analysis” and so adds nothing to the search for proper program part definitions.122 The iterative test’s second prong, however, asks whether “the defendant’s work is an iterative reproduction, that is, one produced by iterative or exact duplication of substantial portions of the copyrighted work.”123 The Uniden court interpreted this prong of the iterative test as a prohibition against literally copying124 or literally translating125 code.
The iterative test thus divides programs into protected literal code, <Page 551> protected literal translations of code, and the unprotected remainder of the program. Uniden’s literal object code and source code parts clearly correspond to source code and object code as defined above. The correspondence between literal translations and this Note’s definitions is less clear, but it seems limited to the three possibilities shown in Figure 2. The translations Uniden speaks of are not translations from source code into object code, but rather translations of a program from one programming language into another.126 Generally speaking, a translation of a program from one language to another may require changes in data structures, algorithms, or even more abstract program parts.127 The first possibility shown in Figure 2 matches literal translations to algorithms and data structures because protection of literal translations seems to require protection of algorithms and data structures that differ from those of the original program only in ways required by translation. Furthermore, even though the Uniden court did not speak in terms of algorithms and data structures, the court’s protection of a “Barker code” algorithm128 and an “H-matrix” data structure129 suggest that algorithms and data structures <Page 552> lie within a protected level of abstraction; algorithms and data structures are clearly more abstract than code, so they must lie in the level occupied by literal translations.
Figure 2
Possible Correspondence Between Uniden and Proposed Abstraction Parts
Figure 2 also shows a second possibility, in which literal translations cover only part of the range of abstraction covered by algorithms and data structures. Literal translation is not rigorously defined in Uniden, but much of the opinion’s language speaks of verbatim copying.130 Algorithms and data structures embedded in a piece of source code can often be copied without duplicating or even approximating the source code’s style; avoiding similarity in source code wording while actually copying functionality is often easy.131 Uniden’s emphasis on protecting “literal” program parts might therefore be interpreted to prohibit use of data structures or algorithms that substantially replicate the original author’s efforts, both in terms of <Page 553> substance and in terms of programming style.132 This narrower definition of literal translation protects more than the literal source code, but covers less than the entire range of abstraction covered by data structures and algorithms.
The third possibility shown in Figure 2 is that literal translations encompass data structures, algorithms, and more abstract parts as well. Uniden’s discussion of literal translation is shaped by Whelan Associates v. Jaslow Dental Laboratory, Inc.,133 a case that treats everything except a program’s purpose as protectable expression.134 Without more guidance, however, it is unclear whether any of these three interpretations is correct.
The iterative test is unsuitable, therefore, because it does not clearly define any abstraction parts other than literal code. Furthermore, even if the definition of literal translations could be clarified, the iterative test would still destabilize software copyright law by recognizing too few levels of abstraction. The literal code component bundles together source code and object code, even though they are clearly discrete abstraction parts. Similarly, literal translations and idea attempt to span four levels of abstraction with only two components. As the history of the SSO test discussed next illustrates, such overly broad definitions too often lead subsequent courts to define additional abstraction parts in conflicting ways.
b. The structure, sequence and organization test.
The structure, sequence, and organization (SSO) test was formulated and first applied in Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc.135 Whelan stated that “the purpose or function of a utilitarian work would be the work’s idea, and everything that is not necessary to that purpose or function would be part of the expression of the idea.”136 In other words, protection may be available for every part of a program except its single overriding purpose.137
The SSO test thus defines programs as having a purpose part and an SSO part. As illustrated in Figure 3, Whelan’s purpose part corresponds to section I.B’s main purpose.138 SSO corresponds to system <Page 554> architecture, ADTs, algorithms, and data structures,139 because Whelan also discusses source code and object code. Like Uniden, Whelan does not purport to apply Learned Hand’s test, so the correspondences with abstraction parts shown here were deduced mainly from the case as a whole rather than any explicit definitions.
Figure 3
Correspondence Between Proposed Abstraction Parts and Parts Defined in Whelan and Healthcare.140
Whelan’s part definitions are poorly adapted to the abstractions test because they fail to distinguish different levels of abstraction within a program’s SSO. Uniden and other cases draw the idea-expression line inside the SSO, suggesting that the range of abstraction encompassed by SSO is too broad.141 “The crucial flaw in [Whelan’s] reasoning is that it assumes that only one ‘idea,’ in copyright law terms, underlies any computer program, and that once a separable idea can be identified, everything else must be expression.”142
Parts, such as SSO, that cover too much of the abstraction spectrum compel courts to define additional parts in subsequent cases. In Healthcare Affiliated Services, Inc. v. Lippany,143 the court nominally followed Whelan but actually narrowed the breadth of SSO by defining a new abstraction part, methodologies. The Healthcare court treated methodologies as idea rather than expression144 by denying them copyright protection. Unfortunately, Healthcare did not expressly define methodology, so the part may be difficult to recognize in subsequent cases. The examples145 provided in the Healthcare opinion and the court’s reasoning146 seem to equate methodologies with system architecture and ADTs, as shown in Figure 3, but other correlations are not ruled out. Courts also nominally recognized SSO in both Johnson Controls, Inc. v. Phoenix Control Systems, Inc.,147 and Telemarketing Resources v. Symantec Corp.,148 but actually focused on more specific program parts and declined to apply the SSO test.149
In short, the SSO test is unsuitable because overly broad parts such as SSO require subsequent courts to define additional parts: such narrowing definitions are, unfortunately, typically concerned with the characteristics of a particular program rather than with the widely recognized components of programs in general. These additions to the growing collection of judicially recognized program parts therefore make poor candidates for a generally applicable abstractions framework.150 <Page 556> Rather than defining additional parts, however, some courts have chosen to define no parts at all, as the next test illustrates.
c. The “total concept and feel” test and the “look and feel” test.
Unlike the iterative and SSO tests for substantial similarity, the “total concept and feel” test did not arise in a software infringement case, but emerged rather from a case concerning greeting cards.151 Subsequent cases involving juvenile books152 and a children’s television program153 further developed the test, which finally came to software cases by way of video game infringement suits.154 This history suggests that the total concept and feel test might be poorly suited to the analysis of software infringement, and such is indeed the case.
The total concept and feel test apparently defines no program parts at all. Instead, the test finds substantial similarity if the allegedly infringing work captures the copyrighted work’s total concept and feel.155 A closely related test compares two works’ “look and feel.”156 The feel tests are so situation-dependent that any general statement of how they work is necessarily inaccurate. Feel, as one court put it, “is a conclusion. . . . Thus, in trying to understand the relevance of ‘concept and feel’ precedents, we need to look to details of those cases that appear to have been relied upon in reaching the conclusion, rather than merely embracing the conclusion without regard for underlying reasons.”157
Examination of particular feel cases is unnecessary, however, because both feel tests suffer from fundamental flaws that render them<Page 557> practically useless in an abstractions test. Software cases have developed the feel tests primarily in disputes over the similarity of user interfaces;158 because user interfaces are by definition meant to be used and understood by nonprogrammers, this legal context provides little guidance in analyzing internal program components such as ADTs, algorithms, and data structures which are normally seen only by programmers. Both feel tests have also been appropriately criticized as vague and overly broad.159 Moreover, the copyright statute expressly forbids protection of concepts.160 Courts sometimes adapt the tests by focusing on specific program parts, but different courts discuss different parts,161 and some of the parts introduced in an attempt to avoid vagueness are themselves poorly defined.162 In sum, although the feel tests may be appropriate for assessing the similarity of greeting cards, they are wholly unsuitable for determining levels of abstraction in software infringement cases.
d. The successive filtering test.
The perceived shortcomings of the iterative, SSO, and total concept and feel tests for substantial similarity spurred the adoption of a successive filtering test.163 The test <Page 558> was originally suggested by Professor Nimmer and his colleagues:
To [evaluate substantial similarity] an allegedly infringed program should be analyzed on several different levels. A different copyright doctrine is applied at each level, and material which is unprotectable under that doctrine is excluded from further consideration in analyzing substantial similarity. By successively filtering out unprotectable material, a core of protected material remains against which the court can compare the allegedly infringing program.164
Successive filtering therefore recognizes that complex software is best analyzed for similarity by partitioning it appropriately. However, separating programs into doctrinal levels is not equivalent to adopting an abstraction parts analysis.
Many traditional copyright doctrines have little bearing on the idea-expression distinction. For example, scenes a faire165 analysis under successive filtering denies copyright protection to those portions of a program that “follow naturally from the work’s theme rather than from the author’s creativity.”166 Suppose a program must accept information stored on noncopyrightable paper forms and add the information to a computer database. The data structure A into which values are initially read may well be substantially dictated by the paper forms, but the final destination of the values, data structure B in the database, is largely independent of the various values stored. Under scenes a faire, A is therefore denied protection while B is not.167 By distinguishing between data structures, which all lie in a single level of abstraction, scenes a faire analysis creates a distinction based on concerns other than level of abstraction. Parts defined by the scenes a faire doctrine therefore do not belong in any refinement of Learned Hand’s abstractions test. Other doctrines applied during successive filtering, including lack of originality, independent creation, and fair use, similarly ignore program part definitions that are based on level of <Page 559> abstraction.168
Successive filtering in its present form is too broad and undeveloped to provide adequate abstraction part definitions. Although abstraction is central to the idea-expression dichotomy,169 the other traditional doctrines successive filtering invokes170 are based on policies that find no clear reflection in levels of abstraction. While successive filtering may certainly build on a prior abstraction analysis,171 it may not replace that narrower analysis. Unfortunately, the abstraction analysis performed under the recently adopted successive filtering test utilizes definitions that either are tailored too closely to a specific type of program172 or drawn too vaguely to identify distinct levels of abstraction.173
Vague and incongruous program part definitions in existing substantial similarity tests cripple current judicial efforts to adapt Learned Hand’s abstractions test to software copyright infringement cases. A stable set of part definitions could narrow the range of disagreement over where to draw the idea-expression line, as well as discourage the present practice of defining new, inconsistent parts on a case-by-case basis. The following Part proposes a standard for evaluating the suggested definitions.
II. Properly Defining Program Abstraction Parts
This Part argues for judicial adoption of the abstraction part definitions presented in section I.B. Section II.A discusses requirements any set of definitions should satisfy and establishes that the proposed definitions meet these requirements. Section II.B discusses the merits of change, arguing that consensus on the appropriate scope of copyright protection for software is impossible without judicial agreement on a coherent set of abstraction part definitions. The Part concludes that courts should adopt this Note’s abstraction part definitions or an equivalent set of definitions, instead of masking policy decisions and ignoring programming realities.
A. Criteria for Defining Abstraction Parts
This section presents requirements that any set of abstraction part definitions used in software copyright infringement cases should satisfy. Briefly stated, the definitions should divide any program into a manageable and complete set of stable, nonoverlapping abstraction parts that defer appropriately to existing law and accepted programming concepts. Any attempt to provide a stable definitional foundation for software substantial similarity analysis should meet the standard defined by these requirements. The section reconsiders the part definitions proposed in section I.B and argues that they satisfy these requirements, unlike many of the part defined by existing substantial similarity tests.
The primary purpose of any set of part definitions is, of course, to minimize ambiguity. When program part definitions partition a range of abstraction into smaller parts, ambiguity may manifest itself as unstable borders between parts. The importance of firmly established abstraction part boundaries to legal consistency is evident from the forgoing discussion. Hence expression, as defined by the substantial similarity tests examined in section I.C, is unsuitable as a program part because its boundaries shift widely from case to case. Other than purpose and code, the other parts defined by existing substantial similarity tests have also proven unstable.174
The abstraction parts proposed in section I.B., however, are defined in terms of stable software engineering characteristics of the various levels of abstraction.175 These characteristics of software do not depend <Page 561> on legal policy concerns, and therefore persist unaltered throughout many different fact situations. Basing part definitions on established programming concepts176 also has the advantage of narrowing the gap between copyright law and computer science; because the abstraction level boundaries in any particular program are drawn in practice through expert testimony,177 part definitions that make sense to programmers are desirable.
Although stable part boundaries help eliminate ambiguity, they are not sufficient because ambiguity may also occur when boundaries overlap. Levels of abstraction should be distinct from one another,178 but conflicting approaches by different courts have created a set of program parts that overlap each other in a multitude of confusing ways. As a result, SSO overlaps literal code,179 and methodologies apparently overlaps algorithms and literal translations.180 User interface spans the entire range of abstraction,181 as does total concept and feel,182 and therefore each of these overlaps every other program part. Courts could attempt to eliminate overlapping part boundaries by selecting parts from among those already defined to obtain a set of distinct parts. However, most such parts are defined in conclusory legal terms, not according to independently grounded programming criteria, so they are subject to drift in future cases. Moreover, if parts are selected from several substantial similarity tests, they might not fit together neatly because they arose in, and are tailored to, different factual contexts. A set of parts S consisting of Uniden’s literal code, <Page 562> Healthcare’s methodologies, and Whelan’s purpose, for instance, omits the range of abstraction covered by data structures and algorithms.183 In selecting among existing parts, eliminating overlap may therefore require introducing gaps between parts.
Gaps between parts are undesirable because they may be closed incompatibly. A gap may be closed by extending the range of the less abstract part, by extending the range of the more abstract part, or by “plugging” the gap with an additional part. In the example S, an inconsistency arises if one court extends literal code to encompass data structures and algorithms while another court extends methodologies to cover the same range; the situation deteriorates even further if a third court plugs the gap by including data structures and algorithms in the range of abstraction covered by modules184 or another additional part. The proposed definitions prevent such problems by comprehensively covering the entire range of abstraction from object code up to main purpose. Existing definitions, by contrast, contain gaps. The total concept and feel test apparently omits algorithms, data structures, and ADTs.185 Other sets of abstraction parts noted by courts also leave gaps between levels of abstraction.186 Courts could eliminate overlap and avoid gaps more effectively by adopting a new set of part definitions. The parts proposed in section I.B are distinct from one another because each level of abstraction contains specific software entities not found in the higher levels.187 Moreover, the proposed definitions were designed from the start to complement each other; this cannot be said of any aggregation of existing parts plucked from different substantial similarity tests.
Of course, correct part definitions must do more than merely eliminate ambiguous overlaps and gaps; confusion may also arise if definitions address fundamentally different policy concerns. In particular, <Page 563> doctrinal elements and evidentiary elements should be excluded from the set of abstraction part definitions. Doctrinal elements implicate different concerns about the scope of protection than do abstraction parts, because scenes a faire and other doctrines rest on different policy concerns than the idea-expression dichotomy.188 Evidentiary elements are much more program-specific and programming-language-specific than abstraction parts, so their inclusion hampers the goal of creating a manageable and stable set of definitions. This Note’s proposal recognizes that abstraction parts, doctrinal elements, and evidentiary elements each play a different critical role in software infringement cases.189
In deciding what parts to include or exclude, the analysis should defer to prior legal analysis where possible. The proposed definitions accordingly defer to what little agreement exists among courts regarding levels of abstraction. All courts recognize a program’s purpose as an unprotectable idea that lies at the most abstract level of any program, and all courts treat literal code as the most concrete expression in any program.190 The unsettled state of software copyright law strongly suggests that this agreement is worth preserving. Levels of abstraction that have already received judicial notice should also receive some deference. However, complete consistency between new and existing abstraction parts is not required, because most existing sets of abstraction part definitions are mere lists of terms mentioned in passing, rather than coherent definitions arrived at after careful legal and technical analysis.191
On the other hand, prevailing legal judgments about the proper location of the idea-expression line deserve deference, because courts have carefully analyzed that issue. The line between idea and expression marks a change from the abstract to the specific.192 The proposed <Page 564> levels are defined in a way that permits courts following precedent to draw the line between two levels instead of within a level. Main purpose and source code are proposed as parts because the SSO test and the iterative test, respectively, draw the idea-expression line along the borders of these parts. The proposed definitions also avoid extremely broad parts such as SSO and total concept and feel, because overly broad abstraction parts defined by one court tend to fragment as other courts draw the idea-expression line inside them.193 Even with sufficiently small parts, courts may still draw idea-expression lines in several different places. But each line will lie on one of the borders between recognized levels of abstraction, and the prevailing agreement that purpose is an idea and that code is expression will also be preserved.
Although the definitions should create enough levels of abstraction to permit courts to draw the idea-expression line between levels, too many levels of abstraction are just as undesirable as too few levels. Creating too many parts will make any set of definitions intellectually unmanageable. Decreasing the number of parts reduces the number of software engineering definitions courts must master to apply the definitions in practice. Keeping the number of parts small may also make expert testimony more useful. Defining fewer parts tends, of course, to increase the range of abstraction covered by each part. These larger parts may in turn promote agreement among experts asked to classify a given piece of evidence according to its level of abstraction. Expert testimony may thus be freed of fine distinctions that are important to programmers but irrelevant to the legal issues at hand.194
Any upper limit on the number of parts is arbitrary, but apparently no court has recognized more than five abstraction parts or levels at one time.195 The proposed definitions require familiarity with numerous <Page 565> technical concepts, and define more parts (seven) and levels of abstraction (six) than any court has previously utilized. The definitions proposed here, however, should not be dismissed as overly complex. First, although some familiarity with programming concepts is required, judges need not be experts to apply the proposed definitions. A judge who cannot actually translate code from one programming language to another is nonetheless capable of understanding expert testimony about the effects of translation on the program’s system architecture, data structures, and source code. Furthermore, courts applying the proposed definitions in software infringement cases may and should rely on competent counsel, as well as court-appointed experts196 or special masters197 where appropriate. Finally, the proposed definitions are less numerous and more coherent than the existing jumbled confusion of parts. The cases discussed in this Note employ explicitly or implicitly at least seventeen abstraction parts,198 many of which contradict each other.
In summary, the proposed framework meets requirements that any set of program abstraction part definitions should satisfy. The proposed definitions cleanly divide a computer program into an intellectually manageable set of discrete abstraction parts, covering the entire range from main purpose through object code, without gaps. The definitions are stable and workable because they rest on widely recognized aspects of top-down programming. Existing idea-expression distinctions receive deference and abstraction parts already recognized by courts are given due consideration. Although the proposed abstraction parts are therefore preferable to other definitions, the larger question of the need for any explicit definitions at all merits further consideration.
B. Merits of Explicit Abstraction Part Definitions
This section argues that the program part definitions of section I.B should be adopted judicially because they form a clear and consistent framework that rests on well-established programming and copyright concepts. The section first argues that an explicit framework of abstraction parts will provide a useful yardstick for comparing existing and proposed substantial similarity tests by separating objective definitional issues from more subjective policy debates. The section then argues that an explicit framework may beneficially narrow the range of disagreement over placement of the idea-expression line by clarifying what is being classified as idea or expression. The section also argues that a desirable decrease in the case-by-case proliferation of new program parts may follow from adoption of explicit, technically based definitions. Finally, the section concludes that even though adopting a framework of part definitions requires departure from existing case law, the benefits of express definitions substantially outweigh the costs.
Adopting a single framework of abstraction parts facilitates comparison of policy arguments about protection199 by providing a yardstick for measuring different substantial similarity tests. One cannot directly compare the SSO and iterative tests because of their different terminology, but superimposing this Note’s framework on the cases reveals that the iterative test does not protect ADTs while the SSO test does.200 Recognizing ADTs as one part in a framework of parts common to both tests permits a focused policy discussion on the wisdom of protecting ADTs201 where previously only a general discussion of tradeoffs between prohibiting literal copying and protecting SSO was possible. Superimposing any other coherent framework would, of course, similarly facilitate comparison of different substantial similarity tests.
Lacking a settled abstractions framework, the existing cases mix controversial policy-based arguments over the proper scope of protection with definitional questions about program parts, and fail to reach agreement on either front. Several observations suggest that previous judicial attempts at part definitions are shaped to some extent by a <Page 567> priori judgments about the proper scope of protection. First, new parts are defined in cases that move the idea-expression line. For example, Healthcare’s introduction of methodologies202 permitted that court nominally to follow Whelan while actually providing narrower protection. Second, several of the parts are judicial constructs rather than embodiments of recognized programming concepts.203 Third, some cases do not precede discussion of the scope of protection with a separate discussion defining a program’s levels of abstraction; instead, definitions of the scope of protection and of the inherent program structure are jumbled together.204 Establishing a stable framework of abstraction parts allows judges to separate policy conclusions from software engineering definitions more easily, as they must in order to resolve policy issues permanently.
A harmonious framework of abstraction parts may also narrow the range of disagreement over where the idea-expression line should be drawn by clarifying precisely what is being treated as idea or as expression. If this Note’s framework were adopted, a consensus might emerge that a program’s main purpose and system architecture are ideas, while source code and object code are expression; such a consensus would narrow the range of disagreement to ADTs, algorithms, and data structures. Alternatively, courts might agree that algorithms and data structures constitute expression. The significance of this Note’s framework lies not in predicting what consensus will emerge, but rather in noting that the current lack of a common framework makes any consensus extremely unlikely; without a framework, it is unclear precisely what part of a program has been treated as idea or as expression. Moreover, even if courts continue to disagree over protectability, explicit levels of abstraction may at least encourage courts to draw the idea-expression line between parts rather than within them.205 If two courts both recognize that ADTs are basic parts of any program and agree that the ADT level of abstraction is indivisible for idea-expression purposes, then progress has been made even if one court draws the idea-expression line above ADTs while the other draws it below. <Page 568> At present, the various substantial similarity tests do not even employ the same parts terminology.
Adopting this Note’s proposal to define explicitly program parts by their level of abstraction will also discourage further case-by-case part definitions because the abstractions test fits the inherent top-down structure of software.206 Courts rely on expert testimony to identify parts,207 and programmers substantially agree on the levels of abstraction presented in section I.B because these levels reflect the inherent structure of top-down programming.208 Any framework of abstraction part definitions that permits programmers to tender opinions using familiar terms should be more stable than the current tangle of conflicting and unfamiliar program parts.209
In contrast with the advantages just described, the cost of adopting a common framework of program part definitions for use in substantial similarity analysis is small. Some departure from existing case law is required because the various program parts presently recognized are simply irreconcilable.210 However, the departure is limited in that contested part definitions do not undermine the basic rationales for traditional copyright doctrines and policies. The universally accepted holding that every program has a purpose that is an unprotectable idea will be unaffected by any framework that recognizes a program’s main purpose as a distinct level of abstraction. Another conflict with existing case law arises from the ordinary observer standard some courts apply in assessing substantial similarity;211 expert testimony will be required under this Note’s approach because ordinary observers are unfamiliar with ADTs, algorithms, and other abstraction parts. However, <Page 569> although some courts still limit the use of expert testimony,212 other courts, recognizing the need for expert guidance, have appointed their own experts213 or moved away from lay standards of comparison.214
The benefits of adopting the proposed framework of abstraction part definitions substantially outweigh the costs. Although the framework impugns aspects of existing case law, it provides a useful yardstick for comparing substantial similarity tests. The framework also facilitates the separation of policy arguments over the proper scope of protection from definitional questions about program parts. Policy questions cannot be properly resolved without a stable definitional foundation, because the question of precisely what is or is not protected remains unclear in the absence of reliable definitions. The framework may also narrow disagreement over where the idea-expression line should be drawn. At the very least, adopting the proposed framework will discourage further confusing case-by-case definitions of new parts and so remove one of the most frustrating obstacles to a coherent law of software copyright infringement.
Conclusion
The need for definitions that promote coherent evolution of software copyright infringement law is evident in the inharmonious, incomplete and inaccurate part definitions spawned by existing tests for substantial similarity. The four major tests for substantial similarity each use different terminology; none adequately separates policy questions from part definitions. Flawed definitions promote further confusion and proliferation of poorly defined abstraction parts as courts attempt – thus far unsuccessfully – to create part definitions that are both coherent and correct. Indeed, it often seems that courts and commentators blur the issue of defining program parts with the separate policy questions of protecting certain parts.
Some of the resulting chaos is undoubtedly due to the relative youth of software copyright law. Courts have confronted software <Page 570> copyright infringement cases for only fifteen or twenty years; most such cases arose in the 1980s. Compared to books, plays, or movies, software is a newcomer to copyright law. Because software relies on rapidly evolving technology and addresses unique problems, software is also more complex in some ways than these other works. Finally, software is much less familiar to jurists, particularly in its internal manifestations such as data structures and ADTs.
This Note has attempted to pull back from the confusion surrounding substantial similarity to find some common ground upon which courts may agree. Software substantial similarity analysis must be founded on the inherent structures of computer programs. Moreover, any set of abstraction part definitions should divide the entire range of abstraction into a manageable set of stable, distinct parts that recognizes the useful contributions of earlier case law. This Note has proposed six levels of abstraction for computer programs: (1) main purpose; (2) system architecture; (3) abstract data types; (4) algorithms and data structures; (5) source code; and (6) object code. The proposed abstraction part definitions provide a yardstick for comparing the substantial similarity tests by cleanly and manageably dividing a computer program into discrete abstraction parts. Adopting the definitions should help reduce disagreement over placement of the line between idea and expression, discourage further bewildering proliferation of new part definitions, and promote the orderly development of promising copyright doctrines such as the successive filtering test. Other definitions may be preferable, but unless sui generis protection for computer programs is forthcoming, some judicial agreement on program parts must be reached. Without such agreement, courts will never succeed in fashioning a coherent, correct, and broadly applicable test for software substantial similarity, and the conflict will simply grow worse.