Open source compliance review: documents to prepare

An open source compliance review maps every third-party component inside a codebase, checks the licence attached to each one, and confirms whether your distribution model triggers a disclosure obligation. The review moves fastest when engineering has already assembled an inventory, and stalls for weeks when that inventory does not exist.

What the review actually checks

The review is not a licence audit in isolation. It looks at three things together: which components are present, what each licence requires, and how the product reaches its users. A component under a permissive licence changes nothing about distribution. The same type of component under a strong copyleft licence can force source disclosure the moment the product ships to a customer.

Context matters as much as the licence text itself. A tool used only inside a build pipeline carries different exposure from a library linked into a shipped binary or exposed through an API. The review separates internal tooling from shipped code before it reaches any conclusion about obligations.

Documents to prepare

Assembling the following before the first call removes most of the back-and-forth that otherwise stretches a review from days into weeks.

The format of these documents rarely matters. A spreadsheet, an SPDX file, or an export from a scanning tool all work, provided the version numbers are current and match the build under review, not an earlier release.

A missing dependency manifest is the single most common reason a review restarts. Without it, the reviewer cannot confirm the inventory is complete, and an incomplete inventory cannot be signed off.

Stages of the review

The review runs in four stages. First, the inventory is collected and reconciled against the actual build, not against an earlier design document. Second, each licence is classified by obligation type — permissive, weak copyleft, strong copyleft, or unclear.

Third, the distribution model is matched against each classification to identify where an obligation is actually triggered rather than merely present. Fourth, findings are written up with a remediation option for each flagged component, ranked by how much work each option needs.

Components handled by external delivery partners or subprocessors need the same treatment as in-house code. Where a subprocessor supplies a component or a build step, the same inventory and licence questions apply to that supplier before the file closes — see Subprocessors, including local delivery partners overview step by step.

The point of no return

Once the inventory is signed off by both engineering and legal, it becomes the working record for the rest of the file. Adding a component after sign-off does not amend the record — it reopens stage one for that component alone, and the clock resets for it specifically, not for the whole file.

Teams that treat the inventory as final too early tend to discover late additions during a customer audit rather than during the review itself, which is the more expensive place to discover them. A late finding after release usually means a remediation plan under time pressure, rather than a calm choice between options.

What to do

1. Engineering lead exports the dependency tree from the build system before the first meeting.
2. Compliance officer maps each dependency to a licence identifier, flagging anything unclear as unclear rather than guessing.
3. Product owner writes one paragraph describing how the product reaches the end user.
4. Legal reviews the three documents together and lists components that need a closer look.
5. Engineering confirms or corrects each flagged item within an agreed window.
6. Legal issues a written finding once the inventory is stable for every flagged component.
7. The finding is filed alongside the relevant technology contract for reference at the next release.

Who decides

The compliance officer or in-house counsel sets the scope of the review and decides which flagged components need outside input. Engineering management decides whether a flagged component can be replaced or must be kept and disclosed.

Where a supplier or contributor is asked to clarify a licence term and does not answer within the agreed window, the file proceeds on the most conservative reading of that licence until a response arrives. Escalation beyond the compliance officer usually happens only when the flagged component sits in code already scheduled for release.

Forks

If the product is distributed to customers rather than run only internally, every copyleft component carries real exposure and needs a remediation plan before release. If the codebase only ever runs on your own servers, exposure narrows to components with network-triggered obligations, and the review can move faster.

If the product is offered purely as a hosted service with no code delivered to the customer, some copyleft obligations still apply through network-use clauses in certain licences, so the distribution description needs to state hosting model explicitly, not just "not distributed". If a component was modified in-house, the review needs the modification log regardless of licence type, because modification itself can trigger disclosure under some licences.

Limits

This page does not replace a licence-by-licence legal opinion once a strong copyleft component is confirmed inside a shipped product — that step needs its own file. It does not cover patent grants attached to some open source licences, which sit outside a standard compliance review.

It does not set how long a review takes for a specific codebase; that depends on the size of the inventory and how much of it arrives complete. It also does not cover security vulnerabilities inside a component, which is a separate check running alongside, not instead of, the licence review.

Sources and limits

Findings from a compliance review sometimes need corroboration from a counterparty's own filings, for example when a supplier's licensing claims need checking against public registry data — see Counterparty in Ireland and its limits in practice.

Where a document underlying a licence claim needs its own verification against a deadline, a separate registry check applies — see Document in Spain and the deadline. Both checks sit outside the compliance review itself and answer a narrower, document-specific question.

This page reflects our internal review practice and the document list we ask clients to prepare before the first call. It is checked against our current working templates on a rolling basis and updated when the underlying procedure changes.

Related publications

A compliance review often runs alongside planning for the end of a technology contract, where a similar document list applies to a different question — see Exit and transition planning: documents to prepare.

FAQ

How long does open source compliance review take in practice?

With a complete inventory ready on day one, a straightforward review closes within one to two weeks. Missing dependency manifests or an incomplete licence inventory typically add another week for each round of follow-up requests.

Which documents are needed to start?

A dependency manifest, a licence inventory, and a short description of how the product is distributed. These three let the reviewer classify the bulk of components before asking any follow-up questions.

What happens if a flagged component's supplier does not respond?

The file proceeds on the most conservative reading of that component's licence. If the component sits inside a shipped product, this usually means treating it as if disclosure is required until the supplier confirms otherwise.

If your file needs a first look at what has to move before a release date, our first response comes within minutes during working hours, and a fee estimate follows within one working day — see When a right is pledged on-chain step by step.

— Rasa Tumenaite, AURELIS