Neither license policy wins by default. Normalize how both teams name licenses, group licenses into tiers based on how the code is used and distributed, and have counsel review the tier boundaries. The stricter list is a reasonable starting point, but it should not be copied blindly. This is not legal advice.
Start by speaking the same language
Two teams often record the same license in different ways: "Apache 2", "Apache-2.0", "ASL". Before comparing policies, normalize the names. The SPDX License List exists to identify licenses and exceptions in a consistent way, giving each a short identifier, a full name, the license text, and a permanent URL. Using SPDX identifiers in both policies removes a whole class of false disagreements.
SPDX also covers exceptions. A license with an exception is written with the WITH operator, so a policy that only lists base licenses may treat two different cases as one.
Compare the policies by use, not by company
A license risk depends on what you do with the code. Ask these questions for each product line:
- Is the software shipped to customers, or run only on your own servers?
- Is the dependency linked into your code or run as a separate program?
- Is it modified, and are the modifications distributed?
A company that ships on-premises software and a company that runs a hosted service may have written different policies for good reasons. The merged policy should say which rule applies to which kind of product.
Build the merged tiers
A common pattern is three tiers: allow, review, and deny. Place each license in a tier per use case. Where the two old policies agree, copy the placement. Where they disagree, take the disagreement to counsel with the product context attached.
| Old policy A | Old policy B | Merged approach |
|---|---|---|
| Allow | Allow | Allow |
| Deny | Deny | Deny |
| Review | Allow | Review until counsel confirms |
| Deny | Allow | Decide per product use, document why |
| Silent | Deny | Deny until reviewed |
Handle what is already in the code
New rules apply to the future. The code you already have may contain licenses the merged policy would flag. Run an inventory of both codebases and list each flagged package with where it is used. Then pick an action per item: replace, isolate, get a commercial license, or accept with sign off. See copyleft risk in acquisitions for the linking questions.
Keep a record
Store the merged tier list with a version and date, and keep the old lists. When a customer asks what your open source policy was at the time of a release, you need to answer for that date.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how each package is listed with its license, which is the data your tiers need.
Safeguard scans dependencies and builds an SBOM, and its policies can check license rules at the gate once your tiers are agreed.
Quick check
Is the stricter license list always safer?
Not always. A list written for shipped software can block things that are fine for internal tools, which pushes teams toward exceptions. Match tiers to use.
Do we need SPDX identifiers?
They are not mandatory, but using one naming scheme in both policies and both tools avoids mismatches.
Sources
Last reviewed: 19 October 2026.
