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.
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.
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.
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.
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.
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 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.
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.