Open Source Compliance Checklists: The Complete Collection

A compliance officer once described her open source problem to me this way: "We don't have a license. We have eleven thousand of them, and I can't tell you what's in any single one of our products without a forty-minute meeting." She was not exaggerating. A modern web application pulls in a handful of direct dependencies, each of which pulls in its own, and within three or four hops the dependency tree has swelled into the thousands. Every leaf on that tree is governed by a copyright license. Most are harmless. A few are not. And the entire structure changes every time a developer runs npm install.

That is the real shape of open source risk. It is not that the law is obscure—the obligations attached to the major license families are, by legal standards, refreshingly readable. It is that the obligations attach to everything, silently, at the speed of software development, and the consequences of missing one do not announce themselves until a copyright holder, an acquirer's diligence team, or a federal court does it for you. The Federal Circuit settled the central legal question almost two decades ago: in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), it held that the conditions of an open source license are not mere contract terms but limits on the scope of the copyright grant, so that using the software outside those conditions is copyright infringement, with all the statutory remedies that follow. Open source is free as in freedom and free as in beer. It is emphatically not free as in unconditional.

This collection exists because compliance, like every complex process, becomes manageable the moment you stop trying to hold it in your head and start working through a list. Where our narrative writing on this subject explains the doctrine and the strategy in prose, this is the operational reference: the checklists a team can actually work through during an audit, a release, an acquisition, or a 2 a.m. incident call. It deliberately keeps the list-and-table format that makes a checklist useful, but each item carries enough context to tell you why it earns its place. Use these to ensure completeness during audits, to onboard new engineers, to prepare for transactions, and to verify that your ongoing processes still work.

These checklists are the operational companion to our narrative guide on open source licensing landmines in enterprise software development, which explains the law and the strategy behind every step here. For the foundational concepts—what open source actually is, how the licenses are structured, and why copyleft behaves the way it does—see our overview of open source software. For the broader question of how copyright, patent, trade secret, and contract law combine to protect (and sometimes endanger) a software product, see legal protection of software. Use the guides to understand the "why"; use these checklists to execute the "how."

A word of warning before you begin: a checklist is a tool, not a substitute for judgment, and it is certainly not legal advice. The hardest open source questions—what counts as a "derivative work," whether two modules form a "single program," whether your SaaS deployment trips the AGPL's network clause—turn on facts and on caselaw that is thinner than anyone would like. Where a checklist says "escalate to legal," it means exactly that.

Part 1: Pre-Audit Preparation Checklists

Before scanning a single line of code, preparation determines whether your audit will be comprehensive, efficient, and actionable—or a pile of false positives nobody trusts. The most common audit failure is not a missed component; it is a scan that produces ten thousand findings, no prioritization, and an engineering team that quietly decides the whole exercise can be ignored.

Checklist 1.1: Defining Audit Scope

Getting scope right prevents both over-auditing (wasting resources on internal tools nobody distributes) and under-auditing (missing the firmware blob that ships to a million devices). The single most important scoping question is also the most legally consequential one: what do you distribute, and to whom? Almost every burdensome open source obligation—the GPL's source-disclosure requirement, the LGPL's relinking obligation, attribution and NOTICE duties—is triggered by distribution, not by mere use. Software you run only on your own servers for your own purposes generally sits in a far safer place. The glaring exception is the GNU Affero General Public License (AGPL), which was written precisely to close the "SaaS loophole" by treating network interaction as if it were distribution. Map your distribution surface first; everything else follows from it.

Scope Decision Matrix. Prioritize by the two variables that drive legal exposure: whether the product leaves your four walls, and whether it contains copyleft code.

                        Distributed Externally?
                           YES          NO
                      ┌──────────┬──────────┐
    Contains     YES  │ CRITICAL │  MEDIUM  │
    Copyleft?         │ PRIORITY │ PRIORITY │
                      ├──────────┼──────────┤
                 NO   │   HIGH   │   LOW    │
                      │ PRIORITY │ PRIORITY │
                      └──────────┴──────────┘

The "MEDIUM" cell deserves a note. Copyleft in an internal-only tool feels safe—and usually is, today. But internal tools have a way of becoming products, contractors have a way of becoming distribution channels, and the company you are quietly building inside a GPL-laced internal platform is the company a buyer will one day scrutinize line by line. Document the limitation that keeps you safe (internal use only) so that if the assumption ever changes, someone notices.

