Checklist · Intellectual Property and Technology

The Open Source Compliance Playbook: A Complete Collection of Working Checklists

Type
Checklist
Jurisdiction
National
Date
2024-11-10
Topic
Intellectual Property and Technology

Open source compliance rarely fails because the law is hard; it fails because no one runs the list. A modern application resolves into thousands of licensed components that change every time a developer types install, and the burdensome obligations attach silently at the moment of distribution. This playbook is the operational spine of a compliance program: sequenced, working checklists for every phase, from audit scoping and component discovery through license classification, copyleft and derivative-work analysis, gap assessment, remediation, the standing program, M&A diligence, SBOM generation, and incident response. Each list is anchored to the governing law, from Jacobsen v. Katzer and the covenant-versus-condition line to the BusyBox campaigns, Artifex v. Hancom, and SFC v. Vizio, so an engineer or in-house lawyer can see why every box earns its place. It is the operational companion to our narrative analysis of open source licensing traps, and a research-grade reference for teams that would rather check a box than answer a demand letter.

The Open Source Compliance Playbook: A Complete Collection of Working Checklists

Intellectual Property and Technology > Open Source Compliance | Published 10 November 2024 - Updated 11 December 2024 | UpLaw - uplaw.us

A working reference for the whole life cycle of open source compliance: scope the audit, find every component, classify the licenses, assess the copyleft, remediate the gaps, stand up a durable program, and survive the high-stakes moments when a deal or a demand letter concentrates all of that risk into a single event.

Keywords: open source compliance checklist, GPL compliance, copyleft scope, software composition analysis, SBOM, SPDX, CycloneDX, AGPL, LGPL relinking, attribution, M&A diligence, incident response

Why This Playbook Exists

Ask an engineering director how many open source licenses ship inside her flagship product and watch the number climb as she thinks about it. The honest answer is almost never a number she carries in her head. A single web service declares perhaps forty direct dependencies; each of those declares its own; and within three or four hops the resolved dependency graph has swollen into the thousands. Every node on that graph is a copyrighted work governed by a license. Most of those licenses ask for very little. A handful can quietly obligate a company to publish source code it considered its crown jewels. And the whole structure is rewritten every time someone runs npm install, go get, or pip install.

That is the real shape of open source risk, and it explains why the failure mode is so consistent. The problem is not that the obligations are obscure. By the standards of intellectual property law, the major open source licenses are unusually plain-spoken documents. The problem is that the obligations attach to everything, automatically, at the speed of a build pipeline, and a missed obligation does not announce itself. It waits. It surfaces when a copyright holder sends a letter, when an acquirer's diligence team runs its own scanner, or when a court is asked to decide what the license actually required.

The doctrinal foundation was settled almost two decades ago and has not meaningfully eroded since. In Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), the Federal Circuit held that the conditions attached to an open source license are not mere contract promises floating alongside the copyright grant; they define the scope of that grant. Use the software outside those conditions and you are not simply a licensee in breach. You are, potentially, a copyright infringer, exposed to the full remedial arsenal of the Copyright Act: injunctive relief under 17 U.S.C. § 502 and statutory damages under § 504, not the modest fee you would have paid had there been a fee to pay. Open source is free as in liberty and free as in no invoice. It is emphatically not free as in unconditional. Our narrative treatment of the doctrine, open source licensing traps in enterprise software, works through the caselaw and strategy; for the structural basics of what open source is and how the licenses are built, start with open source software licenses, compliance, and risk.

This collection is the operational half of that pairing. Where the guides explain the law, these checklists let a team execute it: during an audit, before a release, inside an acquisition, and at two in the morning when a demand letter has landed. The list-and-table format is deliberate. Compliance, like every complex process that exceeds working memory, becomes tractable the instant you stop trying to hold it in your head and start working through steps that can be delegated, automated, and checked. But a bare checkbox teaches nothing, so each item here carries enough legal context to tell you why it exists and what breaks if you skip it.

One caution before the first list. A checklist is a tool, not a substitute for judgment, and nothing here is legal advice. The hardest questions in this field, whether two linked modules form one "work," whether an arm's-length API call keeps two programs separate, whether a SaaS deployment trips the AGPL's network clause, turn on specific facts and on caselaw thinner than anyone would like. Where a checklist says escalate to counsel, it means precisely that.

The one distinction that governs everything: covenant versus condition

Before scoping anything, internalize the legal hinge on which open source enforcement turns. A license term can be either a covenant (a promise whose breach sounds in contract) or a condition (a limit on the license grant whose breach sounds in copyright). The difference is the difference between a bill for damages and an injunction that can pull a product off the market. Jacobsen treated the open source attribution and notice terms as conditions. The Ninth Circuit's framework in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010), refined the test: a licensee's violation is copyright infringement only where the disputed term 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 under 17 U.S.C. § 106; a mere covenant breach is "only" a contract claim. See also Sun Microsystems, Inc. v. Microsoft Corp., 188 F.3d 1115 (9th Cir. 1999). Copyleft licenses are drafted, deliberately, to read as conditions. That drafting choice is what gives the GPL its teeth, and it is why "we'll just pay a license fee later" is not a coherent remediation plan when there was never a fee and the remedy on the table is disclosure of your source code.

Part I: Scoping the Audit Before You Scan

Preparation decides whether an audit produces a defensible inventory or a ten-thousand-line report that engineering quietly agrees to ignore. The most common audit failure is not a missed component. It is a scan with no prioritization, no owner, and no theory of what actually matters, which trains the organization to treat compliance as noise.

Checklist 1.1: Map the distribution surface

Every scoping conversation should begin with the single most legally consequential question in open source: what do you distribute, and to whom? Nearly every burdensome obligation, the GPL's source-disclosure duty, the LGPL's relinking requirement, the attribution and NOTICE duties that ride on almost all licenses, is triggered by distribution, not by mere internal use. Software you run only on your own servers, for your own purposes, sits in a materially safer place. The great exception is the GNU Affero General Public License, whose Section 13 was written specifically to treat network interaction as a distribution-equivalent event and thereby close the "SaaS loophole." Map the distribution surface first; the risk tiers fall out of it.

# Scoping item Owner Status
1 Inventory every product shipped externally as a binary ☐
2 Inventory every product shipped externally with source ☐
3 List anything delivered to customers on-premise or as an appliance ☐
4 Flag every product offered as SaaS or a hosted API (AGPL analysis) ☐
5 List products embedded in hardware or firmware (highest copyleft risk) ☐
6 Identify white-labeled or OEM products a partner redistributes ☐
7 Note internal tools that reach contractors, auditors, or partners ☐
8 Record products with community/enterprise or free/paid editions ☐
9 Capture dual-licensed or commercially licensed components already in use ☐
10 Confirm the agreed scope with legal, engineering, and the business ☐

