Open Source Licensing and Compliance

Open source software (OSS) is no longer the domain of hobbyist developers and niche technical projects — it is the foundational infrastructure of global software development. The 2024 Synopsys Open Source Security and Risk Analysis (OSSRA) report finds that 96% of commercial codebases examined contain open source components, with the average codebase comprising 77% open source code by volume. This pervasive adoption creates profound legal, security, and governance challenges: every open source component carries a license that imposes legal obligations on the software that uses it, and failing to comply with those obligations creates intellectual property infringement risk, litigation exposure, and reputational damage.

Open source licensing is a specialized area of intellectual property law that operates through the mechanism of copyright. OSS licenses are copyright licenses — the copyright holder grants specified permissions to use, copy, modify, and distribute the software, subject to conditions. Different licenses impose very different conditions, ranging from the minimal attribution requirements of permissive licenses (MIT, Apache 2.0, BSD) to the powerful "copyleft" obligations of viral licenses (GPL, AGPL) that require derivative works to be licensed under the same terms. Understanding these obligations — and the consequences of violating them — is essential for anyone building commercial software that incorporates open source components.

The stakes of OSS compliance have increased dramatically in recent years due to three converging forces: first, the proliferation of high-profile copyleft enforcement litigation and pre-litigation demands; second, US federal mandates for Software Bill of Materials (SBOM) disclosure following major supply chain security incidents; and third, the EU Cyber Resilience Act's mandatory SBOM and vulnerability disclosure requirements. This topic provides a comprehensive guide to open source licensing categories, copyleft obligations, compliance risk management, SBOM requirements, and building an enterprise OSS governance program.

OSS licenses fall into three principal categories based on the obligations they impose on those who use, modify, and distribute the licensed software. Understanding these categories — and the specific terms of the most widely used licenses within each — is the foundation of any OSS compliance program.

Permissive licenses impose minimal obligations on users and distributors, making them highly compatible with commercial software development. The MIT License (one of the most widely used OSS licenses globally) requires only that the original copyright notice and license text be included in all copies and substantial portions of the software. The BSD 2-Clause License is substantially similar to MIT; the BSD 3-Clause adds a clause prohibiting the use of the original developers' names to promote derived products. The Apache License 2.0 adds two important provisions not found in MIT/BSD: an express patent grant (the licensor grants recipients a perpetual, irrevocable patent license for any patents covering the licensed code) and a patent retaliation clause (the patent grant terminates if a recipient initiates patent litigation against the licensor). The Apache 2.0 patent grant makes it particularly suitable for use in commercial products where patent exposure is a concern.

Copyleft licenses are built on the "share-alike" or "reciprocal" principle: anyone who distributes a modified version of a copyleft-licensed work must license their modifications under the same (or compatible) copyleft license. This requirement — often called the "viral" effect — is the most important compliance risk in commercial software development. The GNU General Public License (GPL v2, v3) is the archetype of strong copyleft: it requires that any derivative work — meaning any work based on or incorporating GPL-licensed code — must be licensed under the GPL when distributed. The GPL does not prohibit commercial use of GPL software; it restricts the terms on which the software can be redistributed. The GNU Affero General Public License (AGPL v3) extends GPL's copyleft to network use: if you run a modified AGPL-licensed program on a server and allow users to interact with it over a network, you must make the source code available to those users — a critical distinction for SaaS companies that deploy open source software in cloud services.

The GPL family of licenses — developed by the Free Software Foundation (FSF) — represents the most widely encountered and most legally significant copyleft licenses in commercial software development. Understanding precisely what constitutes a "derivative work" under the GPL, when the copyleft obligation is triggered, and what compliance requires is essential for any organization developing software that might incorporate GPL-licensed components.

Under GPL, the copyleft obligation is triggered by distribution — if you distribute software that incorporates GPL-licensed code (whether modified or unmodified), you must distribute the entire combined work (or at minimum a written offer to provide the source code) under the GPL. The most contentious area of GPL interpretation is what constitutes a "derivative work" or "combined work" — the FSF's position is that any program linked to a GPL library (whether at compile time or runtime) is a derivative work and must be licensed under the GPL. Others argue that mere application programming interface (API) interaction does not create a derivative work. This unresolved legal question has practical implications for commercial software that interacts with GPL-licensed components.

The LGPL (Lesser GPL) was specifically created to address the linking question for libraries: LGPL v3 allows the library to be used as part of a larger work without triggering copyleft, provided the library is used "through its normal interface" and the user retains the ability to replace the LGPL-licensed library with a modified version (practical in dynamic linking, difficult in static linking). Modifications to the LGPL-licensed library itself must still be released under LGPL. The AGPL's extension of copyleft to network use is particularly significant for cloud computing: a company running a modified version of an AGPL-licensed application as a SaaS service must make the source code of the modified application available to users of that service — a requirement that is fundamentally incompatible with most proprietary SaaS business models and has made AGPL a controversial license for commercial developers.

