Checklist · Technology

Open Source Software Compliance: A Practical Checklist

Type: Checklist
Jurisdiction: National
Date: 2026-02-06
Topic: Technology

Open source compliance rarely fails because the law is obscure; it fails because nobody runs the checklist. A single web application resolves thousands of components across dozens of license families, and the dependency tree mutates every time an engineer runs a package install. This checklist decomposes the problem into discrete, verifiable steps: scoping by distribution surface, exhaustive component discovery, license classification along the permissive-to-copyleft spectrum, copyleft and AGPL exposure analysis, attribution, remediation, a continuous program with a tiered license policy and CI-integrated scanning, SBOM generation, M&A diligence, and incident response. Each step is anchored in real authority — Jacobsen v. Katzer on license conditions as limits on the copyright grant, the third-party-beneficiary theory tested in SFC v. Vizio, the Orange/Entr'ouvert award in France, and the concrete obligations of MIT, BSD, Apache, LGPL, GPL, and AGPL. It closes with a worked hypothetical, the most common mistakes, primary authority, and related UpLaw resources.

Open Source Software Compliance: A Practical Checklist

Technology > Open Source | Published 6 February 2026 - Updated 11 May 2026 | UpLaw - uplaw.us

A practitioner-grade, single-flow checklist for open source compliance — scoping, discovery, license classification, copyleft and AGPL analysis, attribution, remediation, continuous governance, SBOMs, and deal diligence — grounded in the copyright doctrine that makes every license condition enforceable.

Keywords: open source compliance, GPL, AGPL, LGPL, copyleft, permissive license, Apache NOTICE, SBOM, SPDX, CycloneDX, software composition analysis, transitive dependency, license incompatibility, derivative work, M&A due diligence, Jacobsen v. Katzer, SFC v. Vizio, source-available license, attribution.

Open a modern application's dependency graph and count the leaves. A tidy front-end project declares a dozen direct dependencies; each of those declares its own; and within three or four hops the resolved tree holds several thousand distinct packages. Every one of those leaves is a copyrighted work distributed under a license. Most of the licenses are harmless. A handful are not. And the whole structure rearranges itself the moment a developer runs an install command or a bot merges a dependency-bump pull request. That is the real geometry of open source risk. The problem is not that the governing law is mysterious — it is remarkably settled — but that the obligations attach to everything, silently, at the speed of continuous integration.

The central legal question was answered almost two decades ago. In Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), the Federal Circuit held that the terms of an open source license (there, the Artistic License governing model-railroad software) are conditions on the scope of the copyright grant, not merely contractual promises. Step outside those conditions and you are using the work without authorization — which is to say, you are infringing copyright, with the statutory remedies of 17 U.S.C. §§ 502–505 available to the licensor, including injunctive relief and, where the work was timely registered, statutory damages and fees. Open source is free as in freedom and free as in beer. It is emphatically not free as in unconditional.

This checklist exists because the way most organizations "handle" open source is to trust that someone, somewhere, read the licenses. No one did. What follows turns an amorphous obligation into a sequence of things you can actually check off: scope the distribution surface, discover every component, classify every license, assess copyleft exposure, remediate what is broken, stand up a continuous program, and handle the special situations — mergers, SBOM mandates, and enforcement letters — when they arrive. Where a step says escalate to counsel, take it literally. The hardest questions in this field — what counts as a "derivative work," whether two modules form a "single program," whether a network service trips the AGPL — turn on facts and on caselaw that is thin, foreign, or still being written. A checklist is a tool, not a legal opinion.

The Legal Engine: Why a License Nobody Signed Still Binds You

Before the phases, spend two minutes on the doctrine that powers every one of them. Understanding why a license you never negotiated can force you to publish your source code makes the rest of the checklist feel less like superstition and more like risk management.

An open source license is a public copyright license. The author retains copyright and grants the world the rights to copy, modify, and distribute — subject to conditions. Because copyright's exclusive rights under 17 U.S.C. § 106 include reproduction, preparation of derivative works, and distribution, a license is the only thing standing between an ordinary user and infringement liability. Ignore the conditions and the permission evaporates. That is the holding of Jacobsen, and it is what distinguishes a condition (a limit on the grant, breach of which is infringement) from a mere covenant (a promise collateral to the grant, breach of which sounds only in contract). The Ninth Circuit drew the line carefully in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010), holding that a licensee's violation is copyright infringement only when the term breached is a condition that limits the scope of the license, and there must be a nexus between the condition and the licensor's exclusive rights. Good license drafting — and the GPL is drafted this way — states its obligations as conditions precisely so that violation opens the door to copyright's more potent remedies.

