Software was traditionally constructed from scratch, however nowadays requirements have gotten a lot more complex; the evolution of software has now resulted in software modularity and developers’ jobs now mostly involve assembling components from a variety of sources, including many components that are freely available on the internet. This ‘open source’ software enables developers to build on the work of others, they can tweak components and integrate it with other software to produce a specific product. According to Forrester Research, open source now comprises as much as 90% of a new application’s code. It’s a valuable resource, enabling software developers to build applications more affordably and bring them to market quickly.
Of course, those open source components usually come with a licence that defines what rights you have; those licenses also contain obligations involved which developers do not always consider.
How does this relate to the M&A world? Well, Phil Odence explains to us that when a company is buying another company where a lot of the value is tied up in software, lawyers want to ensure that intellectual property rights are clear and that the software isn’t burdened with licence infringements or full of cybersecurity vulnerabilities.
Phil is the Vice President and General Manager of Black Duck’s On Demand Audit Division; he works with M&A and technology lawyers to help them locate what open source code has been used where, and to identify any risks they should know about.
How has open source (OS) software use changed the due diligence process for lawyers?
Using OS is great for software development productivity. But the trouble is many companies use it without being fully aware of the licence agreements that come with it or the need to continually review it for cybersecurity vulnerabilities. Most acquirers today want to make sure they know what really is in the target’s code, in advance, before the close of the transaction. So an open source code audit and risk assessment has become an important part of the technical due diligence process.
Have you heard of any cases where potential problems were noticed a little too late? What was the effect of that?
The best example is Cisco acquiring Linksys ten years ago. Soon after spending half a billion dollars, they were served with a law suit for an open source licence violation, resulting in bad press, lawyers’ fees and, ultimately, an out of court settlement. Although the terms were not public, it is likely they were required to pay the plaintiff, put an open source management programme in place, and disclose all of the proprietors’ software to the public. This is probably the worst case scenario.
In what sort of M&A deals might it be important to look out for where the company (being acquired) has used OS and so make scanning for it an important component of the due diligence process?
Any time when software assets are significant to the company’s value. When software is a company’s primary asset, it’s vital to know what open source is being used, where it is being used, and of any license or security risks.
How frequently is open source software used by companies? Is use growing?
In today’s world where agile software development is key, OS software is used very frequently. Analysing recent audits for clients, Black Duck took a set of 200 software applications and found almost all of those applications used OS. Indeed, we find OS in 98% of the applications we audit. Ten years ago, software consisting of 10% or less OS was normal, but today, open source now comprises as much as 90% of a new application’s code.
Organisations must employ automated processes to gain visibility into what OS components developers are using – manual processes seldom are efficient. For example, when we ask the code owner for a list of OS being used, we only receive a response 50% of the time, because in most cases they just don’t know. In cases where we do get a list, on average, that list only reveals half of the OS code we eventually discover in the audit.
To what extent are lawyers already familiar and informed about this and considering it in due diligence?
Most technology and commercial lawyers have some familiarity with OS license compliance risk; however, even in the large international law firms, there are only usually a handful of lawyers that have the unique expertise required. M&A lawyers who are involved in all aspects of the deals will bring their expert colleagues into deals where software is an important part of the transaction.
Do you know if this knowledge of open source varies from country to country?
Anywhere where technology development is prevalent, such as in the UK and Germany, the knowledge of open source and its legal baggage is well-known. I would say the way in which the US differs from Europe is that in Europe companies are more reliant on legal mechanisms rather than specialists like Black Duck to perform the checks and factually define exactly how things are. I am not sure why that is, as there has been more litigation around open source in Europe, so I would expect more scrutiny in Europe in the future.
What issues arise from open source software and the due diligence process and how can companies overcome the issues presented?
Both companies in a deal are typically unaware of the type and extent of OS code within the target company’s software assets. Black Duck helps establish that use for both sides. When you know what OS is being used, and where, you can then assess the potential risks and move to address them.
Issues that arise include legal issues in relation to the licence (which is the main driver behind companies coming to Black Duck for an audit), operational issues and risks, and security issues. Legal risks concern the use of OS beyond the rights granted in the licence or not meeting the obligations stated within the license. For example, almost every licence states you must provide attribution for to the person that created it. Operational risks involve assessing the code’s quality, whether some components might make the code base more expensive to maintain, and so forth.
A big area of risk in OS use is one of cybersecurity. About two thirds of the OS components we look at have known security vulnerabilities. Acquirers want to know about these and any that could be a real threat. For example, is there a risk that sensitive information like designs or customer data might have been exposed?
There are two fundamental approaches to resolving these issues: technical solutions and business solutions. A technical solution can mean meeting the licence obligation, asking the copyright owner for permission to rewrite components, for example. From a business level, perhaps the valuation and terms of the deal are amended. Often there is a cash holdback to be used in case a lawsuit arises, or if there are problems within the first year. Sometimes deals are just delayed and transactions are put on hold whilst the issues are resolved; some companies prefer to resolve issues before transfer of ownership, some are comfortable resolving things after the transaction.
Do some issues arise more than others?
Security vulnerabilities in software are a big issue. More than 80% of all cyber attacks target software applications. With the majority of code in those applications now being OS, it’s vital to know what’s in use, where it is in the codebase, and to secure it against known vulnerabilities. In almost every audit we conduct we discover vulnerabilities, some of which were published publically years ago. Some vulnerabilities are so infamous they’ve earned names. Heartbleed, Dirty Cow, and Drown are just three of some 6000 vulnerabilities published since the start of 2014. Companies need to get better at tracking what open source components they use, where they’re using it, and ensuring those components are kept up-to-date and patched.
Do you see this changing in five or ten years when people become more aware?
I would say that companies are already getting better in time with their software management. In the future I think that companies will get better at knowing what is in their software and managing those risks. Beyond audits, a primary Black Duck business is providing tools for companies to help manage those risks for themselves.
Could the due diligence process be more extensive – more effective for lawyers to ensure the process is cleaner and quicker?
If companies were to get better at managing their OS, then they’d have fewer issues and need less help from lawyers. At the moment, I’d say that M&A lawyers do need to talk to their technical colleagues and consider 3rd party audit services to gain true insight into OS use and to establish what risks might be hidden within.
