Approve exceptions by risk, and scale the approver to company size. At around 10 people, the policy owner decides. At 100 or so, the owner plus a legal or security partner decides. At scale, local reviewers handle common cases and a board handles rare high risk ones. Always set an expiry date.
Definition
An open source policy exception is a documented permission to do something your policy does not normally allow: use a not allowed license, keep a vulnerable component, or release code outside the standard process. A good exception has a reason, an approver, conditions and an end date.
Who approves, by size
| Company size | Low risk exception | High risk exception |
|---|---|---|
| About 10 people | Policy owner | Policy owner plus founder or CTO |
| About 100 people | Policy owner | Owner, with legal or security consulted |
| 1,000 or more | Local reviewer | Review board, with an executive for the rarest cases |
The Linux Foundation guide describes a review board as engineering and product representatives, legal counsel and a compliance lead. It also warns that central approval for everything does not scale in very large companies, where local reviewers fit better. Use the board for exceptions, not for every request.
What makes an exception high risk
- The license has obligations that conflict with how you distribute software, for example a strong copyleft license in a product you ship.
- The component has a known exploited vulnerability and is reachable in a deployed service.
- The code is confidential or the release is public.
- The exception covers a regulated product or customer commitment.
The exception record
| Field | Content |
|---|---|
| What | Component and version, or the release |
| Rule being waived | Policy clause |
| Why | Business reason and alternatives considered |
| Risk and compensating control | What limits the damage |
| Approver | Name and role |
| Expiry | A date, not "until fixed" |
| Evidence | Link to scans, tests or legal review |
A fuller template is in a security exception for an open source dependency.
Rules that keep exceptions honest
- No self-approval. The requester cannot also approve.
- Expiry always. Renewing takes a fresh decision.
- Count them. Report the number of active exceptions each quarter. A rising number means the policy needs a change or the tooling needs work.
- Publish the register to the people who must live with it, not just the approver.
- Close the loop. When an exception ends, record whether the component was removed, upgraded or renewed.
Signals that your policy is wrong
If the same exception is requested repeatedly, change the policy. The Linux Foundation guide advises repeatedly asking why each rule exists and removing or automating rules that do not earn their keep.
Where Safeguard fits
Safeguard's policies and gates can enforce the standard rules and make exceptions visible, and compliance and evidence automation helps gather the proof an exception record should link to. A free scan is available at gold.safeguard.sh/scan.
Quick check
Can an engineer approve their own exception?
No. Separate the requester from the approver, even at a small company where the approver may be the founder.
How long should an exception last?
Set a date tied to the plan to fix the underlying issue. Ninety days is a common starting point, but choose a period you can actually meet.
Sources
Last reviewed: 19 October 2026.