Enforcers have not stopped at copyright. A parallel contract theory has gained ground: because open source licenses recite obligations that run to downstream recipients, a user who never receives source code may sue as a third-party beneficiary of the license between the distributor and the upstream author. That theory survived a motion to remand and reached trial in Software Freedom Conservancy, Inc. v. Vizio, Inc. (Cal. Super. Ct.), where a December 2025 tentative ruling accepted that a recipient's request for "complete corresponding source" can ripen into an enforceable contractual entitlement; the case went to trial in February 2026. A federal court reached a compatible conclusion in Artifex Software, Inc. v. Hancom, Inc., No. 16-cv-06982 (N.D. Cal. 2017), allowing a breach-of-contract claim to proceed on a GPL/dual-license theory. Contract remedies matter because they can reach conduct and parties that a bare copyright claim cannot, and because specific performance — ship the source — is exactly what many enforcers want.

The remedy stakes are not hypothetical. In Entr'ouvert v. Orange S.A., the Paris Court of Appeal in February 2024 upheld an award of roughly €860,000 against a telecom for distributing GPLv2-licensed identity-management software without honoring the license. Earlier U.S. enforcement — the BusyBox campaigns, SFC v. Best Buy Co., 2010 WL 4860780 (S.D.N.Y. 2010) — established the template: copyleft code buried in shipped consumer-electronics firmware, distributed without the corresponding source, met with an injunction. And the source-available relicensing wars produced Neo4j, Inc. v. PureThink, LLC and the related Neo4j v. Suhy (9th Cir. 2021), where the Ninth Circuit held that a licensee could not strip a "Commons Clause" restriction from an AGPL-plus-rider license and market the result as "free and open source." For the layered relationship among copyright, contract, and the other software-protection regimes, see How the Law Protects Software: Copyright, Patents, Trade Secrets, and Contract Rights and the deeper treatment in Open Source Software Licenses, Compliance, and Risk: A Comprehensive Guide.

Hold onto three ideas as you work the checklist. First, the obligation follows the copyright, not a signature — you are bound whether or not anyone at your company ever saw the license. Second, distribution is usually the trigger — most burdensome duties fire when software leaves your walls, not when you merely run it (the AGPL, discussed below, is the great exception). Third, the expensive questions are combination questions — how your proprietary code and the open source code fit together determines whether you owe a NOTICE line or your entire source tree.

How to Use This Checklist

The seven phases below run in order for a first-time audit, but they are also a repeating loop. Run Phases 1 through 5 once to clean up the codebase you have; then live inside Phase 6 forever so the codebase stays clean; and pull out Phase 7 when a deal, a regulator, or a demand letter forces a special situation. Every checkbox is written so that a non-lawyer engineer can execute it and a lawyer can audit it. Treat findings as inputs for fixing, never as ammunition for blame — an audit that punishes disclosure teaches your engineers to stop disclosing.

Phase 1 — Scope by Distribution Surface

[ ] Inventory every software product distributed externally or delivered to customers, in either binary or source form.
[ ] List internal-only tools, and flag any that are shared with contractors, auditors, or channel partners (sharing can itself be distribution).
[ ] Mark every product offered as a SaaS or hosted service for separate AGPL analysis.
[ ] Identify products embedded in hardware, firmware, or an appliance — the highest copyleft-risk category.
[ ] Note products shipped as community/enterprise editions, and any white-labeled builds that partners redistribute under their own brand.
[ ] Pull the existing paper: prior inventories, NOTICE / THIRD-PARTY-NOTICES files, LICENSE files, past audit reports, the open source policy (if any), dual-license and commercial agreements, contributor license agreements (CLAs), and vendors' third-party notices.
[ ] Confirm scope and an escalation path with legal, engineering, and business stakeholders in writing.

The single most legally consequential question in the entire program is asked here: what do you distribute, and to whom? Nearly every heavy obligation — the GPL's source-disclosure duty, the LGPL's relinking requirement, Apache's NOTICE propagation, plain attribution — is triggered by distribution, not by internal use. Software you run only on servers you control generally sits in the safest place the law offers. Which is why the map of your distribution surface, drawn first, tells you where to spend the rest of your attention.

The exception that swallows a lot of comfort is the GNU Affero General Public License (AGPL). Its Section 13 was written specifically to close what its authors saw as the "SaaS loophole": if you modify AGPL-covered software and let users interact with it over a network, you must offer those remote users the corresponding source, even though you never handed them a binary. A company that reflexively assumes "we're SaaS, so copyleft can't reach us" is right about the GPL and dangerously wrong about the AGPL.

