Following a public preview opened in June 2026, GitHub announced general availability of open source license compliance on October 16, reserved for GitHub Enterprise Cloud customers with GitHub Code Security. The feature lets an organization define a license policy and enforce it automatically on every pull request that adds or changes a dependency.
The principle: a license policy enforced at merge time
A license policy defines which open source licenses are allowed, which are banned, and which require a case-by-case review. The moment a pull request introduces a non-compliant dependency, GitHub attaches an annotation to it. None of that is new in principle, but general availability opens the door to making the check a blocking one.
A new condition inside rulesets
The policy is enforced through a repository ruleset, following the same pattern as the existing code scanning conditions. An organization can now require the license compliance check to pass before any merge, on the same footing as a code review or a green test suite.
| Before (preview, June 2026) | After (general availability, October 2026) |
|---|---|
| No license data for data-residency customers | Data available and fed into the dependency graph and SBOM exports |
| No dedicated ruleset condition | “Require license compliance results before merging” condition |
| No dedicated governance role | Predefined “Enterprise Open-Source License Manager” role |
| Policy changes untracked | Every policy change emits an audit log event |
| No policy management API | REST endpoints to read, update, and check a package’s compliance |
Resolving an annotation: three paths
When a dependency is flagged non-compliant, a team has three options: remove or replace the dependency, have the license policy amended by whoever is authorized to do so, or create a targeted exception for that specific package. The new “Enterprise Open-Source License Manager” role centralizes review of those exception requests, with email notifications and handling from the enterprise console — a flow that sits alongside the command-line tools teams already use to audit their dependencies.
# Check a package's compliance via the dependency graph REST API
gh api \
-H "Accept: application/vnd.github+json" \
/enterprises/ORG/dependency-graph/license-policy/check \
-f ecosystem=npm \
-f name=some-package \
-f version=2.4.1The license policy now behaves like any other ruleset condition: it can block a pull request from merging, on the same footing as a code scanning check or a required review.
GitHub also highlights a use case beyond human governance: the new API endpoints let automated coding agents check a package’s compliance before adding it to a project. An organization that already structures its deployment pipeline around automated rules, for example through a standardized self-hosting setup, gains another lever to close the loop between security, compliance, and shipping speed.
What it changes for teams managing lots of dependencies
For an organization running dozens of repositories, the difference versus the preview mainly comes down to governance tooling: audit log, dedicated role, API for agents. That at-scale tracking cost explains why the feature stays positioned on the Enterprise Cloud offering rather than on individual repositories.
Key takeaways
Open source license compliance becomes a full-fledged merge gate at GitHub, on the same level as code scanning. The main gain from general availability is governance tooling: a dedicated role, an audit log, an API agents can call. The feature still stays confined to GitHub Enterprise Cloud, leaving individual repositories and small teams without a native equivalent.
This is the kind of feature that means almost nothing below a certain size, and becomes indispensable above it. On engagements where I’ve watched a license review happen after the fact, usually triggered by a client audit or an acquisition, the pattern is always the same: nobody quite remembers which licenses are sitting in the lockfile, and fixing it retroactively costs far more than blocking the merge at the right moment would have. Opening the API to coding agents is the most interesting signal here: compliance is about to stop being a human review step and start being a constraint checked before the code is even proposed. — Simon Janvier
Further reading: the official announcement on the GitHub Changelog.