A two-axis triage. Prioritize by the two variables that actually drive exposure: whether the artifact leaves your walls, and whether it carries copyleft code.

                         Distributed externally?
                             YES          NO
                        ┌───────────┬───────────┐
    Contains       YES  │  CRITICAL │  ELEVATED │
    copyleft?           │           │  (watch)  │
                        ├───────────┼───────────┤
                   NO   │   HIGH    │    LOW     │
                        └───────────┴───────────┘

The "ELEVATED (watch)" quadrant, copyleft in an internal-only tool, deserves a note because it lulls teams to sleep. It is genuinely low risk today. But internal tools have an unnerving tendency to become products, contractors have a way of becoming distribution channels, and the internal platform you laced with GPL code is exactly the asset a future buyer will scrutinize line by line. Document the assumption that keeps you safe, "internal use only, not distributed", so that when it changes, someone notices before the buyer's scanner does.

Checklist 1.2: Gather the existing record

Existing documentation is simultaneously a head start and a confession. It shows what institutional knowledge exists, and by its gaps, where the bodies are buried. Treat a stale NOTICE file as evidence, not comfort: a third-party notices file last regenerated in 2021 is itself proof of an attribution gap that has been accumulating for years.

  • [ ] Collect existing component inventories (treat each as a hypothesis to verify, not gospel)
  • [ ] Gather NOTICE and THIRD-PARTY-NOTICES files from every shipped product
  • [ ] Pull LICENSE files from the repositories
  • [ ] Locate prior audit reports and compliance assessments
  • [ ] Find any written open source policy, approved-list, or prohibited-list
  • [ ] Retrieve records of past incidents, demand letters, or remediation
  • [ ] Gather commercial or dual-license agreements (e.g., a paid Qt or MySQL license bought to avoid the GPL)
  • [ ] Locate contributor license agreements for projects you contribute to
  • [ ] Pull third-party vendor agreements; their embedded open source is now your open source

That last item is where diligence teams find the ugliest surprises. When you license a component from a vendor, you inherit whatever open source the vendor baked into it, along with the obligations. The flow-through of open source risk through the supply chain is precisely why acquirers and downstream customers now demand a bill of materials, a theme we return to in Part VII.

Checklist 1.3: Secure technical access and tooling

Software composition analysis (SCA) is only as good as its access and its coverage. The two most common reasons a scan silently under-reports are that it never received the private-registry credentials needed to resolve dependencies, and that it scanned source but never the built artifact, where statically linked and vendored code actually come to rest.

Requirement Why it matters Verified
Read access to all in-scope repositories, including submodules Submodules hide whole third-party projects ☐
Access to build artifacts for binary scanning The artifact, not the repo, is what you distribute ☐
Credentials for private package registries Unresolved deps read as "no findings," falsely ☐
Pipeline access to integrate scanning One-off scans rot; continuous ones don't ☐
Access-controlled storage for findings Findings can be sensitive and privileged ☐
Valid licenses for commercial SCA tools Coverage varies by ecosystem and tool ☐
Tool configuration for your languages and frameworks A misconfigured scanner is confidently blind ☐

A word on the tools themselves, because the legal weight teams put on them is often misplaced. No scanner is authoritative. Manifest-based scanners read package-lock.json, pom.xml, and the like; they are excellent at cataloging declared dependencies and nearly blind to copied code. Snippet or fingerprint scanners compare your source against a corpus of known open source and catch copy-paste, at the cost of false positives. Binary composition analysis catches what actually made it into the shipped artifact. Mature programs run more than one and reconcile the results. Above all, treat a tool's license identification as a lead to verify, not a verdict, a discipline we operationalize in Part III.

Checklist 1.4: Align the humans

Audits succeed when engineers experience them as quality work and collapse when they smell a witch hunt. The single most valuable sentence at a kickoff is: findings are for fixing, not for blame. A developer who pulled in a GPL library to hit a Friday deadline was responding rationally to the incentives you set. Fix the incentives, not the engineer.

  • [ ] Brief engineering leadership on objectives, scope, and timeline
  • [ ] Name a technical point of contact for each in-scope codebase
  • [ ] Establish an escalation path for decisions that need business input
  • [ ] Define who has authority to approve remediation approaches
  • [ ] Set realistic expectations for developer time during the audit
  • [ ] State explicitly that findings drive improvement, not discipline
  • [ ] Agree on reporting cadence and format up front
  • [ ] Define concrete, checkable criteria for "audit complete"

Part II: Finding Every Component

Everything downstream depends on completeness here, because you cannot comply with a license you do not know you are using. This is also where most real-world violations originate, and for a reason that surprises non-engineers: the riskiest components are precisely the ones the package manager never records. Code copied straight into the tree. A library fused into a container base image. A driver compiled into firmware. Each is invisible to a manifest and lethal to an audit that trusts one.

Checklist 2.1: Scan the lockfiles, not just the manifests

Package managers are the primary, but never the only, source of open source in modern software. The cardinal rule has the force of a commandment: scan the lockfile. A manifest like package.json records intent, "I want some version of express." The lockfile records reality, the exact resolved version of express and every transitive dependency it dragged in behind it. Obligations attach to reality, not to intent, which is why an audit that reads only manifests systematically under-counts the very transitive components most likely to carry a surprising license.

Ecosystem Manifest / lockfile Scanned Transitive resolved
npm package.json / package-lock.json ☐ ☐
Yarn / pnpm yarn.lock / pnpm-lock.yaml ☐ ☐
pip / Poetry requirements.txt, Pipfile.lock / poetry.lock ☐ ☐
Maven / Gradle pom.xml / gradle.lockfile ☐ ☐
NuGet packages.lock.json, *.csproj ☐ ☐
Go modules go.mod / go.sum ☐ ☐
Cargo (Rust) Cargo.lock ☐ ☐
Composer / Bundler composer.lock / Gemfile.lock ☐ ☐
CocoaPods / Swift PM Podfile.lock / Package.resolved ☐ ☐

Checklist 2.2: Hunt down vendored and copied code