Worked example. Cobalt Ledger, a hypothetical fintech, runs three products: a mobile app it publishes to the app stores, a REST API its customers call, and an internal fraud-scoring service that never leaves its VPC. Scoping ranks them instantly. The mobile app is distributed — attribution and any copyleft in the shipped bundle are live. The API is hosted — ordinary GPL is largely dormant, but if the fraud engine embeds a modified AGPL library reachable through the API, Section 13 wakes up. The internal service is use-only — the lowest tier, unless it is ever shared with an outside auditor. Same company, three completely different risk postures, and the difference is entirely a function of the distribution surface. For where these questions sit inside a broader deal, see The Landscape of Software Transactions: An Overview and How Software Licensing Works: An Overview.

Phase 2 — Discover Every Component

[ ] Resolve the lockfile, not just the manifest, for every ecosystem in the build (package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, requirements.txt pins, go.sum, Cargo.lock, Gemfile.lock, Maven/Gradle resolved trees) so that transitive dependencies are captured.
[ ] Detect vendored code copied into the repository (/vendor, /third_party, /libs) via file fingerprinting and snippet matching, stray license headers, and minified or bundled libraries.
[ ] Run binary and container analysis: compiled artifacts and static libraries, Docker base images and their installed OS packages, firmware images, and mobile APK/IPA bundles.
[ ] Reconcile at least two independent scan methods, investigate every discrepancy, and hand-verify ten to twenty of the highest-risk components.
[ ] Separate development/test dependencies from production/distributed ones, and document any component that could not be identified or shows conflicting version data.

The manifest records your intention; the lockfile records your reality; obligations attach to reality. A package.json that lists a permissive framework tells you nothing about the copyleft utility three hops down that the resolver actually pulled in. Scan the lockfile.

The components most likely to hurt you are precisely the ones the package manager never sees. Code copied by hand into a /vendor directory carries its license but not its metadata. A library baked into a container base image ships to your customer even though it appears nowhere in your source. A codec compiled into firmware is invisible to a source scan and fatal to a copyleft audit — which is the exact fact pattern behind the BusyBox and Vizio enforcement actions: GPL code in consumer-electronics firmware, shipped without source. Verify at the artifact level, because the artifact you distribute — the container, the APK, the flashed image — is the thing the license governs, not the pristine repository it was built from.

The development-versus-production boundary is more than housekeeping. A GPL-licensed code generator or test harness that runs on a build server and never ships generally creates no distribution obligation at all. Misclassify a production dependency as dev-only, however, and you have quietly shipped a violation. When in doubt about whether a tool's output is itself a derivative work of the tool, escalate. Discovery is also the moment to think about clean provenance for your own code; the disciplines overlap with Copyright Registration for Software: A Practical Checklist and Registering Copyright in Software and Source Code.

Phase 3 — Classify the Licenses

[ ] For each high-risk or unusual component, verify the machine-detected license against an authoritative source — the SPDX License List and the OSI-approved list — and check for exceptions (for example, the GNU "linking exception"), "or later" upgrade options, and dual-licensing.
[ ] Sort every component into one of four buckets: permissive, weak copyleft, strong copyleft, or special-attention.
[ ] For Apache License 2.0 components, propagate the NOTICE file into your distribution and note the patent bargain: the express patent grant terminates for anyone who initiates patent litigation alleging the software infringes.
[ ] 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, and escalate any conflict you cannot resolve.
[ ] Flag source-available licenses (SSPL, Business Source License, Elastic License 2.0, Commons Clause riders) for legal review — despite appearances, they are not OSI-approved "open source."

Everything downstream — cost, architecture, deal risk — flows from getting this taxonomy right, because the economics differ by orders of magnitude across the buckets. An MIT component costs you one line in a NOTICE file. A modified AGPL component sitting inside a hosted product can cost you your proprietary source. Software composition analysis (SCA) tools do the first pass by pattern-matching license text; they are fast, confident, and periodically wrong, especially about dual-licensed projects and "GPL-2.0-or-later" upgrade options. Verify the ones that matter by hand.

The four buckets

Permissive licenses — MIT, the BSD family, ISC, Apache 2.0 — let you do almost anything, including combining the code into proprietary, closed-source products, provided you preserve copyright notices and license text. They are the low-friction default. Their trap is complacency, discussed below.

