Open source compliance in a deliverable: what the decision maker looks at
A decision maker checks three things before accepting a deliverable that contains open source code: a full inventory of the components used, the licence attached to each one, and proof that any copyleft obligation was resolved before release. Missing any of the three turns acceptance into a guess.
Why the check exists at all
A deliverable rarely arrives written from scratch. Most codebases carry dozens of open source components, pulled in by developers who rarely record where each one came from. That gap is invisible until someone tries to sell the product, raise investment, or defend it in a dispute. At that point, the buyer's or investor's counsel asks for the component list, and a missing answer stalls the deal rather than the audit.
The concern is close in shape to a supplier audit that lands without warning: the party holding the deliverable is asked to prove something it never tracked. The situation is described in detail in An audit right is invoked without notice technology contract, and the two problems share the same root cause — no running record of what is actually inside the product.
What changes once open source sits inside the deliverable
Ownership of the deliverable stops being a single question and becomes a layered one. The client owns the code it commissioned, but each open source component keeps its own licence, and that licence travels with the code wherever it goes. Some licences ask for nothing beyond a credit line. Others require that any code linked to them be released under the same terms if the product is distributed. That second category is where acceptance risk concentrates.
A deliverable accepted without this check can look clean for months and then become a liability the day the product changes hands, is sublicensed, or is bundled into a client-facing release. The fix is cheap before acceptance and expensive after it.
| Component type | Typical licence family | Risk if unresolved | Usual action |
|---|---|---|---|
| Utility library, no linking | Permissive | Low — attribution only | Keep the notice file, move on |
| Framework, statically linked | Weak copyleft | Medium — disclosure of modifications | Isolate, document, or replace before distribution |
| Core module, deeply integrated | Strong copyleft | High — may force release of surrounding code | Remove or ring-fence before acceptance |
| Unidentified fragment | Unknown | Unassessed — cannot be signed off | Trace origin before anything else proceeds |
What to do before acceptance
- Request the bill of materials. The supplier or the internal engineering lead produces a full list of open source components, versions included.
- Map each component to its licence family. Legal counsel, not engineering, classifies permissive against copyleft — the two require different treatment.
- Flag anything that triggers disclosure. The engineering lead isolates strong copyleft components before they touch code meant to stay proprietary.
- Confirm attribution files ship with the release. The release manager checks the notice file is present, not promised.
- Run a parallel review track where the product also needs one. A deliverable heading toward a public release sometimes needs a review outside engineering as well; the pattern is close to the one in Marketing review: stages and deadlines, where a separate track has its own stages and its own deadline.
- Sign off only when the register is clean. The decision maker accepts the deliverable once every flagged component has a resolution, not a promise of one.
Who decides and on what timeline
Acceptance sits with the party named in the development agreement as the decision maker — usually the client's technical lead or in-house counsel, sometimes both acting jointly. The agreement's acceptance clause usually sets the window for review; where the clause is silent, treat silence as unresolved risk rather than as approval by default.
If the supplier disputes a finding, the matter escalates along the dispute route set in the same agreement, whether that is negotiation, mediation, or arbitration. There is no shortcut around that clause once a disagreement is on the table.
Common forks
If the deliverable stays inside the company and is never distributed, most copyleft triggers stay dormant — the obligation activates on distribution, not on internal use. The risk profile changes the day the product is sold, sublicensed, or shipped to a client.
If the supplier cannot produce a bill of materials at all, treat that gap as the finding itself. A missing inventory is not a small delay; it is the reason acceptance should not proceed.
If a strong copyleft component turns up inside a core module rather than a peripheral one, isolating it after the fact is rarely simple. The cheaper fork is catching it before integration, not after.
What this page does not cover
This page does not value the deliverable, does not calculate the cost of remediation, and does not resolve a dispute once the parties disagree on ownership. Those questions sit on the product side of the registry, closer to the way a report establishes what exists on record: see Asset in Finland: what can be established for how that boundary is drawn in a different context.
Nor does this page cover what happens once a component's true owner turns out to be a party pursuing recovery rather than a licensor — a related but distinct problem, closer to the ground covered in Debtor report after a judgment explained.
Verified
Reviewed on 4 March 2025, against current supplier contract practice and the acceptance procedures used across development agreements handled by our team. No statutory reference is cited on this page; the procedure described here concerns internal process, not a legal claim resting on a specific provision.
Related publications
A deliverable that clears open source review is not automatically safe from a later dispute over the underlying artefacts. The next question worth reading is covered in Escrow of development artefacts: what the decision maker looks, which walks through what a decision maker checks once the code itself, not just its licences, needs to be secured.
FAQ
How long does open source compliance in a deliverable take in practice?
The bill of materials can be produced in days if the supplier has kept records. Where none exist, tracing every component's origin can take weeks, and that gap is usually the longest part of the process, not the licence review itself.
Which documents are needed to start?
A component list with versions, the licence text or identifier for each one, and any attribution or notice files the supplier already holds. Without the first document, the review cannot begin at all.
What happens if the other side does not respond?
Silence does not clear the deliverable. The decision maker withholds acceptance and treats the missing response as an open finding, to be escalated under the dispute route set in the development agreement.
A deliverable that fails this check rarely fails because of one licence. It fails because no one tracked where the code came from before the deadline pushed it out the door. If a distributor further down the chain later claims rights based on how the code was licensed to it, that is a separate problem worth understanding on its own terms — see When a distributor claims an implied licence in practice.