Auditing the code base of the technology company you plan to buy is not the only way for an acquirer to gain comfort with regard to open source license risk. However, it is the best way for all parties involved in the transaction to rest more easily.
Several years ago, a prominent UK open source attorney was describing the state of due diligence in Europe with respect to the use of open source software. He recounted a conversation that he’d had with a client’s VP of Engineering that he thought was fairly representative of the current mind set.
I was asking about how they had handled the open source issue in previous acquisitions and the gent told me he would just look the other VP of Engineering in the eye and ask ‘What open source are you using?’
The problem was that the acquirer assumed his counterpart knew the answer. That gent, in good faith, probably believed he did. But, the reality is that he probably didn’t.
My first exposure to this very issue was during my role as the seller in a similar transaction. We had no idea what or how much open source we were using, let alone whether it opened us up to risk. To be fair, that was a number of years back, and certainly the awareness gap has been narrowing. Over the last several years, software development managers have become much more aware of their organization’s use of open source. However, as use and availability of free software continues its steady rise, visibility into the open source developers are using requires solid adherence to well-designed processes. Many organizations are ineffective simply because of the sheer volume of open source being used.
While you may feel confident that your VP of Engineering has a good sense of how scalable your product is or generally knows the quality of the code, it’s unlikely they know the amount of open source you’re using. It’s a tricky matter for any one person to pin down.
So How to Manage Open Source License Risk in an Acquisition?
There are different ways companies can protect themselves. One popular method is inserting legal language into purchase documents. For example, most transactions today involve some representations (reps) and warranties specific to open source. These can range from generic statements about the target’s rights to use what’s in their code and compliance with all licenses. Or they may be more specific to open source components and may enumerate certain licenses of concern. Increasingly, they might also reference actual lists and schedules intended to enumerate all open source in use. There may also be general warranties about security or more specific ones about components with known vulnerabilities.
Open source reps and warranties are a good safety net, but just as medical insurance is not a substitute for a healthy lifestyle, they’re not enough. Law suits are messy and can be highly disruptive. For example, a founder CTO might be an important acquired asset as well as a signatory on the purchase documents. During an lawsuit, they could be held liable personally. That, in turn, could generate ill will among employees and even drive the acquired business into a downward spiral. That’s why it’s much better to anticipate and assess potential risk from open source up front.
Open source litigation concerns aside, often the acquiring companies will find that due to lack of open source governance by the company they plan to purchase, the target company may need to engage in costly remediation efforts just to meet the acquirer’s internal policies. These efforts may cause delay in taking the acquired products to market or may otherwise cause the overall value (or perceived value) of the acquisition to be diminished.
Certainly there should be some effort to quantify open source risks up front. An in-depth analysis of a code base with sophisticated tools, such as those used during Black Duck audits, provides a comprehensive view into the open source content within a code base and the associated risks. If both parties in a transaction have visibility into the issues before the transaction occurs, there are fewer surprises either pre- or post-transaction. The cost of an audit is typically small compared to the potential exposure and messy outcomes that might result from not knowing your open source license risk, and therefore provides comfort to all involved.
Interested in learning more about open source license risk and open source security risk? Join our webinar June 22 at 11:30 AM ET: Strategies for Managing Open Source Security Risk.
The post Levels of Comfort with Open Source License Risk appeared first on Open Source Delivers.