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.