Open source compliance review: costs drivers
An open source compliance review costs more when the codebase mixes many licence families, when no software bill of materials exists, and when a deal deadline is already running. The review itself follows a fixed sequence: inventory, licence matching, obligation mapping, and a remediation list. Cost tracks the length of that remediation list, not the size of the codebase.
Clients often expect the price to scale with the number of lines of code or the number of repositories. In practice it scales with how much information is missing before the review starts. A well-documented codebase with a hundred dependencies can be cheaper to review than a poorly documented one with twenty.
What drives the cost
Every open source compliance review starts from the same three questions: what components are actually used, what licence governs each one, and what obligation each licence attaches to the way the software is distributed. The answers determine how much work the review needs, and work is what drives the cost.
| Cost driver | Why it moves the cost | Evidence that shortens the review |
|---|---|---|
| Number of distinct licence families | Each family needs a separate obligation check and a separate compatibility check against the others | A licence list grouped by family, not by component name |
| Existence of a software bill of materials | Without one, the reviewer has to reconstruct the dependency tree before any licence work can start | An automatically generated bill of materials, even an incomplete one |
| Depth of transitive dependencies | Copyleft obligations can travel through dependencies the engineering team never selected directly | A dependency graph showing at least three levels |
| Distribution model | Obligations differ between internal use, on-premise delivery, and a service offered over a network | A short description of how the product reaches the end user |
| Whether a deadline is already running | A closing date or a funding condition removes the option to wait for missing documents | The date itself, stated at the start |
The pattern across all five drivers is the same: cost is a function of missing information, not of legal complexity as such. A small codebase with no bill of materials and a live deadline often takes longer to review than a large codebase that is already documented and distributed the same way it was last year.
What happens when a licence conflict surfaces late
A conflict found before signing changes a clause. A conflict found after signing changes a remedy. The second version is slower and carries more exposure, because the counterparty has already relied on the software as delivered. The same shift from prevention to remedy appears whenever a defect is found only after a party has already acted on it — When a marketplace delists the collection and the deadline works through a comparable timing problem in a different asset class.
In a technology contract, the practical effect of a late finding is usually one of three things: a delayed closing, a warranty carve-out negotiated under time pressure, or a post-signing remediation plan attached as a side letter. None of these outcomes is available once the deadline that triggered the review has already passed. This is the main reason the review is priced faster when it starts early rather than under pressure.
What to do
- The engineering team exports or generates a dependency list before any lawyer is engaged.
- The reviewer groups the list by licence family and flags anything without a clear or readable licence.
- The reviewer checks each family against the intended distribution model, not against a generic checklist.
- Findings that require a code change go to engineering; findings that require a contract clause go to the drafting team.
- The client signs off on the remediation list before it is treated as closed, item by item.
- Any item left unresolved at closing is logged with an owner and a date, not left silent.
Who reviews the findings and sets the timeline
The review is carried out by the lawyer handling the technology contract, working from material supplied by the client's engineering team. There is no external decision-maker and no filing with any body. The only real deadline is the one the transaction itself imposes — a closing date, a funding condition, or a launch date.
The review is complete when every item on the remediation list has an owner and a status, not when a fixed number of calendar days has passed. This is why two reviews of similar codebases can take different amounts of time: one starts with a clean dependency list, the other starts with none.
Common scenarios
If the codebase already has a maintained software bill of materials, the review moves directly to obligation mapping and typically finishes within days. If no bill of materials exists, the first stage of the review is building one, and that stage alone can take longer than the legal analysis that follows it.
If a copyleft component is found inside a part of the product meant for closed distribution, the fix is usually replacement or isolation, decided by engineering rather than by the lawyer. If the same component sits in a part of the product that is never distributed outside the organisation, the exposure is lower and the finding can often be logged rather than fixed at once.
If the review runs against a live closing date and a conflict is found with days left, the usual outcome is a narrow warranty carve-out covering the specific component, with a remediation obligation surviving closing rather than blocking it.
What this review does not cover
The review does not certify that a product is free of open source risk forever. New dependencies are added after every release, and the review reflects the codebase as inspected on a given date, not the codebase as it will exist next quarter. It does not replace a security assessment.
It also does not extend to the counterparty's own compliance posture when the technology is being licensed onward to a distributor. That is a separate question, addressed before the relationship is signed rather than after, in Counterparty report before onboarding a distributor and its limits.
Where the review's own output — the licence list, the dependency graph, the remediation record — later needs to be relied on in a dispute, its reliability depends on how it was produced and dated. That question is covered separately in Document report before relying on it in a dispute.
First contact and timing
A first response from the partner handling the file arrives within minutes during business hours. A cost estimate for the specific codebase follows within one business day, once the dependency list has been seen. No estimate is given before that list exists, because the size of the remediation list, not the size of the codebase, is what sets the cost.
Verified
Reviewed against current firm practice at the time of publication. The collection and dating method behind the material on this site is described in Methodology: collection, cross-checking and dating step by step.
Related reading
The same cost logic applies at the other end of a technology contract, when the relationship ends rather than begins — see Exit and transition planning: costs drivers.
FAQ
How long does open source compliance review take in practice?
With a maintained dependency list already in hand, obligation mapping usually finishes within a few working days. Without one, building the list first can take longer than the legal review that follows it.
Which documents are needed to start?
A dependency list or a software bill of materials, even a partial one, a short note on how the product is distributed, and the date of any known deadline. Without these, the first task is producing them.
What happens if the other side does not respond?
If a licensor or an upstream maintainer does not confirm a licence term in time, the review proceeds on the licence text as published and marks the item as unconfirmed rather than closed. The remediation list stays accurate, and the item is revisited once a response arrives.