NEWSkillSec — elevating AI Skills security from malware detection to capability auditingSkillSecLearn more →
Deep Dive

The Open-Source License Risk Map: From MIT to AGPL, What to Fear and What Not To

Sectrend Research·2026.07.07·3 min read

There are more than two thousand open-source licenses, but what legal and engineering teams really need is one map, layered by contagion. Fear the wrong thing and you either kill velocity (banning all GPL) or let real risk through (shipping an AGPL component inside your SaaS).

Tier 1: Permissive — use freely, but don't forget attribution

MIT, BSD and Apache-2.0 are permissive: commercial use, modification and closed-source distribution are all allowed, and the obligations largely reduce to retaining copyright notices and license text. Apache-2.0 adds an explicit patent grant, which actually protects you. The real risk at this tier is not the license but the execution: a delivery with zero attribution — not even a NOTICE file — still gets flagged in customer due diligence. The most common problem we see in audits is teams stripping copyright headers off permissive code and passing it as proprietary — which snippet-level detection exposes instantly; see our guide to choosing an SCA tool.

Tier 2: Weak copyleft — contagious only if you touch it

LGPL, MPL-2.0 and EPL are weak copyleft: the boundary is the file or the library. Modify their files and you must open-source those changes, but your own code stays yours as long as the boundary stays clean. The engineering pivot is how you link and isolate — dynamically linking an LGPL component is usually safe, while static linking can pull your whole product into open-source obligations. Embedded and C/C++ projects are the danger zone, because static linking is the norm there.

Tier 3: Strong copyleft — distribution is the trigger

GPL-2.0/3.0 follows one simple, severe rule: once you distribute software containing GPL code, the entire derivative work must be released under GPL. Shipped commercial software, pre-installed device firmware and client applications all count as distribution. Two boundaries are widely misunderstood: purely internal use is not distribution — running GPL software on your own servers carries no release obligation; and the legal edge of a "derivative work" remains gray — communication between independent processes usually does not propagate, while deep linking is high-risk.

Tier 4: Network copyleft and commercial restrictions — the SaaS-era minefield

AGPL-3.0 extends the trigger from "distribution" to "offering a service over a network" — if users reach your SaaS over the network, you owe them the source. This is exactly why major cloud providers put AGPL on their banned lists. A newer wave of "source-available" licenses goes further: SSPL (MongoDB), BSL (formerly used by HashiCorp) and the Elastic License directly restrict offering competing hosted services. They are not OSI-approved open-source licenses, yet plenty of teams still import these components as if they were. The recent string of high-profile relicensing events proves the point: a license is not a static attribute — a version bump can change everything, so pinning a version must mean pinning its license version too.

A three-step governance rollout

Step one: know what you actually have. Run a full scan with CleanSource SCA — the priority is not what the dependency manifest declares, but what came in through copy-paste and renamed reuse, because the highest-risk code is precisely what the manifest cannot see. For a lightweight start, the free Community Edition works.

Step two: set policy by distribution mode. The same component carries entirely different risk in an internal tool, a shipped product and a SaaS. Write the policy as a matrix (license class × distribution mode × allow/review/block) and wire it into the scanner as an admission gate — not leave it in a Word file at legal.

Step three: industrialize the obligations. Auto-generate attribution/NOTICE files that update with every release, and ship license data inside the SBOM. At customer acceptance or export certification, whether that file exists decides if the compliance check takes ten minutes or ten days.

The goal of license compliance was never to eliminate GPL — it is to make every import an informed decision. Once the map is clear, which road to take is the business's own call.

open source licensesGPLopen source compliancelicense riskSCA

Related

Deep Dive

SBOM Is More Than a Compliance Checklist

Many teams treat an SBOM as a document to hand in. But a valuable SBOM drives decisions — which vulns are exploitable, which dependency to fix first, which license carries risk.