# Open-Source Risk in Due Diligence

> How open-source software becomes a diligence red flag: copyleft obligations, license scans, and cleaning up dependencies before a deal.

Guide  |  Author: Lidiia Levitska  |  Source: Intellectual Property Law (outsideipcounsel.com)
Canonical: https://outsideipcounsel.com/guides/open-source-risk-in-due-diligence/


<div class="quick-answer"><p><strong>Quick answer:</strong> Open-source risk is one of the most common red flags in technology due diligence. Almost every modern product is built on open-source components, and each one comes with a license. Permissive licenses (MIT, BSD, Apache 2.0) are usually fine but still require attribution. Copyleft licenses (GPL, AGPL, LGPL) are reciprocal — distribute a derivative work and you may have to release your own source code. Acquirers and investors run <strong>software composition analysis (SCA)</strong> scans to inventory every dependency and flag license conflicts. The fix is to scan your own code first, remediate problematic licenses, and adopt an open-source policy before the deal.</p></div>

Open source isn't a liability — it's how software gets built. The liability is *undisclosed or misused* open source sitting inside a product someone is about to buy or fund. When a diligence team opens your codebase and finds GPL-licensed code fused into your proprietary product, the deal doesn't necessarily die, but the questions start, the escrow grows, and your leverage shrinks. This guide explains how open source becomes a diligence red flag, the license categories that matter, why acquirers scan, and how to clean up your dependencies before anyone else looks.

## Why is open source a top diligence red flag?

Open-source software is a diligence issue for one reason: **every open-source component is licensed, and the license comes with obligations that can conflict with keeping your code proprietary.** A buyer or investor is paying for clean, transferable intellectual property. If your product depends on components whose license terms require you to disclose source code, grant patent rights, or attribute third parties — and you haven't complied — then the IP you're selling has strings attached that the buyer inherits.

The core worry for an acquirer is **copyleft contamination**: the risk that reciprocal license terms have "infected" proprietary code, so that the code you claim as your crown-jewel IP is actually subject to a license requiring public disclosure. A single violation rarely sinks a deal on its own, but it can:

- Force a price reduction or a larger **indemnity holdback / escrow**.
- Trigger **remediation as a closing condition** — you rewrite or rip out the offending code before money moves.
- Create **litigation exposure**, because open-source licenses are enforceable and copyright holders (and enforcement groups) do sue.

Open-source review sits alongside patent, trademark, and ownership review in any serious technical diligence. For the full picture of what buyers examine, see our hub guide on [IP diligence for fundraising and M&A](/guides/ip-diligence-for-fundraising-and-ma/).

## What is the difference between copyleft and permissive licenses?

There are hundreds of open-source licenses, but for diligence they fall into two families that behave very differently.

**Permissive licenses** let you do almost anything — use, modify, redistribute, and even close-source the result — provided you keep the required notices. The big three:

- **MIT** and the **BSD** licenses (2-clause and 3-clause) are short and simple: preserve the copyright notice and license text, and you're compliant.
- **Apache License 2.0** adds an express **patent grant** and a **patent-retaliation clause**, and requires you to preserve the **NOTICE file** and state any changes you made. It's permissive but more paperwork.

**Copyleft licenses** are reciprocal. If you distribute software built on them, you may have to license the combined work under the *same* terms and make the corresponding **source code** available. Strength varies:

- **GPL (GNU General Public License) v2 and v3** — *strong copyleft.* Distributing a derivative work of GPL code generally means the whole work must be released under the GPL, source included.
- **LGPL (Lesser GPL)** — *weak copyleft.* You can use an LGPL library in a proprietary program if you link to it (typically **dynamic linking**) rather than baking its code into yours, and you let users relink.
- **AGPL (Affero GPL)** — the strictest. It closes the "SaaS loophole": the copyleft obligation triggers not only on distribution but when users **interact with the software over a network**. For a cloud or web company, an AGPL dependency can be especially dangerous.

The practical takeaway: permissive licenses are usually compatible with a proprietary product; copyleft licenses require careful architecture and, sometimes, removal. We go deep on how these interact — and which combinations clash — in [open-source license compatibility](/guides/open-source-license-compatibility/).

## Can open-source code really "contaminate" my proprietary code?

Yes, within limits — and the details matter more than the scary word "viral."