"Vendored" code, third-party source copied directly into your repository, is the silent killer of package-manager-only audits, because it appears in no manifest anywhere. It is also where the gravest copyleft violations hide. A developer who pastes one GPL utility file into a proprietary codebase has done something no dependency resolver will ever flag, and something a snippet scanner or a plaintiff's expert absolutely will.

  • [ ] Scan the usual vendor directories: /vendor, /third_party, /external, /lib
  • [ ] Run fingerprint/snippet matching against open source corpora
  • [ ] Look for orphan license or header files that betray a copied component
  • [ ] Inspect large, minified, or bundled files for embedded libraries
  • [ ] Check C/C++ header files copied from external projects
  • [ ] Review build scripts for downloads not captured in any manifest
  • [ ] Enumerate git submodules pointing at third-party repositories
  • [ ] Read Dockerfiles and container manifests for base images and installed packages

Checklist 2.3: Verify at the artifact level, and mind the firmware

What you build is not always what you wrote. A Dockerfile beginning FROM ubuntu silently inherits hundreds of packages under dozens of licenses; a statically linked binary fuses third-party object code into your executable in a way with direct copyleft consequences, developed in Part IV. Verify the artifact you actually distribute, not the repository you happen to scan.

Analysis Target Done Findings recorded
Binary composition analysis Compiled executables ☐ ☐
Shared-library identification .so, .dll, .dylib ☐ ☐
Container base-image analysis Dockerfile FROM lines ☐ ☐
Container layer analysis Installed OS packages ☐ ☐
Firmware extraction Embedded system images ☐ ☐
Mobile package analysis APK / IPA contents ☐ ☐

Firmware earns its own line because the enforcement record singles it out. The most consequential open source enforcement of the last fifteen years, the BusyBox campaigns that produced Software Freedom Conservancy, Inc. v. Best Buy Co. and a default judgment for willful copyright infringement complete with a permanent injunction, statutory damages, and attorney's fees; the German gpl-violations.org injunctions won by Harald Welte against router makers; and Software Freedom Conservancy, Inc. v. Vizio, Inc., 587 F. Supp. 3d 1004 (C.D. Cal. 2022), all involved GPL'd code compiled into consumer-electronics firmware and shipped without the corresponding source. If you ship hardware, your firmware is your single highest-risk distribution surface, and it is the surface a package-manager scan is least likely to see. For how post-sale control over that firmware collides with copyleft, see the right to repair reckoning.

Checklist 2.4: Reconcile the inventory into something you can swear to

A scan result is a draft inventory, not a final one. Reconciling multiple methods and spot-checking by hand is the difference between a list you hope is right and an inventory you can stand behind in a diligence representation.

  • [ ] Cross-reference package-manager results against code-scan results
  • [ ] Investigate every discrepancy between methods (discrepancies are signal)
  • [ ] Confirm component versions match what is actually deployed
  • [ ] Confirm all in-scope products were scanned
  • [ ] Confirm transitive dependencies were captured, not only direct
  • [ ] Flag development-only and test dependencies distinctly from production
  • [ ] Manually spot-check 10–20 components to gauge accuracy
  • [ ] Document every component that could not be identified

The development-versus-production boundary is more than housekeeping; it is a legal line. A GPL-licensed build tool or test framework that never ships in your distributed artifact generally creates no distribution obligation at all, because it is used, not conveyed. Misclassify it as production and you burn a remediation cycle chasing a phantom. Misclassify a production dependency as dev-only and you ship a live violation. Get the boundary right, and record the reasoning, because it is exactly the judgment an acquirer's counsel will probe.

Worked example (hypothetical). Tern Analytics, a fictional data-tooling startup, runs a clean manifest scan across its Python service and reports "all permissive, all clear." A second, snippet-based scan of the built container flags a cluster of matched lines in an image-processing routine. The lines trace to a GPLv3 library a former contractor had vendored into /lib/imgproc eighteen months earlier, deleting the license header but not the code. The manifest never knew it existed. That single copied file, shipped in a distributed appliance, is the whole ballgame under Jacobsen, because using the code outside the GPL's conditions is potential copyright infringement of the whole combined artifact, not a tidy licensing footnote. Tern's real exposure was created the day the file was pasted in; the audit only made it visible.

Part III: Classifying the Licenses

Not all licenses are created equal, and the entire economics of a compliance program flow from classification. An MIT component costs one line in a NOTICE file. An unaddressed AGPL component in a SaaS product can cost you the confidentiality of your source code. Because Jacobsen makes license conditions define the scope of the copyright grant, misclassification is not a clerical error; it is the on-ramp to infringement exposure. Classify first, because every downstream obligation, and every remediation budget, follows from the answer.

Checklist 3.1: Verify the detected license

SCA tools identify licenses by pattern-matching text. They are confident, and they are sometimes wrong. They miss dual-licensing options, they can read "GPL-2.0-or-later" as "GPL-2.0-only" (a distinction that decides compatibility), and they choke on license exceptions, such as the GPL linking exception that makes GNU Classpath and libgcc safe to link. Verify anything high-risk or unusual against an authoritative source before you rely on it.

  • [ ] Locate the original license file in the component's own repository
  • [ ] Compare detected text against an authoritative source (the SPDX License List, OSI)
  • [ ] Check for exceptions or additional permissions (e.g., the GPL linking exception)
  • [ ] Verify the license attaches to the specific version you use (projects relicense)
  • [ ] Record any "or later" option ("GPL-2.0-or-later" vs. "GPL-2.0-only")
  • [ ] Identify dual-licensing paths (a commercial option that sidesteps copyleft)
  • [ ] Run down a license for anything the tool reports as "unlicensed"
  • [ ] Flag every component whose license cannot be determined

The unlicensed case deserves dwelling on, because intuition runs backward here. A component published with no license at all is not free to use; it is "all rights reserved" by default under copyright. The absence of a license is the most restrictive condition imaginable, not the least. When a scanner reports "no license detected," it is flagging a problem, not clearing one. Whether the copied material is even copyrightable in the first place is occasionally a live question, an issue the Supreme Court touched in the API context in Google LLC v. Oracle America, Inc., 141 S. Ct. 1183 (2021), and one we treat in depth in POSIX standards and the law. But "maybe it isn't protected" is a litigation posture, not a compliance plan.

Checklist 3.2: Place each license on the obligation spectrum

The single most useful mental model is the permissive / weak-copyleft / strong-copyleft spectrum. As you move down it, the obligations expand from "give credit" to "share your changes to these files" to "share the source of the whole combined work."

Permissive (attribution, and little else). You may use, modify, and redistribute, even inside closed-source products, so long as you preserve the copyright notice and license text. These are the workhorses of commercial software.

