When a dependency has a custom license, stop automation and review it. Read the full text, ask whether it restricts use, field of use or redistribution, decide allow or deny, and record the decision with the package version. Do not map it to the nearest standard license because it looks similar.
Why custom licenses are risky
Standard licenses have known meanings and an identifier on the SPDX License List. A custom license has neither. A single added sentence can change the answer.
A well known example is the JSON license. Its text grants broad permission to use, copy, modify, merge, publish, distribute, sublicense and sell, if the notice is kept. It also adds the line that the software shall be used for Good, not Evil. That line is easy to read as a joke and hard to test, which is why many organizations send it to review rather than approve it blindly.
The Apache Software Foundation treats field of use restrictions as a reason to exclude software from its products, and judges licenses against the Open Source Definition. Your company policy may differ, but the logic is a useful starting point.
A review process
- Collect the exact license text from the package version you use.
- Check for restrictions on commercial use, field of use, users, or modification.
- Check what you must do when you redistribute, such as notices or source.
- Ask legal for an allow or deny decision for the text, not just the package.
- Record the decision against the text so identical licenses elsewhere resolve faster.
| Question | If yes |
|---|---|
| Restricts who or what you may use it for | Deny, or get written permission |
| Requires source release for your code | Treat like copyleft |
| Adds only attribution | Likely allow, with notice |
| Ambiguous wording | Escalate to counsel |
Recording it in an SBOM
Use a LicenseRef identifier for the unlisted license and keep the text with it. See how to record a license not on the SPDX list.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a gate can hold a change for review and think about which license results should always reach a person.
If a package is important and its license is unclear, consider asking the author to clarify or to adopt a standard license. Maintainers often agree when asked politely, and a clear license helps every user. Keep the reply with your records.
Safeguard supports policies and gates on pull requests, and you can try a free scan first.
Quick check
Is the JSON license open source?
This post does not rule on that. The Good, not Evil line is a use restriction that many teams review manually. Ask counsel.
Can I treat a custom license like MIT if it looks similar?
No. Small wording changes can change obligations, so review the actual text.
Sources
- JSON.org license text: https://www.json.org/license.html
- Apache Software Foundation, Resolved licensing questions: https://www.apache.org/legal/resolved.html
Last reviewed: 19 October 2026.
