💡 Open Source License Compliance Enforcement Standard

[github-actions[bot]]

Summary

GitHub launched open source license compliance via rulesets on June 30, 2026 (public preview). This scans the full dependency graph — including transitive dependencies — against a ruleset-defined license policy, blocking PRs that introduce non-compliant licenses. An org-wide standard should define an approved license allowlist, configure the compliance ruleset across all repos, and start in evaluate mode to baseline current exposure.

Market Signal

GitHub launched license compliance in public preview (June 30, 2026) for Enterprise Cloud with Advanced Security (changelog). Key capabilities:

• Full transitive graph scanning — a GPL-licensed library buried three levels deep in a dependency flags the PR
• Ruleset integration — activated via a new "Require license compliance check results before merging" ruleset condition
• Evaluate mode — annotates PRs without blocking, allowing baseline measurement before enforcement
• Two operating modes — evaluate (annotations only) and active (merge blocking)

This fills a gap that previously required third-party tools (FOSSA, Snyk License, Black Duck) or manual review. Multiple sources (HelpNetSecurity, OpenSourceForYou) report this as a significant governance milestone.

User Signal

Downstream repos (Broodly, TalkTerm, markets) pull in npm/Go/Python dependencies that include transitive license obligations. The org currently has no license policy. The copilot-requirements.txt in scripts/ lists curated Python dependencies but there is no systematic license audit. Feature request #593 (SonarCloud debt reduction) and the broad compliance audit infrastructure show the org is investing in automated quality/compliance gates.

Technical Opportunity

The org already manages rulesets via standards/rulesets/ and apply-rulesets.sh. License compliance integrates into the same ruleset framework — it's another JSON entry in the ruleset config. The compliance-audit.sh could be extended to check license compliance ruleset status across the fleet, matching the existing compliance audit pattern. Evaluate mode makes adoption zero-risk.

Assessment

Dimension	Score	Rationale
Feasibility	med	Requires Enterprise Cloud + Advanced Security + Code Security license. Feature is in public preview.
Impact	med	Catches transitive license obligations invisible to manual review. Protects downstream repos shipping to users.
Urgency	low	Evaluate mode and preview status mean no rush. But establishing a license policy now avoids technical debt as the dependency graph grows.

Adversarial Review

Strongest objection: This is in public preview on Enterprise Cloud with Advanced Security — may not be available or stable enough for production enforcement. The org's repos are internal DevX infrastructure, not software shipped to customers with license obligations.

Rebuttal: The evaluate mode makes preview-stage risk negligible — it annotates PRs without blocking merges. Even for internal tooling, transitive license obligations matter because downstream repos (Broodly, TalkTerm) ship to users. A GPL-licensed transitive dependency in a shared library becomes a compliance issue for every consumer. Starting in evaluate mode now builds baseline data for a future enforcement decision at near-zero cost: a JSON entry in the existing ruleset config.

Suggested Next Step

1. Define an initial license allowlist: Permitted: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, CC0-1.0, Unlicense. Restricted (require review): GPL-2.0+, LGPL, MPL-2.0. Blocked: AGPL-3.0, SSPL, EUPL.
2. Deploy the compliance ruleset in evaluate mode to the .github repo first to measure transitive exposure.
3. Review the evaluate-mode annotations after 2-4 weeks to calibrate the allowlist before fleet-wide rollout.