Weak (or "file-level") copyleft — the GNU Lesser General Public License (LGPL), the Mozilla Public License 2.0 (MPL), the Eclipse Public License — reaches modifications to the covered files themselves but generally lets you link the library into a larger proprietary program without infecting your own code, so long as you preserve the user's ability to swap in a modified version of the library.

Strong copyleft — GPLv2, GPLv3, and the AGPL — reaches the whole "work based on the Program." Combine your code with it into a single distributed work and the license's terms attach to the combination: you must offer the complete corresponding source under the same license. This is the "reciprocal" or (pejoratively) "viral" quality, and it is entirely by design. The Free Software Foundation created copyleft with the GPL and the GNU Project in the 1980s precisely so that derivatives of free software would remain free.

Special-attention covers the imposters and the unknowns — source-available licenses, custom licenses, and components with no detectable license at all.

Permissive licenses and the NOTICE trap

The reason "permissive" is not the same as "obligation-free" is attribution. MIT and BSD both require that the copyright notice and permission text travel with every copy and substantial portion of the software. Apache 2.0 goes further: Section 4(d) requires you to carry forward the contents of any NOTICE file, and Section 4(a)–(c) require preserving notices and stating changes. A distribution that quietly drops those notices is out of compliance with a "permissive" license — a small breach, but a real one, and one that multiplies across a thousand permissive dependencies into a genuine attribution deficit. Waving permissive licenses through on the theory that "only copyleft matters" is how organizations accumulate hundreds of quiet MIT/BSD/Apache attribution failures. Note too that a permissive license can itself be evidence of the author's retained rights: in Planetary Motion, Inc. v. Techsplosion, Inc., 261 F.3d 1188 (11th Cir. 2001), the Eleventh Circuit held that distributing software under the GPL was "use in commerce" sufficient to establish trademark ownership in the software's name — a reminder that "open" does not mean "no one owns this."

Weak copyleft and the relinking obligation

The LGPL's bargain is elegant and frequently botched. You may link an LGPL library into a proprietary application without the application becoming subject to the LGPL — provided you preserve the user's freedom to replace the library with a modified version. If you link dynamically (the application loads a shared library at runtime), you satisfy this almost for free: the user can drop in a new .so/.dll/.dylib and relaunch. If you link statically (the library is compiled into your binary), you must ship something that lets the user relink — object files, or the application in a relinkable form. Static linking of an LGPL library into a shipped binary, with nothing provided to enable relinking, is a common and avoidable violation.

Strong copyleft: GPL and AGPL

The GPL's reciprocity attaches on distribution of a work based on the Program. Distribute a combined binary and you owe the complete corresponding source, under the GPL, to your recipients — plus the machine-readable scripts to build and install it. GPLv2 § 4 terminates your license automatically on violation, with no cure period; GPLv3 softened this with a cure mechanism (reinstatement if you fix within 30 days of notice, and automatic reinstatement for first-time, promptly-cured violations). The AGPL adds Section 13, extending the source-offer duty to users who interact with a modified version over a network, which is why it, and only it, threatens the ordinary SaaS posture.

Source-available imposters

A growing category of licenses looks open but is not. The Server Side Public License (SSPL, used by MongoDB), the Business Source License (BSL, used by MariaDB, HashiCorp's Terraform before its fork, and others), the Elastic License 2.0, and the "Commons Clause" rider all restrict commercial use or hosting in ways that fail the Open Source Definition; the OSI has declined to approve them. They are lawful and often perfectly reasonable to accept — but they are commercial licenses wearing open source clothing, and they belong in legal review, not in the green-light lane. The 2021–2024 relicensing wave (Elastic, HashiCorp, Redis, Terraform's community fork into OpenTofu) proves a subtler point: a license is not a permanent attribute of a dependency. A project you adopted under Apache 2.0 can relicense on its next release. Your SCA tooling must therefore flag license changes on upgrade, not merely license types at intake.

License incompatibility

Two perfectly valid, perfectly "open" licenses can be legally incompatible, meaning you cannot lawfully combine both works into one distributed program. The canonical example: GPLv2-only and Apache License 2.0. Apache 2.0's patent-termination and indemnity provisions count, from GPLv2's perspective, as "further restrictions" that § 6 of GPLv2 forbids adding — so the two cannot be merged. GPLv3 was drafted specifically to cure this, and Apache-2.0-plus-GPLv3 combinations are fine. Likewise, GPLv2-only and GPLv3-only are mutually incompatible because neither permits relicensing to the other. This is why "or later" matters so much: "GPL-2.0-or-later" can be upgraded to v3 and combined with Apache code, while "GPL-2.0-only" cannot. When your SCA report shows both a GPLv2-only component and an Apache-2.0 component fused into one binary, that is not a paperwork problem — it is a genuine conflict that must be engineered away or escalated. For how these compatibility and grant-scope questions echo through negotiated software deals, see Software License Agreements: Key Terms and How to Negotiate Them and Anatomy of a Software License Agreement: A Comprehensive Guide.

