Modern software is a mix of proprietary code, off-the-shelf commercial code, and open source code. Open source often includes many dependencies.
The Linux Foundation describes direct and indirect dependencies in the following way:
- A direct dependency is a package that you included in your own directory.
- An indirect dependency is a package that you are not using directly, but one that is used by one of your direct dependencies.
Mergers and acquisitions (M&As) often have extremely tight timelines, so it may seem that performing due diligence only on a seller’s source code/proprietary code is sufficient to identify all the compliance and security risks. But buyers should also be concerned about the components upon which the seller’s application depends. If components under copyleft licenses are nested in the application’s direct and indirect dependencies, the buyer is taking on the responsibility to comply with those copyleft licenses as part of the whole work. Similarly, security vulnerabilities in dependencies may expose the entire application.
If an open source project is licensed under a permissive license such as MIT, a common belief is that there is no need for concern. However, in the audits we perform for M&A due diligence, we frequently find copyleft-licensed components within permissively licensed open source projects. This might not represent a compliance risk if the open source project is not being used for commercial purposes. However, when our customers are acquiring assets as part of an M&A transaction, they are almost always interested in using these assets for commercial purposes, and that is where the compliance risk resides.