For a regulated company, license compliance means three things you can show on request: a complete inventory of components with their licenses, a written policy saying which licenses are allowed where, and records proving the policy was enforced on each release. The risk is unmanaged obligations, not open source itself.
Why do regulated industries care more?
A bank, a hospital system or a device maker faces contracts, audits and customers that ask for evidence. An unexpected license obligation found during diligence can delay a release or a deal. The evidence you need is the same kind used in security work: an inventory, a policy and a trail.
This is a compliance process, not legal advice. Have counsel set the policy for your products and distribution model.
What does the inventory need?
Every component in every shipped artifact, including transitive dependencies, with a version and a license. Store it with the release so you can answer later what was in version 4.2.
Use standard identifiers. The SPDX License List gives each license a standardized short identifier, a full name, the text and a permanent URL. Using those identifiers means two tools, or a tool and an auditor, mean the same thing. SPDX aims never to change identifiers, and deprecated ones stay valid but should no longer be used.
Plan for the messy cases: components with no license declared, dual licensed packages, and license expressions that combine several licenses. Each needs a human decision and a note.
What belongs in the policy?
A policy answers three questions per license family. Is it allowed? In what kind of product or deployment? What must we do when we use it, such as keeping a notice or offering source?
Many teams sort licenses into three bands: allowed, allowed with review, and prohibited for this product. How you sort depends on how you distribute software, so what is fine for an internal tool may be a problem for a product you ship to customers. Get counsel to confirm the bands.
How do you enforce it?
Check on the pull request, not at the end. When a developer adds a dependency, the check compares its license against the policy and either passes, asks for review or blocks. A late finding at release time is expensive because the code is already built around it.
Record exceptions. Each approved exception needs an owner, a reason, the component and version, and a review date.
Safeguard scans produce license results alongside vulnerability and secret results, so one inventory serves both. Whether a license is acceptable is your decision, and the tool reports what it finds.
What do auditors typically ask for?
We cannot speak for any specific auditor, so use these as a practice list and confirm with yours.
- The current inventory for a named release.
- The written license policy and its approval date.
- Evidence of automated checks in the pipeline.
- A list of exceptions with approvals.
- How you handle a newly discovered license change in a dependency.
What are the common failures?
Inventories built once for an audit and never updated. Policies that nobody can find. Exceptions with no expiry. Container images whose operating system packages were never counted. And license checks that run on the main branch but not on forks or release branches.
What to do
- Generate an inventory with versions and licenses on every build.
- Normalize licenses to SPDX identifiers.
- Have counsel write a policy with allowed, review and prohibited bands.
- Check licenses on every pull request that changes dependencies.
- Record exceptions with owner, reason and expiry date.
- Archive the inventory with each release.
- Review the policy once a year or after a change in how you distribute software.
Quick check
Do open source licenses apply to software we only use internally?
Obligations vary by license and by how you use and distribute the software. Ask counsel, and do not assume internal use is always free of obligations.
Is an SBOM the same as a license report?
No. An SBOM lists components. A license report adds what each license requires. Many formats can carry both, including SPDX.
Sources
Last reviewed: 18 October 2026.