Phase 4 — Assess Copyleft Exposure and Attribution

[ ] Run the attribution review: confirm a NOTICE / THIRD-PARTY-NOTICES file ships in the distribution, that required copyright notices and full license text are present, that the attribution is accessible to end users (not buried on a build server), that Apache NOTICE contents are carried forward, and that the file is generated from the current inventory.
[ ] For each strong-copyleft (GPL, AGPL) component in a distributed or hosted product, answer the combined-work questions: Is it distributed externally? Is it linked — statically or dynamically — with proprietary code? Was it modified? Is it fused into a single binary? For AGPL: do users interact with the modified version over a network?
[ ] Assign a risk tier to each copyleft finding (see below) and route it accordingly.
[ ] Verify LGPL compliance specifically: preserve the user's ability to relink a modified library (dynamic linking usually satisfies this; static linking requires shipping object files or a relinkable form).

Attribution is the most under-rated obligation in the entire field: the easiest to satisfy and the easiest to forget. It is worth remembering that the obligation actually breached in Jacobsen v. Katzer was, at bottom, an attribution-and-notice requirement — the defendant stripped author credits and change notices from copied files — and the Federal Circuit treated that as potential copyright infringement, not a trivial oversight. If notice-stripping was enough to state an infringement claim in Jacobsen, a NOTICE file that silently drifts out of date is not a safe place to be.

The genuinely hard analysis is the combined-work question, because strong copyleft's reach turns on whether your code and the GPL code together form a single "work based on the Program" — in copyright terms, essentially a derivative work (a concept defined at 17 U.S.C. § 101). The Free Software Foundation's position is that linking — whether static or dynamic — generally creates a combined work subject to the GPL, while communication between separate programs at arm's length (over a socket, a pipe, or a documented network protocol, exchanging data rather than sharing an address space) generally does not. That position is not law. No U.S. appellate court has squarely blessed or rejected the FSF's dynamic-linking theory, which is exactly why so much copyleft analysis ends at "escalate to counsel." The uncertainty is compounded by Google LLC v. Oracle America, Inc., 141 S. Ct. 1183 (2021), which resolved the reuse of the Java API declarations as fair use without settling the boundaries of software derivative works generally — leaving the derivative-work line as blurry in the copyleft context as everywhere else in software copyright. When your architecture depends on the answer, get a written opinion; do not let an engineer's intuition about "we only call it over an API" carry legal weight it cannot bear.

A practical risk tiering keeps the queue sane:

Low — GPL used purely internally, never distributed. Log it and move on.
Medium — arm's-length communication with a GPL component across a real process or network boundary. Legal review of whether the boundary is genuine.
High — dynamically linked GPL inside a distributed application. Legal review, likely remediation.
Critical — statically linked GPL in a distributed binary or firmware image, or a modified AGPL component in a user-facing hosted service. Remediate immediately; this is the Vizio fact pattern for the former and the AGPL nightmare for the latter.

Worked example. Meridian Robotics (hypothetical) ships a warehouse robot whose firmware statically links a GPLv2-only motion-planning library, and it distributes the firmware image to customers with no source offer. That is the critical tier: strong copyleft, static linking, distributed artifact, no source — the precise shape of the enforcement actions that produced injunctions against BusyBox defendants and the award against Orange in France. By contrast, if Meridian had run the same library as a separate process on the robot's controller, talking to its proprietary code over a local socket and exchanging only telemetry, it would have a colorable (if still counsel-worthy) arm's-length argument. Same library, same product, radically different exposure — determined entirely by how the pieces are combined.

Phase 5 — Remediate

[ ] Fix attribution: generate the NOTICE file from the build system (never by hand), populate all required copyright notices and license texts, carry forward Apache NOTICE contents, and confirm the file is reachable by end users.
[ ] Remove a problematic component: identify a permissively licensed alternative, evaluate functional equivalence and maintenance/security health, replace it, and re-scan to confirm.
[ ] Isolate architecturally: hold the component at arm's length in a separate process or container, communicating over a network or IPC boundary, with no shared memory, headers, or linking — then obtain legal review of whether the isolation is adequate.
[ ] Resolve conflicts: before re-engineering, check for an alternative or dual license, or a newer, compatibly licensed version.
[ ] Comply where removal and isolation are impractical: release the complete corresponding source under the required license.

