Applying the AFC Test: When to Apply the AFC test

October 16, 2017 - from DisputeSoft's Josh Siegel and T.J. Wolf

We noted in our first blog in this series that when evidence of literal copying is non-existent, inconclusive, or particularly weak, and defendants had access to a protected work, experts can search for evidence of non-literal copying. But in what kinds of matters is it appropriate for an expert to employ the AFC test? The AFC test applies to intellectual property suits as follows:

-Copyright (YES): The AFC test was expressly adopted for copyright matters in which one party contends that non-literal copying of computer software has occurred. An expert abstracts source code to the appropriate level, filters out non-protectable expression, and compares the remaining expressive elements of the filtered programs for substantial similarity.

-Trade Secret (MAYBE): When an allegedly misappropriated trade secret involves computer software, an expert can follow abstraction-filtration-comparison methodology similarly to the way he/she would in a copyright matter. The abstraction step remains the same, but filtration removes elements not protectable as trade secrets, such as open source code. After filtration, an expert can then compare the parts of the program remaining against the allegedly misappropriated trade secrets/

-Patent (NO): The AFC test is not applicable to patent litigation. Patent protections deal closely with explicit functionality, not with expression. The process of abstraction is not appropriate when reviewing patents, as any level of abstraction removes the specificity required for patent claim and/or specification comparison and analysis.

The AFC test, as variously promulgated by several District Courts, is an accepted method for determining whether indirect or non-literal copying has occurred in intellectual property matters involving copyrights and trade secrets, but it is not used for matters concerned with patents. Check back next month for the next installment in our “Applying the AFC Test” series: “Why use the AFC test?” To learn more about the services we provide as Copyright Infringement Experts, please don’t hesitate to contact us at inquiries@disputesoft.com.

Applying the AFC Test: What is the AFC Test?

September 18, 2017 - from DisputeSoft's Josh Siegel & T.J. Wolf

Software development is a competitive business, and disputes over intellectual property can arise when software engineers move to new companies that compete with their former employers. Should a dispute result in litigation, expert witnesses may be employed to determine whether and to what extent a party copied proprietary source code.

Experts encounter two kinds of copying: literal copying and non-literal copying. To prove copying occurred, a plaintiff must demonstrate that an alleged infringer had access to the copyrighted material and that the allegedly infringing work is substantially similar to the protected work. Experts are primarily employed to find evidence that supports or refutes allegations of substantial similarity.

In most cases of this sort, an expert first examines code for evidence of literal copying. Experts use a variety of software analysis tools to determine whether portions of code from program A were copied directly into program B. Such tools allow experts to review and compare source code files to determine whether the same text appears in both programs and the extent to which the programs overlap.

When evidence of literal copying is non-existent, inconclusive, or particularly weak, experts can search for evidence of non-literal copying. To find evidence of non-literal copying, an expert must determine whether protectable non-literal elements of a computer program, such as its “look-and-feel” or “structure, sequence, and organization” have been copied from one program into another. The Abstraction-Filtration-Comparison (“AFC”) test is a methodology promulgated by several U.S. district courts that allows an expert to analyze and compare the protectable elements of code of two programs.

The U.S. Circuits conceptualize and prescribe slightly different approaches for conducting an AFC test by placing emphasis on different “levels of abstraction.” For example, the Ninth Circuit focuses on the software’s structure, sequence, and organization, as well as user interfaces as the appropriate levels at which the abstraction analysis takes place, whereas the Second Circuit emphasizes parameter lists and services required. However, the test always has three steps.

– Abstraction incrementally pulls back from source code to compare the “structure, sequence, and organization” or the “look-and-feel” of two programs at different levels of generality/specificity. By analogy, this is similar to zooming out from a detailed map. If we think of source code as specific houses on a street, Abstraction involves zooming out to view the street’s location in a neighborhood, the neighborhood’s location within a city, the city’s location within a state, and so on. The appropriate level of “zoom” varies from case to case, and there is no one-size-fits-all. Two programs may appear completely different from each other when viewed at street level or city level, and an expert may need to examine the programs at the state level to view them in the way that they are most appropriately comparable to each other.

