Why you need to perform open source due diligence in an M&A transaction

Most companies involved with technology M&A understand the importance of open source risks in software. Today’s software contains significant amounts of open source, on average more than 50%, according to a 2018 Synopsys study. Consequently, it has become the norm for acquirers to raise open source questions as part of technical and legal due diligence.

How to perform open source due diligence

There are several ways to assess and manage open source risk in a transaction. Here are just a few:
 

Ask the target

Obviously, the simplest approach to determining what open source is in a target’s IP is to ask the target. But many targets have difficulty producing a full and accurate inventory (also known as a bill of materials, or BoM) of open source in their code. So relying on the target’s knowledge for open source due diligence can be problematic. See “Reps and warranties.”
 

Rely on reps and warranties

Reps and warranties are the assertions that buyers and sellers make in a purchase and sale agreement. Both parties rely on each other to provide a true account of all information. From an open source due diligence perspective, the seller represents that they’re in compliance with all open source licenses and known security risks. However, beware of knowledge qualifiers—that is, where the seller limits the reach of reps and warranties to what the relevant party “knows.” Few companies manage their developers’ use of open source effectively. Consequently, most codebases contain unknown open source components that may carry license or security risks.
 

Employ a third party for an open source code audit

The only way to be sure of what’s in the code is to analyze it. But few targets are willing to grant extensive code access to potential acquirers. In any case, acquirers will question the accuracy of results produced by a target. Given those reasons, acquirers often involve independent third parties, such as Black Duck Audit Services, to do a code analysis focused on open source.

How a Black Duck Open Source Code Audit works

Black Duck works with the code owner, often a third party in an M&A transaction, to get a high-level view of the composition and complexity of the codebase and its architecture. In great part, the scope of work is driven by the number of files and the prevalence of open source components in the technologies used. For example, JavaScript tends to be full of open source files, whereas a typical C++ codebase contains much less open source.

Black Duck tools employ a variety of techniques to ferret out unknown open source. In many cases, the tools definitively identify open source components. But sometimes, owing to limited information in the code, they just provide clues for expert auditors to chase down.

The result of this identification process is a comprehensive bill of materials (BoM), essentially a list of the open source components in the codebase. The BoM is the foundation for identifying open source risks. Open source due diligence must surface all open source–related risks in a codebase. And only by knowing what’s in the code can you know the associated risks.