Every open-source dependency you install carries a license — a contract, not a formality. Permissive licenses (MIT, Apache 2.0, BSD) impose almost no obligations. Weak-copyleft licenses (LGPL, MPL) require sharing changes to the library itself, not your application. Strong-copyleft licenses (GPL, and especially AGPL) can require sharing your own source code, sometimes even without distributing a binary.
Software composition analysis exists for two reasons, not one. Vulnerability scanning gets most of the attention, but the live market for SCA tools defines the category around "vulnerabilities and licensing compliance" together — see our SCA tools comparison for how the two capabilities split across vendors. Licensing is the quieter half, and it's easy for an engineering team to ship a dependency tree nobody actually reviewed for license obligations.
Accuracy note: every license classification and quote below is sourced to the license text itself, the SPDX License List, the Open Source Initiative's approved licenses, or the Free Software Foundation's license list. This is engineering guidance, not legal advice — a specific license-combination question for your product should go to counsel, not a blog post.
The Three License Risk Tiers
Dependency licenses fall into three practical risk tiers, and the tier — not the license name alone — is what should drive your review process. This is the same tiering GeekWala's license checker uses to classify a scanned manifest.
Permissive. MIT, BSD (2-clause and 3-clause), and Apache 2.0 let you use, modify, and redistribute the code with minimal conditions — typically just preserving the copyright notice. You can ship permissively-licensed code inside a closed-source commercial product without releasing your own source. The OSI's approved license list and the SPDX License List both classify these as permissive; the FSF's license list separately confirms Apache 2.0 as "a free software license, compatible with version 3 of the GNU GPL."
Weak-copyleft. The LGPL and the Mozilla Public License (MPL) require that changes to the licensed library itself be shared if you distribute the modified library, but they generally don't extend that requirement to the rest of your application, provided you link to the library rather than statically embed its modified source. The boundary between "linking" and "embedding" is exactly the kind of specific-combination question that needs a real license review, not a general guide.
Strong-copyleft. The GPL (versions 2 and 3) and the AGPL are the licenses that can require you to release your own source code, not just the dependency's. The condition that triggers this, and specifically what counts as "distribution," is where most of the practical risk lives — covered next.
Is AGPL Safe for Commercial Use?
This is the single most consequential license question a SaaS team can ask, because the answer differs from ordinary GPL in a way that matters specifically for hosted software.
The regular GNU GPL's copyleft obligation is triggered by distribution — historically read as shipping a binary or source copy to someone else. A company can run a modified GPL-licensed program on its own servers, offer it to users over the internet, and never trigger the GPL's source-sharing requirement, because nothing was ever "distributed" in the traditional sense. This is sometimes called the "SaaS loophole" or "ASP loophole."
The GNU AGPLv3 license text closes that loophole directly. Its Section 13 ("Remote Network Interaction") requires that if you modify an AGPL-licensed program, your modified version "must prominently offer all users interacting with it remotely through a computer network... an opportunity to receive the Corresponding Source" — meaning the obligation to share source can trigger the moment you run a modified version as a network service, whether or not you ever distribute a binary.
Practically: using an unmodified AGPL-licensed dependency as a library inside your product is a materially different question from modifying AGPL-licensed code and operating it as your product's backend. Whether your specific usage counts as a "modified version" under Section 13, and what "Corresponding Source" means for your architecture, is exactly the kind of question this article cannot answer for your specific codebase — verify against the license text and your own counsel before shipping AGPL-licensed code as part of a commercial SaaS backend.
MIT vs Apache 2.0: What Actually Differs
Both are permissive and both let you build closed-source commercial products on top of the licensed code, so the practical difference is narrower than the two-license comparison implies — but one clause matters for larger organizations.
The Apache License 2.0 text includes an explicit patent grant in Section 3: each contributor grants licensees "a perpetual, worldwide, non-exclusive, no-charge, royalty-free... patent license" covering their contributions, and that grant terminates automatically if the licensee initiates patent litigation against a contributor over the work. The MIT License contains no equivalent patent clause at all — it's a shorter, older license that predates the modern emphasis on explicit patent grants.
For a small team, this rarely changes a decision. For an organization with its own patent portfolio, or one integrating code from a company it might someday be in patent disputes with, Apache 2.0's explicit patent grant (and defensive termination clause) is a real, sourced difference — not a marketing distinction between two otherwise-identical licenses.
GPL in a SaaS Product
Because the ordinary GPL's obligation is distribution-triggered rather than network-triggered, using a GPL-licensed tool in your build pipeline (a linter, a test runner, a compiler) generally doesn't create an obligation on your product's source at all — you're not distributing the tool, you're using it to build something else. The higher-risk pattern is linking GPL-licensed code into your running application: if your SaaS backend statically links or directly incorporates GPL-licensed library code, and you ever distribute that combined work (including, depending on interpretation, via container images pushed to a registry a customer pulls from), the GPL's copyleft can extend to your own code. AGPL removes even the distribution requirement, as covered above. Again: this generalization is not a substitute for reviewing your specific dependency tree and deployment architecture against the actual license text.
How to Audit Your Dependency Licenses
- Generate a full dependency inventory, direct and transitive — not just your top-level
package.jsonorrequirements.txt. Most license risk hides in transitive dependencies nobody consciously chose. GeekWala's SBOM generator produces a CycloneDX or SPDX bill of materials from a manifest or lockfile for exactly this — submit a lockfile to include the transitive packages. - Classify each license by tier (permissive / weak-copyleft / strong-copyleft) using the SPDX License List as your canonical identifier source — or run the manifest through GeekWala's free license checker, which does this classification automatically for the first 10 packages in a check.
- Flag anything strong-copyleft for manual review, especially AGPL, and especially anything linked into your running service rather than used only at build time.
- Build a license compatibility matrix for your specific stack if you combine multiple copyleft licenses — GPL-compatibility rules are license-pair-specific (the FSF's license list documents GPL-compatibility per license), and combining two copyleft licenses that aren't mutually compatible is its own distinct problem from either license alone.
- Re-run the audit on every dependency upgrade, not just once. A minor version bump can change a package's declared license — it has happened industry-wide when maintainers relicense a project.
Frequently Asked Questions
Can I use an MIT-licensed package in a closed-source commercial product?
Yes. MIT is one of the most permissive licenses available — the OSI and SPDX both classify it as permissive, requiring only that you preserve the copyright and license notice. This is general guidance, not a legal opinion on your specific product.
Does using a GPL-licensed build tool (not a library) affect my product's license?
Generally no — a build-time tool (compiler, linter, bundler) that isn't itself distributed or linked into your shipped product typically doesn't extend its own license terms to your output. This is a common pattern, not a loophole, but confirm the specific tool's license doesn't contain unusual output-licensing clauses before relying on it.
What's the fastest way to check a package's license before adding it?
Run your manifest through GeekWala's license checker — it's free, requires no signup, and returns a permissive/weak-copyleft/strong-copyleft risk tier instantly for each of the first 10 packages, sourced against SPDX license identifiers.
License risk and vulnerability risk are triaged separately but both feed the same "should this dependency stay in my tree" decision — see Reachability vs EPSS for how to prioritize the vulnerability side once the license side is clear.
This article is an engineering explainer, not legal advice. License compliance decisions for your specific product and deployment architecture should be verified against the license texts linked above and, where the stakes justify it, your own counsel.
Ready to see what's actually in your dependency tree? Check your dependency licenses for free — no account required.
