Table of Contents:

- Applying The AFC Test

- Other Issues

- New Software from Old

- Summary

Digital Copyright

Patent Overview

Software Patents

Full treatise table of contents

Home Copyright/Other Information Send Comments

Chapter 2: Copyright of Computer Programs

IV. Applying The AFC Test

While it seems simple to describe the abstraction-filtration-comparison analysis, the devil is in the details. The abstraction can result in the comparing of hundreds or thousands of different aspects of a computer program if one is not careful. Elements are filtered out of consideration on the basis of broad criteria, including:

· The element’s expression was dictated by reasons of efficiency, such as when it is the best way of performing a particular function.

· The element’s expression was dictated by external factors, such as using an existing file format or interoperating with another program.

· The element’s expression is a conventional way of writing something in the particular programming language or machine running the program.

· The element, at the particular level of abstraction, is an unprotectable process and not protectable expression.

· The element is taken from the public domain or is an unprotectable fact.

Any protection for elements dictated by efficiency or external factors or processes must come from patents or trade secrets, if at all, and not from copyright.

For most alleged copyright infringements, this filtering makes little difference. It is important to recognize that, with today’s large, complex programs, most copyright infringement consists of the verbatim copying or unauthorized distribution of a computer program, and no question over whether any similarities are protected expression or unprotected function need be considered.

But sometimes a program is based on another program, or takes features from another program, and at those times the abstraction-filtration-comparison test must be used to determine whether too much was taken and a copying of the non-literal elements has resulted in a copyright infringement.

IV.A. A Suggested Approach

The application of the abstraction-filtration-comparison test is complicated because the test is not described in language that is familiar to the computer scientists who would be the technical experts helping the court.

Five computer scientists (including the author of this text and the court-appointed expert in Computer Associates v. Altai {FN77: 982 F.2d 693, 23 USPQ2d 1241 (2d Cir. 1992)} )discussed the complexity inherent in abstraction-filtration-comparison (AFC) test in a friend of the court brief {FN78: Amicus Brief of Computer Scientists, Harbor Software v. Applied Systems, No. 97-7197 (2d Cir. 1998)} to the Second Circuit in a case that settled before that court made its decision. In one portion, we suggested how the AFC test should be performed, first discussing what can be done to refine the magnitude of the task:

1. Qualified Technical Experts Should Play an Important Role in the Abstraction Process.

Given the difficulty and complexity of creating a technically accurate set of abstractions, this Court should clarify that this is properly a task for a qualified expert in the field. As U.S. Court of Appeals Judge John Walker, author of the Altai decision, has noted, “Most juries, and most judges (myself included), are less than completely comfortable with the concepts and terminology of computer programs and need extensive education in order to make intelligent decisions.”

2. Refining the Task Will Reduce Technical Complexity.

In the interests of efficiency and manageability, the abstraction process should be carried out on a well-focused body of software. If the program is small, it may be practical to abstract the entire thing. When possible, this is advantageous because the abstraction and filtration processes can be carried out on the plaintiff’s code prior to discovery of the defendant’s code, yielding a clear picture, early in the process, of the exact contours of the protectable expression in the plaintiff’s program.

Given the large size of most commercial programs, however, the effort involved in abstracting and filtering the entire program is enormous and would yield a daunting number of exhibits. The court would likely be overwhelmed with paper and with the filtration effort of determining protectability for every element of the plaintiff’s program, even if only a small part of that program is at issue in the claim of infringement. Thus, the obvious subset of code for analysis is that portion of the software that the plaintiff alleges the defendant copied.

3. The Plaintiff Must have Access to the Defendant’s Code in Order to Focus the Inquiry.

In many instances, the initial evidence of copying is a relatively insignificant incident that turns out to be only the tip of the iceberg. For example, one case that eventually involved claims of extensive code theft (both literal and non-literal) as well as a variety of other serious charges began when a software developer noticed that a competing program built by former employees of his company displayed the same misbehavior that he knew to be present in his own code. As a piece of misbehavior, the behavior could not be motivated by the task, suggesting the possibility of copying. When this initial evidence of copying is sufficient to support a complaint, the plaintiff will need access to the defendant’s code in order to determine the full extent – if any – of the problem.

We recognize the difficulty this access to code presents: if the plaintiff is permitted to examine the defendant’s code before abstracting his own code, the plaintiff may “mine” the defendant’s code for potential foci of alleged copying, thereby distorting the inquiry. But we believe some form of difficulty is unavoidable. If plaintiff instead must perform the abstraction and filtration before seeing the defendant’s code, it may feel that the only way to protect the claim is to abstract the entire program, resulting in an impractical – and wasteful – amount of work for both the plaintiff and the court. If, in the interests of economy, the plaintiff abstracts only those parts of its code that it suspects at the outset were copied by the defendant, the plaintiff’s exhibits are likely to be incomplete and require augmentation after it has had the opportunity to examine the defendant’s code, in which case the possibility of “mining” reappears. In any event, we believe that manufactured claims of copying become evident at the filtration stage, where the court’s expert can raise such observations and the court can deal appropriately with them at that time. {FN79: Amicus Brief, at 8-9 (citations omitted)}