– Filtration removes any non-protectable elements of code before they are compared to allegedly infringing code. Non-protectable elements of code may be auto-generated, open source, or otherwise unoriginal or non-protectable. Since such code does not receive copyright protection, finding similarities between two programs’ non-protectable elements would not be useful or appropriate. Once the non-protectable elements of the programs are filtered out, all that remains are the protectable parts of each program as viewed at the appropriate level of abstraction, ready for comparison to each other.

– Comparison compares the two programs at the appropriate level of abstraction, with all non-protectable elements filtered out. During the Comparison stage, an expert comes to an opinion regarding substantial similarity between the two programs, and thus, whether copying of non-literal elements has occurred.

While the appropriate abstraction level varies from case to case and circuit to circuit, AFC methodology is repeatable. The value of the AFC test lies in its ability to uncover copying of non-literal elements of a computer program, which is useful in situations where copying is not obvious solely from a review of source code.

The AFC test is clearly applicable to copyright infringement matters involving allegations of non-literal copying; but could it be used to contemplate other intellectual property claims as well? To learn more about the kinds of intellectual property matters for which the AFC test can be used, check back next month for the next installment in our “Applying the AFC Test” series: “When to Apply the AFC Test.” To learn more about the services we provide as Copyright Infringement Experts, please don’t hesitate to contact us at inquiries@disputesoft.com.

Source Code Repositories: Authenticating Production of Source Code

August 15, 2017 - from DisputeSoft's Josh Siegel

The reliable record of changes maintained by source code repositories makes them among best evidence an expert can be provided for the purpose of authenticating source code production. A source code repository tracks the development of a program by maintaining native source code files that can be examined as they existed throughout the history of the program’s development. Each change made to a source code file can be recorded by the repository, and it is difficult to alter the data within a repository without leaving traces of the alteration. For example, source code repositories often tie a unique, sequential ID number to each update of code. A gap in the sequence of code updates may indicate that the repository has been altered. Similarly, if a program was purportedly developed over the course of several years, but all of the code contained in a produced repository was added to the repository on the same day, the produced repository is probably not the repository used during the development of the software.

When an expert lacks access to a source code repository, he or she can still potentially authenticate produced source code if provided with individual files in native format. Although files produced outside of a repository are more easily altered, files in native format still contain metadata that may allow an expert to authenticate evidence. Metadata is data about data, and experts review metadata that records such information as the date of creation and last date of modification for computer files produced as evidence. For example, if all three of the following conditions were true, they would be strong indicators that produced code is authentic:

The party producing the code states that the year of completion for a version of code is 2005.
The produced code contains only files with last modified dates prior to 2005.
There are no obvious omissions from the produced code.
However, even where code is produced in native format as in the example above, individual source code files may be drawn from several different versions of a program. Access to a source code repository allows an expert to verify whether produced code constitutes a true and accurate copy of a version of a program as it existed at a certain time, or if the produced code was reconstructed from several different versions. Additionally, source code in native format but produced outside of a repository can omit files containing evidence of copying. Access to the repository allows an expert to evaluate the completeness of a production of source code.

Because converting a file out of its native format may alter or delete data that might have been used to authenticate the file, source code produced in a non-native file format is the most difficult to verify. Unless provided with more information, an expert may be unable to authenticate code produced in static formats such as paper printouts or text images (e.g., PDFs). For example, when filing a copyright, only the first 25 and last 25 pages of a program must be submitted to the copyright office. When this “deposit copy” of a program contains the program in its entirety, an expert can compare it to produced code for the purposes of authenticating the produced code. However, this method is limited to small programs and cannot rule out the possibilities that the copyright filing itself contains errors or that the documentation submitted to the copyright office is a reconstruction.

For all of these reasons, the source code repository is instrumental for verifying the completeness, authenticity, and validity of a source code production.