License SPDX ID Patent grant Notable term
MIT MIT None express None
BSD 2-Clause BSD-2-Clause None None
BSD 3-Clause BSD-3-Clause None No-endorsement clause
Apache 2.0 Apache-2.0 Express NOTICE duty; patent-retaliation termination
ISC ISC None None
Zlib Zlib None Mark modified source
Unlicense / CC0 Unlicense / CC0-1.0 None Public-domain dedication (avoid CC0 for code)

Apache 2.0 is the most important entry and the one teams most often under-comply with. Beyond attribution, its Section 4 imposes an affirmative duty to propagate any NOTICE file the upstream project ships, a real obligation, not a courtesy. And its Section 3 embeds a patent bargain: an express patent license that terminates automatically if you sue the licensor for patent infringement over the work. That express grant is also Apache 2.0's great virtue and the reason patent-conscious enterprises default to it, a point we develop in how the law protects software.

Weak (file- or library-scoped) copyleft. You must share modifications to the open source itself, but you can keep the surrounding proprietary code closed if you respect the boundary. The boundary is the entire game.

License SPDX ID Copyleft scope Linking
LGPL 2.1 / 3.0 LGPL-2.1 / LGPL-3.0 Library Yes, with relinking conditions
MPL 2.0 MPL-2.0 File Yes
EPL 2.0 EPL-2.0 Module Yes
CDDL 1.0 CDDL-1.0 File Yes (note CDDL/GPL incompatibility)

MPL 2.0 is the cleanest weak-copyleft license to live with, because its copyleft is scoped to the individual file. Modify an MPL file and you must share that file under MPL; add wholly new files of your own and they stay yours. Mozilla's drafters deliberately drew the line somewhere a developer can see and reason about.

Strong (work-scoped) copyleft. The headline: distribute a work that incorporates this code and you must offer the complete corresponding source of the whole combined work under the same license. This is the clause that reaches into proprietary code, and the reason GPL-family components cause the majority of serious incidents.

License SPDX ID Network trigger Patent grant
GPL 2.0 GPL-2.0 No Implied/limited
GPL 3.0 GPL-3.0 No Express
AGPL 3.0 AGPL-3.0 Yes (§ 13) Express

The AGPL's Section 13 is the trap laid for SaaS companies. Ordinary GPL is triggered by distribution; run GPL code only on your own servers and you arguably never "convey" it, so the source-disclosure duty never fires. The AGPL slams that door: if users interact with your modified AGPL program over a network, you must offer them the corresponding source as if you had shipped it. For a cloud business, an unnoticed AGPL dependency converts "we just run it internally" into "we must publish our source."

Licenses that look open but aren't. Several popular licenses live on GitHub and pass for open source without being OSI-approved.

License The concern Action
SSPL Network copyleft reaching the whole service stack Legal review
Commons Clause A bolted-on "no selling" restriction Treat as proprietary
BSL / Business Source License Time-delayed open source; restricted until a change date Read the additional-use grant
Elastic License 2.0 Source-available with use restrictions Treat as proprietary
JSON License The "used for Good, not Evil" clause; legally unusable Many organizations ban outright
Custom / Unknown Unpredictable obligations Legal review; do not guess

That these are enforceable, non-open-source licenses despite their appearance is the reminder that "it's on GitHub" tells you nothing about your obligations. For how these terms surface in commercial paper, see software license agreements: key terms and how to negotiate them.

Checklist 3.3: Assess compatibility across the combination

When you combine components into a single distributed work, their licenses must coexist. Incompatibility is not academic. GPL-2.0-only and Apache-2.0 are famously incompatible, because the Free Software Foundation reads Apache 2.0's patent and indemnity terms as restrictions GPLv2 forbids; and GPL-2.0-only cannot mix with GPL-3.0-only because each demands the whole work be under its exact terms. The good news is that GPLv3 was drafted to be compatible with Apache 2.0, resolving one of the ecosystem's most painful collisions.

  • [ ] List every unique license present in the product
  • [ ] Identify the most restrictive; it may govern the whole combination
  • [ ] Check GPL-2.0-only against any Apache-2.0 components (incompatible)
  • [ ] Confirm no AGPL component sits inside a proprietary SaaS service
  • [ ] Check for GPL-2.0-only versus GPL-3.0-only collisions
  • [ ] Document every conflict identified
  • [ ] Determine whether a version bump or an "or later" clause resolves it
  • [ ] Route unresolvable conflicts to remediation (Part V)
If your product is PROPRIETARY (closed source):
  ├── Permissive (MIT/BSD/Apache): OK (attribution; Apache NOTICE)
  ├── MPL 2.0:                     OK (share modified MPL files only)
  ├── LGPL, dynamically linked:    OK (preserve relinking ability)
  ├── LGPL, statically linked:     CARE (provide relinkable form)
  ├── GPL (any combination):       PROBLEM (source of the whole work)
  └── AGPL (network / SaaS use):   PROBLEM (Section 13 network trigger)

Part IV: Assessing the Gaps

This is where findings become issues, and where the doctrine lawyers argue about meets the architecture engineers actually built. Two questions drive nearly every gap: have we honored attribution on the easy permissive components, and have we correctly analyzed the copyleft components, where the analysis turns on how the code is combined?

Checklist 4.1: Attribution compliance

Attribution is the most under-rated obligation in open source, because it is both the easiest to satisfy and the easiest to forget. Nearly every license, permissive and copyleft alike, requires you to preserve copyright notices and reproduce license text. The stakes are bracingly concrete: the obligation the defendant breached in Jacobsen was, at bottom, an attribution-and-notice requirement, and the Federal Circuit treated its violation as potential copyright infringement. The Jacobsen matter finally settled in 2010 with the defendants paying $100,000 and accepting a permanent injunction, a reminder that "just a missing credit" is the exact failure that turned a hobbyist model-railroad dispute into a landmark federal opinion.

Attribution element Present Complete Accurate
NOTICE / THIRD-PARTY-NOTICES file in the distribution ☐ ☐ ☐
Copyright notices for every component that requires them ☐ ☐ ☐
Full license text reproduced where required ☐ ☐ ☐
Attribution accessible to end users (not buried on a build server) ☐ ☐ ☐
Attribution generated from the current inventory ☐ ☐ ☐
Apache 2.0 NOTICE files propagated correctly ☐ ☐ ☐
Build process auto-generates attribution (manual means stale) ☐ ☐ ☐

"Accessible to end users" is a genuine requirement, so satisfy it where a user can actually look: Help → About or an install-directory LICENSE for desktop software; Settings → About → Open Source Licenses on mobile; a footer link to /third-party-notices on the web; a --licenses flag for a CLI; and printed or on-device documentation for hardware. If the only copy of your attribution lives in a CI artifact no customer will ever see, you have not complied; you have merely generated the file.

