“He who sells what isn’t his’n, Must buy it back or go to prison.”
Daniel Drew, 19th Century American Financier
In Part I of this series, we covered several ways in which tech diligence identifies technical debt and other risks that can lead to unexpected costs and value impairment. In Part II, we explore other technical and legal IP issues that could require unplanned work, delay shipment, or, in the worst case, land an acquirer in a lawsuit over licensing that exposes proprietary intellectual property.
Where software assets are a large part of valuation, it’s important to verify the ownership and to ensure proper licensing. Lawyers are well-accustomed to combing through and investigating compliance with contracts/licenses for commercial third party code.
But today, most software contains a large portion of open source code with licenses every bit as valid and binding. And there are other security and operational risks with open source that may be trickier to manage than their commercial counterparts.
What is and Why Open Source
Open source software is a type of third party code, licensed in a way to enable and encourage collaborative development. The idea is that developers can avoid reinventing the wheel by finding the wheel they want built by a counterpart, perhaps half way around the world, and perhaps contributed to by many others. Open source development has ramped to the point where there are now more than a million components freely available on the Internet.
Few software projects today start with typing the first line of code on a blank screen; it’s much more about “gluing” together useful piece parts from a variety of sources in clever ways. The basic benefit is clear: If an organization can avoid having to create large pieces of functionality, it can focus its resources on high-value, differentiating features. Savvy investors and acquirers today look for technologists who can gain this kind of leverage.
Industry research and data from Black Duck audit work show that most software today contains 30-35% open source. There are examples of products ranging from trading applications to mobile handsets that contain as much as 80% open source code. According to Gartner, “by 2016, at least 95% of IT organizations will leverage nontrivial elements of open-source software technology in their mission-critical IT portfolios, including cases where they might not be aware of it — an increase from 75% in 2010.”¹
“We only develop what we can’t download.” -CIO of large financial services company.
The Risks of Open Source
So what’s the catch? With open source components come potential risks of which a development organization must be aware and manage. Caveat emptor applies even for free software, and developers often don’t understand the risks and issues unless they are trained and equipped to do so.
The most acute risk from the perspective of most acquirers has to do with the way the components of a software application are licensed. A license is essentially the conditions under which the copyright holder allows use of their software, and open source licenses are every bit as enforceable as commercial licenses. It is a misconception that open source software doesn’t have owners or copyright holders. Because of this, there are a variety of legal issues that need to be managed. In extreme cases, a company may be sued and may forfeit proprietary intellectual property due to misuse of someone else’s code. In fact, the deep pockets of a new acquirer could be the impetus for such a suit.
Not all open source licenses are created equal. Many are “permissive” and require little more than keeping copyright notices in place. But some of the most popular licenses have “copyleft” features that can impact the proprietary code with which they are combined. Even code under copyleft licenses can be safely used with proprietary code; it just has to be done right. Linux is licensed under the GNU General Public License (GPL), the most popular copyleft license, and is shipped on many proprietary devices with no problem.
Of late, high profile cases of security vulnerabilities in popular open source components (e.g. Heartbleed in OpenSSL) have raised sensitivity to this class of risk. Other operational risks are also a consideration. Typically open source components are supported by a loosely affiliated community. A vibrant community can be highly effective at maintaining software, but applications built upon components that are not actively maintained are likely to have future problems.
Example: Cisco and Linksys
Cisco experienced a well-known example of license risk. They expanded their portfolio in the consumer space with a half-billion dollar acquisition of Linksys. Linksys used Broadcom chips with drivers developed by a Taiwanese firm that, in turn, had its own chain of software suppliers. Somewhere upstream in the supply chain of the WRT54G router, a developer introduced a bit of GPL-licensed code. Soon after the acquisition, suit was brought. It was settled out of court but only after much bad press and legal fees. Part of the settlement required Cisco to make the router’s proprietary code public.
Open Source Management
Open source code is so easy for developers to access on the Internet—they can get whatever they want whenever they want—that it is difficult for companies to have visibility and control over the components their developers are utilizing. Only with a fairly well-managed software development process is an organization likely to even know what components are in their code.
A robust tech diligence process will include analysis of the open source and 3rd party code used by the target company. The first step is to ask the target company, through an information request and/or a face-to-face interview, which 3rd party products they use. These typically fall into three categories:
- Tools used in the development process but not shipped with the product comprises the first group. These often include compilers, debuggers, certain code generators, source code control systems, defect tracking systems, build systems, and performance analysis tools.
- Open source runtime components comprises the second group. These components include frameworks (like Spring), application servers (like Apache/Tomcat), utility libraries (like OpenSSL), GUI frameworks (like Bootstrap, JQuery), as well as many other types and instances of runtimes.
- Commercial runtime components comprises the final group. This group is similar to the open source group above, but is licensed under commercial terms from an independent software vendor (ISV). The license might involve royalties, up-front payments, or annual fees.
The R&D team should be able to articulate why and how each product or tool in the provided lists is used. Their ability to do so is indicative of their thought process in designing their software, as well as their financial oversight process in balancing the tradeoffs between using third party products and writing code that might be considered commodity. It is not uncommon for us to engage with a CTO, even a good CTO, who is surprised to find out the extent of open source his team is using as a result of our work.
I didn’t realize how valuable this process was going to be. There are some unexpected positive consequences of my being made aware of the informal decisions our developers have been making. – CTO $80M Middleware Software Company
How to Conduct Open Source Diligence
Clearly it’s important as part of diligence to dig into what open source components are employed in a target’s code and to evaluate the associated risks. It has become the norm today, at least in North America, for an open source audit or review to be part of deal diligence.
As described above, acquirers should, at a bare minimum, ask for a list of open source components in the software. A wise acquirer will assess not only the answer, but the reaction to the question. Bewildered looks and a response like, “We will have to get back to you on that,” should raise red flags.
Oftentimes open source use is a grassroots movement in a development organization. The gap is closing over time, but historically senior managers in software organizations have been out of touch with the fact that the just-out-of-university developers are using open source like water.
Unless a development organization has been systematic about tracking use of open source, it is very difficult to manually identify what components are in a code base. There are, however, automated tools that compare code to a vast database of open source software, identify matches, and can therefore identify the components and associated risks. It’s a fairly specialized area, so many acquirers and investors employ expert third parties to perform this part of diligence.
An open source scan, such as that provided by Black Duck, can be employed to scan the code and determine what open source and third party products are actually used by the target and also what licenses they fall under.
It is typical that the results of the audit don’t match those provided ahead of time by the R&D team. In other words, there are libraries and tools being used by most R&D organizations that R&D leadership are often unaware of, which means there are likely risks that they are unaware of as well.
Reps and warranties in a purchase agreement are a good idea, but they may be agreed to by officers who don’t understand what’s really in the code. Due diligence is the opportunity to understand the risks before signing the agreement.
“When we were selling off a business line and the question came up, the director of engineering told me we weren’t using much open source. But the scan turned out he had no idea.” – Business Development VP of a Tech Company
Attractive acquisition candidates should be leveraging open source, but if they are not managed well, the open source components in their code likely create license, security and operational risks. Due diligence is the opportunity to understand the open source content of a code base and the management practices around it.