In today’s software industry, mergers and acquisitions are quite common, even considered a frequent occurrence. Some in the industry have even said they’re “the name of the game” in the software industry. While larger companies often acquire smaller ones, it isn’t at all uncommon for the opposite to occur, so no matter how large or small a software company is, developers need to be prepared for the possibility that their company can be acquired at any time.
For many software companies, the goal is to be acquired. Anything that creates risk in the acquisition process creates business valuation risk.
Keeping track of open source software use within the company is the development/engineering team’s job to be prepared for the due diligence process associated with the acquisition.
Almost all companies developing software use some sort of OSS during their product development and/or day to day operations, it is even estimated that 94% of software projects use OSS. Using OSS is often considered a necessity of doing business, as its use can save time, money and resources that companies would otherwise need to spend developing their own software.
During mergers and acquisitions, the buying companies need to know the state of OSS use in the target company, as buying companies can put themselves at high risk of violating OSS licenses if they’re unaware of OSS use.
To prevent issues from arising, buying companies will demand proof of pedigree of the company and its software that they’re buying, as well as details about where OSS is used, what kind of OSS is used, and especially what kind of license the OSS is under.
OSS Issues that Arise During Mergers and Acquisitions
Open source use at a company can sometimes make or break a merger or acquisition deal.
Under the wrong circumstances, OSS usage within the target company can dramatically lower or entirely eliminate the value of the company or its software.
Copyleft OSS licenses are often the culprit of problems that arise. Some weaker, less restrictive copyleft licenses only require companies to make the source code of any modifications to OSS available to others. This can sometimes create issues, but often stronger copyleft licenses are to blame. Stronger copyleft licenses require the source code of all software based on or including OSS to be made available to others as OSS, meaning that proprietary works based on or including any OSS will themselves be required to be released as OSS.
In some cases, this is only required when software based on OSS is distributed, but some licenses also require source code to be released when software is hosted.
If the buying company wishes to sell the target company’s software as proprietary, non-OSS software, but the software is under a strong copyleft license, the buying company has very limited options.
It can:
- Release the software as OSS without charging for it, which defeats the purpose of the merger/acquisition
- Discontinue the software bound by this OSS license, again defeating the purpose of the merger/acquisition
- Change the license on the OSS, which isn’t easy or likely to work
- Replace the OSS with proprietary code that functions identically without being restricted by the license, which can be time consuming and expensive
- Violate the OSS license by selling the software without releasing source code, which will inevitably expose the company to legal trouble
Out of those options, two entirely defeat the purpose of the merger, one isn’t legal, one is incredibly difficult and unlikely, and the last, replacing the OSS with new code, can be impractical and cost prohibitive depending on the size and complexity of the OSS software.
In short, none of the options are good ones, even if one or two are technically possible. For this reason, buying companies must be aware of the state of OSS use ahead of time, to determine if the merger or acquisition is even worth the trouble and expense.
An example of a company making poor choices after an acquisition can be found in the Free Software Foundation (FSF) v. Cisco case. Cisco acquired Linksys in 2003, seemingly unaware that some Linksys software contained OSS under the GPL license, a copyleft license.
The FSF, creators of the GPL license, filed a copyright lawsuit against Cisco in 2008 for failing to disclose the source code of several Linksys products it had distributed since the acquisition five years prior. Cisco’s options were quite limited, and they decided that it would be cost prohibitive to reengineer the OSS used in the Linksys versions they had already released.
They ended up reaching a settlement with the FSF, which included releasing the source code for the versions they had released under the GPL license, and contributing an undisclosed monetary donation to the FSF. Due to this case, Cisco ended up unable to generate further revenue from the Linksys software it had acquired in 2003. This was a preventable issue, as had Cisco been aware of the restrictive license on the software, they may have avoided the legal trouble and the costs that came with it, or they may have called the Linksys deal off and avoided this lawsuit altogether.
If ignorance of OSS licenses can cause such significant problems, how should these problems be avoided?
Open Source Audits
Performing an open source audit can identify the details and potential problems presented by OSS and its licenses. An open source audit is an investigation by a certified auditor into the open source components used in a software product or used in a company’s daily operations.
Audits provide a number of valuable things:
- A Due Diligence Report – Inventory of the OSS
- This report identifies the details of where and how open source components are used.
- Security Vulnerabilities Report
- This is used to identify potential security threats, including information about the type of vulnerability found in the software, the location of the vulnerability and suggested fixes.
- Attribution Report – An analysis of license compliance
- The attribution report is an investigation into the compatibility of OSS licenses with one another, as well as their compatibility with company policies. This can be quite important, as there can be several types of OSS used within one application, and with them there can be several types of licenses, including both copyleft and permissive licenses.
- Compatibility Risk Report
- This report can identify out-of-date or multi-versioned libraries that need updating, and can include recommendations on how to update the libraries.
- An in-person walkthrough of the audit’s significant findings
Audits are incredibly valuable and include nearly everything a buying company needs to know about OSS use in a target company and its software. It can be quite reassuring, as the information it presents should allow the buying company to avoid future legal issues.
Audits indicate what OSS licenses allow buying companies to do, whether they’re allowed to sell software without releasing source code, or if they’re more restricted by licenses. Some companies are even required to release the information from open source audits to their shareholders, to alert them to any risks the company may be taking. Having the details of OSS use thoroughly outlined and having issues highlighted can help to prevent cases like FSF v. Cisco in the future.
It is imperative for target companies to comply with the audit and ensure that it is completed as quickly as possible.
If OSS use isn’t well documented and organized, it can require extra time to conduct the audit and will draw out the mergers and acquisition process. Also, if issues are found with license compliance, it will be the responsibility of the target company to bring the OSS into compliance, extending the process further.
Extending the merger and acquisition process can be a serious waste of time and capital, and can put the entire process at risk of falling through. Buying companies can become disinterested if the process takes too long, and even if they remain interested but an outside issue arises, such as an economic recession or market crash, this can be enough to kill a deal.
