Most security conversations about open-source dependencies are about vulnerabilities: which package has a CVE, how exploitable it is, when to patch. That is the right conversation to have, but it quietly ignores a second kind of risk that lives in the exact same dependencies and can be just as damaging to the business — the license. Every open-source component you pull in comes with legal terms attached, and some of those terms impose obligations that, if ignored, can force you to open-source your proprietary code, expose you to litigation, or blow up a due-diligence review right when you are trying to close an acquisition or a funding round.
The uncomfortable part is that most engineering teams have no idea what licenses they are actually shipping. They know their direct dependencies, maybe. They almost never know the licenses of the hundreds of transitive dependencies those pull in — the packages nobody chose, several layers down, any of which could carry a license that is incompatible with how the company distributes its software. The risk is invisible precisely because it lives in the parts of the dependency tree nobody looks at.
This article is for engineering and security leaders who understand dependency vulnerabilities but have not given the same attention to dependency licenses. We will explain why licenses are a genuine business risk and not a lawyer’s abstraction, how the major license categories differ (with copyleft as the one that matters most), why runtime packages specifically are where the risk concentrates, how license compliance connects to the SBOM and SCA work you may already be doing, and how to inventory and govern the licenses you ship. The aim is to make the invisible risk visible and manageable.
Why a license is a real risk, not a legal abstraction
Start with the thing that makes this concrete, because “license compliance” sounds like paperwork until you see what it can actually do to a company.
Open-source software is not public-domain, do-whatever-you-want software. It is copyrighted work that the author has licensed for use under specific terms. When you include an open-source package in your product, you are agreeing to those terms — whether or not anyone on your team read them. Most of the time the terms are permissive and the obligations are light. But some licenses impose conditions that can directly conflict with how a commercial software company operates. The consequences of getting it wrong fall into a few categories, and they are not theoretical:
- Forced source disclosure. Certain licenses require that if you distribute software incorporating the licensed component, you must make your own source code available under the same terms. For a company whose proprietary code is its core asset, being obligated to open-source it is close to an existential outcome. Teams have discovered, too late, that a single transitive dependency with the wrong license placed their entire proprietary codebase under a disclosure obligation.
- Litigation and injunction risk. License violations are copyright violations. Rights holders — including organizations that actively enforce open-source licenses — can pursue legal action, demand compliance, and in some cases seek injunctions that stop you from distributing your product until you comply.
- Blocked acquisitions and funding. This is where license risk most often becomes visible, and it is brutal timing. Technical and legal due diligence before an acquisition or a funding round routinely includes an open-source license audit. If that audit turns up a copyleft license improperly embedded in the proprietary product, the deal can stall, get repriced, or collapse while the issue is remediated. A problem that could have been managed quietly over months becomes a fire drill with a deal on the line.
- Attribution and notice obligations. Even permissive licenses usually require you to preserve copyright notices and include the license text. Failing to meet these lighter obligations is still a violation, and it signals to an auditor that your license hygiene is poor generally.
None of this requires a vulnerability or an attacker. The risk is purely legal and contractual, it is present the moment the dependency is included, and it compounds silently as the dependency tree grows. That is what makes it a genuine business risk rather than a compliance nicety — the downside is measured in disclosed source code and dead deals, not in a checkbox.
The license categories you need to understand
You do not need to be a lawyer to manage this, but you do need a working mental model of the main license categories and how they differ in what they demand. The spectrum runs from “do almost anything” to “and now your code is open too.”
Permissive licenses
Permissive licenses — MIT, Apache 2.0, BSD, and similar — impose minimal obligations. Broadly, they let you use, modify, and distribute the software, including in proprietary and commercial products, as long as you preserve the copyright notice and license text (and, for Apache 2.0, respect its patent and notice provisions). The large majority of popular open-source packages use permissive licenses, which is why dependency licensing is a manageable problem rather than an impossible one. If every component you shipped were MIT or Apache, license risk would be mostly about getting attribution right.
Weak copyleft
Weak copyleft licenses — the LGPL and Mozilla Public License are the common examples — sit in the middle. They generally require that modifications to the licensed component itself be shared back under the same license, but they allow the component to be used within a larger proprietary work without forcing that larger work to be open-sourced, provided certain conditions (often about how the component is linked or integrated) are met. The nuance in “certain conditions” is exactly why these licenses require attention: whether you trip the copyleft obligation can depend on technical details of how you incorporate the component.
Strong copyleft — the one that matters most
Strong copyleft licenses — the GPL family (GPLv2, GPLv3) and the AGPL most prominently — are the ones that can force source disclosure, and they are the reason license compliance is a serious discipline rather than a formality. The core principle of strong copyleft is reciprocity: if you distribute software that incorporates a strong-copyleft component, you must make the entire work’s source available under the same license. Embed a GPL component in your proprietary product and distribute it, and the license’s terms reach for your whole codebase.
The AGPL deserves special mention because it closes the loophole that mattered most to cloud and SaaS companies. Traditional GPL obligations are triggered by distribution — shipping the software to someone. A SaaS company that merely runs the software on its own servers and offers it as a network service was historically not “distributing” it, and so could use GPL components without triggering disclosure. The AGPL was written specifically to close that gap: it treats providing the software as a network service as a trigger for the source-disclosure obligation. For any company that delivers software as a hosted service — which is most of them now — an AGPL dependency is precisely the kind of thing that can force disclosure despite nothing ever being “shipped” in the traditional sense.
The practical upshot: permissive licenses are low-concern, weak copyleft needs a careful look at how you integrate the component, and strong copyleft — GPL and especially AGPL — is the category that can genuinely compromise your proprietary code and must be known about and governed deliberately. You cannot govern what you have not inventoried, which is the next problem.
Why runtime packages are where the risk lives
Not every dependency carries the same license risk, and understanding the distinction sharpens where to focus. The key split is between runtime dependencies and development/build dependencies.
A development dependency — a test framework, a linter, a build tool — is used to produce your software but is not shipped as part of it. Its license obligations are generally lighter in practice, because you are not distributing it or incorporating it into the product your customers run. A runtime dependency, by contrast, is part of the software that actually runs and that you deliver — whether shipped to a customer or run as a service they access. Runtime dependencies are the ones that get incorporated into the thing you distribute, and therefore the ones whose copyleft obligations can reach into your product.
This distinction matters enormously for prioritization. A GPL-licensed linter in your dev dependencies is a very different risk from a GPL-licensed library compiled into the service you run in production. The former you use; the latter you ship (or serve), and shipping is what triggers the serious obligations. So license compliance work should weight the runtime dependency tree most heavily — the packages that are present in the running artifact, the container image, the deployed service.
And runtime is exactly where the inventory problem bites hardest, because a runtime dependency tree is dominated by transitive packages. You chose a web framework; it pulled in dozens of runtime packages; those pulled in more. Any one of them, deep in the tree, could be AGPL. Nobody on your team selected it, reviewed its license, or is aware it is there — and yet it is running in production and incorporated into the service you offer. The licenses you are most legally exposed by are disproportionately the ones you are least aware of, because they live in the transitive runtime dependencies that are invisible without deliberate inventory.
License compliance is a dependency-inventory problem
Here is the reassuring part: managing license compliance is, mechanically, the same problem as managing dependency vulnerabilities, and the same tooling solves both. If you are already doing software composition analysis and generating an SBOM, you are most of the way there.
Software composition analysis (SCA) resolves your full dependency tree — direct and transitive — from manifests and lockfiles. The same resolution that lets it check each component against vulnerability databases also lets it read each component’s license. And a Software Bill of Materials (SBOM) — the structured inventory of every component you ship — records each component’s license as one of its core fields, precisely so that license questions can be answered from the inventory. License compliance and vulnerability management are two queries against the same underlying component inventory.
That reframes the whole thing from “a legal project” to “a reporting capability on data you can already collect.” Once you have a complete, current, per-component inventory with licenses attached, the compliance questions become answerable:
- What licenses are we actually shipping? Across all runtime dependencies, direct and transitive — the question most teams cannot answer today.
- Do we have any strong-copyleft licenses in the runtime tree? The GPL/AGPL scan that prevents the acquisition-killing surprise.
- Where exactly is each risky license? Which service, which dependency path, so you can assess and remediate (replace the component, isolate it, or get legal sign-off) deliberately rather than in a panic.
- Are our attribution obligations met? The lighter but still-required notices for permissive licenses.
The discipline that makes this work is the same as for SBOMs and vulnerability management: the inventory must be complete (down to transitive runtime dependencies), current (regenerated as dependencies change, because a dependency update can introduce a new license), and queryable (so “do we have any AGPL” is a search, not an audit). A license inventory generated once for a due-diligence checklist and never refreshed is as useless as a stale vulnerability scan — the risky dependency gets added next sprint and nobody notices until the next fire drill.
Governing licenses, not just inventorying them
Inventory is the foundation; governance is what turns it into actual risk reduction. A mature license-compliance posture does a few things beyond producing a list:
- Define an allowed/denied license policy. Decide, with legal input, which license categories are acceptable for runtime dependencies (typically: permissive is fine, weak copyleft needs review, strong copyleft is denied or requires explicit sign-off). Encode that as policy rather than relying on individual developers to know the rules.
- Check new dependencies against the policy at the pull request. The cheapest time to catch a disallowed license is before the dependency is merged — the same shift-left logic that applies to vulnerabilities. A developer adding an AGPL package should learn at the pull request that it violates policy, not discover it during an acquisition audit two years later.
- Keep the running inventory under continuous watch. Because dependency trees shift, continuous monitoring catches a newly-introduced risky license or a license change in an existing dependency (licenses do occasionally change between versions).
- Maintain exportable evidence. For due diligence, audits, and customer questionnaires, the ability to export a current license report from the inventory turns a months-long scramble into a few-minutes export.
Put together, this is the difference between license compliance as a reactive, panic-driven event (the acquisition audit finds a GPL component) and license compliance as a continuous, boring, well-governed property of your dependency pipeline (disallowed licenses never get merged, and the current report is always one click away).
How Cloudanix handles license compliance
The practices above work with any tooling that inventories dependencies and their licenses. Cloudanix Code Security is built so that license compliance is a natural output of the same scanning that handles vulnerabilities, rather than a separate legal project bolted on later.
Cloudanix SCA resolves your full dependency tree — direct and transitive — across major ecosystems and generates a CycloneDX SBOM per repository, with each component’s license recorded alongside its version and vulnerability status. That means the license inventory is produced automatically as part of scanning: the same resolution that finds your vulnerable packages also tells you which licenses you ship, so the strong-copyleft component buried in a transitive runtime dependency becomes visible rather than hiding until a due-diligence audit. Because the container scanning also inventories what is actually in the running image, license identification extends to runtime packages — the ones that are part of the artifact you deliver, which is exactly where copyleft obligations concentrate.
The payoff of having this on the same platform as the rest of your code and cloud security is that license risk is not a standalone silo. It sits in the same component inventory as your vulnerabilities and, through Cloudanix’s single asset graph, can be associated with the workloads that actually run the licensed code when the layers are connected for a service — so “we ship an AGPL component” can be refined to “this AGPL component runs in this service we offer as a hosted product,” which is precisely the fact pattern that triggers AGPL’s network-service disclosure obligation. The report that answers “what licenses are we shipping, and where are the risky ones” is exportable for due diligence, audits, and customer questionnaires.
One honest framing: Cloudanix identifies and inventories the licenses in your dependency tree and surfaces the risky categories; the decision about whether a given license is acceptable for your business is a legal judgment your organization makes. The tool makes the invisible risk visible and governable — it does not replace legal counsel’s assessment of your specific obligations.
If you want to see which licenses you are actually shipping, including the transitive runtime dependencies you have never inspected, connect a repository and look at the component inventory: book a free assessment.