We then suggested how the AFC evaluation can be performed:

Having performed a thorough examination of the defendant’s code to evaluate the extent of copying, if any, the plaintiff’s technical expert can then prepare a well-focused set of exhibits describing the relevant portions of the plaintiff’s code at multiple levels of abstraction. This set of exhibits is the plaintiff’s initial contribution to the AFC process.

At this point, the defendant must have access to the plaintiff’s code in order to make an independent judgment as to whether the abstractions are accurate. This must include access to the plaintiff’s entire program, even though the abstractions may deal with only a small part of the program, in order to test for errors of omission.

The court will now have before it a set of exhibits describing a carefully selected portion of the plaintiff’s code, which the plaintiff claims is both protected and infringed. It is now in a position to evaluate the first of these claims independent of the second, and we suggest it do so, proceeding with the filtration test.

This approach has several significant advantages. If the exhibits contain no protectable material, the case is over. The defendant is spared unnecessary expense, yet the plaintiff has had a full opportunity to find copying in the defendant’s program. As a matter of practicality, this may be a significant virtue in a world where litigation may be used as an economic weapon, particularly against smaller companies, of which there are many in the software world.

An additional advantage arises from the reduced workload presented to the court: by focusing the filtration purely on the plaintiff’s exhibits, there is no need for the court to examine or display the defendant’s code at this point. Finally, if the plaintiff understands that infringement claims will be required to pass the filtration test relatively early in the litigation process, independent of any court consideration of the defendant’s code, the plaintiff may perform more careful analysis before filing infringement cases.

After the filtration is complete, the court should require the plaintiff to augment its exhibits with specific references to the defendant’s code, indicating the exact lines of the defendant’s code that it alleges are copied from the plaintiff’s software. (Even where the plaintiff alleges non-literal copying, the plaintiff should be able to cite specific lines of the defendant’s program that embody the non-literal element(s) allegedly copied.) Plaintiff’s specific allegations will further focus the court’s task and enable the defendant better to perform the next step, having the defendant’s expert prepare abstraction exhibits of the defendant’s code.

The inherent flexibility of the abstraction process, involving as it does many judgment calls, requires that the court permit each side to abstract its own code and to prepare its own abstraction exhibits embodying that analysis. The fact that the district court in the present case apparently permitted the plaintiff to prepare the abstraction exhibits for both parties, subject to defense objections, demonstrates once again a level of uncertainty as to the technical limitations of the AFC process.

The AFC process is not a magic wand that will eliminate disagreement; it is instead a framework within which the parties may carry out a discussion. As experts in the field, we anticipate that there will, in fact, be disagreement over the abstraction exhibits. Indeed, these arguments may hold the key to the remainder of the case. For this reason, the court should require the parties to offer technical grounds both in defense of their choices and when challenging the choices made by the opposing party. Even so, if the parties cannot reach agreement on the challenged exhibits, this Court should advise the district courts to consider seriously the appointment of a neutral expert of its own in order to assist in arriving at a consensus as to what constitutes an accurate, specific, and complete description of the code in question.

With these agreed-upon exhibits in place, the court is now ready to begin the comparison process. The trier of fact will now have before it a set of exhibits characterizing specific elements from plaintiff’s program that are subject to copyright protection, along with corresponding elements from the defendant’s program that the plaintiff alleges are infringing.

We suggest some form of early technical evaluation of the plaintiff’s initial copyright infringement claims; that is, the plaintiff should be required to establish at this early stage of litigation some minimal technical evidence of infringement in order to proceed with its claim. We believe that our approach is consistent with federal procedure for the evaluation of cases before trial, particularly in the form of motions for summary judgment.

We further suggest that this Court encourage trial courts to have the plaintiff meet this minimal burden through the independent evaluation of the plaintiff’s claim by a court-appointed expert or by support from disinterested third parties, concerning the technical substance of the initial evidence for infringement. Such a barrier, even if relatively modest, would set some threshold level of technical substance to deter the filing of cases for little more than economic reasons (i.e., to interrupt the business of a competitor). We believe that, given the extensive time, effort, and expense of fighting a lawsuit, this process is a worthwhile way of minimizing the undesirable economic costs of unnecessary litigation. {FN80: Amicus Brief, at 9-10 (citations omitted)}

Finally, we suggested some guidelines for the production of the abstractions:

1. Routine Abstractions Include Control Structure, Data Structure, Data Flow, Information Architecture and Textual Organization of the Code.

