Handle a license exception as a short, recorded waiver: who asked, which package and version, why, what scope, who approved, and when it expires. Review expiring waivers on a schedule. An exception without an expiry date turns into a permanent policy hole that nobody remembers approving.
When you need one
Policy denies a license, but a team needs the package. Or a package changed license in a new version and the old version is stuck. Or a package is dual licensed and you want to record the chosen option. In each case, the exception documents a decision.
Fields to record
| Field | Why it matters |
|---|---|
| Package, version, license text reference | Exactly what was approved |
| Product and use | Internal, SaaS, or distributed software |
| Reason | Why no alternative works |
| Scope | One repository or the whole company |
| Approver | Counsel or a named role |
| Conditions | Notices to ship, no modification, and so on |
| Expiry date | Forces a fresh decision |
| Exit plan | Replacement or removal date |
The review loop
- Request: the engineer files the waiver with the fields above.
- Decision: legal or the designated approver accepts, rejects, or accepts with conditions.
- Enforcement: the gate reads the waiver so the same package passes for the stated scope only.
- Reminder: send a notice before expiry.
- Renewal or removal: renew with a new reason or remove the dependency.
Common mistakes
Waivers scoped to a package name instead of a version carry over to a changed license silently. Waivers with no owner never get renewed. Waivers kept in email cannot be searched in an audit. Keep them in a register that the gate and your audit evidence both read. See setting up a security exception process.
Audit angle
Auditors and customers ask how you handle policy deviations. A register with approvals and dates is a clear answer, and it shows the policy is actually enforced.
Keep the process light. A short form and a same week answer beat a long review that teams route around. For low risk cases such as a permissive license that simply is not on the allow list yet, add it to the policy instead of granting waivers one by one. Use waivers for real deviations, and let the register stay small enough that people read it.
Write the decision in plain words, such as: approved for the internal billing service only, until the end of next quarter, with a plan to move to the alternative library. A sentence like that is easier to enforce and to audit than a vague approval. Link the waiver to the ticket where the work to remove the dependency lives, so the exit plan has an owner.
Safeguard supports policies and gates, so exceptions can sit alongside enforcement. A free scan is a way to see current findings.
Quick check
Should a waiver apply to all versions of a package?
No. Scope it to the version approved, since a later version can change license.
Who should approve?
Counsel or a named delegate, with engineering providing the technical case.
Last reviewed: 19 October 2026.
