/>iThe number of different open source licenses is growing and the variation in their terms and complexity is increasing. A number of licenses that appear to be, or are commonly referred to as, “open source” do not actually meet the Open Source Initiative (OSI) definition of “open source.” Thus, they do not appear on the OSI list of approved open source licenses. We like to say that these licenses are open source-ish! To complicate matters further, another leading software organization, the Free Software Foundation, defines “open source” differently than OSI does. Some licenses that are deemed open source by OSI are not by the FSF, and vice versa. For these and other reasons, there is no universally accepted definition of “open source.”
The lack of standard definition of “open source” can lead to potential legal issues and business problems, particularly in connection with investments or acquisitions in companies that use software covered by such licenses.
This article addresses why these issues are relevant to both companies that use open source software (OSS) and potential investors in or acquirors of those companies.
For example, when conducting diligence and drafting representations and warranties in deal documents, it is critical to ensure a comprehensive definition of “open source” that includes both true open source licenses and those that are only open source-ish. Many of the standard definitions that are used in form legal documents do not follow this practice! Failure to properly define open source in diligence requests can lead to situations where software covered by a license that triggers significant legal or business issues should be identified and disclosed, but is not!
Companies using OSS, and investors in or acquirors of those companies, should work with counsel who specializes in open source licensing (and understands its many intricacies and nuances) to minimize adverse legal issues and business problems associated with the use of OSS. For example, companies using OSS should work with open source counsel to develop and implement a written corporate open source policy. Investors and acquirors of such companies should engage specialized open source counsel to handle open source diligence and legal issues that arise in transactions.
Examples of Open Source-ish Licenses
One of the most permissive licenses, the Creative Commons Zero (CC0) license, was submitted to OSI for approval but was not approved. By way of example, the “grant” clause in this license is tantamount to a waiver of copyright and a dedication of the software to the public domain. The license states as follows:
To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer’s Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the “Waiver”). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer’s heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer’s express Statement of Purpose.
This license permits users to copy the licensed software, modify it, and share it with others for free.
If you were investing in or buying a company that developed software covered by this license, and you asked for all software covered by an open source license, wouldn’t you want that software to be identified? Depending on how the diligence request defines “open source” (e.g., if “open source” was defined using only the OSI definition), software covered by this license may not be identified.
A number of important new licenses that are referred to as open source licenses are actually open source-ish and do not appear on the OSI list of approved licenses. The Redis Source Available License (RSAL) and the MongoDB Server Side Public License are just two examples. Many other open source-ish licenses exist.
Open Source Legal Issues
Significant adverse consequences can result from using software covered by certain open source licenses. Two of the most potentially problematic consequences from a business valuation perspective are the loss of software licensing revenue and/or the obligation to license company patents for free. The following is a brief overview of these and some other potential issues.
Various actions trigger source code obligations.
Under some open source licenses, if a licensee develops software that includes or is derived from the OSS, it is required to license that software under the open source license (as opposed to a proprietary license). This means that the software developer must grant recipients a license to copy, modify and redistribute the software for free and make the source code available under those same terms.
If a company’s goal is to develop “proprietary” software, with the intent of licensing that software to collect license fees, these license grant and source code obligations may prevent it from doing so. This can significantly impact the company’s revenue and valuation!
Under some open source licenses, these license grant and source code obligations are triggered when a licensee distributes software that includes or is derived from the OSS. However, under a growing number of other open source licenses, these obligations are triggered by offering access to the software via a network (e.g., via software-as-a-service (“SaaS”) deployment). For this reason, diligence requests should not focus solely on software that the target “distributes,” but should also include other software that the target makes available (e.g., via a SaaS model or otherwise).
Various actions may trigger free patent licenses.
A growing number of open source licenses include patent-related provisions. See Patent Issues with Open Source Software. Certain uses of OSS under these licenses trigger the obligation for licensees to grant patent licenses to others for free. The scope of these patent licenses vary, including the patents subject to the license and the scope of licensed activities. For example, some licenses only include patents currently owned by the licensee, but others also include future acquired patents. In some cases, the licensed activities are relatively narrow (e.g., patents that cover the OSS as it currently exists). However, in other cases, the licensed activities are broader and cover patents that cover any modification to or combination with the OSS. This can be problematic for commercial entities which rely on patents to protect their innovative technology. Some companies just do not know how broad these patent grants are and what rights they are obligated to grant.
Failure to comply may lead to copyright infringement claims.
Most open source licenses, even ones that are not otherwise legally problematic, have certain compliance obligations (e.g., copyright notice and attribution requirements). Companies that do not have effective open source policies often overlook these obligations. Some open source licenses automatically terminate in the event of a failure to comply with these obligations. In such cases, the target’s continued use or distribution of the OSS components, without a license, may constitute copyright infringement. There are a growing number of open source lawsuits, and lack of compliance with open source license terms is one of the most common bases for suit.
Patent retaliation clauses may terminate open source license rights.
Some open source licenses have so-called “patent retaliation” clauses. These clauses specify that, if the licensee sues another user for patent infringement, the licensee’s open source license is terminated. This means that the licensee must stop using the OSS or face potential copyright infringement claims. If the licensee made extensive use of OSS under that license, it could be left in a bind. In some cases, it is not easy to immediately rewrite the code to remove the OSS and replace it with new code. If the acquiror is active in patent enforcement, it is important to understand what software uses OSS and is at risk due to these patent retaliation provisions. For more on this issue, see Patent Issues with Open Source Software. Other potentially problematic open source legal issues can arise. Those discussed above are examples only.
Why Does This Matter?
All of this matters for acquirors and investors because during open source diligence for investments, acquisitions or other transactions, it is critical to identify all software that may be covered by an open source license or have open source-related legal issues. Many people erroneously assume that if a target has been licensing its software and no open source issues have previously surfaced, then there is a high likelihood that no such issue exists. This is a huge mistake! When Cisco acquired the Linksys router, issues with use of OSS in the router arose after the acquisition. This led to a lawsuit and Cisco ultimately making the OSS available for free.
Surprisingly, despite the ubiquitous and growing use of OSS, many companies still do not have effective open source policies (or do not enforce them). Some have no policy at all. These companies often let developers unwittingly use problematic OSS. Often these issues do not arise until an investor or acquiror conducts (proper) diligence. In other cases, these issues have arisen in connection with litigation, where the issues are surfaced during discovery.
All of this matters for companies using OSS because these issues may significantly affect valuation. Additionally, failure to effectively manage and track open source or open source-ish use can result in violations that persist for months or years before they are detected, which increases the company’s (or the acquiror’s) financial exposure in the event of a lawsuit.
How to Avoid Missing Important Open Source Issues During Deals
When acquiring or investing in companies where software is a valuable part of the deal, it is important to conduct open source due diligence and to obtain the appropriate representations and warranties to avoid buying into an open source issue. The diligence typically includes asking the target for information about all of the “open source” software that they use. The representations and warranties often are designed to ensure that no undesired legal ramifications result from using “open source,” including the obligation to disclose source code or grant patent licenses, among other things. For more information on conducting open source diligence, see Open Source Software in M&A and Finance Transactions.
The effectiveness of this diligence and the representations and warranties can be hampered if you do not use a comprehensive definition of “open source” that includes both true open source licenses and those that are only open source-ish. Many diligence requests and deal agreements use an incomplete definition of open source. As a result, some of the problematic uses of OSS can be missed during the diligence process and some of the representations and warranties may not fully cover all desired issues. Properly covering open source issues in deals requires a thorough understanding of all of the legal ramifications that can result from these types of licenses and use of a more comprehensive definition for open source than is often used in many standard “form” agreements.
Positioning a Company to Avoid Diligence Issues When Seeking Funding or Being Acquired
All companies that use OSS should implement and enforce a written open source policy. For companies seeking funding or looking to be acquired, it is even more important to have your open source house in order, before you undergo diligence.
Absent an effectively implemented open source policy, open source issues often manifest themselves at the least opportune times, for example, during diligence performed in connection with an investment or acquisition. This is not the time you want to first learn that you have an open source issue. We have seen deals crater due to previously unknown use of problematic OSS. In some cases, when these issues surface, the deal still gets done but the valuation is impacted.
For at least these reasons, it is critical for companies using OSS to understand the legal, practical and business issues resulting from such use and to manage their OSS use to avoid adverse issues. The best way to do this is to develop and implement a written corporate open source policy. For information on open source policies, see Open Source Software Policies – Why You Need Them And What They Should Include.