The program’s control structure is the sequence of operations that it carries out, often indicated with a well-established graphical language of boxes and arrows called a flowchart . . . Control is frequently the most complex aspect of a program; a complete set of control abstractions may have many levels of detail. The data structures indicate the way in which individual elements of information are stored in the program; in the earlier checkbook hypothetical, for example, data structures are used to store the sorts of information found in a check register (e.g., check number, date, payee, amount). The data flow is a description of how information flows through a program; that is, how the information for a check flows from the register where it is entered, to the check itself. The information architecture of a program indicates the overall organization of the data used by the program, often in the form of the organization of databases.

All of these abstractions concern the behavior of the program. Because programs can be viewed in terms of both their behavior and their text (treating the source code as a body of text), we can also describe the organization of the textual code itself at several levels of abstraction, ranging for example, from individual routines, to files containing multiple routines, to directories containing multiple files.

2. Abstractions Should be Specific and Precise.

As one indicator of such precision, there should be no ambiguity about what behavior is being described and what body of literal code is being abstracted. This enables evaluation of the accuracy and completeness of the abstractions. Courts should thus require: (a) that labels on abstraction exhibits clearly specify the program behavior at issue; and (b) that each component of an abstraction exhibit refer clearly either to more detailed exhibits or to literal code. . . .

3. Abstractions at Any Given Level Should Be Complete.

Such completeness will ensure that the exhibits present an entire and accurate picture of the program at any chosen level of detail. The abstraction effort can be focused on the code relevant to the case at hand by cutting off the abstraction process below a certain level for the irrelevant parts of the code.

4. Parties Should Adopt Explicit and Consistent Graphical Conventions for All Exhibits.

The adoption of consistent graphical conventions will permit the trier of fact to make sensible comparisons of the exhibits. . . . To a trained eye, some of the graphical organization of the abstraction exhibits is informative, while other elements are accidental (e.g., the left-to-right order of certain of the boxes). If the parties cannot agree on a set of conventions, the court’s expert should assist the parties and the court in reaching a uniform set of standards for the exhibits. {FN81: Amicus Brief, at 12-13}

IV.B. A Judge’s Comments on the Suggested Approach

In a subsequent law review article, {FN82: Jon O. Newman, New Lyrics For An Old Melody: The Idea/Expression Dichotomy In The Computer Age, 17 Cardozo Arts & Ent L.J. 691 (1999)} one of the judges on the panel that received the amicus brief commented on it favorably and then suggested that we should move away from the general language of copyright law and describe things in terms more appropriate to the subject being considered:

In the area of computer programs, I think we might be better off to recognize that, although we need to separate protectable “expression” from unprotectable “ideas,” a somewhat different vocabulary might assist us in properly balancing the ultimate values we seek to advance. Thus, I do not consider it helpful, in considering the protection accorded source code, to ask whether it is the written expression of an idea embodied at some higher level of abstraction within the computer program. I would rather begin the process of labeling the protectable and unprotectable elements of computer programs with terms peculiar to the realm of software. For example, I might move away from referring to source code as the “expression” of an “idea,” a phrasing that all too readily enlists the doctrines and case law developed in cases involving written texts, and instead call these arcane writings what they are called in cyberspace – namely, source code. Then, I could consider which source codes or which portions of source codes were protectable. Also, I might not call the unprotectable aspects of a computer program “ideas,” which again evokes the written text cases, but instead call them something like “program purposes” or “program objectives.” After all, you don’t see many cases involving copyrights in musical works talking about the “expression” of some musical “idea.” Why should we force upon copyright cases involving computer programs the same vocabulary we use for cases involving written texts? . . .

By using terms appropriate to the subject matter, I might begin to realize that what is relevant in applying the idea-expression dichotomy to computer programs is not necessarily the same as what is relevant in other areas. Judge Hand observed that with plays, characters and the sequence of incidents were especially important. Well, there are no characters in software, at least not literary characters. There are, I suppose, what might be called “incidents,” but we ought not blithely equate the sequence of incidents that combine to form the plot of a play with the sequence of steps that the computer program instructs the computer to perform on data. {FN83: Newman, at 699-700}

He then indicates what he needs from expert witnesses in a trial or in the briefs on appeal:

These professionals would be well advised not to tell me simply that the source code is or is not protectable expression. Their opinions are relevant, but, as with all opinions, what renders them persuasive is not the vehemence of their assertion and not even the credentials of those asserting them; it is the cogency and persuasive force of the reasons they give for their respective positions. These reasons had better relate to the specifics of the computer software field. For example, as Altai indicates, even with its overly structured mode of analysis, it will be very important for me to know whether the essential function being performed by the copyrighted program is a function that can be accomplished with a wide variety of source codes, which will strengthen the case for protection, or, on the other hand, is a function capable of execution with very few variations in source code, or variations of such triviality as to be disregarded, in which event protection will be unlikely. For me, this mode of analysis is essentially what in other contexts we call the merger doctrine – the expression is said to have merged with the idea because the idea can be expressed in such limited ways that protection of the plaintiff’s expression unduly risks protecting the idea itself. {FN84: Newman, at 702}

Next section: Reverse Engineering