Review license findings in this order: unknown or custom licenses in shipped code, then strong copyleft in anything you distribute, then network copyleft in services, then weak copyleft, then notice only licenses. Rank by license type, by how you use the code, and by whether it reaches customers.
Why ranking helps
A first scan of a mature codebase can return thousands of rows. Nearly all are permissive and need only a notice. A few need a lawyer. Without an order, the important ones hide in the pile.
The three questions
- What license is it, and is it known? Unknown and custom come first, because nobody has judged them.
- How is the code used? Linked into a distributed binary, run as a hosted service, used only in your build, or kept internal.
- Does it reach someone outside your company? Shipped to customers or users is different from internal tooling.
A triage table
| Priority | Finding | Why |
|---|---|---|
| 1 | Unknown or custom license in shipped code | No one has decided yet |
| 2 | Strong copyleft in distributed software | Source obligations may apply |
| 3 | Network copyleft in a hosted service | Can reach users over a network |
| 4 | Weak or file level copyleft | Narrower obligations |
| 5 | Permissive with notice rules | Ship notices |
| 6 | Build or test only | Check what the build outputs |
This order is a starting frame. Your counsel may rank differently for your business. See internal use versus distribution and the AGPL network clause.
Make each review small
Give the reviewer the package, version, license text, where it is used, and whether it ships. A decision then takes minutes. Record it so the next finding with the same text is automatic.
Use the order to set your gate
Block at priorities 1 to 3 for new code, route 4 to review, and keep the rest silent. See allow, review, deny tiers and rolling out a gate.
Try it yourself
Click through it at your own pace, or open it full screen.
See how findings are prioritized by context and compare that with the license order above.
Keep a running count by priority band and watch it over time. If band one keeps growing, your intake process is letting unknown licenses in, and the fix is upstream at the pull request gate. If band two is large, check whether your products really distribute that code or whether the findings are for internal tools you can scope out with a recorded decision.
Safeguard offers dependency scanning with policies and gates, and a free scan to produce your first inventory.
Quick check
Are build only dependencies out of scope?
Often lower priority, but check whether any build output ships.
Who decides the priority order?
Counsel, using your products and distribution model. The table is a starting point.
Last reviewed: 19 October 2026.