OSS compliance failures create several distinct categories of legal risk that organizations must understand and manage. The first and most common is license conflict: combining OSS components under incompatible licenses in a single software product. The most significant incompatibility is between GPL-licensed code and proprietary (all-rights-reserved) code — you cannot distribute a combined work containing both. Similarly, GPL v2 and GPL v3 are technically incompatible without special permissions; Apache 2.0 is incompatible with GPL v2 (due to the Apache 2.0 patent termination clause, which GPL v2 does not permit additional restrictions). Organizations must track the licenses of all OSS components and analyze compatibility before incorporating components into products intended for distribution.

Source code disclosure obligations are the second major compliance risk, particularly for companies distributing products containing copyleft-licensed code. The GPL requires providing complete corresponding source code — not just the modified open source components, but the complete source code of the entire combined work — to recipients of the binary distribution, either alongside the binary or through a written offer valid for three years. Failure to provide source code when required is a copyright infringement, which carries significant statutory damages potential in the US and similar remedies in other jurisdictions. The Linux kernel (GPL v2) is the most significant example — any device that ships with a modified Linux kernel (consumer electronics, network equipment, embedded systems) must comply with GPL v2 source disclosure requirements, and enforcement organizations like the Software Freedom Conservancy actively pursue compliance through litigation when companies fail to comply.

Patent exposure is the third category of OSS compliance risk. Several OSS licenses include explicit patent grants (Apache 2.0, GPL v3, MPL 2.0) that grant recipients rights under the licensor's patents covering the licensed code. Correspondingly, patent retaliation clauses (in Apache 2.0, GPL v3) terminate these grants if the recipient initiates patent litigation against the licensor. Organizations should understand the patent implications of the licenses they use and ensure that their OSS license policy accounts for patent grant and retaliation clause interactions.

The Software Bill of Materials (SBOM) is a machine-readable, structured inventory of all software components in a given product or application — including OSS components, third-party commercial libraries, and proprietary code — along with their version numbers, licenses, and provenance. The SBOM concept, long advocated by security researchers, became a federal mandate following US Executive Order 14028 on Improving the Nation's Cybersecurity (May 2021), which directed federal agencies to require SBOMs from software vendors supplying software to the US government.

Two primary SBOM standards have emerged: SPDX (Software Package Data Exchange), an ISO standard (ISO 5962:2021) developed under the Linux Foundation, which provides a comprehensive format for expressing component information, license data, and relationships; and CycloneDX, developed by the OWASP Foundation, which emphasizes security and is particularly well-suited to vulnerability management use cases. The US National Telecommunications and Information Administration (NTIA) has published minimum SBOM elements: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp.

The EU Cyber Resilience Act (CRA), adopted in 2024 and applicable from 2027, mandates SBOM creation and maintenance for all products with digital elements sold in the EU market — a sweeping requirement that will affect every hardware and software manufacturer with EU market access. The CRA also imposes vulnerability disclosure obligations: manufacturers must notify ENISA (European Union Agency for Cybersecurity) within 24 hours of discovering actively exploited vulnerabilities in their products. Combined with the US EO 14028 SBOM mandate (for federal software suppliers) and CISA's continued development of SBOM frameworks, SBOM generation and management is rapidly becoming a baseline requirement for responsible software development globally.

