M&A Diligence Has Started, but Nobody Can List the Open-Source Components: What Should Legal Check?

Signals considered

• no central SBOM
• inherited licenses from transitive dependencies
• legal and engineering speak different data languages

The Day the Spreadsheet Failed

You are seven days into confirmatory due diligence on a B2B SaaS acquisition. The engineering lead sends a 43-row spreadsheet titled “Open Source Components.” It lists Redis, Postgres, three npm packages, and a note that reads “everything else is standard.” The container registry shows 117 images. The procurement file records 19 third-party SDK agreements. The deal timetable gives you two more weeks.

This is not a corner case. When technology legal operations leads inherit software from target companies, the compliance map is almost always incomplete — not because the target is careless, but because no single team owns the full picture. Engineers track libraries they import directly; infrastructure teams manage container base images; product teams negotiate SDKs. Nobody maps license obligations to distribution channels, and nobody has a bill of materials that connects a component to a legal commitment.

You — the technology legal operations lead — are the person expected to close that gap before the signing committee asks whether the deal carries hidden open-source liability. The usual response — “we will ask engineering to update the spreadsheet” — does not scale.

Why the Spreadsheet Is Not Enough

The surface problem looks simple: collect a list of open-source components and check their licenses. Three structural realities make that approach fail in practice.

First, transitive dependencies. A single npm install can pull 400+ packages that the target’s developers never explicitly chose. Each carries its own license, and a MIT-licensed top-level package may depend on LGPL-licensed lower layers that trigger distribution obligations. The spreadsheet captures what the team remembers, not what the build graph contains.

Second, distribution ambiguity. A license’s obligations — disclosure, source-code provision, reciprocal licensing — depend on how the software is delivered. A container image pushed to a customer’s Kubernetes cluster is a distribution. A server-side API dependency that never leaves the data center may not be. The target’s team rarely documents delivery context alongside component names.

Third, ownership gaps. When diligence reveals a problematic component, you need to know who owns the remediation decision: the engineering director who imported it? The SRE team that baked it into the base image? The product manager who selected the SDK? Without ownership mapping, the finding sits in a ticket until the deal closes.

You need a method that surfaces components, maps obligations to distribution, and assigns remediation priority — all within a deal timetable.

The Open-Source Obligation Checklist: A Three-Phase Method

The method below treats open-source diligence as a bounded audit — bounded by the target’s actual artifacts, not by what a spreadsheet claims. Use it as a repeatable checklist for every acquisition, regardless of the target’s size.

Phase 1: Artifact Discovery (Days 1–3)

You cannot inspect what you cannot see. Phase 1 identifies every artifact that enters a customer environment or runs in production.

• Request the target’s container registry inventory — every image tagged as production or staging, including base images.
• Extract lock files: package-lock.json, go.sum, Cargo.lock, Gemfile.lock, and requirements.txt from the main application repositories.
• Collect third-party SDK agreements from procurement or the legal file.
• Ask engineering for the CI/CD pipeline definitions — these often reveal build-time dependencies not recorded elsewhere.

At the end of Phase 1, you should have an artifact inventory that is machine-readable, not a human-maintained spreadsheet.

Phase 2: License Mapping (Days 4–8)

Map every discovered component to the terms under which the target received it and the terms under which the target distributes it.

For each component, record:

Field	Question to Answer
Component name and version	Exact version from lock file or image manifest
Declared license	SPDX identifier from the component’s metadata
Distribution channel	SaaS backend, customer-deployed container, mobile SDK, embedded binary
Obligation trigger	Does distribution trigger source disclosure, notice retention, or reciprocal licensing?
Inherited dependency chain	If transitive, which parent package introduced it?

Use a license classifier (ScanCode, FOSSLight, or an equivalent automated tool) on the target’s source repositories and container images. Manual reading is reserved for the top 20 components by distribution blast radius.

Phase 3: Remediation Triage (Days 9–14)

Not every non-standard license is a deal issue. Triage findings into three priority levels:

• Priority 1: Copyleft licenses (AGPL, GPL, LGPL with distribution triggers) or undisclosed proprietary components embedded in customer-facing artifacts. Requires engineering time to replace or re-license. Flag for deal terms.
• Priority 2: Notice-only obligations (BSD-3, Apache-2.0 with missing attribution files) or components with ambiguous SPDX declarations. Requires documentation, not code changes.
• Priority 3: Permissive licenses with proper notice files already in place. No action needed; archive for the post-close compliance record.

Assign every Priority 1 and Priority 2 finding an evidence owner — a named person from the target’s engineering or product team who can confirm the distribution context and the remediation timeline.

What You Walk Away With

After three phases, you hold three deliverables that the spreadsheet model never produced:

