Open Source Software Compliance Checklist: A Practical Checklist

A modern web application pulls in a handful of direct dependencies, each of which pulls in its own, and within three or four hops the tree has swelled into the thousands. Every leaf is governed by a copyright license. Most are harmless; a few are not; and the whole structure changes every time a developer runs npm install. That is the real shape of open source risk — not that the law is obscure, but that the obligations attach to everything, silently, at the speed of development. The Federal Circuit settled the central legal question in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008): the conditions of an open source license are limits on the scope of the copyright grant, so using the software outside those conditions is copyright infringement, with statutory remedies that follow. Open source is free as in freedom and free as in beer. It is emphatically not free as in unconditional.

This checklist makes compliance manageable by turning it into a list. Where a step says "escalate to legal," it means exactly that — the hardest questions (what is a "derivative work," whether two modules are a "single program," whether your SaaS trips the AGPL) turn on facts and thin caselaw. A checklist is a tool, not legal advice.

Phase 1 — Scope by Distribution Surface

Inventory all software products distributed externally or to customers (binary or source)
Identify internal tools that may be shared with contractors or partners
Flag products offered as SaaS/cloud services for AGPL analysis
List products embedded in hardware/firmware (highest copyleft risk)
Note products with community/enterprise editions and any white-labeled products distributed by partners
Gather existing documentation: prior inventories, NOTICE/THIRD-PARTY-NOTICES files, LICENSE files, prior audit reports, OSS policies, dual-license/commercial agreements, CLAs, and vendors' third-party agreements
Confirm scope and an escalation path with legal, engineering, and business stakeholders ("findings are for fixing, not for blame")

The single most legally consequential scoping question is what do you distribute, and to whom? Almost every burdensome obligation — the GPL's source-disclosure requirement, the LGPL's relinking obligation, attribution duties — is triggered by distribution, not by mere use. Software you run only on your own servers generally sits in a far safer place. The glaring exception is the AGPL, written to close the "SaaS loophole" by treating network interaction as distribution. Map your distribution surface first; everything else follows from it. Prioritize by two variables: whether the product leaves your walls, and whether it contains copyleft.

Phase 2 — Discover Every Component

Scan the lockfile, not just the manifest for every ecosystem (package-lock.json, yarn.lock, poetry.lock, go.sum, Cargo.lock, etc.) so transitive dependencies are resolved
Detect vendored code copied into the repo (/vendor, /third_party), via file fingerprinting/snippet matching, stray license files, and minified or bundled libraries
Run binary and container analysis: compiled artifacts, shared libraries, Docker FROM base images and installed packages, firmware images, mobile APK/IPA packages
Reconcile multiple scanning methods, investigate every discrepancy, spot-check 10–20 components by hand, and flag dev/test dependencies distinctly from production
Document any component that could not be identified or has conflicting version information

The manifest is your intention; the lockfile is your reality, and obligations attach to reality. The riskiest components are precisely the ones the package manager never sees — code copied into the tree, libraries baked into a container base image, a driver compiled into firmware. Verify at the artifact level, because that artifact, not your repository, is what you distribute. Firmware deserves special vigilance: the most consequential enforcement actions (BusyBox, SFC v. Best Buy, SFC v. Vizio) all involved GPL'd code in consumer-electronics firmware shipped without source. The dev/production boundary is more than housekeeping — a GPL build tool that never ships generally creates no distribution obligation, but misclassify a production dependency as dev-only and you ship a violation.

Phase 3 — Classify the Licenses

For each high-risk or unusual component, verify the detected license against an authoritative source (the SPDX License List, OSI); check for exceptions (e.g., GPL linking exception), "or later" options, and dual-licensing
Classify each component as permissive, weak copyleft, strong copyleft, or special-attention
For Apache 2.0, propagate the NOTICE file and note the patent-retaliation bargain (the express patent grant terminates if you sue the licensor)
Treat no license / unknown as the most restrictive case ("all rights reserved"), not the least — stop and research
Run a compatibility check across the licenses combined in each distributed work (GPL-2.0-only vs. Apache-2.0; GPL-2.0-only vs. GPL-3.0-only; AGPL inside a proprietary SaaS service) and escalate unresolvable conflicts
Flag source-available licenses (SSPL, BSL, Elastic License, Commons Clause) for legal review — they are not OSI "open source" despite appearances

