Open source compliance in a deliverable: documents to prepare
Before a deliverable containing open-source code is accepted, the receiving team needs four documents: a software bill of materials, a licence inventory, a notices file and a written compliance statement. Without these, nobody can confirm what was actually delivered, and acceptance sign-off has no basis to rely on.
What triggers the check
The check starts the moment a deliverable is marked ready for handover, before invoicing and before the acceptance certificate is signed. A development team rarely tracks every dependency by licence type while it builds; a compliance pass has to reconstruct that picture afterwards. Skipping this step does not remove the risk. It moves the risk to whoever accepts the deliverable without reading the fine print.
The point of no return sits at the acceptance certificate. Once it is signed, the receiving party has accepted the deliverable as compliant. Unwinding a missed copyleft obligation afterwards usually means a separate remediation project, not a re-opening of the original one.
Documents to prepare
Four documents cover a typical review. Larger deliverables split some of them into per-component files, but the structure stays the same.
| Document | What it records | Who prepares it |
|---|---|---|
| Software bill of materials (SBOM) | Every third-party and open-source component, with version | Development lead |
| Licence inventory | The licence type attached to each component and its obligations | Compliance reviewer |
| Notices file | Required attribution text and copyright notices | Development lead |
| Compliance statement | A signed confirmation that the inventory was checked against the deliverable's use case | Project manager or CTO |
A fifth document, a copyleft risk note, is added when any component carries a licence that could require releasing the deliverable's own source code. Not every deliverable needs one; a component-only review usually settles this within a day.
A similar review discipline applies to disclosure documents in unrelated deals: How offering document preparation token issuance what the decision maker looks at follows the same pattern of inventory, flag and sign-off.
Steps, in order
- Development lead exports the dependency tree and drafts the SBOM before the code freeze.
- Compliance reviewer matches each entry to its licence text and flags anything with copyleft terms.
- Development lead assembles the notices file from the flagged licences' attribution requirements.
- Project manager circulates the inventory and notices file to the client-side technical contact for comment.
- Project manager or CTO signs the compliance statement once comments are closed.
- The signed statement is attached to the acceptance certificate before final sign-off.
Who reviews and signs off
On the delivering side, sign-off usually rests with the project manager or the CTO, whoever holds contractual authority to confirm deliverable readiness. On the receiving side, a technical reviewer checks the SBOM against the client's own dependency policy, if one exists.
Escalation, when the two inventories disagree, goes to whoever negotiated the statement of work, not to the development team directly. A typical review cycle runs three to ten working days, depending on how many components need licence-by-licence checking.
The staging logic mirrors escrow set-up for other technology deliverables: How escrow set-up technology contract runs in practice follows a comparable sequence of freeze, review and sign-off.
Three common scenarios
If the SBOM shows no copyleft components, the compliance statement can be signed the same day the inventory is confirmed.
If one component carries a strong copyleft licence, the team either replaces it before delivery or discloses the obligation in writing and gets the client's acceptance of that condition.
If the client's own policy bans a licence type outright, the component is swapped before the deliverable is resubmitted for review.
What this page does not cover
This page does not set out licence-by-licence obligations, and it does not value the cost of a compliance breach. Source code escrow arrangements sit in a separate procedure, not here. It also does not replace a review of a specific licence's enforceability for a given deliverable.
Sources and limits
Verified: 1 June 2025. The staging order reflects delivery practice on software engagements; it draws on project-management norms rather than a statutory timetable, so no external registry entry is cited for the steps above.
Before signing off, some receiving teams check the counterpart's disclosed asset position first, as a broader risk read: Asset report belgium.
If a deliverable dispute later reaches enforcement, a party's status after a judgment becomes relevant: Debtor report after a judgment in detail.
FAQ
How long does open source compliance in a deliverable take in practice?
A component-only review typically closes in three to ten working days. Complex deliverables with many dependencies, or with a disputed copyleft component, can run several weeks while a replacement is sourced.
Which documents are needed to start?
The dependency tree or build manifest listing every third-party component used in the deliverable. Without it, the software bill of materials cannot be drafted.
What happens if the other side does not respond?
The compliance statement stays unsigned and the acceptance certificate cannot be issued. Most agreements set a response window after which the delivering party can treat the inventory as accepted by default; check the specific agreement for that clause.
Related reading
For the parallel procedure covering deposited source code rather than open-source components: How escrow of development artefacts ownership of results documents.
Next step
Cost-of-being-wrong analyses cover adjacent disputes. A court in another country decides first patent what it costs to be wrong looks at cross-border timing.
When a franchise partner leaves with the sign: what it costs to be wrong covers a related trade mark dispute.
When royalties are underreported: what it costs to be wrong shows how an audit trail gap plays out in licensing.