As a former open source expert, who worked as a consultant for major financial corporations and telcos, I’m probably one of the (very) few lawyers knowing what a “git commit” is (and actually using it on a regular basis!)
As a transactional attorney, I noticed that, even in the most stringent M&A deals, due diligence with regards to open source software components is too often either disregarded (most likely by a lack of understanding of the risks at stake), or at least downplayed and not given the right amount of priority.
The risks posed by some open source components embedded in a proprietary software part of a transaction can be far-reaching and extremely costly. Typically, the impact of a so-called “copyleft” license (or, sometimes, fine-prints in a less common open source license) on a product developed by the target of a deal can dramatically change the outcome!
How many times have I heard of clients realizing only a few hours before closing that they didn’t cover that risk, or even sometimes after closing?
Rarely do we find readily available lists of open source components embedded in a company’s products and environments. Although it is increasingly common to provide so-called “Software Bills of Material” (SBOMs) in public (and sometimes even private) procurement, that document (or its equivalent) is rarely included in the original set of documents provided in data rooms. The requirement for SBOMs has become a de facto standard in great part due to the requirements set out in Executive Order 14028 (May 2021), and more and more vendors develop tools that can automatically (and without disruption) parse source code and dynamically compile SBOMs.
Most recently, GitHub started offering a new feature, dynamically compiling SBOMs directly from a repository, based on the dependencies of the project.
If such features could make it more common to include SBOMs or similarly useful documentation about open source software components at the time of performing due diligence, rebuilding the full line of ancestors of a software product would be far easier… and that could save transactional attorneys (and their clients) some licensing nightmares!
If you ever have any open source licensing-related issues or need advice on your next due diligence process for open source software, contact us or schedule your first free appointment!