Open source compliance review: what the decision maker looks at
The reviewer checks three things in order: which licences sit inside the codebase, whether any of them trigger a distribution obligation once the product ships, and whether the attribution and source files match what the licence text requires. Nothing else moves the decision. A gap on any of the three stops the release calendar, not the negotiation.
What the reviewer actually checks
A compliance review starts with an inventory, not with a legal opinion. Someone runs a scan against the build, pulls out every third-party component, and matches each one to its stated licence. The decision maker then sorts the list into three buckets: components with no distribution obligation, components with an attribution obligation only, and components that trigger a copyleft obligation if the code is modified and shipped.
The third bucket is where reviews stall. A copyleft component inside a product that is sold, not just used internally, can force disclosure of source code that the vendor never intended to publish. The reviewer's job is to flag that risk before the release, not after a customer's engineering team finds it.
Who decides and how long it takes
The reviewer is usually the engineering lead or a designated compliance owner inside the vendor, not a court and not a regulator. There is no filing, no docket, no external forum. The decision is internal and the only deadline that exists is the one the vendor sets for the release.
| Stage | Who runs it | Typical duration |
|---|---|---|
| Automated scan of the build | Engineering or a scanning tool | Hours |
| Manual review of flagged components | Compliance owner | 2–5 working days |
| Legal sign-off on high-risk items | In-house or external counsel | 3–10 working days |
| Remediation (swap, rewrite, or licence-in) | Engineering | Depends on the component; can add weeks |
The point of no return sits at the release build. Once a product ships with a copyleft component that was not disclosed, the obligation attaches to every copy already distributed. Fixing it afterwards does not undo what already went out the door.
What to do before submission
- Ask engineering for a full component list before the review starts, not after.
- Match each licence to its text, not to its short name — two licences with similar names can carry different obligations.
- Flag any component with a copyleft term and route it to the compliance owner separately.
- Decide, for each flagged item, whether to remove it, replace it, or accept the obligation in writing.
- Keep the attribution file and the licence texts inside the shipped package, not only inside the repository.
- Record the decision on each flagged component before the release build is cut.
If the review also touches software that carries tokenised rights alongside its open source components, a separate filing clock applies to those rights and it does not wait for the compliance review to finish. Filing formalities in tokenised rights and the deadline sets out that clock and who it reaches.
If the process stalls
If the other side — a supplier, an acquired team, or a contractor — does not respond to a request for the component list, the review cannot close and the release should not proceed on schedule. Silence is not a pass.
If a flagged component turns out to be unused dead code, removing it resolves the flag without a legal opinion. If it is load-bearing, the choice is between a licence-compliant replacement and accepting the disclosure obligation before the next release, not after.
If the codebase was inherited through an acquisition and the target company kept no licence records, the review takes longer by default — the inventory step has to be rebuilt from the binaries, not from documentation that does not exist.
Sources and the limit of this page
This page describes the internal procedure a vendor runs before shipping code. It does not set out which licence terms apply to a specific component, and it does not replace a line-by-line review of the actual licence text — that depends on the component, not on a general rule.
Where the compliance gap sits with a supplier rather than inside the vendor's own code, exposure is easier to size before money changes hands. Counterparty report before extending credit and what to prepare sets out what to gather before that decision is made.
Where the same gap needs confirming against what is on file for a Lithuanian counterparty, the underlying record and its limits are covered separately. Document in Lithuania and the evidence explains what that record does and does not show.
If you are named in a report overview in the course of this kind of check, separate rights apply to how that data was gathered and held.
Last checked: this page reflects the procedure as run in current engineering and compliance practice; no statute or regulation number is cited because none is required to describe an internal process.
Related reading
Exit and transition planning: what the decision maker looks covers the parallel decision that comes up when a technology contract ends rather than when it ships.
FAQ
How long does open source compliance review take in practice?
A clean codebase clears in a few days. A codebase with several flagged copyleft components, or one inherited without licence records, can take two to three weeks once remediation is included.
Which documents are needed to start?
A full component list from the build, the licence text for each component, and any existing attribution file already shipped in earlier versions of the product.
What happens if the other side does not respond?
The review stays open and the release should not proceed on the original schedule. A missing component list is treated as an unresolved flag, not as a pass.