Grappling with GPL: Managing Open Source Software Licensing Risk | Practical Law

Grappling with GPL: Managing Open Source Software Licensing Risk | Practical Law

A Legal Update discussing open source software (OSS) and associated licensing risks, particularly under the GNU General Public License (GPL) 2.0 and other restrictive OSS licenses. This Update includes practice tips for addressing OSS licensing risk both in internal business operations and in mergers and acquisitions (M&A transactions) in the software industry.

Grappling with GPL: Managing Open Source Software Licensing Risk

Practical Law Legal Update 7-604-7205 (Approx. 6 pages)

Grappling with GPL: Managing Open Source Software Licensing Risk

by Practical Law Intellectual Property & Technology
Law stated as of 17 Mar 2015 • USA (National/Federal)
A Legal Update discussing open source software (OSS) and associated licensing risks, particularly under the GNU General Public License (GPL) 2.0 and other restrictive OSS licenses. This Update includes practice tips for addressing OSS licensing risk both in internal business operations and in mergers and acquisitions (M&A transactions) in the software industry.
Open source software (OSS) has gained increasingly widespread acceptance and use in recent years as an alternative or supplement to proprietary software. A 2014 survey by a leading OSS audit and consulting services provider found that over 50% of corporate enterprises across all industries are expected to adopt and contribute to OSS (Black Duck Software: Future of Open Source 2014).
In recent years there has also been a shift in the OSS community away from more restrictive, or "copyleft," OSS licenses, a welcome trend for both IT managers and legal counsel. Most notably:
  • The most restrictive OSS license, GNU General Public License (GPL) 2.0, which alone accounted for nearly half of all OSS licenses in 2010, dropped to 27% of OSS licenses in 2014.
  • The three most permissive OSS licenses (Apache License 2.0, BSD License 2.0 and MIT License) collectively accounted for over 37% of OSS licenses in use in 2014, compared to just 14% in 2010.
  • Subsequent versions of GNU licenses, including GPL 3.0 and the GNU Affero GPLv3 (Affero GPL), have not been adopted as widely as GPL 2.0, with GPL 3.0 increasing by just 5% from 2010 to 11% of OSS licenses, and the Affero GPL accounting for less than 1% of OSS licenses in 2014.
(See Black Duck Software: Top 20 Open Source Licenses and Practice Note, Open-source Software: The OSS Licenses.)
Restrictive licenses, however, still dominate the OSS licensing world overall, and GPL 2.0 is still the most commonly used OSS license. In both daily business operations and any merger or acquisition (M&A transaction) involving a company in the software industry, IT managers and counsel must understand:
  • How OSS is used by a company, particularly in connection with its proprietary software products or services.
  • The nature (restrictive or permissive) of the licenses governing any OSS used or proposed to be used.
  • The obligations imposed by the applicable OSS licenses.
A company's failure to understand the terms of OSS licenses and the consequences of use of OSS governed by restrictive licenses places it at risk of:
  • Loss of operational flexibility for developing and using certain types of software.
  • Contract and copyright infringement liability.
  • Loss of valuable intellectual property (IP) rights.

Restrictive versus Permissive OSS Licenses

While OSS is typically made publicly available without charge, this does not mean its use is unrestricted or in the public domain. The OSS developer or community of developers retains copyrights in the software and licenses it under terms and conditions that may be characterized as permissive or restrictive, depending on the form of license.
Permissive OSS licenses:
  • Are intended to be compatible with commercial proprietary software licenses.
  • Typically require only that any distribution of the original licensed OSS be on the same license terms.
  • Permit modification of the OSS code and combination of the OSS code with commercial proprietary code, in each case without placing licensing restrictions or other significant obligations on the modified or combined code, other than copyright notice and attribution requirements.
In contrast, restrictive, or "copyleft," OSS licenses impose significant obligations on the use, modification and distribution of the licensed code. For example, the GPL 2.0 requires that any derivative work based on the GPL 2.0 licensed code, including any commercial proprietary software incorporating the licensed OSS code, must:
  • Be licensed as a whole at no charge to all third parties under the terms of the GPL 2.0 license and with no additional restrictions on use, copying or modification other than what is in the GPL 2.0.
  • If distributed in object code, allow the recipient to obtain a copy of the complete corresponding source code, including the source code for any commercial proprietary portions containing the GPL 2.0 licensed code.
Most restrictive licenses impose source code distribution requirements on distribution of a copy of the software itself. However, at least one copyleft license, the Affero GPL, requires the user to offer the source code under the Affero GPL to anyone to whom the software's functionality is made available as a network service, for example, under a software as a service (SaaS) model.
Depending on how the OSS code is combined with the licensee's commercial proprietary code, these restrictive license obligations can have significant adverse consequences on:
  • The licensee's commercial exploitation of its proprietary software.
  • The trade secret status of the source code for the licensee's proprietary software.
