License compliance check: what breaks in the build pipeline
A license incident almost never looks like an incident. While the release is being built, no one notices that another transitive dependency has dragged in terms that prohibit use in a closed-source product.
License checking in the build lives as a separate script on the engineer's machine — so forbidden licenses in dependencies quietly reach production and surface during an audit or a deal, when changing the composition is already expensive.
There are three reasons. The dependency tree updates faster than anyone can read the terms: one edit to a lock file adds a dozen new packages.
The pipeline pulls from different sources — the package manager, images from a registry, ready-made binary modules, where the analyzer does not go by default. And a manual run once a quarter cannot keep up with the frequency of changes and quickly ceases to be a mandatory step.
The cost of a miss is not a line in a report. License risks of a release turn into a requirement to cut out or rewrite functionality, and sometimes into a claim from the rights holder and a halt in deliveries. You have to roll back not one change, but the entire dependency chain, including transitive ones.
This is closed by moving the license compliance check inside the pipeline: a separate step compares the dependency tree with the policy — allowed, conditionally allowed, and forbidden licenses — before publishing the artifact.
The build stops at the check stage, not in production. We analyze how this is set up and where the line runs between blocking and warning.
What automatic checking on every merge gives
License checking built into the pipeline looks not at the whole release, but at a specific set of changes in a merge: new and updated dependencies, transitive packages, version changes. Below is what the team gets in measurable form.
- Change coverage — the rule triggers on every merge to the main branch, not before release; the share of changes that passed automatic dependency checking approaches 100% without manual control.
- License review time — the report comes with a ready analysis: which license, which package brought it, and who pulled in the dependency. Reviewing one merge takes minutes instead of hours of comparing manifests.
- Eliminated class of failures — licenses with mandatory source code disclosure do not reach release: the merge is blocked, and the engineer immediately sees a suitable package replacement.
- Unified report format — results are stored in a machine-readable form (SPDX), so one export works both for legal review and as a history of decisions for each package.
- Controlled exceptions — manually allowed packages are recorded with justification and a review date, so approvals are not lost between releases.
- Feedback before release — the developer learns about the problem in their merge, not at acceptance; the amount of rework falls along with the number of unexpected licenses.
In total, this turns license cleanliness from a one-time campaign before release into a constant background: every change passes the check, not just the one included in a manual sample. Next, we analyze how such a check is configured and what prevents it from making noise.
Check modes: blocking, warning, deferred
The check mode is a trade-off between the cost of a false positive and the cost of a missed license.
In the first case, the release is stopped and engineers manually investigate whether the component is truly incompatible; in the second, disputed code goes into delivery, and you have to deal with the legal consequences.
The depth of dependency analysis is configured separately from the mode: you can check only direct dependencies or analyze the entire tree, including transitive ones.
The latter is more honest, but requires pinned versions — otherwise the rule triggers on a component that did not make it into the build at all.
| Mode | When suitable | Limitations |
|---|---|---|
| Blocking | Release branches and builds that go into customer delivery | Stops release on any non-compliance; without a vetted list of allowed licenses, gives false positives |
| Warning | Development branches, early stages of work on a task | Stops nothing: findings accumulate and go into release if no one regularly reviews the report |
| Deferred license check | External and transitive dependencies, component registry | Does not affect the build: non-compliance is discovered later, when the code is already in the main branch |
In practice, modes are combined: blocking is enabled on release branches, where every minute of downtime matters; warning — on the rest; and the deferred check is run on a schedule to track license changes for external components. Such a set gives rigor where it is justified and does not interfere with daily work.
Implementation step by step: from inventory to regulation
The order of steps here is not a formality: if you start by configuring blocks, the pipeline will stop on the very first merge and the check will be disabled.
Therefore, first we collect facts about what is already used, then we formulate the rules, and only then we put them into operation.
- Dependency inventory. We collect a complete registry: direct and transitive libraries, images, external components — with license and version for each. We separate what goes into the delivered product from what lives only in the build: the requirements for them differ.
- License admission policy. We sort licenses into three groups: allowed without question, requiring conditions (attribution, preservation of text), forbidden. We record disputed cases separately — with justification of who made the decision and on what basis.
- Configuring the check in the pipeline. We move the rules into an automatic check that runs on every change and looks at manifests and lock files. A violation stops the build with an indication of the specific dependency and license — the engineer immediately sees what to fix.
- Testing on a real merge. We run the rule on a real request, not a training example: we look at how many false positives there are, whether the check slows down the build, and whether the error message is clear. Then we configure exceptions — more precisely than disabling the rule entirely.
- Procedure for handling violations. We agree on what to do when triggered: replace the library, obtain written permission, record an exception with a deadline. Without this step, the check turns into a constant argument with developers.
- Handover of the regulation. We deliver a document with license groups, instructions for handling violations, and the points where the rule lives in the code. The regulation is updated when the policy changes — otherwise it loses force in a couple of months.
Implementation artifacts: admission policies, schemes, regulations
The result of the work is not a configured tool that lives as long as an engineer is nearby, but a set of artifacts by which the team itself reproduces the license compliance check.
Everything lies in the repository next to the code, goes through review, and is versioned together with the services.
- License admission policies — rules broken down by method of use: what is acceptable for an internal service, what for a delivered product, what goes to manual approval.
- Check flow diagram — from dependency pinning to build blocking: entry point, mandatory steps, place for human decision.
- Exception registry — a table with justification for each deviation, owner, and review date, so that allowances do not become permanent.
- License documentation — a list of components and their terms: what obligations arise upon delivery and what to attach to the release.
- Team regulation — what to do when the check triggers: how to analyze the cause, whom to go to, how to formalize an exception.
- Procedure for updating rules — who adds a new license to the lists, how the change goes through review, and how the team learns about it.
- Release reports — what was checked, what remained outside the check, where exceptions have accumulated.
The formats are open: policies are text files, documentation is ordinary text files next to the code. Such a set survives changes of tools and people.
Case study: eliminated a class of release failures due to licenses
The release stalled two days before deployment: a library under a license requiring disclosure of derivative code got into the build transitively, and the product's distribution model did not allow this.
The investigation took three meetings — lawyers looked for who and when added the package, engineers checked whether it could be replaced without rewriting the module.
The release was delayed, although the code was ready and tested: the problem turned out to be not in the logic, but in the composition of the build.
Before: check at the end of the path
License control happened at the release preparation stage, after code freeze, when the cost of fixing is maximal. Eight out of ten cases surfaced in the last days before deployment, and fixing required returning the task to development and re-running regression. The check history did not accumulate — each incident was analyzed from scratch.
After: control at merge
The check was moved to the merge moment: for each change, a list of dependencies and their licenses is assembled, and scanning based on ScanCode compares it with the policy — allow and deny lists plus exceptions with a review date.
The conclusion comes into the change discussion within minutes, next to the code changes, and the author immediately sees the package that violated the rule.
The share of non-compliances found at the release stage decreased from about 80% to 10%, release delay due to checks — from several days to hours, and analysis of one incident takes 10–15 minutes instead of a series of meetings.
Denials and exceptions are recorded in the policy, the list of licenses accumulates automatically, so repeated manual analysis is no longer needed.
How does compliance policy differ from vulnerability scanning?
Compliance policy and vulnerability scanning look at the same set of dependencies but answer different questions. The first is about rights: can this component be used in the product at all, and under what conditions.
The second is about security: does the component have a known hole, and is it reachable in our scenario.
Hence the different signals at the output. A license with an obligation to disclose derivative code in a closed-source product is not a security defect, and a vulnerability scanner simply will not show it.
The reverse situation occurs no less often: a critical vulnerability in a component under a permissive license does not violate rights but requires urgent updating.
The reactions and owners of findings also differ. A license case is closed by replacing the component, isolating it into a separate service, or a conscious decision at the product level.
A vulnerability is closed by a patch, version update, or compensating measure at the perimeter — and here the decision is made by an engineer, not a lawyer. The timelines are also different: a hole is fixed according to criticality, a license — before release.
That is why in the pipeline both checks are placed side by side but not mixed into one report. One analysis of the build composition gives two independent verdicts: on rights and on security, with different blocking rules.
If you combine them into a common list, a license finding will drown among hundreds of scanner warnings and go into production.
Combining checks in the pipeline gives a time saving: dependencies are analyzed once, and the rules are applied twice. The quality gate is common — the build does not go further if the compliance policy is violated or the criticality threshold for vulnerabilities is exceeded.
Thus the difference between the checks remains visible, and the release decision is made on both grounds at once.
Technical questions: exceptions, limitations, edge cases
License compatibility checking relies on package metadata, not on the text of the license file inside the archive.
Dual licensing, nested terms, and packages without an explicit label are marked as disputed — and this is correct: the tool narrows the circle, and a human makes the verdict.
What to do with dependencies that are already running in production?
The check reads manifests and build artifacts, not what is running on servers, so the first run will show the entire accumulated tail at once.
You cannot suppress it with blocking: first inventory — which packages are under restrictive terms, where they are actually called, and whether there is a replacement. We enable blocking rules on an agreed set; the rest goes into a queue with a review date.
How to formalize an agreed exception?
The exception lives in the repository next to the manifest — in a policy file, not in correspondence. The entry has the package name, version range, reason, approver, and review date; an overdue entry again fails the build, so the exception does not become eternal.
When the restriction comes from the rights holder, we formalize the approval in writing and attach it to the entry — until a response, the package remains on the list.
How much does the check slow down the build?
Dependency tree analysis is cached between runs, so the check adds seconds, not minutes. The report is generated as a separate step: a specific rule fails, not the whole pipeline, and the image build does not stop.
We know the boundaries in advance — packages with closed metadata and locally vendored libraries are not seen by the check; we cover them with separate rules.
Let's discuss the task: what to clarify before starting work
Before starting, it is important to understand how your dependency registry is structured and at what point in the release license checking will have an effect rather than just adding noise.
We clarify the sources of components, the current approval rules, and how deeply transitive dependencies need to be analyzed. Both the scope of work and the estimate of setup time depend on this.
- Dependency registry: which package managers are used, whether there are private and internal mirrors, and what share of direct and transitive components.
- License policy: which types are allowed, what we consider unacceptable in a delivered product, and whom to notify for a disputed license.
- Control points in the build: at what stage the check blocks release, and where a warning and a report entry are sufficient.
- Exception procedure: how a temporary permission is formalized, who approves it, and when it is reviewed.
- Artifacts and reporting: whether a list of all build components with licenses is needed and in what form to pass it on.
- Legacy in delivery: components that are already shipped and requirements for their separate analysis.
- Acceptance criteria: the share of components with confirmed licenses and the acceptable time for the build check to pass.
The collected inputs are enough to return with an implementation plan for license checking: stages, composition of changes in the build, blocking points, and an estimate of setup time.
Describe the task — we will discuss it substantively and propose a work order for your release process.