Once the exception, the use of free and open-source software (FOSS) in commercial products has become the rule. FOSS can be particularly attractive to resource-strapped software and hardware companies that can avoid significant development costs and licensing fees by leveraging the availability of high-quality FOSS solutions. The use of FOSS in commercial products is not without risk, however, which must be accounted for in the diligence process associated with mergers, acquisitions, investments and similar transactions.
As FOSS use and distribution transitioned from obscurity to ubiquity, the sophistication and meticulousness of FOSS diligence in transactions evolved in turn. Indeed, FOSS diligence once consisted of little more than confirming the target company's products do not include FOSS licensed under a "copyleft" license, such as the General Public License (GPL), whereas current FOSS diligence practices often include a review of all FOSS used by the target company for copyleft, provenance, and compliance risks as well as an investigation of the target company's FOSS governance practices.
FOSS Disclosures and FOSS Scanning
Nearly every transaction involving computer software will include at least some FOSS diligence and, in nearly every case, the target company will be required to provide an inventory of FOSS software distributed or used in the development process. The requested inventory will typically include at least a list of distributed FOSS software, the FOSS licenses covering that software, the target products in which such software is distributed, how the FOSS software is integrated with those target products, and whether the target has modified the FOSS software.
If the target's software is one of its primary assets, the target should also expect its software's source code to be subjected to a FOSS scan by a commercial service provider such as Palamida, Black Duck, OpenLogic, or Protecode. This typically involves the target providing a copy of its software, in source code form, to the service provider. The service provider then compares the target's software with the service provider's collection of FOSS to produce a set of potential matches. It is common for commercial FOSS scans to identify FOSS not included within the inventory produced by the target. A few newly identified FOSS packages are unlikely to have a significant impact on the transaction. A significant number of previously unidentified FOSS packages, however, is often taken as an indication of poor FOSS governance practices and can impact the transaction, resulting in additional costs and risks being shifted to the target and, in severe cases, termination of the transaction.
A primary concern of most acquirers is whether the target has improperly embedded FOSS in its products that is subject to a "copyleft" or "weak-copyleft" license. Copyleft FOSS licenses (aka "viral" or "hereditary" licenses) include the GPL, Affero General Public License (AGPL), Creative Commons Share-Alike Licenses (CC-BY), and Berkeley DB (aka "Sleepycat") License. The terms of these copyleft licenses require that distribution (and in some cases hosted use) of the FOSS, and proprietary software combined with the FOSS, be under the terms of the same copyleft license. These licenses include terms that are inconsistent with many commercial licensing business models, such as requiring that software combined with the FOSS be provided to recipients in source code form and that recipients be permitted to modify and freely distribute the software combined with the FOSS. Accordingly, target use and distribution of copyleft FOSS is strictly scrutinized by acquirers to ensure the target has not become contractually obligated to license its valuable software or other intellectual property under the terms of a copyleft license (i.e., has not "tainted" its software or IP).
Weak copyleft or "file-level copyleft" licenses include the Lesser (or Library) General Public License (LPGL), Mozilla Public License (MPL), Common Public License (CPL), Common Development and Distribution License (CDDL), and Eclipse Public License (EPL). The terms of weak-copyleft licenses require distributors of the weak-copyleft FOSS to provide their modifications to the weak-copyleft software under the terms of the same weak-copyleft license. Unlike copyleft licenses, which extend the copyleft (or "tainting") effect to software combined with the FOSS, weak-copyleft licenses extend the copyleft effect only to modifications to the FOSS. So long as the specific requirements of these weak-copyleft licenses are met, distribution of the weak-copyleft FOSS will not have a copyleft effect on target software with which it is combined. However, if improperly combined with target software, weak-copyleft software can have the same effect that copyleft software would have on the target software with which it has been combined. Accordingly, use of weak-copyleft FOSS is also strictly scrutinized by acquirers.
Another primary concern of many acquirers is whether the target has used or combined its products with FOSS or "freeware" software that has been the subject of significant enforcement efforts, or aggressive licensing campaigns, or that is licensed by a third party that is a competitor of the target or perceived to be litigious. One example is BusyBox, FOSS that was the foundation for a broad GPL enforcement campaign that included lawsuits being filed against Best Buy, Samsung, and Westinghouse. Oracle's Java EE and SE products are another. Use and distribution of such software and compliance with the terms of the FOSS or freeware licenses governing that software is often strictly scrutinized by acquirers due to what is perceived to be a significant risk of enforcement or litigation.
A secondary concern of some acquirers is whether the target is in compliance with the obligations and restrictions imposed by FOSS licenses. These obligations can include, for example: providing recipients with source code, a copy of the FOSS license, notice of the use of FOSS, copyright or similar authorships notices, or notice of changes to the FOSS; indemnifying licensors; and granting recipients copyright or patent licenses. Restrictions can include, for example: limitations on the terms under which the FOSS is distributed; prohibitions against removal of licensing, IP, disclaimer or FOSS notices; restrictions on the application of distributor patents; and prohibitions against claiming ownership of the FOSS or using the author's name to endorse software combined with the FOSS.
Failure to have complied with the obligations and restrictions of FOSS licenses is generally perceived by acquirers to be less of a threat than copyleft and provenance risks. This perception is based primarily on the acquirer's risk exposure likely being limited to monetary damages (as opposed to loss of IP protection) and the lower enforcement rate for many of the non-copyleft obligations and restrictions. Further, many FOSS license enforcement efforts are primarily aimed, not at monetary damages for past contractual or IP infringement, but at obtaining compliance with the obligations and restrictions of the applicable FOSS licenses. Accordingly, acquirers often assume that bringing the target into compliance with FOSS licenses significantly reduces the risk of past non-compliance.
Another secondary concern of some acquirers is whether the target has put effective FOSS governance policies and procedures in place. The effectiveness of the target's practices will be apparent if a commercial FOSS scan has been performed. Alternatively, acquirers will typically request copies of any target documentation relating to its FOSS policies and procedures, and will seek to interview the target regarding its FOSS practices. A well-designed and executed set of policies and procedures can help build confidence in the target's management of FOSS risk and may sway acquirers considering whether to conduct a commercial scan. The absence of such policies and procedures typically invites additional scrutiny.
Preparation for Transactions
Preparing FOSS disclosures requires technical knowledge of how FOSS is being used by the target and within the target's products, and will require the participation of the target's engineers. The transaction diligence period is typically compressed, in most cases lasting only a matter of weeks, and can be incredibly taxing on targets, which are often tasked with disclosing enormous amounts of information about their business and products. Compiling this information in such a compressed time period can be a significant undertaking, further taxing the target's already strained resources, and inevitably leads to errors and omissions. Such errors and omissions typically prompt additional scrutiny, sometimes result in the target absorbing additional risks and costs, and can even lead to an acquirer abandoning the transaction. Further, remediating potentially high-risk FOSS use often requires considerable re-engineering of the product, which cannot be completed during the typical diligence period.
By adopting appropriate policies and procedures for managing and tracking the use of FOSS, targets can avoid unnecessary complications in the transaction process. The most cost-effective and efficient FOSS policies and procedures for a particular target depend on a number of factors, including, for example, the target's business model, distribution methods, resources, personnel, organization, and product development methods. Indeed, the right policies and procedures for a company often change as the company grows and evolves. However, at an absolute minimum, every target should be prepared to provide the FOSS disclosures that will be required in nearly every transaction.