Checklist 1.2: Gathering Existing Documentation

Existing documentation is both a head start and a confession—it reveals what institutional knowledge already exists and, by its gaps, where the bodies are buried. Pay particular attention to NOTICE files and prior audit reports: a NOTICE file that hasn't been regenerated since 2021 is itself evidence of an attribution gap.

• Collect any existing open source component inventories (treat as a hypothesis, not gospel)
• Gather NOTICE and THIRD-PARTY-NOTICES files from shipped products
• Retrieve LICENSE files from code repositories
• Locate previous audit reports or compliance assessments
• Find documented open source policies or guidelines
• Collect records of prior compliance incidents or remediation
• Identify existing approved/prohibited component lists
• Gather license agreements for dual-licensed/commercial open source (e.g., a paid MySQL or Qt license that avoids the GPL)
• Locate contributor license agreements (CLAs) for projects you contribute to
• Retrieve third-party software agreements from vendors (their open source is now your open source)

Checklist 1.3: Technical Access and Tool Setup

Scanning tools are only as good as their access. The two most common reasons a software composition analysis (SCA) scan misses components are (1) it never saw the private registry credentials needed to resolve dependencies, and (2) it scanned source but never the built artifact, where statically linked and vendored code actually lives.

A practical note on SCA tooling: no scanner is authoritative. Manifest-based scanners (reading package-lock.json, pom.xml, and the like) are excellent at cataloging declared dependencies and nearly blind to copied code. "Snippet" or fingerprint scanners compare your code against a corpus of known open source and catch copy-paste, but generate false positives. Binary composition analysis catches what made it into the shipped artifact. Mature programs run more than one and reconcile. Treat the tool's license identification as a lead to verify, not a verdict—a point we return to in Part 3.

Checklist 1.4: Stakeholder Alignment

Audits succeed when engineers see them as quality work and fail when they smell a witch hunt. The single most useful sentence you can say at a kickoff is: "Findings are for fixing, not for blame." Developers add a GPL library to ship a feature on time; they are responding rationally to the incentives you gave them. Fix the incentives, not the engineer.

• Brief engineering leadership on audit objectives and timeline
• Identify technical contacts for each in-scope codebase
• Establish an escalation path for decisions requiring business input
• Define who has authority to approve remediation approaches
• Set realistic expectations for developer time during the audit
• Communicate that findings are for improvement, not blame
• Schedule a kickoff meeting with all stakeholders
• Agree on reporting format and cadence during the audit
• Define concrete success criteria for audit completion

Part 2: Component Identification Checklists

Finding all open source components is the foundation of everything that follows. Miss a component, miss its obligations—and you cannot comply with a license you don't know you're using. This is also the stage where most real-world violations originate, because the riskiest components are precisely the ones the package manager never sees: code copied straight into the tree, libraries baked into a container base image, a driver compiled into firmware.

Checklist 2.1: Package Manager Scanning

Package managers are the primary—but never the only—source of open source in modern software. The cardinal rule here has the force of a commandment: scan the lockfile, not just the manifest. A manifest like package.json declares "I want some version of express." The lockfile records the exact resolved version of express and every transitive dependency it dragged in. The manifest is your intention; the lockfile is your reality, and obligations attach to reality.

Checklist 2.2: Vendored Code Detection

"Vendored" code—third-party source copied directly into your repository—is the silent killer of package-manager-only audits, because it appears nowhere in any manifest. It is also where the most serious copyleft violations hide, because a developer who copies a single GPL utility file into a proprietary codebase has done something no dependency resolver will ever flag.

• Scan common vendor directories (/vendor, /third_party, /external, /lib)
• Run file fingerprinting/snippet matching against open source databases
• Check for stray license files that betray a vendored component
• Review large files that may be minified or bundled third-party code
• Inspect JavaScript bundles for embedded libraries
• Check for header files copied from external C/C++ libraries
• Identify statically linked libraries in binary builds
• Review build scripts for external downloads not captured in manifests
• Check git submodules for third-party repositories
• Examine Docker/container files for base images and installed packages

Checklist 2.3: Binary and Container Analysis

What you build is not always what you wrote. A Dockerfile that begins 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 that has direct copyleft consequences (see Part 4). Verify at the artifact level, because that artifact—not your repository—is what you actually distribute.