An effective enterprise OSS governance program is a systematic framework for managing all aspects of OSS use throughout the software development lifecycle — from initial selection and approval through ongoing monitoring, compliance, and contribution. The goal is not to prohibit OSS use (which would be counter-productive and commercially impossible given OSS's ubiquity) but to ensure that OSS is used responsibly, legally, and securely.

The core components of an OSS governance program include: an OSS policy (defining approved licenses, prohibited licenses, processes for evaluating new components, contribution policies, and escalation procedures); an automated scanning and analysis process (integrating Software Composition Analysis tools — Snyk, Black Duck, FOSSA, WhiteSource, Mend — into the CI/CD pipeline to automatically identify OSS components, their licenses, known vulnerabilities, and policy violations with every code build); an SBOM generation process (automatically generating SBOM artifacts in SPDX or CycloneDX format for each product release); an OSS inventory and registry (maintaining a current inventory of approved OSS components, their versions, and licenses); an obligation management process (tracking and ensuring fulfillment of license obligations — attribution notices, source code disclosure offers); and an OSS contribution governance process (managing when and how employees contribute to open source projects, including intellectual property assignment and CLA/DCO compliance).

The Contributor License Agreement (CLA) and Developer Certificate of Origin (DCO) are two mechanisms for managing intellectual property rights in OSS contributions. A CLA is a legal agreement between the contributor and the project maintainer under which the contributor grants the maintainer rights to use, modify, and relicense the contribution — CLAs are used by major projects including the Linux Foundation projects, Apache Software Foundation projects, and Google's open source projects. The DCO is a lighter-weight alternative that requires contributors to certify (by adding a "Signed-off-by" line to commits) that they have the right to make the contribution under the project's license — used by the Linux kernel and many other projects. Organizations must have processes for both signing CLAs when employees contribute to external projects and obtaining CLAs/DCOs when accepting contributions to internally maintained open source projects.

Understanding OSS license obligations in the abstract is necessary but insufficient — effective compliance requires applying those obligations to specific software development scenarios. Several practical scenarios illustrate the compliance challenges and appropriate responses most commonly encountered in commercial software development.

Scenario 1: Building a commercial product incorporating GPL v3 code. If a company incorporates GPL v3-licensed code into a commercial product distributed to customers (on-premise software, firmware, embedded systems), the entire combined work must be made available under GPL v3. The practical solutions are: replace the GPL component with a permissively-licensed alternative; negotiate a commercial license from the GPL software vendor (many OSS projects with commercial licenses offer this dual-licensing model, including Qt, MySQL, MongoDB, and many others); or accept the GPL compliance obligation and provide source code as required.

Scenario 2: Running AGPL-licensed software as a SaaS service. If a company deploys a modified version of AGPL-licensed software (e.g., a modified version of an AGPL-licensed analytics tool) on its servers and makes the application available to users over the network, the AGPL requires that those users be able to download the complete source code of the modified application. For most commercial SaaS companies, this obligation is fundamentally incompatible with their business model. The solutions are the same as GPL scenarios: replace with a permissive alternative, obtain a commercial license, or comply with AGPL source disclosure.

Scenario 3: A newly acquired company's codebase contains unlicensed OSS. In M&A due diligence, undisclosed or non-compliant OSS use is a significant risk factor. Buyers should require comprehensive SCA scanning as part of technical due diligence, with results reviewed by IP counsel before closing. Post-acquisition remediation of copyleft-violated codebases can be technically complex, expensive, and time-consuming — identifying this risk pre-closing enables price adjustment, escrow, or indemnification provisions to account for the remediation cost and litigation exposure.

Q: Can I use MIT-licensed software in a commercial product without releasing my source code? A: Yes. MIT-licensed software requires only attribution — you must include the original copyright notice and MIT license text in your software distribution (typically in a NOTICES or LICENSE file). You are not required to release your own source code. This makes MIT one of the most commercial-friendly open source licenses. Apache 2.0 has similar requirements but also includes an express patent grant and requires you to preserve any NOTICE file content from the original software.

Q: What is the GPL "linking" question, and why does it matter? A: The GPL's copyleft obligation extends to "derivative works" of GPL-licensed code. The unresolved legal question is whether software that merely links to (calls functions from) a GPL-licensed library creates a derivative work that must also be licensed under GPL. The FSF's position is that any linking (static or dynamic) creates a derivative work. Courts have not definitively resolved this question in the US. In practice, most commercial software counsel treat the FSF's position as the legally conservative approach and avoid linking commercial proprietary code with GPL-licensed libraries, using LGPL alternatives where available.

Q: What is the difference between OSS vulnerabilities and OSS license compliance? A: OSS license compliance (the focus of this topic) is about legal obligations — ensuring that using a licensed OSS component does not create copyright infringement or breach of license terms. OSS vulnerability management is a security concern — ensuring that OSS components do not contain known security vulnerabilities (CVEs) that could be exploited. Both are addressed by Software Composition Analysis (SCA) tools, but they represent distinct risk categories. A component can be license-compliant but contain critical vulnerabilities, or license-problematic but security-clean. Both must be managed in a comprehensive OSS governance program.

Q: Is an SBOM required for all software? A: Currently, SBOM requirements apply to: software vendors supplying software to US federal government agencies (under EO 14028 and CISA guidance); medical device manufacturers (FDA guidance on cybersecurity requires SBOMs for software in devices); and (from 2027) products with digital elements sold in the EU under the Cyber Resilience Act. Many organizations are proactively generating SBOMs regardless of regulatory requirements as part of supply chain security and customer transparency initiatives. The trend toward mandatory SBOM is clearly toward broader applicability across industries and jurisdictions.

Q: How do we handle OSS when acquiring a company? A: OSS due diligence in M&A should include: comprehensive SCA scanning of all acquired codebase to identify all OSS components and licenses; legal analysis of copyleft obligations and any GPL/AGPL compliance failures; review of any historical enforcement actions or third-party IP claims; assessment of SBOM maturity and OSS governance program adequacy; and evaluation of any OSS components with known critical vulnerabilities. IP counsel specializing in open source should be involved in reviewing SCA results and assessing materiality. Significant OSS compliance issues should be addressed through purchase price adjustment, representations and warranties, indemnification, or post-closing remediation plans.