Open source license compliance is the practice of identifying every open source component in your software, understanding the license terms attached to each one, and meeting the resulting legal obligations — attribution, notice preservation, source disclosure, and more. It's the legal counterpart to security scanning: where vulnerability management asks "is this component dangerous?", license compliance asks "am I legally allowed to use it this way, and what must I do in return?"
Why License Compliance Is a Real Business Risk
Open source is free to use, but "free" is not the same as "no strings attached." Every open source component ships with a license — a legally binding grant of rights that comes with conditions. Ignore those conditions and the consequences are concrete: copyright infringement claims, court-ordered injunctions, forced public disclosure of proprietary source code, and — very commonly — a failed or delayed acquisition when due-diligence reviewers find unmanaged license risk.
That last scenario is where most companies feel the pain first. During mergers and acquisitions, technical and legal due diligence routinely includes a full open source audit. Discovering a strong copyleft license buried deep in a transitive dependency of a product being acquired can reduce the valuation, trigger costly remediation, or kill the deal. Because so much of a modern application is open source, and because most of those components arrive as transitive dependencies nobody chose deliberately, license risk accumulates silently until someone goes looking.
There's precedent for enforcement, too: organizations like the Free Software Foundation and gpl-violations.org have successfully pursued GPL compliance actions, establishing that these licenses carry real legal weight. For related definitions, see our concepts library.
The Categories of Open Source Licenses
Open source licenses generally fall into three buckets defined by how far their obligations reach:
| License category | Examples | Core obligation | Risk to proprietary code |
|---|---|---|---|
| Permissive | MIT, Apache 2.0, BSD | Preserve copyright notice & attribution | Low |
| Weak copyleft | LGPL, MPL 2.0, EPL | Share modifications to the licensed files | Medium |
| Strong copyleft | GPL, AGPL | Share the entire derivative work's source | High |
The critical concept is copyleft. Permissive licenses (MIT, Apache 2.0) let you use the code in proprietary software as long as you preserve attribution. Copyleft licenses require that if you distribute software incorporating the component, you must release your combined work under the same license — meaning your proprietary source could have to be published.
The AGPL (Affero GPL) deserves special attention: it extends copyleft obligations to software accessed over a network, closing the "SaaS loophole." A company that would never distribute GPL software may still trigger AGPL obligations simply by running AGPL code as a hosted service — a trap that catches many SaaS businesses off guard.
How License Compliance Works in Practice
Effective license compliance is a continuous, mostly automated process rather than a one-time legal review:
- Inventory. Discover every component — direct and transitive — and identify its declared license. This is where a software bill of materials (SBOM) becomes essential.
- Classification. Map each license to its category and obligations, flagging copyleft and unusual or custom terms.
- Policy evaluation. Compare each component's license against your organization's policy. A team shipping proprietary SaaS might allow MIT and Apache 2.0, flag LGPL for review, and block AGPL entirely.
- Obligation fulfillment. Generate the required attribution and notice files, preserve copyright statements, and document how obligations are met.
- Continuous monitoring. Because dependencies change with every build — and licenses can even change between versions of the same package — compliance must be re-checked on every scan.
A subtle risk is license changes: a package that was MIT-licensed at one version may adopt a more restrictive or non-open-source license in a later release, as several high-profile projects have done. Pinning to a version that later relicenses can quietly change your obligations.
Best Practices for 2026
- Maintain a current SBOM for every product so your component and license inventory is always answerable.
- Define a clear license policy stating which categories are approved, which need legal review, and which are prohibited.
- Automate enforcement in CI so a newly introduced GPL or AGPL dependency is flagged in the pull request, not in an acquisition audit.
- Track transitive licenses, since the riskiest obligations usually hide several layers deep.
- Watch for license changes across version upgrades, not just new dependencies.
- Generate attribution automatically to reliably satisfy notice requirements at release time.
How Safeguard Helps
Safeguard treats license compliance as a first-class output of dependency analysis, because the same scan that finds your vulnerabilities already knows every component and version you depend on. Our Software Composition Analysis identifies the declared license for each direct and transitive component and classifies it by obligation, so a strong-copyleft or AGPL dependency is surfaced the moment it enters your graph — including when a package changes its license in a new version.
Findings flow into SBOM Studio, which maintains a standards-compliant, always-current inventory (CycloneDX and SPDX) that doubles as your license record for compliance and due diligence. You can define policy directly — approve permissive licenses, flag weak copyleft for review, block strong copyleft — and enforce it in CI through the Safeguard CLI, so license risk is caught in the pull request instead of the boardroom.
Create a free account to audit your license exposure, or read the documentation to configure a license policy for your team.
Frequently Asked Questions
Is open source software really free to use however I want? No. Open source is licensed, not public domain. Each license grants specific rights in exchange for specific obligations — at minimum, preserving attribution, and in the case of copyleft licenses, potentially releasing your own source code. Using a component outside its license terms is copyright infringement.
What is copyleft, and why is it risky? Copyleft is a licensing condition requiring that derivative works be distributed under the same license as the original. For a company shipping proprietary software, incorporating strong-copyleft code (like GPL) into a distributed product can obligate you to publish your own source, which is why these licenses require careful review.
How does the AGPL differ from the GPL? The AGPL closes the "SaaS loophole." Standard GPL obligations are triggered by distributing software, so hosting GPL code as a web service traditionally avoided them. The AGPL extends the obligation to software accessed over a network, meaning you can trigger source-disclosure requirements just by running AGPL code as a hosted service.
Why do I need an SBOM for license compliance? Because most of your components are transitive dependencies you never explicitly chose, you can't manually track every license. An SBOM provides a complete, machine-readable inventory of every component and its license, making it possible to evaluate obligations automatically and prove compliance during audits or acquisitions.