Allow license policies to be conditioned on dependency scope (Production vs Development)

Suggest new features
,
1

Problem
Some licenses are acceptable for build- or dev-only dependencies but not for anything shipped to production. A concrete example: MPL-2.0 (weak, file-level copyleft) on a pure build tool such as lightningcss carries a very different legal risk than MPL-2.0 on a runtime dependency. Today a License Profile can only mark a license as allowed or prohibited globally. The profile applies at project level and cannot distinguish by dependency scope. As a result we either allow the license everywhere (too permissive) or handle each finding individually via status changes (does not scale).

Request
Let a license policy be scoped to the dependency’s scope, e.g. “MPL-2.0 allowed for Development-scope dependencies, prohibited for Production-scope dependencies.” The scope is already tracked and filterable on the Dependency and Dependency Risk views, so the data model appears to support this.

3

For this, would you and your legal compatriots prefer the policy be scoped to the dependency scope, or the quality gate?

4

I asked around and we would prefer the policy to be scoped to the dependency scope to do the work once in a central place.

The quality gate implementation would be an improvement, but then we could merge PRs with e. g. non-compliant dev dependencies that would create work after the merge.