Checklist 4.2: Copyleft exposure and the derivative-work question

Strong copyleft is where the legal analysis gets genuinely hard, because the obligation turns on whether your proprietary code and the GPL code together form a single "work based on the Program" (GPLv2) or a "covered work" (GPLv3), essentially, whether one is a derivative of the other within the meaning of 17 U.S.C. § 101. The Free Software Foundation's well-known position is that linking, static or dynamic, generally creates such a combined work, while arm's-length communication between separate programs (pipes, sockets, command-line invocation between independent processes) generally does not. That position is influential, and it drew support from the Jacobsen court's general framing, but no U.S. appellate court has squarely blessed the FSF's dynamic-linking theory. The surrounding copyright law is itself unsettled: the Ninth Circuit's derivative-work cases, such as Lewis Galoob Toys, Inc. v. Nintendo of America, Inc., 964 F.2d 965 (9th Cir. 1992), require that a derivative work incorporate the protected work in some "concrete or permanent form," which is exactly the question dynamic linking raises. This is why the honest terminus of the analysis is so often escalate to counsel. Run the questions; let the answers set the tier.

Question (per strong-copyleft component in a distributed product) Yes No N/A
Is the product distributed externally (not internal-only)? ☐ ☐ ☐
Is the component linked (static or dynamic) with proprietary code? ☐ ☐ ☐
Does proprietary code call into the component's functions? ☐ ☐ ☐
Is the component modified from its original form? ☐ ☐ ☐
Is it compiled into a single binary with proprietary code? ☐ ☐ ☐
For AGPL: do users interact with it over a network? ☐ ☐ ☐
Is a complete-corresponding-source offer required, and being made? ☐ ☐ ☐
Scenario Risk Recommended action
GPL in an internal-only tool Low Document the no-distribution limitation; revisit if it ships
GPL in a separate process, arm's-length API Medium Legal review of the derivative-work question
GPL dynamically linked in a distributed app High Isolate, replace, or comply
GPL statically linked into a distributed binary Critical Remediate immediately
AGPL in a user-facing web/SaaS service Critical Remediate immediately

Worked example (hypothetical). Northwind Imaging, an invented maker of warehouse-scanning robots, statically links a GPLv2 motion-planning library into the same firmware binary as its proprietary navigation stack, ships the robots to customers, and offers no source. Under Jacobsen, Northwind is using the library outside the scope of its license, and a static link into one binary is the paradigm case the FSF treats as a combined work. Northwind's exposure is not "the fee it should have paid", there was no fee, but copyright infringement, with the GPLv2 source obligation reaching the entire firmware image. This is precisely the fact pattern at the heart of the Vizio litigation. The menu of fixes is not subtle: isolate the library into a separate process, swap in a permissively licensed equivalent, or comply by releasing the corresponding source. What Northwind cannot do is nothing.

Checklist 4.3: LGPL relinking verification

The LGPL is the "have your cake" license: it lets you link a copyleft library into proprietary software, but only if you preserve the user's ability to swap in a modified version of the library. The whole license is engineered around that one right. Dynamic linking satisfies it almost for free, the user drops in a replacement .so or .dll. Static linking is where teams stumble, because a statically linked binary cannot be relinked unless you hand the user what they need to do it.

  • [ ] Determine whether the component is dynamically or statically linked
  • [ ] Dynamic: verify users can substitute a modified library build
  • [ ] Static: provide object files (or relinkable form), or switch to dynamic linking
  • [ ] Provide the LGPL text and the required copyright notices
  • [ ] LGPL 3.0 on "User Product" hardware: satisfy GPLv3 § 6 "Installation Information" (the anti-Tivoization rule)
  • [ ] Record the linking method in your compliance file
  • [ ] Confirm the build actually preserves the substitution ability you claim

The anti-Tivoization requirement in GPLv3 § 6 collides directly with locked-down consumer hardware, and it is a live front in the broader fight over post-sale control mapped in the right to repair reckoning.

Checklist 4.4: Process gaps

A point-in-time audit tells you whether you are compliant today. A process audit tells you whether you will stay compliant after the next sprint. The most expensive failures are the ones a working process would have caught automatically, which is why mature programs shift compliance "left" into the developer's workflow instead of bolting it on at release.

Process area Exists Documented Followed Effective
New-component approval workflow ☐ ☐ ☐ ☐
Developer training on license families ☐ ☐ ☐ ☐
Approved-component and prohibited-license lists ☐ ☐ ☐ ☐
CI-integrated compliance scanning ☐ ☐ ☐ ☐
Attribution-generation automation ☐ ☐ ☐ ☐
Incident-response procedure ☐ ☐ ☐ ☐
Compliance metrics tracking ☐ ☐ ☐ ☐

Part V: Remediation

A gap is a finding; remediation is the fix. There are really only four moves: correct the attribution, remove the component, isolate it behind an arm's-length boundary, or comply with its terms. Choosing among them is a joint engineering-and-legal decision, and the option that looks cheapest at first is almost never the one that is cheapest in the end.

Checklist 5.1: Attribution remediation

Most attribution gaps are fixed once and prevented forever by the same intervention: generate the NOTICE file from the build, not by hand. A hand-maintained attribution file is wrong the moment the next dependency changes.

  • [ ] Generate a current component list with license data
  • [ ] Build a NOTICE / THIRD-PARTY-NOTICES template with all required sections
  • [ ] Populate copyright notices for every attributed component
  • [ ] Include full license text where the license requires reproduction
  • [ ] Wire attribution generation into the build pipeline
  • [ ] Confirm attribution updates automatically when dependencies change
  • [ ] Verify the file actually appears in the distributed package
  • [ ] Confirm end-user accessibility (see the locations in 4.1)

Checklist 5.2: Removing the component

When the cleanest fix is to rip the component out, do it with a documented comparison, because a future acquirer will ask why you chose what you chose.

  • [ ] Map every place the component is used
  • [ ] Assess what functionality it actually provides
  • [ ] Research permissively licensed alternatives
  • [ ] Evaluate alternatives for functional equivalence, maintenance health, and security history
  • [ ] Implement the replacement and test for functional parity
  • [ ] Remove the original from every manifest and confirm it no longer appears in scans
  • [ ] Update attribution and record the decision and rationale
Factor Original Alternative A Alternative B
License GPL-3.0 MIT Apache-2.0
Functional match — 90% 100%
Maintenance Active Active Abandoned
Security history 2 CVEs 0 CVEs 5 CVEs
Migration effort — 2 days 5 days
Decision Remove Selected Rejected

