At a glance
- Challenge
- Open-source licence obligations — copyleft, source disclosure, notice and modification terms — are unknown until a product ships or a customer asks.
- Approach
- Generate an SBOM from SCA in the build pipeline, classify every component licence, assess obligations against the actual distribution model, and gate release on unresolved strong-copyleft findings.
- Primary KPI
- % of in-scope applications with a current, reviewed SBOM and a completed licence-risk assessment.
- Impact
- IP and distribution risk detected in the SDLC rather than in a customer due-diligence questionnaire.
01
Executive Summary
Most organisations have solved open-source vulnerability scanning and have not touched open-source licence governance. They are different problems with different owners. A CVE is a security finding with a patch. A strong-copyleft obligation on a component linked into a distributed product is a legal and commercial finding with no patch — the remedy is replacement, architectural change, or source disclosure.
This playbook describes a representative licence governance model built on the SBOM that SCA tooling already produces. The critical insight is that the obligation depends on the distribution model, not on the licence alone. GPL-family components in an internally hosted service raise very different obligations from the same components in software shipped to a customer or embedded in a device — and the classification must be assessed against how the software is actually delivered.
The governance objective is not to prohibit open source. It is to make the obligation visible early enough that a developer can pick a permissively licensed alternative in an afternoon, rather than a legal team discovering the problem during acquisition due diligence.
02
Business Challenge
Open-source components enter through transitive dependencies far more than through deliberate selection. A team adds one well-known library; that library pulls in forty more, several under licences nobody has read. Version pinning is inconsistent, so the licence set changes between builds without anyone approving the change. By the time a customer asks for a licence attestation, the dependency tree has thousands of nodes and no history.
The organisational failure is that licence findings have no owner. Security owns CVEs, engineering owns build pipelines, legal owns contracts — and open-source licence obligations sit precisely between them. Findings are produced by the SCA tool, filed in a report, and never assessed against the distribution model that would determine whether they matter.
03
Typical Symptoms
Organisations that need this playbook usually recognise several of the following.
- SCA tooling runs for vulnerabilities but its licence findings are ignored or filtered out entirely.
- No current SBOM exists for products that are distributed to customers or embedded in devices.
- Nobody can state which components in a shipped product carry strong-copyleft obligations.
- Transitive dependencies are unreviewed, so the licence set changes silently between releases.
- Dual-licensed components are treated as permissive without anyone electing or documenting a licence.
- Developers have no approved-component list, so licence choice is made ad hoc at import time.
- Legal review is requested late, blocks a release, and is then bypassed under delivery pressure.
- There is no notice file, or it was generated once and never regenerated.
04
Business Risks
Business risks by domain, with the risk and its impact
| Domain | Risk | Impact if unaddressed |
|---|
| Operational |
Licence findings produced by SCA with no assessment owner or workflow |
Findings accumulate unactioned in the tool. The organisation has the data required to identify its exposure and no process that converts it into a decision. |
| Commercial |
Strong-copyleft obligations discovered during due diligence or a customer review |
Remediation happens under external deadline pressure, at the worst possible negotiating moment, and can require architectural change rather than a component swap. |
| Compliance |
Distribution and disclosure obligations unmet in shipped software |
Notice, attribution, source-availability and modification-disclosure terms are breached, creating IP and contractual exposure that is difficult to remediate retrospectively. |
| Technology |
Unpinned transitive dependencies changing the licence set between builds |
An approved release and the next patch build carry different obligations, and the SBOM on record no longer describes what actually shipped. |
05
Operating Workflow and Reference Architecture
Operating workflow
12 stages, each producing a defined output. This workflow is specific to this
playbook; the category lifecycle on the
Software Value index is an overview of how the playbooks relate,
not how any one of them runs.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative open-source licence governance workflow. Obligation depends on the distribution model as much as on the licence text; classification without a distribution assessment is incomplete. Licence interpretation should be validated with qualified legal counsel. Outcomes are not guaranteed.
Reference architecture
The systems, data and controls the workflow above runs on.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative reference architecture. SBOM generation belongs in the build pipeline so the SBOM describes the artefact that actually shipped, rather than a periodic scan of a branch that has since moved on.
06
Implementation Approach
A representative implementation sequences in 5 phases. Duration and overlap
vary with estate size, data quality and the number of source systems in scope.
Phase 1
Policy and classification framework
Decide the rules before scanning produces findings nobody knows how to judge.
- Licence policy catalogue. Classify licence families as permitted, permitted-with-conditions, requires-review or prohibited, and state the reasoning against each.
- Distribution model definition. Define the delivery models in use — internal only, hosted SaaS, distributed binary, embedded in device — since obligations differ materially across them.
- Copyleft treatment. Set the organisation's position on strong copyleft, weak copyleft and linking, validated with qualified legal counsel rather than assumed from community guidance.
- Approved-component list. Publish a pre-approved component list for common needs so the default developer path is compliant without requiring a review.
Business value
Developers get an answer at import time instead of a blocking review at release time, and reviewers judge against a written policy rather than case by case.
Phase 2
SBOM generation in the pipeline
Put scanning where the artefact is built, so the SBOM describes what actually ships.
- Pipeline integration. Run SCA as a build stage across every in-scope repository, including container image layers, rather than as a scheduled scan of a branch.
- Transitive resolution. Ensure the dependency tree resolves transitive components fully — this is where the majority of unexpected licences live.
- SBOM standardisation. Generate SBOMs in CycloneDX or SPDX, versioned and stored against the release artefact so it can be produced on demand years later.
- Version pinning. Enforce version pinning so the licence set cannot change between builds without an approved dependency update.
- Scope definition. Define which applications are in scope by distribution risk, rather than attempting universal coverage on day one.
Business value
Every release has a machine-readable, retained SBOM tied to the artefact — which is what a customer due-diligence request or a regulator actually asks for.
Phase 3
Obligation assessment
Turn detected licences into assessed obligations. This is the step that most programmes skip.
- Classification against policy. Classify each component's licence against the catalogue, flagging strong copyleft, unusual terms and unrecognised licences for review.
- Distribution-aware assessment. Assess obligations against how the software is actually delivered, since the same component may be unproblematic internally and material when shipped.
- Linking and modification analysis. Determine whether components are statically linked, dynamically linked or modified, as these change disclosure obligations under several licences.
- Dual-licence election. Where a component is offered under more than one licence, record which is elected and on what basis — an unelected dual licence is an unresolved obligation.
- Legal review routing. Route genuinely novel or high-consequence findings to qualified legal counsel with the SBOM context attached, and record the determination for reuse.
Business value
Findings become assessed obligations with a documented rationale, which is the difference between a scan report and a governance position.
Phase 4
Decision, remediation and release gating
Make the assessment consequential. Governance that cannot hold a release is advisory.
- Risk decision. Record accept, remediate, replace or escalate against each finding, with a named decision owner and a date.
- Remediation paths. Define the standard responses: swap to an approved permissive alternative, isolate behind a process boundary, or accept with disclosure obligations met.
- Release gate. Block release on unresolved strong-copyleft findings in distributed products, with a documented, time-bound exception route rather than an informal bypass.
- Notice and attribution. Generate the notice file from the SBOM at build time so attribution obligations are met automatically and stay current.
- Exception register. Track accepted risks with expiry dates so an exception cannot quietly become permanent.
Business value
Obligations are met at release rather than discovered afterwards, and accepted risks are time-bound and visible rather than forgotten.
Phase 5
Continuous monitoring and developer enablement
Keep the position current as dependencies move, and make the compliant path the easy one.
- Build-time re-scan. Re-scan on every build and alert on drift against the approved SBOM, so a transitive update that introduces a new licence is caught immediately.
- Developer feedback in the IDE and pull request. Surface licence classification at the point of dependency addition, where the cost of changing course is minutes rather than weeks.
- Remediation ageing. Track mean time to remediate by severity and drive the tail, since old unresolved findings are the ones that surface in due diligence.
- Policy refresh. Review the licence catalogue periodically as new licences and community practice emerge, with legal counsel validating changes.
- Metrics to engineering leadership. Report SBOM coverage, unresolved findings and release-blocking issues where engineering can act on them.
Business value
The compliant choice becomes the path of least resistance, and licence drift is caught at the commit rather than at the customer.
07
Technology Components
Tool categories are named rather than specific SCA products, because most organisations already own an SCA capability for vulnerability scanning and the licence governance capability is usually already licensed but unused. Licence interpretation must be validated with qualified legal counsel; nothing here constitutes legal advice.
Source and build
- GitHub / GitLab / Azure DevOps
- npm, Maven, pip, NuGet, Go modules
- CI/CD pipelines
- Container image registries
SCA and SBOM
- Software composition analysis tooling
- CycloneDX
- SPDX
- Dependency tree resolution
- Container layer scanning
Governance and workflow
- Licence policy catalogue
- Approved and prohibited component lists
- Jira for remediation tracking
- Legal review queue
- Exception register
Evidence
- Versioned SBOM storage
- Notice and attribution generation
- Release gate records
- Audit trail
08
Governance Considerations
Governance should be proportionate. The six areas below are the minimum set that has to be
explicit for this capability to hold up under internal review.
Ownership
A named open-source governance owner, typically in engineering leadership; legal counsel as the authority on interpretation; a product owner accountable for each in-scope application's SBOM.
Decision rights
Engineering may accept permissive findings within policy; legal counsel is the only authority on strong-copyleft and novel licence determinations; release-gate exceptions require named approval.
Policies
Open-source use policy with the licence catalogue, distribution-model policy, version-pinning policy, and an exception policy with mandatory expiry dates.
Approvals
New licence classifications approved by legal counsel; prohibited-component exceptions approved at defined seniority; release gate overrides recorded with rationale and expiry.
Evidence
Versioned SBOM retained per release artefact, licence determinations with reasoning, dual-licence elections, notice files and the full exception history.
Controls
Build-stage scanning on every in-scope repository, release gate on unresolved strong-copyleft findings in distributed products, drift alerting against the approved SBOM, and exception expiry enforcement.
09
Success Metrics
Primary KPI
SBOM and assessment coverage
In-scope applications holding a current, versioned SBOM with a completed licence-risk assessment against their actual distribution model.
100% of distributed applications
Operational KPIs
SBOM coverage
100% of in-scope repositories
Repositories generating an SBOM at build.
Scan freshness
Every build
Elapsed time since the last successful licence scan.
Transitive dependency coverage
≥ 99% resolved
Dependency tree nodes with a resolved licence.
Mean time to remediate
< 30 days for high severity
Finding raised to remediation confirmed.
Governance KPIs
Unresolved licence risks
Zero high severity at release
Open findings on distributed products.
Strong-copyleft findings
Tracked with a decision on each
Components carrying strong-copyleft terms.
Dual-licensed components
100% with a recorded election
Components with an elected, documented licence.
Unapproved components in use
Trending to zero
Components outside the approved list.
Policy exceptions
All time-bound with expiry
Accepted risks with a recorded expiry date.
Legal review turnaround
< 10 working days
Elapsed time for a novel determination.
Value KPIs
Release-blocking issues
Trending down
Releases held on unresolved licence findings.
Approved replacement rate
Tracked per quarter
Findings resolved by swapping to an approved component.
Due-diligence response time
Days, not weeks
Elapsed time to produce an attestation on request.
Indicative targets
Every target above is an indicative KPI for a typical enterprise, intended to support
planning discussions. Baselines should be measured in the first operating cycle and targets
set from them. These are not benchmarks, commitments or achieved client results.
10
Positive Business Impact
Obligation found in the IDE, not in due diligence
A developer sees the classification when adding the dependency, where changing course costs minutes rather than an architectural rewrite under acquisition deadline.
Distribution-aware assessment
Obligations are judged against how the software is actually delivered, so internal services are not over-governed and shipped products are not under-governed.
Consistent, documented developer guidance
An approved-component list and a written licence catalogue replace case-by-case judgement calls that vary by reviewer and by delivery pressure.
Faster legal review
Counsel receives SBOM context and a specific question rather than a raw scan report, and prior determinations are reusable.
Release confidence
The gate is objective and its exceptions are time-bound, so engineering knows in advance what will hold a release and what will not.
Attestation on demand
A versioned SBOM per release artefact means a customer questionnaire or regulatory request is answered from evidence rather than from a reconstruction exercise.
Outcomes depend on estate, contracts, data quality and organisational context, and are not guaranteed.
11
Related Playbooks
Playbooks commonly delivered alongside, before or after this one.
Important — please read
This playbook describes a typical implementation approach and a representative operating
model. It is illustrative guidance, not a statement of results. Any figures, targets or
ranges shown are illustrative and are intended to support planning discussions rather than
to predict or promise an outcome. Outcomes are not guaranteed and depend on the estate,
contracts, data quality and organisational context of each engagement.
No client names, client data, engagement detail or confidential delivery material is
disclosed anywhere in this library. Technology named in these pages appears only as an
illustrative example of a capability category and does not imply a partnership,
certification or recommendation.
