Open-source questions rarely get a section of their own in financing diligence, yet they come up every time. The reason is straightforward: what sits in the code determines whether the company’s core asset can be freely disposed of, and that fact does not appear anywhere in the financial statements. Only an audit answers it.
Most companies, asked for the first time, produce a dependency list. A list shows what is used; it does not show whether it can be commercialised, whether obligations have been performed, or who bears the risk. Investors want the latter three.
1. Three moments when someone will ask
Financing. The investor’s counsel sends a technology questionnaire. It usually contains six lines of questions and a request for evidence. A vague answer goes straight into closing conditions or valuation adjustments.
M&A. The buyer works backwards from post-closing liability and asks about legacy exposure: which components cannot be sold with the product, and which obligations survive closing.
Overseas launch or receipt of a claim. When a product enters a foreign market, or a licensee or foundation writes in, the audit stops being preventive and becomes responsive, with a very short window.
The common feature of all three: the material must be producible quickly and verifiable by a third party.
2. Six recurring questions
| Question | Typical answer | Evidence that satisfies |
|---|---|---|
| Which components are used | A package.json or dependency tree | An SBOM including transitive dependencies, with versions and paths |
| What licences apply | “All MIT and Apache” | A licence inventory mapped component by component, including dual licensing and exceptions |
| Any copyleft licences | “No GPL” | A conclusion reasoned from the distribution model, separating internal use from external distribution |
| Any commercial restrictions | “Open source is always commercial” | Restrictions listed one by one: SSPL, Commons Clause, non-commercial terms |
| Have obligations been met | “We included the LICENSE file” | Records of copyright notices, full licence texts, modification notices, source-code availability |
| Who bears the risk | “Presumably the community” | Scope of disclaimers, liability caps, and the company’s own substitution or isolation plan |
The third and fourth are the hardest. The first four ask for facts; the last two ask for judgment. Judgment depends on distribution model, modification practice and business model, and cannot be read off a table.
3. Five parts of a usable deliverable
The value of the report lies not in length but in whether the investor’s counsel can cite it directly.
| Part | Content | Answers |
|---|---|---|
| Component inventory | SBOM with direct and transitive dependencies, versions, paths | What is used |
| Licence matrix | Component, licence, obligation, performance status | What must be done |
| Risk grading | Red, amber, green, with reasons | What the worst case is |
| Remediation plan | Substitutes, isolation, completion steps and timing | How to fix it |
| Audit opinion | Conclusion, assumptions, re-review triggers | Whether it can be signed |
The fifth part is most often omitted and most affects the deal. Investors need a sentence that can go into the diligence report: on what assumptions these components can be sold with the product.
4. How to grade risk
Grading follows distribution model plus performance status, not licence names.
| Level | Typical case | Treatment |
|---|---|---|
| Red | AGPL, SSPL or a non-commercial licence combined with external distribution; unlicensed code; unknown provenance | Substitute, isolate into a separate process and assess, or disclose as a specific item in the transaction documents |
| Amber | GPL or LGPL with external distribution; MIT or Apache with missing notices; dual licence not elected | Complete performance, set a deadline, close before signing |
| Green | Permissive licence with obligations met; internal use only | Record and move on |
The same component can sit at different levels under different distribution models. GPL used internally usually does not trigger source-code obligations; once the product is delivered on-premise or as an SDK, the conclusion must be redone. Grading must state its assumptions, or it will be obsolete within six months.
5. What can be done in-house
Generating an SBOM and mapping dependencies can be done internally with tooling at low cost. Three judgments are difficult to keep in-house: the boundary between copyleft and distribution model, identification of commercial restrictions, and technical feasibility of substitutes.
External work usually starts at those three points rather than rescanning from scratch. An existing inventory can serve as the audit input, which reduces both fee and timeline.
6. What drives fee and timeline
Quotes vary with four variables: the number of components and dependency depth; whether model weights and training data are included; the distribution model (SaaS, on-premise, SDK, hardware pre-installation); and whether a formal opinion usable in the transaction is required.
A typical engagement runs two to four weeks. Where the licence chain includes model weights — base model, fine-tuned output, inference framework — the timeline extends, because authorisation documents must be checked layer by layer rather than scanned.
7. The cost of doing nothing
It shows up in three forms, all at the transaction or dispute stage.
Delayed closing. Diligence finds the problem, the buyer requires remediation before closing, and the seller bears the delay.
Valuation discount or specific indemnity. Where copyleft reaches core code, the buyer asks for a price reduction or an escrow.
Downstream claims. After delivery, a customer receives a licence claim, and liability travels back up the contract chain. The room to remediate is far smaller than before closing.
Against those three, an audit fee is usually modest. That is why it belongs before the financing starts.
8. Next steps
If financing is being prepared, three things can be done first: generate an SBOM including transitive dependencies; write down the external distribution model, since SaaS, on-premise and SDK lead to different conclusions; and list substitution or isolation options for red and amber components.
After those three, decide whether a formal external opinion is needed. Most of the time the investor only wants one sentence confirmed: core code contains no non-commercialisable component, or if it does, it has been isolated.
Related reading: IP planning for AI companies, the core contract set for AI companies, investor compliance due diligence, and the intellectual property service page.
Last updated: 4 June 2026.
Frequently Asked Questions↑ Back to article
Can all open-source components be used commercially?
No. Permissive licences such as MIT and Apache usually can; AGPL, SSPL and licences with non-commercial restrictions depend on the distribution model. The same component may lead to opposite conclusions when used internally and when distributed externally.
Does internal use of GPL components trigger source-code obligations?
Usually not. GPL's source-code obligation is triggered by external distribution. Once the product moves to on-premise delivery, SDK distribution or hardware pre-installation, the assessment must be redone and the earlier conclusion no longer applies.
What does an investor usually ask for in diligence?
Five things: an SBOM with transitive dependencies, a licence matrix by component, red-amber-green risk grading, a substitution and isolation plan, and an audit opinion that can be cited. The first two answer facts, the last three answer judgment.
How long does an open-source audit take, and how is it priced?
Typically two to four weeks. Pricing varies with four variables: the number of components and dependency depth, whether model weights and training data are included, the distribution model, and whether a formal opinion usable in the transaction is required.
How should unlicensed code be treated?
As high risk. Substitute it or obtain a licence from the rights holder; where substitution is not possible in the short term, isolate it at process level, assess the exposure, and disclose it as a specific item in the transaction documents.
Can the audit report be given directly to investor counsel?
Yes, provided it states the assumptions the conclusion rests on and the triggers for re-review. Investors need a sentence that can go into the diligence report, not a list of problems.