There are only four moves — fix, remove, isolate, or comply — and the cheapest is almost never the one that looks cheapest in the moment. Removal costs almost nothing when a problem is caught during component selection, when a substitution is a one-line change and a re-run of the test suite. The same removal, discovered eighteen months later under acquisition deal pressure with the architecture frozen and three products depending on the component, can cost a quarter's engineering capacity. That asymmetry is the entire argument for the intake gate in Phase 6.

Isolation deserves a warning label. It rests on the FSF's linking-versus-communication distinction, and it works only if "arm's length" is real. Bolt the component into your address space through a shared library, a header include, or a static link, and you have pulled it back across the line no matter how the architecture diagram is captioned. This is why legal review of isolation adequacy is the one step in this phase you cannot skip: the adequacy question is precisely the unsettled derivative-work question from Phase 4, and it should not be resolved by the same engineer who wants to ship on Friday. Compliance — actually releasing your source — is sometimes the rational choice, particularly where the surrounding code has little competitive value; it is a business decision, not a defeat.

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 two questions instinctively: May I add this dependency? If I'm not sure, who do I ask?
[ ] Gate new components at intake: license verified and on the approved list, security and maintenance health checked, business justification recorded.
[ ] Verify every release: SCA scan clean of prohibited or unreviewed licenses, attribution current, SBOM generated (SPDX or CycloneDX) and archived with the release artifact, and a complete-corresponding-source offer prepared wherever copyleft requires one.
[ ] Run quarterly reviews: full SCA scan, newly disclosed vulnerabilities, upstream relicensing, attribution currency — and track metrics, with copyleft-exposure count driven to zero as the headline number, alongside license coverage and mean time to remediate.
[ ] Consider certifying against OpenChain (ISO/IEC 5230) to signal program maturity to enterprise customers and acquirers.

Audits are photographs; programs are video. A codebase certified clean on Monday has ingested new transitive dependencies by Thursday, which means a one-time audit ages out almost immediately. The only durable posture is a process that scans continuously, gates new components at the door, and re-verifies at every release — engineered so that the compliant path is also the path of least resistance for a developer who just wants to ship. A well-drawn open source policy — the kind Practical Law's model policies describe, assigning intake approval, audit cadence, contract language, and training acknowledgments to named owners — is what turns these checkboxes into an operating rhythm rather than a heroic quarterly scramble.

The intake gate is the highest-leverage control in the whole program, for the reason Phase 5 made concrete: it is dramatically cheaper to decline a dependency at the door than to excise it surgically from three shipped products later. A gate need not be bureaucratic; a green/yellow/red list wired into the dependency-review bot, so that a red-tier package fails CI and pings legal automatically, converts policy into muscle memory. The tiering discipline mirrors the way disciplined teams handle other pre-launch risks — compare the clearance mindset in The IP Clearance Toolkit: Securing Freedom to Operate Before You Launch and the governance patterns in Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork. For teams shipping to app stores, the same program feeds directly into Launching a Mobile App: A Practical Legal Checklist.

One caution about relicensing, because it defeats naive programs. Because a dependency can change its license on any release, the quarterly review must diff licenses across versions, not just enumerate current ones. A team that pinned a component under Apache 2.0 and later upgraded past the version where it flipped to the BSL — without noticing — has swapped a green-tier dependency for a red-tier one while believing nothing changed. Catching that is a tooling requirement, not a matter of diligence-by-vibes.

Phase 7 — Special Situations: M&A, SBOM Mandates, and Incident Response

Three situations pull open source out of the steady-state program and into a deadline. Handle each with its own sub-checklist.

Mergers and acquisitions

[ ] Buyer: run an independent SCA scan of the target's code rather than trusting its representations; compare results against the disclosed inventory; quantify remediation cost; and allocate residual risk through reps, warranties, and indemnification.
[ ] Seller: audit and remediate before going to market; prepare a defensible inventory and a data room (policy, audit report, attribution files, source-escrow agreements); and disclose known issues with their remediation status — concealment is far more damaging than disclosure.

