Trade Secret Misappropriation in Software: What the Code Can Prove

---

By Michael Barr

Note: All information about specific litigation discussed in this article is drawn exclusively from publicly available court opinions, SEC filings, and published news reports.

When two software companies collaborate on a joint venture, they inevitably share confidential technical information. What happens when that collaboration ends and one party's proprietary techniques turn up in the other's products? That is the central question in trade secret misappropriation cases involving software, and the answer increasingly depends on what a forensic analysis of the source code can prove.

A $480 Million Lesson: Teradata v. SAP

A recent high-profile case illustrates how trade secret disputes over software can unfold, and how high the stakes can be.

In 2008, Teradata and SAP launched the "Bridge Project," a joint venture to integrate SAP's front-end enterprise applications with Teradata's back-end database architecture. The companies signed both a software development cooperation agreement and a mutual non-disclosure agreement to protect their respective intellectual property during the collaboration.¹

During the project, Teradata's engineers encountered technical difficulties and proposed incorporating Teradata's proprietary "batched merge" method, a technique for efficient aggregation of large batches of data that was central to the Teradata Database's competitive advantage. A Teradata engineer sent SAP a design document marked "Teradata Confidential" on every page that described the method.¹

Teradata alleged that SAP subsequently used the batched merge technique in its own HANA database platform without authorization. What began as a collaborative engineering partnership became a federal lawsuit spanning nearly eight years.

In December 2024, the Ninth Circuit Court of Appeals reversed a lower court's summary judgment in SAP's favor, finding that Teradata had created triable disputes over whether it properly designated the batched merge method as confidential and whether SAP's agreements gave it a license to use the method.¹ Just weeks before trial was set to begin in early 2026, the parties reached a settlement: SAP agreed to pay Teradata $480 million to resolve the litigation, which by then combined the trade secret claims with related antitrust claims.² Because the case settled, no court ever ruled that SAP had in fact misappropriated the method. That is worth underscoring: even a very large recovery can arrive as a negotiated settlement rather than a liability verdict, and the size of this one reflects the combined stakes of the whole dispute, not a trade secret damages award alone.

What Makes Software Trade Secrets Different

Trade secret law occupies a unique space in intellectual property protection. Unlike patents, which protect innovative ideas, or copyrights, which protect creative expression, trade secrets can protect the entirety of secrets within source code, provided the owner has taken reasonable steps to keep them secret.

For software, trade secrets can include:

• Algorithms and methods: Proprietary techniques for processing, sorting, or analyzing data
• Architectural decisions: How software components are organized and interact, including database schemas, API designs, and system architectures
• Optimization techniques: Performance-critical code paths, caching strategies, or memory management approaches that give a product its competitive edge
• Configuration and tuning parameters: The specific values and settings that make a system perform well under real-world conditions

The breadth of what qualifies as a trade secret is a double-edged sword. Almost anything in source code can be a trade secret, but only if the owner can demonstrate both that the information has independent economic value from not being generally known and that reasonable efforts were made to maintain its secrecy.

How Forensic Source Code Analysis Detects Misappropriation

When trade secret theft is suspected, software expert witnesses employ a range of forensic techniques to determine whether misappropriation occurred. Unlike copyright analysis, where the question is whether code looks similar, trade secret analysis often requires experts to determine whether the same underlying ideas and methods were taken, even if the code itself looks different on the surface.

Structural and Algorithmic Comparison

Expert witnesses begin by comparing the high-level architecture and algorithmic approaches of the two software systems. Even when variable names, function signatures, and programming languages differ, the structural "fingerprint" of a proprietary algorithm can be detected. Experts look for telltale patterns: the same sequence of operations, the same data flow, the same edge-case handling.

Development Timeline Analysis

Version control repositories and file metadata tell a story. Experts examine when specific code was written and by whom, looking for suspicious correlations. If a competitor's implementation of a technique appears shortly after a collaboration ended or an employee departed, the timeline itself becomes evidence. Build logs, commit histories, and code review records can establish a chronological narrative that supports or undermines claims of independent development.

Access and Opportunity

A critical element in trade secret cases is establishing that the accused party had access to the confidential information. This is where the digital paper trail becomes essential. Forensic analysts examine email archives, shared repositories, file access logs, document management systems, and collaboration tools. In the Teradata case, the court record shows that a document marked "Teradata Confidential" was sent to SAP engineers during the Bridge Project, establishing access.¹ But even without such a clear paper trail, metadata in shared files, server access logs, and version control commit records can establish who had access to what and when.

Reverse Engineering vs. Independent Development

A common defense in trade secret cases is that the accused party independently developed the disputed technology or reverse-engineered it from publicly available information. Software experts evaluate this defense by examining:

• Prior art and public disclosures: Was the technique described in academic papers, conference presentations, or open-source projects before the alleged misappropriation?
• Development artifacts: Does the accused party's version control history show a genuine, iterative development process, or does the code appear fully formed without the typical trial-and-error of independent creation?
• Technical sophistication: How likely is it that the accused party's engineering team could have independently arrived at the same technique given their background and the state of the art?

Lessons for Attorneys Handling Software Trade Secret Cases

Recent software trade secret litigation, including cases such as Teradata v. SAP, offers several practical takeaways for attorneys:

1. Confidentiality markings matter enormously. The Ninth Circuit's published opinion in Teradata focused heavily on whether the design document was properly marked as confidential under the parties' agreements.¹ Ensure that all confidential technical information shared during collaborations is clearly and consistently labeled.

2. NDAs need specificity. Generic non-disclosure agreements may not be sufficient. The agreements should clearly define what constitutes confidential information, how it must be marked, and what uses are permitted. Courts scrutinize whether agreements gave the receiving party an implied license to use shared technology.

3. Get expert analysis early. Software forensic analysis is most effective when it begins early in litigation. Source code, build environments, version control repositories, and development artifacts should be requested in discovery as soon as practicable. Evidence degrades: repositories get pruned, servers get decommissioned, and employees leave.

4. Understand that code comparison alone is not enough. Unlike copyright cases, where side-by-side code similarity is often the primary evidence, trade secret cases require experts to trace the flow of ideas, not just code. An expert who can explain a proprietary algorithm to a jury and then demonstrate its presence in a competitor's product, even when the implementation looks different on the surface, is invaluable.

5. The stakes justify the investment. The $480 million settlement in Teradata v. SAP² is not an anomaly. In 2018, Waymo and Uber settled a trade secret dispute over self-driving car technology for approximately $245 million.³ In 2020, Motorola Solutions won a $764 million jury verdict against Hytera for misappropriating radio technology trade secrets.⁴ Software trade secret cases routinely involve damages in the hundreds of millions of dollars, reflecting the enormous economic value that proprietary software techniques represent.

Conclusion

Software trade secret misappropriation cases sit at the intersection of law and engineering. The evidence is in the code, but extracting it requires experts who understand both the technical subtleties of software development and the legal standards for proving misappropriation. As software becomes increasingly central to competitive advantage across every industry, these cases will only grow in frequency and significance.

---

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

---

Sources