Firmware deserves special vigilance. The most consequential open source enforcement actions of the last fifteen years—the BusyBox campaigns, the Software Freedom Conservancy v. Best Buy litigation, and SFC v. Vizio—all involved GPL'd code compiled into the firmware of consumer electronics shipped without the corresponding source. If you ship hardware, your firmware is your highest-risk distribution surface.

Checklist 2.4: Component Inventory Verification

A scan result is a draft inventory, not a final one. Reconciling multiple scanning methods and spot-checking by hand is what separates an inventory you can swear to in a diligence representation from a list you hope is right.

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

The development/production distinction is more than housekeeping. A GPL-licensed build tool or test framework that never ships in your distributed artifact generally creates no distribution obligation at all—it is used, not conveyed. Misclassify it as a production dependency and you will waste a remediation cycle chasing a phantom. Misclassify a production dependency as dev-only and you ship a violation. Get the boundary right.

Part 3: License Classification Checklists

Not all licenses are created equal, and the entire economics of your compliance program flow from classification. An MIT component costs you one line in a NOTICE file. An AGPL component in a SaaS product can cost you your proprietary source code. The legal stakes of getting this wrong were established in Jacobsen v. Katzer: because license conditions define the scope of the copyright grant, using the component outside its terms is infringement, exposing you to injunctive relief and statutory damages—not the modest license fee you would have paid had you simply complied.

Checklist 3.1: License Identification Verification

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

For each component with a high-risk or unusual detected license:

• Locate the original license file in the component's source repository
• Compare the detected text against an authoritative source (the SPDX License List, OSI)
• Check for license exceptions or additional permissions (e.g., GPL linking exception)
• Verify the license applies to the specific version you use (projects relicense)
• Note any "or later" option (e.g., "GPL-2.0-or-later" vs. "GPL-2.0-only")
• Identify dual-licensing options (e.g., a commercial license that sidesteps copyleft)
• Document a license for any component the tool reports as unlicensed
• Flag every component whose license cannot be determined—"no license" is not "permissive"

That last point is worth dwelling on. A component published with no license at all is not free to use; it is "all rights reserved" by default under copyright law. The absence of a license is the most restrictive condition possible, not the least. SCA tools that report "no license detected" are flagging a problem, not clearing one.

Checklist 3.2: License Classification Quick Reference

Use this to classify by obligation level. 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 licenses (attribution required, little else). You may use, modify, and redistribute—even inside proprietary, closed-source products—so long as you preserve the copyright notice and license text. These are the workhorses of commercial software.

Apache 2.0 is the most important entry here, and the one teams most often under-comply with. Beyond attribution, it imposes two duties many engineers miss: you must propagate any NOTICE file the upstream project ships (a real, affirmative obligation, not a courtesy), and you accept its patent-retaliation bargain—the express patent grant terminates automatically if you sue the licensor for patent infringement over the work. That express patent grant is also Apache 2.0's great virtue: it is why Apache 2.0 is the default choice for patent-conscious enterprises, a point developed in our discussion of legal protection of software.

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

MPL 2.0 is the cleanest weak-copyleft license to live with: copyleft is scoped to the individual file. Modify an MPL file, you must share that file under MPL; add new files of your own, they stay yours. The Mozilla drafters deliberately drew the boundary at a place developers can see and reason about.

Strong (work-scoped) copyleft. The headline obligation: 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 "infects" proprietary code, and it is the reason GPL components are the single most common cause of serious compliance incidents.

The AGPL's network clause (Section 13) is the trap that catches SaaS companies. The ordinary GPL is triggered by distribution; run GPL code only on your own servers and you arguably never "convey" it, so the source-disclosure obligation never fires. The AGPL was written to slam that door: if users interact with your modified AGPL program over a network, you must offer them the corresponding source as if you had distributed it. For a cloud or SaaS business, an unnoticed AGPL dependency is a genuine emergency.

Licenses requiring special attention. Some popular licenses are not OSI-approved "open source" at all, despite living on GitHub and looking the part.