Checklist 5.3: Architectural isolation

Isolation keeps a copyleft component while avoiding a combined-work problem by holding it at genuine arm's length: separate process, separate container, communication across a network or IPC boundary rather than a function call. The strategy rests on the FSF's own line between linking (combined work) and inter-process communication between independent programs (not a combined work). It is defensible, but "arm's length" must be real, because shared memory, shared headers, or any form of linking pulls the component back across the line.

  • [ ] Document the current integration architecture
  • [ ] Design the isolated architecture (separate process, container, or service)
  • [ ] Define the interface (REST, gRPC, IPC, pipe)
  • [ ] Ensure it is truly arm's-length: no shared memory, headers, or linking
  • [ ] Implement and verify no compilation or linking dependency remains
  • [ ] Test functionality through the isolated interface
  • [ ] Obtain legal review of isolation adequacy (the step you cannot skip)
  • [ ] Monitor for architectural drift that re-introduces coupling
Does removing the component break functionality?
  ├── NO  → Remove it (Checklist 5.2)
  └── YES → Is a commercial / dual license available?
             ├── YES → Evaluate it (often cheaper than re-architecting)
             └── NO  → Can the function move to a separate process?
                        ├── YES → Implement process isolation (this list)
                        └── NO  → Counsel on derivative-work analysis,
                                  OR comply (release the source)

The dual-license branch is worth taking seriously. Many strong-copyleft projects, historically MySQL and Qt among them, offer a paid commercial license precisely so that companies can avoid the copyleft. Buying that license is frequently cheaper than a re-architecture, and it converts a hard legal question into a line item. These are the terms you will be negotiating, and the diligence you will be running, in the transactions mapped by the IP transactions toolkit.

Checklist 5.4: Resolving license conflicts

When two components carry incompatible licenses, the GPL-2.0-only-versus-Apache-2.0 classic, or GPL-2.0-only versus GPL-3.0-only, one of them has to change. Before re-engineering, check the cheap escapes: a newer upstream version under a friendlier license, or an "or later" clause that lets you upgrade into compatibility.

  • [ ] Identify the specific licenses in conflict
  • [ ] Check whether either component offers an alternative or dual license
  • [ ] Check whether a newer version carries a compatible license
  • [ ] Confirm the conflict is real (the components are actually combined in distribution)
  • [ ] If unavoidable, replace the component with fewer internal dependencies on it
  • [ ] Implement, verify the conflict is gone, and document the resolution

Part VI: Standing Up a Durable Program

Audits are photographs; programs are video. A codebase that was clean at audit accumulates new dependencies within days, which is why the only durable posture is a process that scans continuously, gates new components at the door, and verifies at every release. The objective is to make the compliant path the path of least resistance for a developer who is trying to ship.

Checklist 6.1: Developer onboarding

Compliance is won or lost at the developer, because the developer is who types install. Onboarding should leave a new engineer able to answer one question instinctively: can I add this dependency, and if I'm not sure, who do I ask?

  • [ ] Introduce the license families and what "copyleft" means
  • [ ] Walk through the company open source policy
  • [ ] Show the approved-component list and the request process
  • [ ] Teach how to check a license before adding a dependency
  • [ ] Explain attribution requirements and how they're met
  • [ ] Explain the real consequence of non-compliance (infringement, not just a fee)
  • [ ] Name the people and docs to consult
  • [ ] Capture written acknowledgment

Checklist 6.2: The new-component gate

A gate at the moment a component enters the codebase is the highest-leverage control in the entire program. It is far cheaper to decline a dependency than to surgically extract it from three shipped products eighteen months later.

Review step Passed Notes
Name, version, and source identified ☐
License identified and verified ☐
License on the approved list ☐
If not: legal review completed ☐
Security vulnerability check completed ☐
Maintenance status acceptable (recent releases) ☐
Business justification documented ☐
Approval recorded in the compliance system ☐

Checklist 6.3: Release verification

Every release is a fresh act of distribution, and therefore a fresh trigger for every distribution-based obligation. It is also where the SBOM gets cut.

  • [ ] SCA scan completed on the release candidate
  • [ ] No new components with unreviewed or prohibited licenses
  • [ ] No new copyleft components lacking an approved integration plan
  • [ ] Attribution current, accurate, and included in the package
  • [ ] SBOM generated (SPDX or CycloneDX) and archived with the release
  • [ ] Compliance sign-off obtained from the designated approver
  • [ ] Complete-corresponding-source offer prepared where copyleft requires it

Checklist 6.4: Quarterly review

Quarterly reviews catch drift before it metastasizes: new dependencies, newly disclosed vulnerabilities in old ones, upstream relicensing, and the slow rot of a NOTICE file nobody regenerated.

Review item Q1 Q2 Q3 Q4
Full SCA scan across all products ☐ ☐ ☐ ☐
Review components added this quarter ☐ ☐ ☐ ☐
Verify attribution files are current ☐ ☐ ☐ ☐
Check for newly disclosed vulnerabilities ☐ ☐ ☐ ☐
Update the approved-component and prohibited-license lists ☐ ☐ ☐ ☐
Verify developer-training completion ☐ ☐ ☐ ☐
Report metrics to leadership ☐ ☐ ☐ ☐

For a single-flow condensed version of this whole program, teams that want one checklist rather than a collection can use our open source software compliance practical checklist; the broader life-cycle roadmap lives in the software and open source licensing toolkit.

Part VII: The High-Stakes Moments

Certain events concentrate open source risk into a single deadline: a transaction, a regulatory requirement, a demand letter. These checklists are for those moments.

Checklist 7.1: M&A diligence (buyer)

Open source diligence has become a standard, sometimes deal-defining, workstream in software acquisitions. The reason is the acquisition risk every practitioner internalizes: a buyer who fails to diligence open source can acquire software, or a company whose principal asset is software, whose value is quietly diluted because copyleft has compromised the proprietary code, or whose products carry latent infringement exposure. The buyer's job is to scan independently rather than trust the target's representations, then to allocate residual risk through the deal documents. Founders on the other side of that table can prepare using our guide to getting diligence-ready before you raise.

Pre-LOI. Request the target's open source policy, its most recent audit report, and a description of what is distributed and how; form a first view of compliance maturity.

Detailed diligence.

  • [ ] Obtain repository access and run an independent SCA scan on all acquired products
  • [ ] Compare results against the target's disclosed inventory (the gaps are the story)
  • [ ] Identify copyleft inside proprietary products and any license conflicts
  • [ ] Identify components with unknown or unclear licenses
  • [ ] Tier each gap by severity (Part IV) and quantify remediation effort
  • [ ] Translate findings into business terms for the deal team