For a discussion of the common terms and legal risks associated with restrictive OSS licenses, see Practice Note, Open-source Software Licenses: Key Terms and Conditions.

OSS Policy

IT managers and their legal counsel need to allow companies to make beneficial use of OSS while minimizing the associated licensing risks. Implementation of an OSS policy that sets out procedures for the selection, approval and use of OSS is crucial to attaining this goal.
At a minimum, an OSS policy should require:
  • Disclosure to management of any current or proposed use of OSS and the associated OSS licenses, including the version number.
  • Management oversight and approval of employees' or third-party developers' use of OSS, particularly any:
    • integration with or use in development of the company's proprietary software;
    • modifications made to OSS used in or in the development of the company's proprietary software; or
    • redistribution of OSS or modifications to OSS, or the distribution or delivery of any software, product or service derived from, containing or using the OSS or modifications to OSS, to customers or other third parties.
  • Legal review and approval of the applicable OSS licenses.
  • Procedures for ensuring compliance with the terms of the applicable OSS licenses, including any notice and attribution requirements.
  • Procedures for monitoring compliance with the OSS policy, including regular, periodic audits.
  • Protocol and procedures for remediation of any unapproved use of OSS or other violation of the OSS policy, including if necessary modification or removal of OSS from the company's proprietary software.
For the OSS policy to be effective, the company must ensure that all employees and agents who use or approve OSS on its behalf have access to, understand and timely implement the policy and its OSS approval procedures. Effective OSS policy management typically requires:
  • Coordination of the company's technical personnel, legal advisers and management.
  • Appointment of an OSS compliance officer or committee to oversee this function.
For a model OSS policy concerning these and other provisions and integrated notes with explanations and drafting tips, see Standard Document, Open Source Software Policy.
For a discussion of key issues and practical tips for companies to consider to effectively govern use of open-source software, see Practice Note, Open-source Software: Use and Compliance.

M&A Transactions in the Software Industry

A proposed acquisition of a company in the software industry requires careful consideration of the target's use of OSS. Depending on the target's use of OSS and the nature (restrictive or permissive) of the applicable OSS licenses, the target's use of OSS can:
  • Cause its software assets to be overvalued.
  • Compromise the rights in any proprietary software the target develops or integrates with the acquired OSS.
  • Result in potential contract or copyright infringement liability.
  • Require costly and time-consuming remediation steps.
A buyer must address these risks through due diligence and representations in the purchase or merger agreement.

OSS Due Diligence

A legal due diligence review of a target company's IP assets and liabilities should include an evaluation of:
  • The nature and extent of the target's use of OSS, including for the target's:
    • internal IT operations; and
    • proprietary products and services.
  • The nature (restrictive or permissive) of the licenses governing the target's use of OSS.
  • The target management's and counsel's awareness of OSS licensing risks.
  • The target's policies and practices relating to OSS.
  • The target's compliance with the terms of OSS licenses.
  • For each item of OSS identified by the seller that is subject to a GPL or other restrictive OSS license, whether:
    • the target has incorporated the OSS (or any modifications to the OSS) or distributed it with any of the target's proprietary software or IT products;
    • the OSS provides material functionality;
    • the OSS is used in modified or unmodified form;
    • the OSS code is linked statically or dynamically with the target's proprietary code; and
    • the OSS can be removed or replaced with proprietary or third-party commercial software and, if so, the estimated time, cost and level of effort associated with these remediation steps.
A comprehensive due diligence review of the target's OSS and associated risks typically requires coordination with the seller's and buyer's IT personnel or external IT consultants.
For a Checklist of OSS and other software and IT issues to be covered in a legal due diligence review involving a company in the software industry, see Software, Cloud & Other IT Due Diligence in Mergers and Acquisitions Checklist.

OSS Representations and Warranties

If the due diligence review reveals that the target has made significant use of OSS, the buyer should seek to add provisions to the M&A transaction agreement to address the associated legal and business risks.
M&A agreements in the software industry typically include representations focusing on the target's:
  • Compliance with applicable OSS licenses, including attribution requirements.
  • Use of OSS in a manner that could jeopardize the commercial exploitation or proprietary status of the target's software products, including any use that results in an obligation for the target to:
    • distribute or otherwise make available the source code for any of the target's proprietary software; or
    • license any proprietary software product or service on a royalty-free basis.
For model representations and warranties addressing OSS issues for M&A transactions in the software industry, see Standard Clauses, Software and IT Representations and Warranties: Section 2(c).
For a sample of OSS and other software and IT representations and warranties in recent private acquisition agreements and public merger agreements in the software industry, see Practice Note, What's Market: M&A Agreements in the Software Industry: Sample IT Representations and Warranties.