SBOMs for open source license compliance: catch GPL problems early

SBOM license compliance is the unglamorous second job of a software bill of materials. Security gets the headlines, but license fields in your SBOM answer a question that has quietly reshaped acquisitions and enterprise deals: does anything in our product obligate us to release our source code, and can we prove the answer? Teams typically discover license problems at the worst possible moments—during M&A due diligence or an enterprise procurement review—when remediation is measured in deal delays.

This guide covers:

Why license risk accumulates silently in modern dependency trees
The license categories that matter and what each obligates
How SBOM data turns license compliance from an annual panic into a CI check
Writing a license policy engineers can actually follow
What acquirers and enterprise buyers examine, and how to be ready

Reading the license terms carefully

GIF via GIPHY

Related guides:

Key takeaways

A typical application carries hundreds of licenses via transitive dependencies—nobody reviewed most of them.
The risk tiers: permissive (fine), weak copyleft (conditions), strong copyleft (obligations), and unlicensed/custom (danger).
SPDX-formatted SBOMs carry standardized license expressions, making policy enforcement automatable in CI.
AGPL in a SaaS backend is the modern trap—network use triggers obligations that GPL's distribution trigger does not.
SecureSlate helps treat license risk as a governed control with owners and evidence, not tribal knowledge.

Why license risk sneaks up on teams

Engineers add dependencies for functionality, not legal terms—and package managers resolve transitive trees no human reads. License risk compounds because:

Transitive dependencies dominate. Your direct dependency is MIT-licensed; its dependency three levels down is GPL. You shipped it either way.
Licenses change between versions. Projects relicense (Elastic, MongoDB, HashiCorp are famous examples)—an upgrade can silently change your obligations.
Copy-paste and vendored code carry licenses that dependency manifests never see.
AI-generated code raises unresolved provenance questions that diligence teams have started probing.

None of this surfaces without an inventory that includes license data—which is precisely what an SPDX SBOM is.

License categories and what they demand

Category	Examples	Obligation when you distribute (or serve)
Permissive	MIT, Apache-2.0, BSD	Attribution, notice preservation—generally low risk
Weak copyleft	LGPL, MPL-2.0, EPL	Share modifications to the component; linking generally OK with conditions
Strong copyleft	GPL-2.0, GPL-3.0	Distributing combined work can require releasing your source under GPL
Network copyleft	AGPL-3.0	Serving users over a network counts as the trigger—the SaaS trap
No license / custom	Unlicensed snippets, bespoke terms	Default copyright: you may have no right to use it at all

The nuance that matters for SaaS: classic GPL obligations trigger on distribution, which pure SaaS avoids—but AGPL closes that loophole. An AGPL library in your hosted backend can obligate source release even though you never ship a binary.

What SBOMs add to license compliance

Before SBOMs, license compliance meant annual scans by a legal-adjacent tool nobody owned. With per-release SBOMs (see how to generate an SBOM):

Every release carries its license inventory—SPDX license expressions per component, machine-checkable
CI can enforce policy: fail the build when a newly introduced dependency carries a denied license
Version-to-version diffs catch relicensing events in upgrades automatically
Historical answers stay answerable: "did v2.3 contain AGPL code?" is a query, not an archaeology project
Diligence packages assemble themselves: the SBOM series is the license evidence acquirers ask for

SPDX is the natural format here—its license list is the industry standard and its expressions handle dual-licensing (MIT OR GPL-2.0) precisely. See SPDX vs CycloneDX.

Building a license policy

Keep it to one page engineers will actually consult:

Allowed by default: permissive licenses (MIT, Apache-2.0, BSD variants)
Allowed with conditions: weak copyleft—dynamic linking only, no modifications without legal review
Denied for distributed/shipped code: strong copyleft (GPL family) unless legal approves an isolation architecture
Denied everywhere without CISO + legal sign-off: AGPL, SSPL, unlicensed code
Escalation path: who reviews exceptions and how fast (a two-day SLA keeps engineers from routing around you)

Enforce the deny list as a CI gate on the SBOM diff—blocking a bad license at PR time costs minutes; removing one from production costs quarters.

M&A and enterprise due diligence

Acquirers routinely commission open source audits (Black Duck-style scans) on targets. What they look for—and what a mature SBOM practice pre-answers:

Copyleft in proprietary code paths, especially GPL/AGPL in core product
License inventory completeness—can you produce component-level license data for current and recent releases?
Policy and process evidence—was there a gate, or is the codebase whatever accumulated?
Remediation history—found issues that were fixed show a working program; surprises show its absence

Deals rarely die from a single GPL finding—they slow down, gain escrow holdbacks, and lose negotiating leverage. A versioned SBOM series with license gates in CI is the cheapest insurance available against that outcome.

License risk as part of GRC with SecureSlate

SecureSlate helps you govern license compliance like any other control: documented policy, named owners, CI-enforced gates as evidence, and exception workflows—alongside your SOC 2 and ISO 27001 program in one platform.

Get started for free · Free readiness score

FAQ: SBOMs and license compliance

Are SBOM license fields reliable?

Scanner-detected licenses are right most of the time but not always—dual licensing, missing metadata, and vendored code need human review. Treat scanner output as the draft, with legal review for anything feeding a diligence package.

Does AGPL really apply if we only use the library internally?

Internal use without serving external users generally avoids the network trigger, but "internal" erodes fast (partner portals, APIs). Most companies deny AGPL by default to avoid depending on that distinction.

What about dev-only dependencies?

Build and test tools that never ship in the artifact carry far lower risk—your policy can be permissive there. This is another reason to generate SBOMs from the shipped artifact, which naturally excludes them.

Can we fix a copyleft problem without removing the component?

Sometimes—architectural isolation (separate process, network boundary), buying a commercial license where offered, or replacing the component. All are cheaper before an acquirer finds it.

Do enterprise customers actually check licenses?

Increasingly yes—procurement in regulated industries asks for license attestations, and some request the SBOM specifically to run their own license analysis.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.