Open source diligence is now a standard, occasionally deal-defining, workstream in software M&A. Practical Law's IP due-diligence checklists direct acquirers to identify all third-party and open source software material to the target, catalog how it is used, and gather license, hosting, escrow, and monitoring agreements — precisely because a buyer who skips the scan can acquire copyleft-compromised "proprietary" code, or latent infringement, at full price. The buyer's independent scan matters because a target's own inventory reflects what its developers remembered to record, and the riskiest components are the ones no one recorded. The seller's incentive is the mirror image: a clean, self-run audit surfaced early becomes a diligence asset, while the same issue discovered by the buyer's scanner becomes a price-chip or a deal-killer. This workstream sits inside the larger diligence picture covered by The IP Transactions Toolkit: A Roadmap for Licensing, Assignments, and Diligence and, for the sell-side founder, Getting Diligence-Ready Before You Raise: A Comprehensive Guide for Founders.

SBOMs and the regulatory floor

[ ] Choose SPDX (ISO/IEC 5962) or CycloneDX per your customers' and contracts' requirements.
[ ] Generate the SBOM from the build, not by hand, capturing for each component its name, version, supplier, unique identifier (e.g., purl or CPE), and SPDX license expression.
[ ] Archive the SBOM with the release artifact and use it to track newly disclosed upstream vulnerabilities against shipped versions.

The software bill of materials moved from best practice to baseline expectation after Executive Order 14028, "Improving the Nation's Cybersecurity" (May 12, 2021), made SBOMs a condition of selling software to the federal government, with NTIA and later CISA fleshing out the minimum elements. The EU Cyber Resilience Act extends comparable expectations to products with digital elements sold in the European market. An SBOM is not merely a compliance artifact; it is the data structure that makes the rest of this checklist executable — the same inventory that answers "do we have a copyleft problem?" answers "are we exposed to this week's disclosed vulnerability?" A program that generates SBOMs as a byproduct of every build has already done most of the work of both license compliance and vulnerability management.

Incident response — the first 48 hours

[ ] Document the report or demand exactly as received, and note the date received (compliance and cure clocks may run from it).
[ ] Assess scope — which product, which component, which versions, distributed to whom.
[ ] Stop distribution of the affected artifact if the exposure is severe, to avoid compounding it.
[ ] Engage counsel before responding to any demand — an unadvised admission can convert a curable lapse into an expensive one.
[ ] Preserve evidence under litigation-hold discipline: build logs, dependency manifests, the offending artifact, and the compliance record.
[ ] Investigate and remediate: confirm a violation actually occurred (many demands overreach), find the root cause, fix it, and consider counsel-guided outreach — most enforcers want compliance, not damages.

The cooperative path is almost always the cheap path. The dominant open source enforcers — the Software Freedom Conservancy, the FSF, individual copyright holders like the BusyBox and BlueZ maintainers — pursue compliance first and damages second; the point of SFC v. Vizio was to obtain source code, not a verdict. Even where money is on the table, as in Entr'ouvert v. Orange, the leverage came from years of non-compliance, not from a single good-faith slip promptly cured. Confirm the violation is real before you concede anything: a demand that asserts "you must open-source your entire product" because you used a permissive library, or a dynamically linked LGPL library you can already relink, is overreaching, and counsel should say so. The trade-secret and privilege disciplines that govern any incident response apply here too — see When a Breach Hits Your Crown Jewels: A Trade Secret Incident-Response Checklist.

A Worked Hypothetical, Start to Finish

To see the phases interlock, follow one invented company through the whole loop.

Northwind Analytics (hypothetical) is a data-visualization startup preparing for a Series B, and its lead investor demands an open source audit. Phase 1 scopes three products: a desktop app it distributes as a signed installer, a browser SDK its customers embed in their own sites, and a hosted dashboard. The installer and the SDK are distributed; the dashboard is hosted and therefore gets separate AGPL scrutiny.

Phase 2 resolves lockfiles across the Node, Python, and Rust portions of the stack, then scans the actual installer and the Docker image behind the dashboard. The lockfile scan is uneventful. The artifact scan is not: the installer bundles a media codec, vendored by hand into /third_party two years earlier by a since-departed engineer, that the manifest never mentioned. Phase 3 classifies it — GPLv2-only — and flags a second problem: the dashboard image contains a modified build of an AGPL-licensed charting server the team had assumed was "just infrastructure." Classification also surfaces a quiet attribution gap: forty MIT and Apache components whose notices never made it into the SDK's distribution.

