Open source licenses are the legal contracts that govern how you can use, modify, and distribute open source software. Unlike most contracts, you agree to them by using the software — there is no signature required. This makes it dangerously easy to violate license terms without realizing it.
In 2022, with the average application containing hundreds of open source components, license compliance has become both more important and more complex. This guide cuts through the legal jargon and gives you practical guidance for the most common licensing scenarios.
Why License Compliance Matters
The consequences of non-compliance are real:
- The Free Software Foundation actively enforces GPL compliance. Companies have been forced to release proprietary source code or pay settlements after incorporating GPL-licensed code into commercial products.
- In 2021, the Software Freedom Conservancy filed a lawsuit against Vizio for alleged GPL violations in their smart TV firmware — the first GPL enforcement action targeting a device manufacturer on behalf of end users.
- Acquisitions and IPOs routinely include open source license audits. License compliance issues discovered during due diligence have derailed deals worth millions.
The License Spectrum
Open source licenses exist on a spectrum from highly permissive to strongly copyleft:
Permissive Licenses
MIT License: The most popular license on GitHub. You can do almost anything with MIT-licensed code as long as you include the copyright notice and license text.
Apache License 2.0: Similar to MIT but adds an explicit patent grant and requires you to state significant changes made to the code.
BSD Licenses (2-Clause, 3-Clause): Permissive like MIT, with the 3-Clause version adding a restriction against using the author's name for endorsement.
What you need to do: Include the license text and copyright notice in your distribution. That is essentially it.
Weak Copyleft
LGPL (Lesser General Public License): You can link to LGPL-licensed libraries from proprietary code without triggering copyleft obligations, but modifications to the LGPL-licensed library itself must be released under LGPL.
MPL 2.0 (Mozilla Public License): File-level copyleft — if you modify an MPL-licensed file, those modifications must be released under MPL, but other files in your project can remain proprietary.
What you need to do: Keep the licensed components in separate files/libraries. Release modifications to the licensed code. Include license text.
Strong Copyleft
GPL v2 and v3: If you distribute software that includes GPL-licensed code, you must release the entire combined work under GPL. This means making your source code available to anyone who receives the binary.
AGPL v3: Like GPL but extends to network use — if users interact with AGPL-licensed software over a network (e.g., a web application), you must make the source available to those users.
What you need to do: Either release your entire project under the same copyleft license, or architect your software to avoid triggering the copyleft obligation (dynamic linking with LGPL, separate processes for GPL, etc.).
Common Compliance Mistakes
Mistake 1: Ignoring Transitive Dependencies
Your application might not directly depend on any GPL-licensed code, but what about your dependencies' dependencies? A GPL-licensed component buried three levels deep in your dependency tree has the same legal implications as one you imported directly.
your-app (MIT)
└── useful-library (MIT)
└── helper-module (MIT)
└── crypto-wrapper (GPL-3.0) ← Problem!
Mistake 2: Confusing "Free" with "No Obligations"
MIT-licensed code is free to use, but you still have obligations. Specifically, you must include the copyright notice and license text. Stripping attribution from open source components is a license violation, even for the most permissive licenses.
Mistake 3: Copy-Pasting Code Without Checking the License
Stack Overflow answers, GitHub Gists, and blog posts all contain code with implicit or explicit licenses. Copying code from a GPL-licensed project into your codebase makes your codebase subject to GPL terms, regardless of how few lines you copied.
Mistake 4: Assuming License Compatibility
Not all open source licenses are compatible with each other. You cannot combine Apache-2.0 code with GPL-2.0-only code (though Apache-2.0 is compatible with GPL-3.0). Understanding license compatibility is essential when combining components.
Building a Compliance Program
Step 1: Inventory Your Components
You cannot comply with licenses you do not know about. Generate an SBOM for every application that includes license information:
# Using Syft to generate SBOM with license data
syft dir:. -o spdx-json > sbom.json
Step 2: Classify Your Licenses
Categorize every license in your SBOM into:
- Approved: Permissive licenses that align with your business model
- Conditional: Weak copyleft licenses that require specific architectural decisions
- Restricted: Strong copyleft licenses that conflict with your distribution model
- Unknown: Components without clear license information (treat as high risk)
Step 3: Implement Automated Checks
Use tools to automatically flag license issues in your CI/CD pipeline:
# Using cargo-deny for Rust
cargo deny check licenses
# Using license-checker for Node.js
npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"
Step 4: Create an Attribution Document
For distributed software, maintain a NOTICES or THIRD_PARTY_LICENSES file that includes the required attribution for every open source component you use.
Step 5: Establish a Review Process
New dependencies should be reviewed for license compatibility before they are added to the project. This does not need to be a heavyweight legal review — a developer checking the license field in package.json against your approved list is sufficient for most cases.
How Safeguard.sh Helps
Safeguard.sh automatically detects and classifies licenses across your entire dependency tree, including transitive dependencies. Our policy engine lets you define approved license lists and automatically blocks components with incompatible licenses from entering your codebase. With Safeguard.sh, license compliance becomes an automated guardrail rather than a manual audit process.