Today’s software contains more than 50% open source. Companies involved in technology M&A need to know why and how to perform open source due diligence.
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.
There are several ways to assess and manage open source risk in a transaction. Here are just a few:
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.”
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.
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.
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.