Mergers and acquisition activity is beginning to pick up again after a few lean years. In my job as open source advocate at Dell, which has acquired a number of software companies, this means more time spent determining if open source code is present in the code base of an acquisition target.
Gartner issued a survey last year where they asked how much open source versus proprietary code was used in companies. The survey had almost 600 enterprise respondents, and the result was that there’s as much open source code deployed in enterprises as has been developed internally. We’ve reached a tipping point in terms of open source use. For companies like Dell which acquire other companies, it’s clear that open source is a great enabler of people who need to develop technology quickly. However if open source is unmanaged it can lead to issues that can impact an acquisition.
In my day job I‘m part of Dell’s Linux OS team, but I’m also the point person for performing technical due diligence when open source code is part of an acquisition. The open source due diligence process at Dell has grown organically. It began during one of the company’s first acquisitions about two years ago in which the corporate development team separately and independently contracted with Black Duck to scan the target company’s code. The scan resulted in a bill of material that had a “bunch of red stuff in it” –code components flagged as having license exposure – and the corporate development guys and the business guys looked at the report and said “What does this mean?” It turns out that interpreting that list is a critically important task that requires some software engineering skills as well as the ability to then translate those risks to the language the business side speaks.
Often the business people managing an acquisition know the value of the assets of a target company, but they don’t really know how to interpret and factor in the results of a scan for open source code, or at a higher level the risks to the business based on the results of a scan. That’s where I was pulled in initially, and I’ve grown into the process over the past couple of years.
It’s important to note a couple of things up front – if a company kills a deal based just on the presence of open source, it’s going to pass up on technology that would add value to the business. A second thing to bear in mind is what’s most important in an assessment is how the open source code is used. In technical terms, GPL compliance hinges on how components are linked together, not on mere presence or absence. You don’t want executives to overreact to the presenceof GPL components. We’ve had several deals where target companies used thousands of open source components. When we analyzed those, using the Black Duck scan and then examining the binaries, the usage was all perfectly fine and within license terms.
With this in mind, here are a few tips for acquirers and companies looking to be acquired.
Know what’s in your code and how it’s used: A concern for an acquirer is how well a target company knows what’s in its code, and how well the code base is managed. When Dell is looking at companies to acquire, we find – and this aligns with industry averages – about 90 percent of target companies have some unknown or undisclosed open source code. In a typical scan we might find 20 percent of the code is open source. Most of the code isn’t an issue, but some is. Being able to quickly explain how each module is used and what is linked to it is key to making this process less painful.
Timing is everything: The M&A process happens very, very quickly. Typical deals have an exclusivity period associated with them that can range from two weeks to a month. So you end up scanning millions of lines of code within a couple of days to be able to answer questions the business guys need to have answered.
Manage your code as if you’re going to be acquired: When we do the kick-off meeting with a target company we ask for a list of open source the company is aware of, then we get Black Duck reports and compare the two lists. When we look at those lists we see how well the company is managing its open source. If the Black Duck report lists 150 open source components but the target’s initial disclosure only lists 10, we know there are discrepancies in the management process. This gets reported up through Dell as management risk. We don’t use it as a gotcha moment, but we do try to use it to evaluate how the target manages its open source process.
Find and fix issues, and be prepared to remediate issues: This can be on the acquirer’s side, or it may be the target’s responsibility. Dell’s main goal is we won’t buy a company and then ship a product with any known violations. We typically will hash out the remediation we’d like to see for each component before we pass the information to the target company, and then we’ll talk to the target and determine how to remediate each violation. There are pre-closing remediations and there are post-closing remediations before Dell ships the acquired product. Each of these can affect the value of the deal. It makes more sense, if you’re planning to be acquired, to identify and fix issues before you get to the deal stage.
For example, something I run into in literally every single company we’ve acquired is violations around posting of source code. Even if they don’t have a reciprocity requirement in the license agreements, a lot of open source licenses require companies that distribute binaries for certain open source components to post the source code to those components. One common failure that I see almost universally is the failure to post source to open source components that have been used. In most cases, we are not talking about posting any proprietary code, but rather simply posting the source of the open source components. I typically see there’s either no policy around posting, the target hasn’t posted the complete source of everything they’re using, or they misunderstand the license requirements of the components they are using. It’s really straightforward to fix, and we always fix this before closing an acquisition.
Use open source, and manage your use: The presence or absence of open source in a product is not a deal breaker. More important is how it’s used, and if proprietary code is linked into open source code in a way that would require disclosure. I’m the open source advocate at Dell and I deal with this a lot. Even if you do have deep linking it might not impact an acquisition. The valuation might go up or down based on the business analysis of the code, but the simple presence or absence of open source isn’t going to kill a deal. How it’s used, and making sure it’s done properly, is what counts.
(Editors Note: View this webinar to hear more from Michael Brown about managing open source during the M&A process.)
