A license decision log should hold, for each dependency decision: package and exact version, the SPDX identifier, where the evidence came from, scope, the decision and its reason, the approver, the date, and an expiry or review date. With those fields, you can answer an auditor or acquirer without reconstructing history.
The fields
| Field | Why it matters |
|---|---|
| Package and exact version | Licenses can change between releases |
| License identifier | Use SPDX so entries can be compared |
| Evidence source | Metadata, LICENSE file or header, with a link |
| Scope | Runtime, development, build only, vendored |
| Decision | Allow, allow with conditions, replace, deny |
| Reason | A line a stranger can understand |
| Approver | A named role or person |
| Date | Shows what you knew when |
| Review date | Forces a second look for exceptions |
Why version and evidence are the ones people skip
The npm and Python documentation both let publishers change license fields between releases, and the Python specification notes the older free text License field and the newer License-Expression field. If you only write "package X is MIT", you cannot show which release you checked or which field you read.
A sample entry
package: example-lib
version: 2.4.1
license: Apache-2.0
evidence: LICENSE file in published archive, NOTICE present
scope: runtime, shipped in mobile app
decision: allow, carry NOTICE text in about screen
approver: engineering lead
date: 2026-10-19
review: next major version
Where to keep it
Anywhere with history and access control: a repository folder with reviewed changes, a ticket system, or your compliance tool. What matters is that it is searchable by package and that edits leave a trail.
Link it to the pipeline
Make the gate point to the log. When a rule blocks a package, the message should say which decision entry would allow it, or how to create one. That turns the log from an archive into a working tool. For exception handling with expiry, see license exception and waiver process with expiry.
Keep it small
Do not log every permissive allow. Pre-approved licenses are covered by policy. Log the reviews, unknowns, customs and exceptions, where a human made a call.
This is practical guidance and not legal advice.
Quick check
Do I log each time a version bumps?
Only when the license changed or the policy requires review. Otherwise the policy covers it.
Who should approve?
Whoever your policy names. It is common to have engineering approve routine items and counsel approve hard ones.
Safeguard's policies and compliance and evidence automation can hold this record next to the findings.
Sources
Last reviewed: 19 October 2026.
