License Policies
Block GPL / AGPL / SSPL introductions in your closed-source project. Continuous license inventory + per-PR enforcement.
Why this matters
Mixing copyleft licenses (GPL, AGPL, SSPL) into proprietary code can force you to open-source your entire product. The risk is real and frequently accidental — a developer pulls in a useful library without reading the license. License Policies catch it before merge.
License categories
Defining policies
Settings → License Policies → + Policy. Each policy has:
- Block list — license SPDX IDs to never allow (default: GPL-3.0, AGPL-3.0, SSPL-1.0)
- Allow list — explicit allowed licenses (overrides block list for specific cases)
- Require-review list — licenses that need security/legal approval (commercial, unknown)
- Scope — which projects / repos this policy applies to
- Action — block PR / require approval / log only
PR-gate enforcement
When a PR introduces a new dependency, the policy check runs:
- Identifies the license of the new dep + its transitive deps
- Compares against your policy
- Block list match → PR comment + failed status check
- Require-review match → PR comment requesting approval; PR can proceed once approved
License inventory
The Dependencies page shows a treemap of your dep tree sized by usage + colored by license category. Quick visual check that nothing copyleft snuck in.
License-specific surfacing
For each license, the inventory page shows:
- How many of your deps use it
- Which deps (drill-down list)
- What you owe (e.g. "include attribution", "publish source if you modify")
- Whether it's currently compatible with your policy
Compliance report
Generate a license-attribution report (typically what you ship as NOTICE.txt in your product). Sectora collects every attribution requirement from every dep and produces a single auditor-friendly document.