1. A component-level compliance map — each artifact connected to its license, distribution channel, and obligation trigger, not a flat list of package names.
2. Evidence ownership assignments — every Priority 1 and Priority 2 finding has a named owner and a confirmed distribution context, closing the “who fixes this” gap before signing.
3. Remediation priority by closing risk — you can tell the deal team exactly which components require pre-close remediation, which can be handled post-close, and which are informational only.

The boardroom question — “are we inheriting open-source liability?” — now has an answer backed by artifact evidence, not by a spreadsheet that misses 400 transitive dependencies.

A Practical Bridge: When the Checklist Needs Product Support

The three-phase method works with spreadsheets, shared drives, and email threads. That is how most technology legal operations teams run their first few diligences. Over time, the overhead of artifact discovery across heterogeneous systems, cross-referencing lock files against container registries, and tracking evidence owner responses across email chains becomes the bottleneck — not the methodology itself.

At that point, a purpose-built signal layer that connects artifact discovery, license mapping, and ownership tracking in a single workspace reduces the coordination tax. Teams that have outgrown the spreadsheet approach typically look for a system that accepts artifact feeds from CI/CD pipelines and registry webhooks, surfaces obligation triggers automatically, and assigns remediation tasks to named owners without email loops. The method stays the same; the operational drag changes.

For teams that want to see how artifact-to-obligation mapping works in practice, the Telegram Business Signal Framework and Telegram Source Governance patterns illustrate the same discovery-and-triage logic adapted to communication-compliance contexts. The Telegram Business Signal Intelligence page documents the product layer that operationalizes these workflows at scale.

Key Takeaways

• Open-source diligence fails when it relies on human-maintained component lists. Transitive dependencies, distribution ambiguity, and ownership gaps are structural problems, not data-entry problems.
• The three-phase checklist (artifact discovery, license mapping, remediation triage) produces a defensible compliance position within a two-week timetable.
• Every finding needs an evidence owner and a confirmed distribution channel — a license identifier alone is not diligence.
• Automation replaces manual data collection in Phase 1, not judgment in Phase 3. The legal operations lead retains triage authority.

FAQ

When during the deal timeline should the open-source check begin?

Start as soon as the letter of intent is signed or the exclusivity period opens. Waiting until the confirmatory diligence phase collapses the remediation window, especially for copyleft components that require source-code publication or re-architecture. A parallel legal-technical run that takes 10–14 calendar days is typical for a mid-size target.

What is the quickest way to identify high-risk components without a full SBOM?

Run a dependency scanner (e.g., scancode-toolkit or FOSSLight) against the target’s production deployment artifacts — container images, compiled binaries with embedded version strings, and lock files in archived repositories. Cross-reference the output against the SPDX License List. You will get an 80-percent-accurate picture in under a week. Use that to triage, not to finalize.

Can the acquiring company indemnify the gap instead of remediating?

Indemnification clauses cover monetary loss, not distribution compliance. If the target distributes a GPL-licensed library as part of a SaaS appliance or embedded system, no indemnity can retroactively make the distribution compliant. The acquiring entity inherits the violation and any third-party infringement claim. Indemnity is a backstop for undisclosed financial exposure, not a substitute for license mapping.

Sources

• OWASP API Security Top 10 (2023-07-03): https://owasp.org/API-Security/editions/2023/en/0x11-t10/
• NIST Secure Software Development Framework 1.1 (2022-03-03): https://csrc.nist.gov/pubs/sp/800/218/final

This article is a composite teaching scenario. It does not describe a specific company, acquisition, or compliance event. Any resemblance to an actual transaction is coincidental.

Frequently asked questions

When during the deal timeline should the open-source check begin?

Start as soon as the letter of intent is signed or the exclusivity period opens. Waiting until the confirmatory diligence phase collapses the remediation window, especially for copyleft components that require source-code publication or re-architecture. A parallel legal-technical run that takes 10–14 calendar days is typical for a mid-size target.

What is the quickest way to identify high-risk components without a full SBOM?

Run a dependency scanner (e.g., scancode-toolkit or FOSSLight) against the target's production deployment artifacts — container images, compiled binaries with embedded version strings, and lock files in archived repositories. Cross-reference the output against the SPDX License List. You will get an 80-percent-accurate picture in under a week. Use that to triage, not to finalize.

Can the acquiring company indemnify the gap instead of remediating?

Indemnification clauses cover monetary loss, not distribution compliance. If the target distributes a GPL-licensed library as part of a SaaS appliance or embedded system, no indemnity can retroactively make the distribution compliant. The acquiring entity inherits the violation and any third-party infringement claim. Indemnity is a backstop for undisclosed financial exposure, not a substitute for license mapping.

Sources and further reading

1. OWASP API Security Top 10
2. NIST Secure Software Development Framework 1.1