Copyleft obligations generally trigger on two things: **(1) creating a derivative work** of the copyleft code, and **(2) distributing** it. The key questions are whether your code is legally a *[derivative work](https://www.law.cornell.edu/uscode/text/17/101)* of the open-source component and whether you *distribute* the result.

- **Mere use** of GPL software internally, without distribution, usually doesn't trigger the disclosure obligation. Running a GPL tool on your own servers to build your product is different from shipping GPL code inside the product.
- **Static linking** — compiling copyleft code directly into your binary — is widely treated as creating a derivative work that pulls in the copyleft terms.
- **Dynamic linking** is the classic gray area; the Free Software Foundation treats it as creating a combined work, while some lawyers disagree. This ambiguity is exactly why LGPL exists and why diligence teams flag it.
- **AGPL** rewrites the distribution question entirely: providing access to the software as a network service counts, so you can't sidestep it by never shipping a binary.

Because "derivative work" is a copyright concept, these fights are ultimately copyright disputes — you can browse how courts handle software copyright and licensing conditions in our [copyright case archive](/topics/copyright/). Courts have repeatedly held open-source licenses enforceable: in *[Jacobsen v. Katzer](https://www.courtlistener.com/opinion/209693/jacobsen-v-katzer/)* (Fed. Cir. 2008) the Federal Circuit confirmed that violating an open-source license's conditions can be **copyright infringement**, not just breach of contract, and *Software Freedom Conservancy v. Vizio* (filed 2021) is testing whether recipients of GPL-covered software can enforce the source-code obligation directly as third-party beneficiaries — a case a federal court sent back to California state court in 2022 rather than dismissing. The point: these terms have teeth.

## Don't permissive licenses come with obligations too?

They do — and skipping them is the most common real-world violation, precisely because teams assume "permissive" means "free of obligations."

Even MIT, BSD, and Apache 2.0 require you to:

- **Preserve the copyright notice and license text** for the component.
- **Include attribution** in your product's documentation, an "open-source notices" screen, or a bundled license file.
- For **Apache 2.0**, carry forward the **NOTICE file** and honor the patent terms.

Fail to attribute, and you're technically in breach even of the most business-friendly licenses. Diligence teams flag missing attributions not because they're deal-killers, but because they signal a company with **no open-source hygiene** — which makes the buyer worry about what else is undocumented. If you're setting up that hygiene from scratch, our companion guide [open-source licensing for startups](/guides/open-source-licensing-startups/) walks through building a clean program from day one.

## Why do acquirers run software composition analysis (SCA) scans?

Because manual review can't find everything, and buyers won't take your word for it. **Software composition analysis (SCA)** tools automatically crawl your codebase and dependency tree to produce three things:

1. A **software bill of materials (SBOM)** — a complete inventory of every open-source and third-party component, often expressed in a standard format like **SPDX** or **CycloneDX**.
2. A **license report** mapping each component to its license and flagging **license conflicts** (e.g., GPL code in a product you distribute closed-source).
3. A **vulnerability report** cross-referencing components against known CVEs.

Common tools include **Black Duck**, **Snyk**, **FOSSA**, and **Mend** (formerly WhiteSource). In a deal, the buyer's technical team runs one of these against your repositories and reads the output alongside your representations. If your reps say "no GPL in the product" and the scan says otherwise, you have a credibility problem on top of a legal one.

There's also a growing compliance backdrop: SBOMs are increasingly expected in enterprise procurement and, since [Executive Order 14028](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity) (2021), in federal software supply-chain requirements. An acquirer that sells to enterprises or the government cares whether *your* SBOM is clean because it becomes *their* problem post-close.

## How do I remediate open-source problems before a deal?

Do the scan *before* the buyer does. Self-diligence is the single highest-leverage move here, because it converts surprises into a managed cleanup on your own timeline. A practical sequence:

1. **Inventory everything.** Run your own SCA scan and generate an SBOM. You can't remediate what you can't see — including transitive dependencies pulled in three layers deep.
2. **Triage by license.** Sort components into permissive (usually keep, verify attribution), weak copyleft (keep only if properly isolated), and strong copyleft (investigate hard).
3. **Fix the strong-copyleft findings.** For each GPL/AGPL component in distributed or network-facing code, either **remove it**, **replace it** with a permissively licensed equivalent, **re-architect** so it's cleanly separated (dynamic linking / separate process), or — rarely — **obtain a commercial license** from the copyright holder (many projects dual-license).
4. **Close the attribution gaps.** Assemble a complete third-party notices file so MIT/BSD/Apache obligations are satisfied.
5. **Adopt a written open-source policy.** Define approved and prohibited licenses, require SCA scans in your CI pipeline, and set an approval process for adding new dependencies. A policy is itself a diligence asset — it shows the process is repeatable.

Remediation can take weeks to months depending on how deep a copyleft component is wired in, so start early. This work naturally folds into a broader pre-raise cleanup — see [the IP audit before you raise](/guides/ip-audit-before-you-raise/) for the wider checklist, of which open source is one workstream.

## How does open source show up in the deal documents?

Even a clean codebase generates paperwork, and the paperwork is where unremediated problems bite. Almost every acquisition agreement and priced financing includes **intellectual-property representations and warranties** — and modern versions carry a specific open-source rep in which you affirm, roughly, that you have not used open-source software in a way that requires disclosing, licensing, or granting rights to your proprietary code. To make that rep true, you attach a **disclosure schedule** listing the open-source components you rely on and any obligations that attach. That schedule is effectively your SBOM in legal form.

Two things follow. First, a false or incomplete open-source rep is a **breach**, and breaches feed the indemnification machinery — the buyer can claw money back from escrow or, in a bad case, sue. Second, the disclosure schedule is only as good as your inventory: if your scan missed a transitive AGPL dependency, your rep is quietly wrong the day you sign. This is why self-diligence and clean drafting are two halves of the same job — the guide on [IP reps and warranties](/guides/ip-reps-and-warranties/) walks through how these clauses are negotiated and where founders get exposed.

## What about AI-generated code and open source?

A newer wrinkle worth flagging: AI coding assistants are trained partly on open-source repositories, and there's live debate over whether their output can reproduce licensed code without attribution or carry copyleft obligations. If your team uses AI pair-programmers, your SCA scan may not catch snippets that were regurgitated rather than imported as a package. Track where AI-assisted code lives, and treat it as another provenance question in your inventory. We cover the ownership and licensing uncertainty around machine-generated work in [who owns AI output](/guides/who-owns-ai-output/).

## The bottom line

Open source is not the enemy of a clean deal — sloppy open-source management is. The distinction that drives diligence is **permissive versus copyleft**: permissive licenses (MIT, BSD, Apache 2.0) are compatible with a proprietary product as long as you honor attribution, while copyleft licenses (GPL, AGPL, LGPL) are reciprocal and can require you to disclose source code when you distribute or, for AGPL, when you serve software over a network. Acquirers will run a software composition analysis scan and read the license report against your representations. Beat them to it: build your own SBOM, replace or isolate the risky components, complete your attributions, and write down an open-source policy. Do that, and open source stays what it should be — an asset, not a red flag.

*This guide is general education, not legal advice, and does not create an attorney-client relationship. Whether a particular open-source license is triggered depends on how your code is combined and distributed and on the specific license text — consult an attorney licensed in your jurisdiction before acting.*


## Frequently asked questions

### Why is open-source software a red flag in due diligence?

Open source itself isn't the problem — undisclosed or misused open source is. Copyleft licenses like the GPL and AGPL can require you to release your proprietary source code if you distribute derivative works, and even permissive licenses like MIT and Apache 2.0 carry attribution obligations. Acquirers and investors run software composition analysis scans to find components whose license terms conflict with keeping your code proprietary, because a single violation can cloud ownership of the product they are buying.

### What is the difference between copyleft and permissive open-source licenses?

Permissive licenses (MIT, BSD, Apache 2.0) let you use, modify, and redistribute code — including inside closed-source products — as long as you preserve copyright notices and, for Apache 2.0, the NOTICE file and patent terms. Copyleft licenses (GPL, LGPL, AGPL) are reciprocal: if you distribute software that incorporates the code, you may have to license your combined work under the same terms and make your source code available. That reciprocity is what makes copyleft a diligence concern.

### What is a software composition analysis (SCA) scan?

A software composition analysis scan is an automated tool — such as Black Duck, Snyk, FOSSA, or Mend — that inventories every open-source and third-party component in your codebase, identifies each component's license, and flags license conflicts and known security vulnerabilities. Acquirers and investors commission SCA scans during technical diligence to build a bill of materials and spot copyleft contamination before closing. Running your own scan first lets you fix problems on your timeline, not theirs.

### How do I fix open-source license problems before a deal?

Start with an inventory: run an SCA scan to produce a software bill of materials listing every dependency and its license. Then triage — replace or remove components under incompatible copyleft licenses, isolate weak-copyleft libraries so they are only dynamically linked, and confirm attribution and NOTICE files are complete. Adopt a written open-source policy governing future use. Remediation takes weeks to months, so begin well before you raise or sell.