About a year ago Forbes published a very comprehensive, nicely organized check list of Business/Legal items that typically come up in M&A due diligence. A few things struck me about the article:
- It is a big list — it reminded me of pulling all-nighters in the midst of a transaction
- It explicitly drew attention to open source — good going, Forbes!
- It was written not as a “how to” for acquirers, but as a “heads up” for sellers
What impressed me most about the list was that it specifically zeroed in on open source:
Has the company historically incorporated open source software into its products, and if so does the company have any open source software issues?
At the same time, the question struck me as a little naïve. Perhaps, because I know the answers: Yes and Yes.
Black Duck has performed thousands of software audits in which we scan code bases to identify the open source code they contain and the “issues.” In virtually 100 percent of audits, we find open source. It’s not surprising. It simply reflects the way software is built these days. There are lots of benefits to using open source components as building blocks. It speeds development time, lowers costs and, most importantly, maximizes innovation. But, often unbeknownst to the code owner, those components carry risks worthy of more diligence.
Anticipating Due Diligence in M&A
The Forbes article provides some sage advice when it comes to mitigating these risks. For entrepreneurs anticipating a possible M&A exit, the article says: “By…properly anticipating the related issues that may arise, the target company will be better prepared to successfully consummate a sale of the company.”
Black Duck as a maturing venture-backed start up sets a good example. We have always proactively maintained a repository documentation that might be of interest to a potential acquirer. This kind of forethought and organization may one day ensure a smooth process.
But anticipating questions around open source demands an additional layer of preparedness. It goes beyond just proactively organizing documents. For example, Black Duck’s repository contains a folder of licenses for commercial third party software we use in our products. That’s relatively straight-forward as most companies know what commercial software they use. However, few companies have a good handle on what open source components are in their code. Without that, they can’t know what license or security red flags might arise and affect a transaction.
Any company whose software assets are a significant part of its value is well-advised (pay heed, if you are an advisor) to gain a reasonable idea of what open source is in their code before going into a transaction. Ideally, this should be the upshot of an established policy and a process for tracking open source component use. Absent that, it’s advisable to perform a proactive scan, with enough lead time before a transaction to allow remediating any issues that turn up. This will ensure a smoother process (and good night’s sleep on the eve of diligence).
The post Anticipating Due Diligence and Sleeping Well appeared first on Open Source Delivers.