Deal documentation.

  • [ ] Include open source representations and warranties (e.g., that the company has not used OSS in any way that obligates it to disclose, license, or make available its proprietary source)
  • [ ] Negotiate indemnification for undisclosed compliance issues
  • [ ] Set pre-closing remediation conditions where warranted
  • [ ] Plan post-closing integration of the two compliance programs

Those representations and the indemnity that backs them are the drafting endpoint of this whole exercise, and they connect directly to the commercial-contract work in software license agreements: key terms and how to negotiate them and the review discipline in reviewing a software license agreement.

Checklist 7.2: M&A diligence (seller)

The mirror image. When you are the target, the buyer's scan is coming whether you prepare or not, and a clean, documented posture translates directly into deal value and a smoother close. The worst outcome is a buyer's scanner surfacing an AGPL component you never knew you had, mid-diligence, when you have lost the chance to fix it quietly.

  • [ ] Run the same scans the buyer will, and remediate significant gaps before marketing
  • [ ] Prepare a defensible component inventory you can stand behind
  • [ ] Assemble the data room: policy, latest audit, per-product inventory, sample NOTICE files
  • [ ] Disclose known issues with their remediation status; concealment is far worse than disclosure
  • [ ] Answer buyer questions promptly, acknowledge genuine issues, and propose realistic remediation timelines

Checklist 7.3: SBOM generation and supply-chain compliance

The software bill of materials has moved from best practice to baseline expectation. The pivot point was Executive Order 14028, Improving the Nation's Cybersecurity, 86 Fed. Reg. 26633 (May 12, 2021), which directed NTIA, and later CISA, to define SBOM requirements for software sold to the federal government, turning "do you have an inventory?" from an internal-hygiene question into a procurement gate. NTIA's July 2021 Minimum Elements for an SBOM set the content floor, and OMB Memorandum M-22-18 pushed secure-software attestation (built on NIST's Secure Software Development Framework, SP 800-218) into federal purchasing. The obligation is spreading by sector, too: for medical devices, section 524B of the Federal Food, Drug, and Cosmetic Act (added in 2022) now requires manufacturers to provide an SBOM as part of premarket cybersecurity submissions. Two formats dominate, SPDX (an ISO/IEC standard, ISO/IEC 5962:2021, originally from the Linux Foundation) and CycloneDX (an OWASP project). In practice, a modern compliance inventory and a modern SBOM are the same artifact viewed two ways: the SBOM is your reconciled component inventory, formatted for machines and for customers.

  • [ ] Choose a format (SPDX or CycloneDX) aligned with customer and contract requirements
  • [ ] Generate the SBOM automatically from the build
  • [ ] Include name, version, supplier, and a unique identifier (PURL or CPE) per component
  • [ ] Include the SPDX license identifier for every component
  • [ ] Capture dependency relationships, not just a flat list
  • [ ] Confirm completeness against the reconciled inventory (Part II)
  • [ ] Archive the SBOM with the specific release it describes (SBOMs are versioned)
  • [ ] Stand up a process to deliver SBOMs to customers and regulators on request
  • [ ] Track upstream vulnerability disclosures against SBOM contents (the security payoff)
  • [ ] Confirm whether federal-sales or sector regulation imposes specific SBOM duties on you

Checklist 7.4: Incident response

When a violation surfaces, discovered by you, flagged by a customer, or asserted in a copyright holder's demand letter, the first 48 hours set the tone. Enforcement here is real and varied. The Software Freedom Conservancy's BusyBox campaigns produced default judgments and injunctions; its ongoing suit against Vizio is being litigated, notably, as a breach-of-contract claim brought by a third-party-beneficiary user seeking source code, a theory distinct from the copyright path in Jacobsen and one a federal court in Software Freedom Conservancy, Inc. v. Vizio, Inc., 587 F. Supp. 3d 1004 (C.D. Cal. 2022), declined to hold preempted. In Artifex Software, Inc. v. Hancom, Inc., 2017 WL 1477373 (N.D. Cal. 2017), a court allowed a GPL/AGPL breach-of-contract claim over the Ghostscript PDF interpreter to proceed, reinforcing that an open source license can be enforced as a contract as well as through copyright. The Free Software Foundation, Inc. v. Cisco Systems, Inc. matter (S.D.N.Y. 2008) settled with a compliance officer and a monetary contribution. The reassuring pattern, borne out repeatedly, is that most enforcers want compliance, not damages: come into compliance and offer the source, and most matters resolve. Litigation tends to follow stonewalling, not good-faith remediation. For the discipline of handling the correspondence itself, see drafting an effective demand letter, read from the receiving end.

Immediate (24–48 hours).

  • [ ] Document the reported issue precisely and assess initial severity and scope
  • [ ] Identify affected products and versions, and whether they are currently being distributed
  • [ ] Engage counsel before responding to any demand
  • [ ] Preserve relevant evidence and communications (litigation-hold discipline)

Investigation (1–2 weeks).

  • [ ] Confirm a violation actually occurred (many demands overreach)
  • [ ] Identify root cause, duration, and scope of non-compliance
  • [ ] Assess legal, financial, and reputational exposure
  • [ ] Document findings for legal review, marking privileged where appropriate

Remediation and after.

  • [ ] Execute the plan (removal, isolation, or full compliance), and prepare the corresponding-source disclosure if required
  • [ ] Consider counsel-guided outreach to the license holder
  • [ ] Update processes and training so the root cause cannot recur
  • [ ] Run a blameless lessons-learned review and monitor the portfolio for related issues

Checklist 7.5: Contributing code outward

Contribution flows the other way, your code going out, and it creates its own obligations. Two matter most: do not publish your trade secrets by accident, and understand that signing a project's contributor license agreement may grant a patent license you did not mean to grant.

  • [ ] Confirm the contribution contains no proprietary code and no trade secrets (public disclosure is irreversible; preserve your protections under standing up a trade secret protection program)
  • [ ] Confirm it infringes no third-party IP
  • [ ] Review the CLA for patent-grant language and obtain legal approval if required
  • [ ] Confirm authority to contribute on the organization's behalf and alignment with policy
  • [ ] Sign the CLA, include appropriate copyright notices, and document the contribution internally

The trade-secret and chain-of-title dimensions of outbound contribution tie back to how the law protects software and to clean employee IP assignment, covered in employee invention assignment agreements. A newer wrinkle, whether AI-generated code carries open source obligations or its own provenance problems, is developing quickly; we track it in generative AI on trial.

Part VIII: The Metrics That Prove the Program Is Real

What gets measured gets managed, and a handful of well-chosen metrics tell leadership, and a future acquirer, whether the program is genuine or theater. Watch one metric above all: copyleft exposure count, the number of unaddressed copyleft components in proprietary products. The target is zero, and any number above zero is a list of remediation tasks, not a statistic.

Metric Target Calculation Cadence
License coverage >99% Components with an identified license ÷ total Monthly
Unknown-license rate <1% Unknown-license components ÷ total Monthly
Copyleft exposure count 0 Unaddressed copyleft in proprietary products Weekly
Mean time to remediate <30 days Avg. days from gap to resolution Monthly
New-component review coverage 100% Reviewed new components ÷ total new Monthly
Developer-training completion 100% Trained developers ÷ total Quarterly
Scan coverage 100% Scanned products ÷ total products Monthly

A metric worth quantifying alongside these is the value at risk if a copyleft exposure is enforced, which is really a copyright-damages question. Because a violation converts into copyright infringement, the downside is measured in injunctions and, where the work is registered, statutory damages and fees, not a license fee; the mechanics are laid out in what an IP case is worth.

Frequently Asked Questions

Is open source software actually free to use however I want? No. Open source is licensed under copyright, and using it outside the license conditions is infringement, not a free-for-all. Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), holds that license conditions limit the scope of the grant, so violating them exposes you to the full arsenal of copyright remedies, including injunctions and statutory damages. "Free" describes the price and the freedoms, not the absence of obligations.

