What makes an open-source software delivery reviewable
An open-source review works best as a shared verification exercise. The recipient needs to trace what was shipped, which licence terms apply, which notices accompany it and how source obligations will be fulfilled. Product, engineering, compliance and legal stakeholders each have a distinct role. Twelve common gaps in the evidence chain—and how to close them before delivery.
A release can contain an SBOM, a licence and copyright document and a scan report and still be difficult to review. Each artefact may be useful on its own, yet the review team may still be unable to tell whether all three describe the same software.
That does not by itself say anything about the quality of the toolchain or the people involved. The information crosses product management, engineering, suppliers, build systems, scanners, licence analysis, legal interpretation and release management. Questions arise when a fact established in one place is not visible in the next—or when a legal question reaches counsel without the technical evidence needed to answer it.
This article treats the review as a collaborative evidence exercise. The examples are deliberately generic and combine recurring patterns. They do not describe a particular organisation, customer or delivery.
A review succeeds when both sides can follow the same release. Delivered artefact ↔ component record in the SBOM ↔ licence conclusion and notices in the L&C document ↔ corresponding source or another fulfilment mechanism where required.
Legal counsel is a process stakeholder. Engineering and compliance teams establish the technical facts, curate findings and prepare the evidence. Questions of licence interpretation, compatibility, copyleft scope, contractual commitments and legal risk should be addressed with qualified legal counsel. Their contribution is most effective when they are involved early and receive a clear, release-specific decision package.
Swipe sideways to see the whole chain.
1. The component record lists findings, but no licence conclusion
A scanner can correctly find several licence texts in one source tree. Some apply to the component as a whole, some to individual files, examples, bundled utilities or generated material. A list of everything detected is useful evidence, but it does not answer the first review question: which licence expression governs the component included in this release?
A reviewable record separates the package-level declaration, file-level findings and the conclusion reached for the delivered artefact. SPDX makes that distinction explicit through declared and concluded licence relationships; a conclusion that differs from the declared information should be explained.1 Where that conclusion depends on ambiguous, custom or conflicting terms, the compliance record should frame the question and refer it to qualified legal counsel rather than turning a scanner finding into a legal conclusion by assumption.
MITBSD-3-ClauseGPL-2.0-onlyLicenseRef-custom-notice- additional file-level findings
- Declared: MIT
- Concluded: MIT
- File-level: mapped to relevant paths
- Obligations: licence copy and notices
- In the release: yes, with build evidence
2. Alternative licences are recorded, but the release assessment is unclear
Software may be offered under alternative licences. The original expression should remain visible, because downstream recipients may receive the same alternatives. At the same time, the delivery team needs to record which compliance path it relied on for the particular release, which files or component instance the assessment covers and why that path was suitable.
This is not a mechanical preference for a permissive option. The consequences of copyleft depend on the licence terms and on how software is modified, linked, combined and distributed. Presence in the same image alone does not settle that question.23 When the assessment turns on interpretation, licence compatibility or copyleft scope, the decision belongs with qualified legal counsel informed by the actual integration and distribution model.
GPL-2.0-or-later OR BSD-3-Clause
The alternatives are visible, but the record does not say how the release was assessed or which files and integration context were considered.
- Scope
src/compat/*in component-x- Offered
GPL-2.0-or-later OR BSD-3-Clause- Assessment
- Compliance for this release is based on BSD-3-Clause; the upstream alternatives remain recorded.
- Reason
- Technical integration and the distribution model were reviewed for this release.
- Owner
- Compliance owner, with engineering and qualified legal counsel · date
3. The same component is described differently across the release
A component may appear in more than one architecture, image or execution environment. Different teams may scan those copies at different times or merge records from different tool versions. The result can be multiple names, versions or licence conclusions for software that is intended to represent the same upstream component.
The review becomes straightforward when the delivery uses one canonical component identity and then records each instance separately: where it is included, which source revision produced it, whether it was modified and whether the licence analysis differs for that instance. Differences are acceptable when they are explained; unexplained differences create questions.
4. The licence expression does not preserve the intended logic
SPDX expressions distinguish a choice from simultaneous obligations. OR represents alternatives, AND means that both sides apply, and WITH attaches an exception or addition. Parentheses make mixed expressions unambiguous; without them, the defined order of precedence applies.2
A label such as “dual licensing” is not enough when the machine-readable expression says something different. The practical fix is to preserve the wording and structure found upstream, use valid identifiers or documented LicenseRefs, and validate the final expression before it is reused in the SBOM and the L&C document. Where the intended meaning or compatibility remains uncertain, preserve the evidence and ask qualified legal counsel rather than rewriting the expression to what seems plausible.
5. Detection results and compliance conclusions are mixed together
Scanners detect legal text. That can include standard licences, project-specific licences, exceptions, contributor agreements, developer certificates of origin, warranty disclaimers and texts whose meaning still needs investigation. A LicenseRef is not automatically an error: SPDX permits user-defined licence references, and ScanCode uses them when no standard SPDX identifier exists.24
The review needs a curated result. Genuine custom licence terms remain part of the analysis and may require legal interpretation. Contributor-process documents and bare disclaimers should not silently become the concluded licence of the shipped component. Exceptions need to stay attached to the licence they modify, and build-only findings need to be separated from software included in the product. Compliance can organise and narrow the issue; qualified legal counsel should decide questions whose answer depends on interpreting the text.
6. The inventory is not connected to the built release
A source repository usually contains more than the software that ships: tests, host tools, examples, documentation, alternative targets and generated artefacts. A source scan describes that repository. The review, however, concerns a particular binary, image, firmware package or installer.
The missing bridge is build and release evidence: the exact source revision, configuration, dependency lock data, build manifest, installed-file or module inventory, and a mapping from those records to the SBOM. In kernel builds, for example, configuration and Kbuild rules determine what is built in, built as a module or not built at all.5
Swipe sideways to see the whole diagram.
7. Names and versions do not support reliable matching
A component called by a local directory name in one document, a repository name in another and a product-specific build tag in a third is difficult to match. The same applies when a version identifies the platform release but not the upstream component revision.
Use the upstream project name, the real component version or source revision, a supplier name where relevant, stable external identifiers and hashes where they add value. The 2026 joint CISA and international-partner minimum-elements guidance strengthens SBOM fields for component hashes, licence information, tool metadata and generation context, all of which improve traceability when used consistently.6
8. Identifiers vary between the SBOM, L&C and build records
Two valid identifiers can still create a matching problem when the relationship between them is not recorded. Licence aliases, different version formats, package URLs, internal component IDs and scanner-specific keys often enter the process from different systems.
A reviewable delivery defines a canonical identity for each component and normalises the identifiers used across the SBOM, L&C document, build manifest and source package. Where an alias must remain, include an explicit mapping rather than expecting the recipient to infer that two records refer to the same thing.
9. Licence texts are complete, but the document is hard to navigate
Repeating the same licence text inside every file group can turn a useful L&C document into thousands of pages without adding new information. The reviewer still needs each distinct applicable licence text. For many licences, the same verbatim text can be included once and referenced from the components or file groups to which it applies, provided it accompanies the distribution and the mapping remains unambiguous.
Keep variants, exceptions and custom terms separately identifiable. A document should never merge texts merely because their short names look similar. Apache-2.0, for example, requires recipients to receive a copy of the licence, while other obligations—such as relevant attribution notices—must remain visible in their own right.7
10. Attribution is present, but its relationship to the code is unclear
Copyright and attribution notices are not decoration. They need to be preserved, associated with the relevant component or files and checked for extraction artefacts such as truncated names, unresolved variables or unrelated boilerplate.
For Apache-2.0 software that includes a NOTICE file, the distribution of a derivative work must carry a readable copy of the relevant attribution notices. The licence allows this in a NOTICE file, source, documentation or an appropriate display; the important point is that the relevant notices accompany the distribution and can be traced to the component.7
11. Recipient requirements enter the conversation after component choices have been made
Licence compliance and customer acceptance are related but not identical. A recipient may have approval rules, preferred identifiers, documentation templates or escalation requirements that go beyond the minimum conditions of the licences. Those requirements are easier to handle before an architecture and supplier chain are fixed.
The constructive approach is to exchange the licence policy and delivery criteria early, identify components that require approval and document agreed exceptions. Qualified legal counsel should review contractual commitments, approval clauses and exceptions that create legal or commercial risk; product ownership and architecture stakeholders can then make informed component decisions before the design is fixed. OpenChain ISO/IEC 5230 addresses the organisational processes, responsibilities and sustainability needed for a licence compliance programme; a concrete delivery still needs the acceptance criteria agreed between the parties.10
12. Source delivery is described, but not operational
Where corresponding source is required, an upstream repository link may be useful provenance, but it does not necessarily identify the source that produced the delivered binary. The release record needs the exact version or revision, local modifications, relevant configuration, interface definitions and build or installation scripts required by the applicable licence.
The fulfilment route must also work in practice: who is responsible, which binaries it covers, whether source accompanies the delivery or is supplied on request, how long any written offer remains valid and how a recipient can make that request. Engineering establishes that the source package matches the binaries, compliance documents the mechanism, and qualified legal counsel reviews whether the chosen route and any offer wording meet the applicable licence and contractual requirements. GPLv2 section 3 provides several distribution routes, and the limited pass-through option for an upstream written offer does not fit every redistribution model.8
| Evidence gap | Why questions arise | What makes it reviewable |
|---|---|---|
| 1. No component conclusion | Findings do not state what governs the delivered component | Declared and concluded licence, file-level mapping and rationale |
| 2. Alternatives without assessment | The release-level compliance path is not visible | Preserve the offered expression; record scope and assessment with engineering and legal input |
| 3. Inconsistent component records | Copies or environments cannot be reconciled | Canonical identity plus an explicit record for each instance |
| 4. Ambiguous expressions | The logic of choice, conjunction or exception is unclear | Valid SPDX expression and legal review where meaning or compatibility is uncertain |
| 5. Findings mixed with conclusions | Not every detected legal text governs shipped code | Classify and curate findings; refer genuine custom terms and exceptions for legal review |
| 6. No build connection | The scan scope and release scope may differ | Source revision, configuration, build manifest and inclusion evidence |
| 7. Weak provenance | Names and versions cannot be matched reliably | Upstream identity, real version or revision, identifiers and hashes |
| 8. Identifier drift | Documents use aliases without a mapping | Canonical identifiers and explicit alias relationships |
| 9. Repeated licence texts | The document is complete but difficult to navigate | One copy per distinct text, clearly referenced; variants kept separate |
| 10. Unmapped notices | Attribution cannot be connected to the relevant code | Validated notices mapped to components or file groups |
| 11. Late policy alignment | Acceptance rules appear after design decisions | Early policy exchange, legal review of commitments and documented exceptions |
| 12. Source route not tested | The obligation is described, but cannot yet be fulfilled | Exact source package and a legally reviewed fulfilment route, owner, duration and request channel |
Legal counsel is a process stakeholder
Open-source compliance is interdisciplinary. Tools and technical teams can establish what is present, how it was built and how it is distributed. Compliance specialists can curate findings, connect the evidence and prepare a decision record. They should not be expected to make final legal interpretations on their own.
Qualified legal counsel should be involved when the work requires interpreting licence terms, determining compatibility, assessing copyleft scope, evaluating a source-offer mechanism, reviewing contractual commitments or accepting legal risk. That does not mean forwarding every scanner result to a lawyer. The effective model is to provide a focused decision package: the relevant text, the technical integration, the distribution model, the available alternatives and the decision that must be made.
Involving counsel early also prevents a common late-stage failure: a technically complete delivery that has to be redesigned because a legal or contractual assumption was never tested.
What a successful review looks like
A successful review is not necessarily one without questions. It makes questions easy to answer because the underlying evidence is available, owned and connected. Product management defines the delivery scope. Engineering establishes what was built and how components are integrated. Compliance specialists curate the licence and attribution evidence and frame unresolved questions. Qualified legal counsel interprets licence terms, compatibility, copyleft scope, contractual obligations and legal risk. The recipient provides its acceptance criteria, and the release owner makes sure the agreed actions are implemented and every output refers to the same release.
Automation remains essential. Scanners, package managers, build systems and SBOM generators can collect and compare more information than a person could handle manually. Human review adds the decisions that tools cannot reliably make on their own: scope, inclusion, licence analysis, technical use, policy acceptance and the practical fulfilment route. Where those decisions become legal conclusions, qualified counsel remains the responsible stakeholder.
The same foundations support modern SBOM practice. The 2026 joint minimum-elements guidance strengthens traceability fields and machine-processable exchange. ENISA’s October 2026 advisory treats an SBOM as a lifecycle artefact that is generated, validated, signed, stored, consumed and maintained. A coherent open-source delivery contributes to those goals, but a licence review by itself does not demonstrate the complete SBOM lifecycle.69
Review as a shared verification exercise
The most productive reviews are collaborative. The recipient explains its acceptance criteria. The supplier provides release evidence. Engineering and compliance teams work through the technical and documentary questions with the people who know the product, while legal counsel on the relevant side addresses interpretation, contractual commitments and risk decisions. The result is not merely a document that passes a gate; it is a delivery that the recipient can understand, maintain and redistribute with confidence.
The process for building that evidence release after release is described in a follow-up article, From scan results to reliable open-source documentation, to be published on 17 November.
Preparing an open-source delivery? ef.next works with product, engineering, compliance and legal stakeholders to connect build evidence, the SBOM, the L&C document and the source-delivery mechanism before submission. We organise the technical and documentary evidence so qualified legal counsel can focus on the questions that require legal judgement. Where documentation needs to be generated from curated scan results, we work with EasyCheckOSS, a service by digitalwerk for which ef.next is a sales partner. Write to [email protected].
Legal notice: This guide describes practical review patterns and is not legal advice. The actual licence terms, technical use, distribution model, contractual commitments and agreed recipient requirements determine the obligations and artefacts for a specific release. Questions about licence interpretation, compatibility, copyleft scope, source-offer mechanisms, contractual obligations or legal risk should be addressed with qualified legal counsel familiar with the product and its distribution model.
Sources and further reading
Primary sources for the licence mechanisms, programme framework and SBOM guidance referred to above. Reviewed on 10 November 2026.
- SPDX 3.0.1, Licensing profile — declared and concluded licence relationships and the expectation to explain differences.
- SPDX 3.0.1, licence expressions —
OR,AND,WITH,LicenseRefand operator precedence. - GNU licence FAQ: aggregates and combined programs — why technical integration and distribution context matter when assessing copyleft scope.
- ScanCode LicenseDB: help and field definitions — ScanCode keys, SPDX mappings and
LicenseRef-scancode-*. - Linux kernel Makefiles (Kbuild) — an example of how configuration and build rules determine what is built into a release.
- 2026 Minimum Elements for a Software Bill of Materials — joint CISA and international-partner guidance on baseline SBOM fields and practices.
- Apache License 2.0, section 4 — licence copy, modified-file notices, retained notices and attribution from NOTICE files.
- GNU GPL version 2, section 3 and GPLv2 FAQ — corresponding source and the available binary-distribution routes.
- ENISA Technical Advisory for Software Bill of Materials (22 October 2026) — architecture, lifecycle, threats and measures for SBOM adoption.
- OpenChain ISO/IEC 5230 — key requirements for a sustainable open-source licence compliance programme.