The entire economics of the program flow from classification: an MIT component costs one NOTICE line; an AGPL component in a SaaS product can cost you your proprietary source. SCA tools identify licenses by pattern-matching; they are confident and sometimes wrong, missing dual-licensing and misreading "or later." Two perfectly valid licenses can be legally incompatible — GPLv2-only and Apache 2.0 cannot be combined (Apache's patent and indemnity terms count as "additional restrictions" GPLv2 forbids), though GPLv3 was drafted to fix this. The relicensing wave (Elastic, HashiCorp, Redis) means a license is not a permanent attribute of a dependency: your SCA tooling must flag license changes on upgrade, not just types.

Phase 4 — Assess Copyleft Exposure and Attribution

Run the attribution review: a NOTICE/THIRD-PARTY-NOTICES file in the distribution, copyright notices and full license text where required, attribution accessible to end users (not buried on a build server), Apache NOTICE files propagated, and generation automated from the current inventory
For each strong-copyleft (GPL, AGPL) component in a distributed product, run the combined-work questions: distributed externally? linked (static or dynamic) with proprietary code? modified? combined into a single binary? for AGPL, do users interact over a network?
Assign a risk tier: internal-only GPL (low), arm's-length API communication (medium, legal review), dynamically linked GPL in a distributed app (high), statically linked GPL in a distributed binary or AGPL in a user-facing service (critical — remediate immediately)
Verify LGPL compliance: preserve the user's ability to relink a modified library (dynamic linking satisfies this almost for free; static linking requires providing object files or relinkable form)

Attribution is the most under-rated obligation: easiest to satisfy, easiest to forget. In Jacobsen, the obligation breached was, at bottom, an attribution-and-notice requirement, and its violation was treated as potential copyright infringement. Strong copyleft is where the analysis gets genuinely hard, because it turns on whether your code and the GPL code form a single "work based on the Program" — essentially a derivative work. The FSF's position is that linking (static or dynamic) generally creates a combined work, while arm's-length communication between separate processes does not; no U.S. appellate court has definitively blessed the dynamic-linking position, which is why this analysis so often ends at "escalate to counsel." A statically linked GPL library in shipped firmware with no source is the exact SFC v. Vizio fact pattern.

Phase 5 — Remediate

Fix attribution: generate the NOTICE file from the build (not by hand), populate copyright notices and required license text, and confirm end-user accessibility
Remove a problematic component: research permissively licensed alternatives, evaluate functional equivalence and maintenance/security health, replace, and re-scan
Isolate architecturally: hold the component at arm's length (separate process/container, communication over a network or IPC boundary), with no shared memory, headers, or linking — and obtain legal review of isolation adequacy
Resolve conflicts: check for an alternative/dual license or a newer compatible version before re-engineering
Comply with the copyleft where removal/isolation is impractical: release the complete corresponding source

There are really only four moves — fix, remove, isolate, or comply — and the cheapest is almost never the one that looks cheapest at first. Removal is dramatically cheaper when caught early (during component selection, when substitution is trivial) than late (under deal pressure, when the architecture is frozen). Isolation rests on the FSF's linking-versus-IPC distinction, but "arm's length" must be real; any linking pulls the component back across the line, which is why legal review of isolation adequacy is the step you cannot skip.

Phase 6 — Build a Continuous Program

Adopt a tiered license policy: green (permissive, pre-approved subject to attribution), yellow (weak copyleft, permitted after review), red (GPL/AGPL and source-available, legal review before any use)
Onboard developers so each can answer instinctively: can I add this dependency, and if not sure, who do I ask?
Gate new components at intake (license verified and on the approved list, security and maintenance checks, business justification)
Verify every release: SCA scan, no prohibited or unreviewed licenses, attribution current, SBOM generated (SPDX or CycloneDX) and archived with the release, and complete-corresponding-source offer prepared where copyleft requires it
Run quarterly reviews (full SCA scan, newly disclosed vulnerabilities, upstream relicensing, attribution currency) and track metrics (license coverage, copyleft exposure count = 0, mean time to remediate)
Consider certifying against OpenChain (ISO/IEC 5230) to signal maturity to customers and acquirers

Audits are photographs; programs are video. A codebase clean at audit accumulates new dependencies within days, so the only durable posture is a process that scans continuously, gates new components at the door, and verifies at every release — making the compliant path the path of least resistance for a busy developer. A gate at intake is the highest-leverage control: far cheaper to say "no" to a dependency than to surgically remove it from three shipped products eighteen months later.

Phase 7 — Special Situations (M&A, SBOM, Incident Response)

M&A (buyer): run an independent SCA scan rather than trusting the target's representations, compare against the disclosed inventory, quantify remediation, and allocate residual risk through reps, warranties, and indemnification
M&A (seller): audit and remediate before marketing, prepare a defensible inventory and a data room (policy, audit report, attribution files), and disclose known issues with remediation status (concealment is far worse than disclosure)
SBOM: choose SPDX or CycloneDX per contract requirements, generate from the build, include component, version, supplier, identifier, and SPDX license; archive with the release; track upstream vulnerabilities
Incident response (first 48 hours): document the report, assess scope, stop distribution if needed, engage counsel before responding to any demand, and preserve evidence under litigation-hold discipline
Investigation and remediation: confirm a violation actually occurred (many demands overreach), find the root cause, remediate, and consider counsel-guided outreach — most enforcers want compliance, not damages

SBOMs moved from best practice to baseline expectation after Executive Order 14028 (May 2021) made them a federal-procurement gate; the EU Cyber Resilience Act extends comparable expectations. Open source diligence is now a standard, sometimes deal-defining, workstream — a buyer who skips it can acquire copyleft-compromised proprietary code or latent infringement. Enforcement is real and varied: SFC v. Vizio's third-party-beneficiary contract theory (a December 2025 tentative ruling found a source-code request can ripen into an enforceable contract; the case went to trial in February 2026); the Paris Court of Appeal's ~€860,000 award against Orange for a GPLv2 violation (Entr'ouvert v. Orange, Feb. 2024); and Artifex v. Hancom allowing a GPL breach-of-contract claim. The cooperative path is almost always the cheap one.

Common Mistakes

Scanning the manifest but not the lockfile, missing the transitive dependencies where obligations actually live.
Assuming SaaS is a universal copyleft shield; it works against ordinary GPL but fails completely against the AGPL's network clause.
Hand-maintaining a NOTICE file so it is wrong the moment the next dependency changes.
Waving through permissive licenses on the theory that "only copyleft matters," quietly accumulating Apache NOTICE and MIT/BSD attribution failures.
Calling isolation done without legal review, when shared memory or headers pulled the component back across the line.
Discovering open source in a buyer's diligence scan rather than your own — late, adversarial, and expensive.

Primary Authority

License conditions as copyright scope: Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008); covenant-versus-condition framework, MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010).
Enforcement: Software Freedom Conservancy, Inc. v. Vizio, Inc. (Cal. Super. Ct.; tentative ruling Dec. 2025; trial Feb. 2026, third-party-beneficiary theory); Artifex Software, Inc. v. Hancom, Inc., No. 16-cv-06982 (N.D. Cal. 2017); SFC v. Best Buy Co., 2010 WL 4860780 (S.D.N.Y. 2010); Entr'ouvert v. Orange S.A., Paris Court of Appeal (Feb. 14, 2024); Neo4j, Inc. v. PureThink, LLC / Neo4j v. Suhy (9th Cir. 2021).
License families: GNU GPL v2 and v3; GNU LGPL; GNU AGPL; Apache License 2.0; MIT/BSD/ISC. Source-available: SSPL, Business Source License.
Standards/policy: Executive Order 14028, "Improving the Nation's Cybersecurity" (May 12, 2021); EU Cyber Resilience Act; OpenChain (ISO/IEC 5230); SPDX (ISO/IEC 5962) and CycloneDX SBOM formats. The hardest combined-work and AGPL-network questions remain unsettled — escalate to counsel rather than guessing.

Related Resources

This checklist is general information, not legal advice. Open source licensing law continues to evolve, and several matters — including the SFC v. Vizio litigation, the dynamic-linking question, and AI-and-open-source provenance — remain unresolved. Consult qualified intellectual-property counsel about your specific circumstances.