M&A deals imperilled by failure to manage open source software risk, says expert

Phil Odence, general manager of Black Duck On-Demand Audits, which carries out software audits in the context of mergers and acquisitions (M&As), told Out-Law.com that he was personally aware of a 12 week delay to one deal as a result of concerns identified with the use of open source software by the target company.

Odence said that it is also common for buyers to increase the level of 'holdbacks' – the proportion of the purchase price withheld from being paid until certain conditions are satisfied – when due diligence checks reveal new open source software risks in a target.

In some cases, Black Duck has even seen "adjustments to [deal] valuations" stemming from open source software risks, he said. Some deal valuations have been "beat down" where "deep-rooted issues with licences" have been identified, for example, as those issues can take time to unravel and can impede future software development, Odence said.

Open source code is incorporated into most software developed by businesses, Odence said. Using open source code allows in-house developers to focus on developing bespoke software specific to the business and its customers, with the more basic "plumbing" delivered via open source code, he said.

Odence said that from 600 software audits carried out by Black Duck last year, 35% of the software "code base" it assessed was open source software code. He said he had seen the use of open source software proliferate in many sectors, including financial services, technology and manufacturing in recent years. Black Duck currently tracks more than two million open source software components, he said.

Odence warned, though, that managers at companies often lack visibility of their developers' use of open source code, and that some also fail to put processes in place to mitigate risks present in that use, such as licensing constraints or cyber vulnerabilities.

Odence said that there are a number of different open source software licences that could govern use of the code.

Some licences allow businesses to incorporate open source code into their own software, provided that attribution is given to the developers and that those developers are not held liable for any issues that arise from its use, Odence said.

The family of licences under the General Public Licence (GPL) regime are more complicated, he said. If open source code developed under GPL licences is "improperly combined" with proprietary software code it can require businesses to disclose their proprietary code, he warned. This is the biggest licensing risk stemming from use of open source software, he said.

Cyber weaknesses may also subsist in open source software used by a business which they may not be aware of, Odence said.

Open source code is built by a community of developers, which helps to ensure testing against known vulnerabilities, Odence said. Those developers also help patch security vulnerabilities after the code has been released, he said. However, for most open source software there is rarely a notification system that alerts businesses to update their code where problems are identified, he said. This means businesses that do not proactively monitor for security updates may unwittingly operate out-of-date software containing vulnerabilities, he said.

In-house developers making use of open source code are "not necessarily asking themselves the right questions" to address the various areas of risk, Odence said.

As an example of the problem, Odence pointed to research carried out by Black Duck at the end of 2015 and beginning of 2016 which found that 10% of businesses it studied were still running open source software containing the so-called 'Heartbleed' bug that was identified in 2014, despite the fact an immediate fix for the vulnerability was available at the time the issue was reported.

Any company where software is important should have a strategy for using open source and have policies in place to explain the procedures to follow for using it, Odence said.

"It is not good practice to leave things up to the developers," Odence said. "Policy should be embodied in organisational processes that need to include some mechanism for tracking use internally. The bigger the company, the more sophisticated tools and processes will need to be."

Odence said that businesses need to ensure they also educate their software developers on why they should follow extra steps before adopting open source code into applications they are developing, to help ensure those employees buy into the right processes.