With the growing worldwide adoption of open source software by corporations of all sizes, no longer is the analysis of open source only relevant to software development companies. In the context of corporate acquisitions, it is becoming increasingly difficult to find companies that do not use or rely on open source software in some manner (knowingly or unknowingly). Whether a company is a potential target of an acquisition, looking to acquire an entire company, or interested in purchasing certain assets, understanding the risks associated with open source software and the steps to properly analyze and manage open source in the transaction is critical.
Potential risks and consequences on transaction
Open source risks that require consideration in acquisition deals fall into three primary categories: pedigree issues, reciprocal license issues, and patent issues. These issues focus on the rights a target company actually has in the open source code it uses and the obligations it must comply with as a result of that use.
Where did the code come from? Because code in an open source project is typically contributed over time by a broad community of developers, it is difficult to know whether each developer had the rights necessary to make a contribution. For example, might a programmer take code developed during the day for his employer and contribute portions to an open source project he is working on at night? With these unknowns in the development history, open source programs are usually distributed “as-is” without any warranties of performance or ownership, or indemnities against intellectual property infringement claims. Users must therefore absorb the entire risk and exposure to potential claims that open source components infringe third-party intellectual property rights. Furthermore, if a target company incorporated open source components into its own proprietary product and distributed that product under a commercially standard agreement that includes intellectual property infringement indemnifications, this obligation may be difficult or costly for the acquirer to keep.
Reciprocal license issues
If a company incorporates open source software components into a proprietary product and then distributes that product, the more restrictive open source licenses require that the distribution of the resulting product be under the same terms as the open source license. Complying with this obligation usually requires making the source code for the entire proprietary product available to licensees for their use, modification, and redistribution — a requirement that may be inconsistent with an acquirer’s business plans. The most notable open source license with this “reciprocal” or “copyleft” requirement is the GNU General Public License (GPL). A company that uses open source software without complying with the terms of an applicable open source license is using copyrighted software without permission and is exposed to liability for damages for copyright infringement. In addition, courts have the authority to issue an injunction preventing the company’s future use or distribution of the infringing work.
Many open source licenses contain either implied or express patent license grants, whereby a contributor to an open source work must offer downstream users a license to the contributor’s related patent claims. In addition, certain open source licenses contain patent retaliation provisions, which condition particular rights to use the open source program on not filing a patent infringement lawsuit against another’s use or distribution of works based on that program. If the acquirer or target company has a significant patent portfolio and is required to use one of these open source licenses, it must consider the potential impact the open source license has on its patent portfolio.
Consequences on the transaction
An analysis of open source issues can impact the representations, warranties, and indemnities in a corporate acquisition and depending on the significance of the risks, will impact the value of the transaction to the potential acquirer. Perhaps the primary reason these open source issues first emerge during an acquisition is that the target company is unaware of potential problems. Many companies have not documented their use of open source software and do not have policies in place to govern such use. Poor documentation of use and a misunderstanding of the ramifications by developers can lead to significant compliance issues for an acquirer to assume.
Steps to manage open source in a corporate acquisition
The initial step for an acquirer in an acquisition transaction is to obtain a complete understanding of the target company’s use of open source software through the due diligence process. Questions must be detailed and intended to focus on the key issues, such as: What open source code is being used? How is it being used or incorporated? How critical is the code? What open source license applies? Since company management is often not fully apprised of the scope of use of open source software within their organizations, these questions should be directed to the company’s technical team.
Unfortunately, with employee turnover, the use of independent contractors, lack of consistent documentation, and the readily available access to open source software online, even good faith attempts to answer diligence questions will not always provide an accurate picture of open source software use. While not appropriate for every transaction, vendors are available with automated tools to scan a target company’s code base and provide detailed reports on open source software being used. Before pursuing this option, an acquirer must balance the potential risks and value of the transaction against the added time and cost associated with an automated code search.
A discovery of open source software during these investigative processes should not automatically be viewed negatively by the acquirer. Many uses of open source software demonstrate good business judgment and present minimal risks to an organization. As open source software becomes more ubiquitous, it is not practical for companies engaging in acquisitions to enforce an absolute prohibition against its use.
Instead, a company needs to carefully examine each use and the potential impact, if any, it will have on the acquisition and the organization’s future business plans. Questions to consider include: How will the acquirer use the relevant code post-acquisition? Is this use consistent with the open source license? Has the target company complied with the terms of the relevant open source license? If necessary, what remediation options are available and how much will they cost to implement? Common remediation efforts include removal of problematic code, independent development of comparable functionality, or replacement with commercially available alternatives. If remediation alternatives are available and deemed worthwhile, the parties need to consider whether these activities should be performed by the target company immediately or by the acquiring company post-closing.
If a company engaging in an acquisition does not appropriately analyze the impact of open source software, it may be acquiring more risk than it otherwise anticipated. Likewise, for any company that may be the target in a future corporate acquisition, understanding these issues will enable the company to grasp the relevance of open source software in its business and take proactive steps to manage and protect against risks, before they present an obstacle in a major transaction.