Where exactly is the line between a contract breach and copyright infringement? On whether the violated term is a covenant or a condition. Under MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010), a licensee's breach is copyright infringement only where the term is a condition that limits the license's scope and bears a nexus to an exclusive right under 17 U.S.C. § 106; a mere covenant breach is a contract claim. Copyleft licenses are drafted to read as conditions, which is what makes them enforceable through copyright's stronger remedies.

Why is the AGPL singled out as dangerous for SaaS? Ordinary GPL is triggered by distribution. A pure SaaS company that runs GPL code only on its own servers arguably never distributes it, so the source-disclosure duty may never fire. The AGPL's Section 13 closes that gap: if users interact with your modified program over a network, you must offer them the source. For a cloud business, an unnoticed AGPL dependency converts "we run it internally" into "we must publish our source."

Does linking to a GPL library really "infect" my whole program? This is the hardest question in open source law, and it has no clean U.S. judicial answer. The Free Software Foundation reads any linking, static or dynamic, as creating a single combined work; arm's-length communication between separate programs it does not. No appellate court has squarely endorsed or rejected the dynamic-linking position, and the underlying derivative-work test, see Lewis Galoob Toys, Inc. v. Nintendo of America, Inc., 964 F.2d 965 (9th Cir. 1992), is itself contested as applied to software. The defensible posture is to treat any linking as exposure and isolate genuinely when you need to keep copyleft and proprietary code apart. This is a "consult counsel" question, not a "guess from a blog post" one.

Do I really need an SBOM? Increasingly, yes, and often by contract or regulation rather than choice. Executive Order 14028 made SBOMs a federal-procurement expectation, sector rules like FDCA section 524B now mandate them for medical devices, and customer contracts routinely demand them. Even absent a mandate, the SBOM is just your reconciled inventory in a standard, machine-readable format (SPDX or CycloneDX), and it doubles as an early-warning system when a new vulnerability lands in a dependency you already ship.

If a copyright holder catches a violation, am I going to be sued for millions? Usually not, if you respond well. Most enforcers, the Software Freedom Conservancy prominent among them, want compliance, not a windfall: come into compliance, offer the corresponding source, and most matters resolve without litigation. Litigation happens (the SFC's Vizio suit, Artifex v. Hancom, the German gpl-violations.org injunctions), but it tends to follow stonewalling. Engage counsel early, preserve evidence, confirm the violation is real, and fix it. The cooperative path is almost always the cheap one.

We're a two-engineer startup. Is all of this overkill? Run it proportionally; don't skip it. A tiny team doesn't need a metrics dashboard, but it absolutely needs three controls: a prohibited-license list banning AGPL and unreviewed copyleft from shipped products, an automated SCA scan in CI, and auto-generated attribution. Those three cost almost nothing and prevent the great majority of incidents, and they are exactly what an acquirer will look for the day your startup becomes someone's diligence target.

Conclusion: Boring, on Purpose

Do not let the hard cases obscure the easy truth. The overwhelming majority of open source compliance is not difficult; it is boring. Inventory the components. Classify the licenses. Honor the attribution. Gate the new dependencies. Regenerate the NOTICE file from the build. Scan in CI. The companies that get burned are almost never the ones that confronted a genuinely novel question about derivative works and got it wrong. They are the ones that never ran the checklist at all, shipped GPL code in firmware without noticing, and then met the community's lawyers on the community's terms.

Use these lists to guarantee completeness, and reserve a lawyer's judgment for the genuinely hard calls, the derivative-work questions, the network triggers, the combined-work scope. Start where your need is: scoping if you are beginning an audit, Part IV if you have found copyleft in a shipped product, Part VII if a deal or a demand letter just landed on your desk. Then build outward toward a program that runs without you. For the doctrine and strategy behind every step, keep open source licensing traps in enterprise software close at hand, and for interpretation on the facts of your own situation, consult qualified counsel.

Quick Reference: The Obligation Summary

If you see… You must… Watch out for…
MIT, BSD, ISC Preserve the copyright notice and license text Almost nothing, just don't drop the notice
Apache 2.0 Include the license; propagate the NOTICE file Express patent grant terminates if you sue the licensor
LGPL Preserve the user's ability to relink a modified library Static linking, provide relinkable form or go dynamic
MPL 2.0 Share your changes to MPL files; include the license File-level copyleft; track which files you touched
GPL Offer complete corresponding source of the whole combined work Everything that links to it may be pulled in
AGPL Offer source even for network/SaaS use, not just distribution The Section 13 network trigger, an emergency in the cloud
SSPL / Commons Clause / BSL / Elastic Treat as proprietary; get legal review Not OSI "open source" despite appearances
No license / unknown Stop and research before using "No license" means all rights reserved, the most restrictive case

When in doubt: do not add the component until the license is understood and approved. A dependency rejected at the door costs nothing. A dependency surgically removed from three shipped products costs a quarter.

Related UpLaw Resources

Related Guides

Related Checklists

Related Toolkits

Related Articles