A workable open source license policy has three tiers: allow, review and deny. Allowed licenses need no approval, review licenses need a named approver and a written reason, and denied licenses are blocked unless an exception is signed. Counsel should set the lists, and engineering should own the process.
Why three tiers
Two tiers, allowed and denied, force every unusual license into a yes or no that nobody is equipped to give. A review tier gives an honest place for the middle: licenses that are fine in some uses and risky in others. It keeps the allow list small and the deny list clear.
What goes where
Your counsel decides the actual assignment, based on how you distribute software. As a starting frame:
- Allow: permissive licenses your counsel has approved for your use cases. Examples people commonly consider are MIT, Apache 2.0 and BSD, but confirm with counsel.
- Review: licenses with conditions that depend on how you use the code, such as weak copyleft, file level copyleft, or network use clauses. See the AGPL network clause.
- Deny: licenses incompatible with your business model, and packages with no license at all. See a repo with no license.
Treat that as an illustration, not advice for your company.
Make the policy readable by a machine
Policies fail when they live in a document. Use SPDX identifiers so the lists can be applied automatically, and decide how to treat expressions. See SPDX OR versus AND. Handle unknown and unrecognized licenses explicitly, by sending them to review.
Owners and service levels
Name a person or a small group for each tier decision. Give review requests a response target, so engineers do not wait weeks and bypass the process. Keep a log of decisions so the same question is not asked twice.
Exceptions
Exceptions are normal. Require them in writing, with the component, version, use case, reason, approver and an expiry date. Expiry matters, because the use case or the license may change.
Where to enforce
Check at three points: when someone proposes a new dependency, in the pull request that adds it, and on a schedule for the full inventory. The first catches problems early, the second is the hard stop, and the third catches changes in dependencies you already have.
Measure it
Track the number of components in each tier, the number of open reviews, the age of the oldest one, and the number of active exceptions. If review requests are rising, your allow list may be too narrow.
Safeguard's policies and gates can enforce rules like these, and its SBOM and dependency scanning supply the inventory. You can try a free scan. For more context, read open source policy template for enterprises.
Quick check
Who decides which licenses are allowed?
Counsel, in consultation with engineering. This post is a frame, not legal advice.
What about licenses we have never seen?
Send them to the review tier by default.
Last reviewed: 19 October 2026.