Checklist 3.3: License Compatibility Assessment

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 (the Free Software Foundation considers Apache 2.0's patent and indemnity terms to impose restrictions GPLv2 forbids), and GPL-2.0-only cannot be combined with GPL-3.0-only because each demands the whole work be under its exact terms. The good news: GPLv3 was deliberately drafted to be compatible with Apache 2.0, which resolved one of the most painful conflicts in the ecosystem.

For each product containing multiple open source components:

• List every unique license in the product
• Identify the most restrictive license—it may govern the entire combination
• Check GPL-2.0-only against Apache-2.0 components (incompatible)
• Verify no AGPL components sit inside a proprietary SaaS service
• Check for GPL-2.0-only vs. GPL-3.0-only collisions
• Document every conflict identified
• Determine whether a conflict resolves through a version or dual-license choice ("or later" often saves you)
• Escalate unresolvable conflicts to remediation

Compatibility quick check.

If your product is PROPRIETARY (closed source):
  ├── Permissive (MIT/BSD/Apache): ✓ OK (with attribution; Apache NOTICE)
  ├── MPL 2.0:                      ✓ OK (share modified MPL files only)
  ├── LGPL (dynamically linked):    ✓ OK (preserve relinking ability)
  ├── LGPL (statically linked):     ⚠️ Requires care (provide object files)
  ├── GPL (any combination):        ✗ PROBLEM (source-disclosure of the whole)
  └── AGPL (network/SaaS use):      ✗ PROBLEM (Section 13 network trigger)

If your product is GPL 3.0:
  ├── Permissive (MIT/BSD):         ✓ OK
  ├── Apache 2.0:                   ✓ OK (compatibility resolved in GPLv3)
  ├── LGPL:                         ✓ OK
  ├── GPL-2.0-or-later:             ✓ OK (upgrades to v3)
  └── GPL-2.0-only:                 ✗ PROBLEM (cannot mix exact versions)

Part 4: Compliance Gap Assessment Checklists

This is where audit findings become actionable issues—and where the doctrine that lawyers argue about meets the architecture that engineers actually built. The two questions that drive nearly every gap are: Have we honored the attribution obligations 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 Review

Attribution is the most under-rated obligation in open source because it is 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 reason this matters is bracingly concrete: in Jacobsen v. Katzer, the obligation the defendant breached was, at bottom, an attribution-and-notice requirement, and the Federal Circuit treated its violation as potential copyright infringement. Missing attribution is not a stylistic lapse; it is the exact failure that turned a hobbyist model-railroad dispute into a landmark federal opinion.

Attribution location by product type. "Accessible to end users" is a real requirement; satisfy it where the user can actually look.

Checklist 4.2: Copyleft Exposure Assessment

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, a derivative work. The Free Software Foundation's well-known position is that linking (static or dynamic) generally creates such a combined work, while communication between separate programs at arm's length (pipes, sockets, command-line invocation between independent processes) generally does not. That position is influential but has never been definitively blessed by an appellate court applying it to dynamic linking, which is precisely why this analysis so often ends at "escalate to counsel." Run the questions; let the answers drive the risk tier.

For each strong-copyleft component (GPL, AGPL) in a distributed product:

Risk assessment.

Worked example (hypothetical). Helios Robotics ships a warehouse robot whose firmware statically links a GPLv2-licensed motion-planning library into the same binary as Helios's proprietary navigation code. Helios distributes the robot to customers but offers no source. Under the Federal Circuit's reasoning in Jacobsen, Helios is using the library outside the scope of its license, and the static link into a single binary is the paradigm case the FSF treats as a combined work. Helios's exposure is not "the fee it should have paid"—there was no fee—but copyright infringement, with the GPLv2 source-disclosure obligation reaching the whole firmware image. This is the exact fact pattern (GPL code in shipped device firmware, no source) at the heart of the Software Freedom Conservancy v. Vizio litigation. The remediation is not subtle: isolate the library into a separate process, replace it with a permissively licensed equivalent, or comply by releasing the corresponding source.

Checklist 4.3: LGPL Compliance Verification

The LGPL is the "have your cake and eat it" 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 can drop in a replacement .so/.dll. Static linking is where teams stumble, because a statically linked binary cannot be relinked unless you give the user what they need to do it.

For each LGPL component in a distributed product:

• Determine whether the component is dynamically or statically linked
• If dynamically linked: verify users can substitute a modified library build
• If statically linked: provide object files (or relinkable form) so users can relink—or switch to dynamic linking
• Provide the LGPL license text and copyright notices
• For LGPL 3.0: satisfy GPLv3 §6 "Installation Information" if the product is "User Product" hardware (the anti-Tivoization rule)
• Record the linking method in your compliance records
• Confirm the build system actually preserves the substitution ability you claim

Checklist 4.4: Process Gap Assessment

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 compliance failures are the ones a working process would have caught automatically—which is why mature programs shift compliance "left" into the developer's workflow rather than bolting it on at release.

Part 5: Remediation Checklists

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

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 information
• Create 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 it
• Integrate attribution generation into the build pipeline
• Test that attribution updates automatically when dependencies change
• Verify attribution actually appears in the distributed package
• Confirm end-user accessibility (see the location table in 4.1)
• Update product docs to reference the attribution location
• Schedule periodic accuracy review

Attribution file template.

THIRD-PARTY-NOTICES
===================

This product includes the following third-party software:

[Component Name] — Version X.Y.Z
License: [SPDX identifier and license name]
Copyright (c) [Year] [Copyright Holder]
[URL to project]

[Full license text where the license requires reproduction]

---

[Repeat for each component]

Checklist 5.2: Copyleft Component Removal

When the cleanest fix is to rip out the problematic component, do it with a documented comparison so the decision survives later scrutiny (an acquirer will ask why you chose what you chose).

• Identify every location where the component is used
• Assess the functional dependency—what does it actually provide?
• Research permissively licensed alternatives
• Evaluate alternatives for functional equivalence
• Evaluate alternatives for security history and maintenance health
• Implement the replacement
• Test that the replacement delivers the required functionality
• Remove the original from dependency manifests
• Verify the original no longer appears in scans
• Update attribution documentation
• Record the decision and rationale for compliance records

Alternative-research template.

Checklist 5.3: Architectural Isolation

Isolation keeps a copyleft component while avoiding a combined-work problem by holding it at arm's length—separate process, separate container, communication over a network or IPC boundary rather than a function call. This rests on the FSF's own distinction between linking (combined work) and inter-process communication between independent programs (not a combined work). It is a defensible strategy, but "arm's length" must be real: 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 communication interface (REST, gRPC, IPC, pipe)
• Ensure the interface is genuinely arm's-length—no shared memory, headers, or linking
• Implement the isolated architecture
• Verify no compilation or linking dependency remains
• Test functionality through the isolated interface
• Document the isolation for compliance records
• Obtain legal review of isolation adequacy (this is the step you cannot skip)
• Monitor for architectural drift that re-introduces coupling

Isolation decision tree.

Does removing the component break functionality?
  │
  ├── NO → Remove the component (Checklist 5.2)
  │
  └── YES → Is a commercial/dual license available?
              │
              ├── YES → Evaluate it (often cheaper than re-architecting)
              │
              └── NO → Can the function be isolated to a separate process?
                        │
                        ├── YES → Implement process isolation (this checklist)
                        │
                        └── NO → Consult legal on derivative-work analysis,
                                 OR comply with the copyleft (release source)

Checklist 5.4: License Conflict Resolution

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 version under a friendlier license, or an "or later" clause that lets you upgrade.

• 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 (components actually combined in distribution)
• If unavoidable, decide which component to replace
• Prefer replacing the component with fewer internal dependencies on it
• Research replacements for the chosen component
• Implement and verify the conflict is gone
• Document the resolution

Part 6: Ongoing Compliance Program Checklists

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

Checklist 6.1: Developer Onboarding

The developer is where compliance is won or lost, because the developer is who types npm 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?

Checklist 6.2: New-Component Approval

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

Quick approval flow.

New Component Request
        │
        ▼
License on Approved List?
   YES │          │ NO
       ▼          ▼
Security Check    Legal Review
       │          │
       ▼          ▼
    Pass?      Approved?
   YES │ NO    YES │ NO
       ▼   │       ▼   │
  APPROVED │  APPROVED │
           ▼           ▼
       REJECTED    REJECTED

Checklist 6.3: Release Compliance Verification

Every release is a fresh act of distribution, and therefore a fresh trigger for every distribution-based obligation. This is also where the SBOM gets cut—increasingly a contractual and even regulatory expectation, discussed in Part 7.

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

Checklist 6.4: Quarterly Compliance Review

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

Part 7: Special Situation Checklists

Certain moments concentrate open source risk into a single high-stakes event: a transaction, a regulatory deadline, a demand letter. These checklists are for those moments.

Checklist 7.1: M&A Due Diligence (Buyer)

Open source diligence has become a standard, sometimes deal-defining, workstream in any software acquisition. 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 any residual risk through the deal documents. This is one place where the operational checklist meets the contract drafting we cover in drafting software license agreements: key terms and negotiation points.

Pre-LOI assessment.

• Request the target's open source policy
• Request the most recent compliance audit report
• Identify the products being acquired and how they are distributed
• Assess the target's general compliance maturity

Detailed due diligence.

• Obtain access to the target's repositories
• Run an independent SCA scan on all acquired products
• Compare results against the target's disclosed inventory (gaps are the story)
• Identify copyleft components inside proprietary products
• Identify license conflicts
• Identify components with unknown or unclear licenses
• Assess the severity of each gap (Part 4 risk tiers)
• Quantify the remediation effort
• Prepare findings for the deal team in business terms

Deal documentation.

• Include open source representations and warranties in the purchase agreement (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
• Define pre-closing remediation conditions where warranted
• Plan post-closing integration of the two compliance programs

Checklist 7.2: M&A Due 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 compliance posture translates directly into deal value and a smoother close. The worst outcome is a buyer's scanner surfacing an AGPL component you didn't know you had, mid-diligence, when you have lost the chance to fix it quietly.

Pre-marketing.

• Conduct a comprehensive internal audit (run the same scans the buyer will)
• Remediate significant gaps before marketing
• Prepare a defensible component inventory you can stand behind
• Document policies and processes
• Gather compliance evidence (attribution files, training records, scan history)

Data-room preparation.

• Include the open source policy
• Include the most recent audit report
• Include a component inventory for every product
• Include sample attribution/NOTICE files
• Disclose known issues with their remediation status (concealment is far worse than disclosure)

Responding to findings.

• Answer buyer questions promptly and accurately
• Acknowledge genuine issues—don't obscure them
• Propose remediation plans for significant gaps
• Negotiate 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 (May 2021), Improving the Nation's Cybersecurity, 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. Two formats dominate: SPDX (an ISO/IEC standard, ISO/IEC 5962, originally from the Linux Foundation) and CycloneDX (an OWASP project). A modern compliance inventory and a modern SBOM are, in practice, the same artifact viewed two ways: the SBOM is your component inventory, formatted for machines and for customers.

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

Checklist 7.4: Compliance Incident Response

When a violation is discovered—by you, by a customer, or by a copyright holder's demand letter—the first 48 hours set the tone. Enforcement in this space is real and varied: the Software Freedom Conservancy's BusyBox campaigns and its ongoing litigation against Vizio (pursued, notably, as a breach-of-contract claim by a third-party beneficiary user seeking source code, a theory distinct from the copyright path in Jacobsen), Artifex Software v. Hancom (where a U.S. court allowed a GPL breach-of-contract claim to proceed), and the German Welte/gpl-violations.org injunctions all show that license holders will, and do, enforce. The good news, repeatedly borne out in practice, is that most enforcers want compliance, not damages—come into compliance and offer the source, and most matters resolve.

Immediate response (24–48 hours).

• Document the reported issue precisely
• Assess initial severity and scope
• Identify affected products and versions
• Determine whether the products are currently being distributed (stop the bleeding if so)
• Engage legal counsel before responding to any demand
• Preserve relevant evidence and communications (litigation-hold discipline)

Investigation (1–2 weeks).

• Confirm whether a violation actually occurred (many demands overreach)
• Identify the root cause
• Determine the duration and scope of non-compliance
• Assess exposure: legal, financial, reputational
• Identify all affected products and distributions
• Document findings for legal review (mark privileged where appropriate)

Remediation.

• Develop a remediation plan (removal, isolation, or full compliance)
• Implement it in the affected products
• Update processes to prevent recurrence
• If required, prepare the complete-corresponding-source disclosure
• If appropriate, prepare a public compliance statement
• Consider proactive, counsel-guided outreach to the license holder

Post-incident.

• Document the incident and resolution for the record
• Run a blameless lessons-learned review
• Update policy and training based on what you learned
• Monitor for related issues across the portfolio

Checklist 7.5: Contributing to Open Source

Contribution flows the other way—your code going out—and it creates its own obligations and risks. The two that matter most: don't ship your trade secrets to the world by accident, and understand that signing a project's contributor license agreement (CLA) may grant a patent license you didn't mean to grant. For the trade-secret dimension, see legal protection of software; for how outbound contribution interacts with your own IP strategy, our open source licensing landmines guide goes deeper.

Before contributing.

• Confirm the contribution includes no proprietary code
• Verify it includes no trade secrets (this is irreversible once public)
• Check that it infringes no third-party IP
• Review the project's CLA (note any patent-grant language)
• Obtain legal approval of the CLA if required
• Confirm authority to contribute on the organization's behalf
• Verify alignment with the company open source policy

Making the contribution.

• Sign the CLA if the project requires it
• Include appropriate copyright notices in contributed files
• Follow the project's contribution guidelines
• Document the contribution for internal records

Part 8: Compliance Metrics Dashboard

What gets measured gets managed, and a handful of well-chosen metrics will tell leadership—and a future acquirer—whether the program is real or theater. The single metric to watch above all is 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.

Key performance indicators

Trend-tracking template

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 copyright 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 copyright 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.

What's the practical difference between permissive and copyleft licenses? A permissive license (MIT, BSD, Apache) essentially asks you to give credit and keep the notices; you can use the code in closed-source products. A copyleft license (GPL, AGPL) asks for reciprocity: if you distribute software built on it, you must offer the corresponding source of the combined work under the same license. Weak copyleft (LGPL, MPL) sits between, scoping the reciprocity to the library or to individual files. The classification drives every downstream obligation, which is why Part 3 comes before everything else.

Why is the AGPL singled out as dangerous for SaaS? The 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 obligation 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 judicial answer in the United States. The Free Software Foundation takes the view that linking—static or dynamic—generally creates a single combined work subject to the GPL, while arm's-length communication between separate programs does not. No appellate court has squarely endorsed (or rejected) the FSF's dynamic-linking position. The conservative, defensible posture is to treat any linking as creating exposure and to isolate genuinely (separate process, no shared memory or headers) when you need to keep copyleft and proprietary code apart. When in doubt, this is a "consult counsel" question, not a "guess from a blog post" question.

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, and customer contracts now routinely demand them. Even where no one is requiring it, the SBOM is just your component inventory in a standard, machine-readable format (SPDX or CycloneDX), and it doubles as your early-warning system when a new vulnerability lands in a dependency you already ship.

What happens if a copyright holder catches a violation—am I going to be sued for millions? Usually not, if you respond well. Most open source enforcers—the Software Freedom Conservancy being the prominent example—want compliance, not a windfall: come into compliance, offer the corresponding source, and most matters resolve without litigation. Litigation does happen (the SFC's suit against Vizio, Artifex v. Hancom, the German gpl-violations.org injunctions), but it tends to follow stonewalling, not good-faith remediation. 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 small startup. Is all of this overkill? Run the program proportionally, not skip it. A two-engineer startup doesn't need a quarterly metrics dashboard, but it absolutely needs (1) a prohibited-license list that bans AGPL and unreviewed copyleft from shipped products, (2) an automated SCA scan in CI, and (3) auto-generated attribution. Those three controls, which cost almost nothing to stand up, 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: Putting Checklists into Practice

Checklists are tools, not solutions. They guide action; they do not replace judgment, and they are not legal advice. Every codebase, every organization, and every situation has features no checklist fully anticipates—which is why the hardest items here route to counsel rather than to a checkbox. Use these lists to guarantee completeness, then use a lawyer's judgment for the genuinely hard calls about derivative works, network triggers, and combined-work scope.

But do not let the hard cases obscure the easy truth: the overwhelming majority of open source compliance is not hard. It is boring—inventory the components, classify the licenses, honor the attribution, gate the new ones, 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 legal question and got it wrong. They are the ones that never ran the checklist at all, shipped GPL code in firmware without noticing, and met the open source community's lawyers on the community's terms.

Open source powers modern software, and compliance is what protects your right to keep using it. Systematic compliance—guided by lists like these—turns an overwhelming obligation into a set of repeatable, delegable, automatable processes. Start with the checklists that map to your immediate need: scoping if you're beginning an audit, Part 4 if you've found copyleft in a shipped product, Part 7 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 here, keep our guide on open source licensing landmines in enterprise software development close at hand. And for license interpretation or compliance strategy on the facts of your own situation, consult qualified counsel.

Quick Reference: License Obligation Summary

Keep this handy.

When in doubt: don't 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 Articles

• Open source software — the foundational overview: what open source is, how the licenses are structured, and why copyleft behaves the way it does.
• Open source licensing landmines in enterprise software development — the narrative companion to this collection, explaining the law and strategy behind every checklist.
• Drafting software license agreements: key terms and negotiation points — how open source obligations flow into the representations, warranties, and indemnities of commercial software contracts and M&A.
• Legal protection of software: copyrights, patents, trade secrets, and contracts — the broader framework for how the four IP regimes protect (and open source can endanger) a software product.