By Michael Barr
The easy software copyright case is the one where the files match. Somebody took the source, changed the header comment, and shipped it. An expert can put the two listings side by side and the argument is essentially over.
Those cases exist and they settle. The cases that reach an expert report are the other kind: where the second program does what the first program did, in a way that feels unmistakably derived, and yet almost no two lines are identical. That is non-literal infringement, and proving it is one of the more demanding things a software expert is asked to do, because the analysis has to separate what copyright protects from everything that merely looks similar for engineering reasons.
Literal and non-literal copying are different investigations
Literal copying is copying of the code itself: whole files, functions, blocks, sometimes with variable names changed or formatting altered. It is detectable with tooling and, once found, hard to explain away.
Non-literal copying concerns the elements above the text: the structure and organization of the program, the way the problem was decomposed into modules, the data structures chosen, the interfaces between components, the sequence and flow of operations. Picture a pump controller rebuilt from memory by an engineer who left the original's maker: new variable names, a new file layout, a different coding style, and yet the same seven-state alarm state machine, the same message frame with its fields in the same order, and the same retry sequence after a sensor fault. All of that can carry over without a single line in common.
The distinction matters procedurally, because a defendant who can truthfully say that no line matches will say so early and loudly, and it is not responsive to the allegation. It is important that the technical framing of the case makes clear from the outset which kind of copying is alleged.
Filtration is most of the work
The commonly applied framework for these disputes separates a program into levels of abstraction, filters out the elements that are not protectable, and compares what remains. The filtration step is where the real technical labor sits, and it is where an unprepared expert loses.
What has to come out includes, broadly: ideas and general methods, as opposed to their particular expression; elements dictated by efficiency, where any competent engineer solving the problem would arrive at substantially the same structure; elements dictated by external factors, such as the hardware, the operating system, an interoperability requirement or a published standard; elements that are standard in the field, the programming equivalent of stock scenes; and material that is in the public domain or licensed from elsewhere.
That last category has grown enormously and deserves specific attention. A modern application is substantially assembled from open-source components, framework scaffolding and generated code. Two programs can share a great deal of identical text simply because both incorporate the same libraries, were produced by the same code generator, or follow the same framework's conventions. An expert who reports similarity without first removing everything of that character has produced a number that means nothing, and the defense will demonstrate that in short order.
Filtration is unglamorous, and it consumes the majority of the hours in a well-run analysis. It is also what makes the comparison that follows worth anything.
The law is moving in the same direction. Most federal appeals courts already require unprotectable material to be filtered out before two works are compared. The Ninth Circuit, which hears appeals from the California courts where much software litigation is filed, has long combined an objective comparison with a jury's subjective impression of the works' "total concept and feel." In September 2026 the full court reheard a copyright appeal in which it was asked to drop that subjective step in favor of a single test that filters first, and several of its judges had already criticized the existing approach in writing. Armond Wilson LLP's summary of the rehearing lays out what is at stake. Whatever the court decides, the trend favors the party whose expert can show exactly what was filtered out and why.
What actually evidences copying
Once the filtration is honest, the persuasive evidence in non-literal cases tends to be of a particular character: similarities that engineering necessity does not explain.
Arbitrary choices that coincide. Where a design decision could have gone many ways with no functional difference, and both programs made the same unusual choice, that carries weight. Field ordering in a structure, an idiosyncratic decomposition into modules, an unconventional algorithm where a standard one would have served.
Shared imperfections. This is the strongest category and the reason experienced experts look for it first. Common bugs, particularly subtle ones. Dead code that serves no purpose in either program. Comments describing behavior that neither program exhibits. Vestigial handling of a case that only mattered in the original's environment. Independent developers do not reproduce each other's mistakes.
Fossils of the original. Names, constants, magic numbers or file layouts that make sense only in reference to the first program. A constant whose value is meaningful only for the original's hardware, carried into software that runs on something else, is difficult to explain innocently: a 37-millisecond debounce delay tuned for the original's switch, say, turning up in a product that has no such switch.
Structural correspondence at the right altitude. Not "both have a database layer," which every program has, but a correspondence in decomposition that is specific enough that the second could be described as a translation of the first.
The reason shared imperfections matter so much is that they invert the defense. Similar correct code invites the explanation that both authors solved the problem well. Similar incorrect code does not have an innocent explanation of the same quality.
The defenses, and how they are tested
Independent creation. The defense is that the second program was written without reference to the first. It is tested against the development record: version history, ticket systems, design documents, and whether the observed development trajectory looks like people discovering a design or people implementing one they already understood. A codebase that appears in nearly final form with little iteration invites questions.
Clean room. A deliberately structured process in which one team documents the behavior of the original and a second, isolated team implements from that specification alone. Where genuinely executed and documented, it is a strong defense. Where it exists only as an assertion, the absence of contemporaneous records is itself informative, and the boundary between the teams is where an expert should concentrate.
Access. Copying requires access, and the technical record often speaks to it: repository logs, downloads, prior employment, and what the defendant's own systems show about what was obtained and when. Where the alleged route runs through departing employees, the analysis overlaps substantially with trade secret misappropriation, and the same forensic record frequently serves both theories.
Reverse engineering. A defendant may contend it studied the original's observable behavior rather than its internals. Whether that is consistent with what the second program actually contains is a technical question, and it interacts with the separate question of whether the reverse engineering itself was lawful and adequately documented.
Tools help and do not decide
Similarity detection tools have their place, particularly for finding literal matches quickly across a large corpus. Their limitations need stating plainly in any report that relies on them.
They generally measure textual or token-level similarity, which is close to orthogonal to the non-literal question. They do not filter for protectability, so their raw percentages include library code, generated code and standard idioms. And a percentage figure has a dangerous rhetorical quality in front of a jury: it sounds like a measurement of infringement, and it is not.
A defensible report uses tooling to locate candidate material and then relies on human analysis for the filtration and the comparison, and it says exactly that.
Choosing the expert
The qualification that matters is depth in the specific languages and platforms of both programs, and enough breadth to recognize what is standard practice in that ecosystem, because recognizing the standard is what makes filtration possible. Someone who does not know a framework's conventions cannot filter them out.
Worth asking directly: have you performed an abstraction and filtration analysis before, and can you describe how you documented it. How do you handle open-source and generated code in the comparison set. What tooling do you use and what do you consider its limits. How would you look for shared defects rather than shared correctness. The broader framework for interrogating a review team, including who testifies and who does the actual reading, is in our guide to vetting a source code review team.
What we do at Barr Group
Our electronics and software expert witnesses are matched to the languages and platforms of both codebases, because a filtration analysis performed by someone unfamiliar with the ecosystem's conventions is not worth much. We treat filtration as the main event rather than a preliminary, we document what was removed and why, and we use similarity tooling to find candidates rather than to generate headline percentages. We look for shared defects early, since they are the findings that survive. Our work in software copyright matters is described further in our expert witness case studies, and it carries through to expert reports and testimony.
The takeaway
Non-literal software copyright cases are won in the filtration, not the comparison. Establish early which kind of copying is alleged, so a defendant's true statement that no lines match does not become the frame. Remove everything that similarity does not prove, open source, generated code, standard idioms, anything dictated by efficiency or by an external constraint, and document the removal. Then look hardest at the similarities that competence cannot explain, above all the shared mistakes. And keep similarity percentages out of the conclusion, because a number that includes unprotectable material measures nothing anybody is arguing about.
Note: This article offers practical guidance for attorneys engaging technical experts. It is general commentary, not legal advice. Copyright doctrine and its application vary by jurisdiction and by the facts. Consult your own counsel about any specific matter.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
Get a matched recommendation >
Free, confidential, conflicts-checked, and our fee is built into the expert's hourly rate, so we are paid only if you retain.