Recently, a large, well-known company in the computer software industry approached a small technology company to gauge its level of interest in being acquired at a nice multiple. The management team and investors quickly reached a decision to accept the large company’s offer and due diligence ensued.
If you haven’t gone through an M&A exercise, there are a number of standard due diligence processes that you need to step through. For example, on the federal level if the transaction is larger than $63.4M, then the transaction is subject to the the Hart-Scott-Rodino (HSR) Anti-Trust Act which the FTC enforces to help ensure competition remains in any one industry. Passing the HSR test is relatively easy if you’re a smaller company but if two large competitors want to “merge”, it gets more complicated and difficult to get past HSR.
There are many other standard process “hoops” you must jump through during the M&A process but I want to focus this blog on one that is relatively new. This process isn’t mandated by any government regulator but if you’re not prepared for it well in advance, it has the potential to derail the entire transaction at the worst possible moment.
The process I want to talk about is the “source code scan”. The source code scan has now become “de rigeur” in any M&A or PE transaction – and with any of my investments. Why? Simple. If there is embedded open source or third party software that is not appropriately licensed, then that company – and its acquirer – could be subject to substantial IP issues, rengineering efforts, lawsuits, legal fees, penalties and royalties.
Here is an excerpt from Palamida, a company that provides code scanning software/services, that sums it up nicely:
“…access to diverse code resources, combined with pressure to deliver product to market rapidly and cost-effectively, has given rise to the blending of homegrown, commercial and particularly, the widespread use of open source software. While using these multiple resources for code can and does speed a company’s development, time to market, and overall innovation, it makes identification and monitoring of unknown and potentially vulnerable software components difficult and the assessment of intellectual property and vulnerability risks more challenging than ever.”
So, with that as a backdrop, here is what happened to the company I introduced at the beginning of this blog.
As part of the acquirer’s due diligence, it used an independent third party to run a source code scan. Not surprising, there were open source elements that had been embedded in to the main code line of the company’s products.
However, what was surprising was that several of those open source elements, unbeknownst to engineering and the rest of management, were subject to certain terms that stated if the original code was modified, all modifications were required to be donated back to the open source provider for public use. Therefore, the company’s proprietary IP was instantly clouded. No one in the company’s current engineering organization had any idea this code – with its attendant licensing requirements – had been embedded into the software. And, removing and replacing it was determined to be non-trivial.
The deal was put on hold for this and other reasons. And, now that the company is aware of this issue it must determine how it will bring the company into compliance and how feasible it is (how much it will cost) to remove the code in a future release.
Like a colonscopy that is recommended for anyone over 50, I would strongly encourage any company that creates and/or uses software in its products to perform a complete source code software scan on a regular basis. And, that scan should generate a report delivered to executive management and the board that verifies it is appropriately licensed for any/all code assembled into its products. A silent killer may be lurking.