Phase 4 tiers the findings. The vendored GPLv2 codec, statically bound into a distributed installer with no source offer, is critical. The modified AGPL charting server, reachable by users over the network, is critical for a different reason — Section 13. The forty missing notices are a real but lower-severity attribution deficit. Phase 5 remediates: the codec is removed in favor of a permissively licensed equivalent (a two-day change now, versus the six-month rewrite it would have been after the deal closed); the AGPL server is isolated only after counsel confirms the boundary is genuine, and where isolation is doubtful, replaced; and the NOTICE files are fixed by wiring generation into the build. Phase 6 installs a green/yellow/red gate in CI so the next vendored GPL codec fails the build instead of shipping, and starts emitting a CycloneDX SBOM with every release — which, come Phase 7, is exactly the artifact the investor's counsel asks for. Northwind walks into diligence with a clean scan, a defensible inventory, and a story about catching and fixing rather than being caught. That is the entire value proposition of running the checklist before someone runs it for you.

Common Mistakes

Scanning the manifest, not the lockfile — and so missing the transitive dependencies where obligations actually live.
Assuming SaaS is a universal copyleft shield — true against ordinary GPL, false against the AGPL's network clause.
Hand-maintaining a NOTICE file — so it is wrong the moment the next dependency changes; generate it from the build.
Waving permissive licenses through — quietly accumulating Apache NOTICE and MIT/BSD attribution failures on the theory that "only copyleft matters."
Calling isolation done without legal review — when a shared header or a static link has already pulled the component back across the derivative-work line.
Verifying at the repository, not the artifact — and missing everything baked into a container base image or firmware blob.
Tracking license types but not license changes — and sleeping through a relicensing from Apache to the BSL on a routine upgrade.
Discovering your open source problem in the buyer's diligence scan — late, adversarial, and priced against you.

Primary Authority and Key Sources

License conditions as copyright scope. Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008) (open source license terms are conditions limiting the scope of the copyright grant); the covenant-versus-condition framework, MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010). Underlying statutory framework: 17 U.S.C. § 106 (exclusive rights), § 101 (derivative-work definition), §§ 502–505 (remedies).

Enforcement and contract theory. Software Freedom Conservancy, Inc. v. Vizio, Inc. (Cal. Super. Ct.; tentative ruling Dec. 2025; trial Feb. 2026) (third-party-beneficiary contract theory for source-code requests); Artifex Software, Inc. v. Hancom, Inc., No. 16-cv-06982 (N.D. Cal. 2017) (GPL breach-of-contract claim allowed to proceed); SFC v. Best Buy Co., 2010 WL 4860780 (S.D.N.Y. 2010) (BusyBox firmware enforcement); Entr'ouvert v. Orange S.A., Paris Court of Appeal (Feb. 14, 2024) (~€860,000 award for GPLv2 violation); Neo4j, Inc. v. PureThink, LLC / Neo4j v. Suhy (9th Cir. 2021) (rejecting removal of a Commons Clause rider from AGPL). See also Wallace v. International Business Machines Corp., 467 F.3d 1104 (7th Cir. 2006) (the GPL does not violate the antitrust laws); Planetary Motion, Inc. v. Techsplosion, Inc., 261 F.3d 1188 (11th Cir. 2001) (GPL distribution as trademark-establishing use in commerce); Google LLC v. Oracle America, Inc., 141 S. Ct. 1183 (2021) (API reuse as fair use; derivative-work boundaries left open).

License families. GNU GPL v2 and v3; GNU LGPL v2.1 and v3; GNU AGPL v3 (§ 13 network clause); Apache License 2.0 (§ 4(d) NOTICE; § 3 patent-termination); the MIT, BSD, and ISC permissive licenses; Mozilla Public License 2.0 and the Eclipse Public License (weak copyleft). Source-available: SSPL, Business Source License, Elastic License 2.0, and the Commons Clause rider — none OSI-approved.

Standards and policy. Executive Order 14028, "Improving the Nation's Cybersecurity" (May 12, 2021); the EU Cyber Resilience Act; OpenChain (ISO/IEC 5230); SPDX (ISO/IEC 5962) and CycloneDX SBOM formats; the Open Source Definition maintained by the Open Source Initiative. The combined-work, dynamic-linking, and AGPL-network questions remain unsettled in U.S. appellate law — escalate them to counsel rather than guessing.

Related UpLaw Resources

Related Checklists

Related Guides and Articles

Related Toolkits

This checklist is general information, not legal advice. Open source licensing law continues to develop, and several questions central to it — the SFC v. Vizio litigation, the dynamic-linking and combined-work boundary, the AGPL network clause, and the provenance of AI-generated code — remain unresolved. Consult qualified intellectual-property counsel about your specific facts.