On October 16, GitHub made open-source license compliance generally available for GitHub Enterprise Cloud, including data-resident deployments, for repositories with GitHub Code Security enabled. GA follows the June public preview. Teams can configure license policy checks to stop noncompliant dependency changes from merging. But GA does not switch on enforcement in every tenant: the operational question is which dependencies, rulesets, and review decisions actually control a pull request. The release announcement describes availability, not evidence of a working deployment.
What the policy gate evaluates
GitHub’s product documentation says checks compare detected dependency changes in pull requests between the base and proposed branches, including changes to package manifests, using dependency-graph data that can include detected transitive dependencies. Policies support a built-in license list or manually entered SPDX identifiers, with policy configuration at enterprise, organization, and repository scope.
That makes the dependency inventory an evaluation input, not proof of complete coverage. Before rollout, teams should ask whether representative dependency changes appear in that inventory.
Evaluate can still encounter merge protection
An Active ruleset with the required license-compliance condition blocks a noncompliant pull request. Evaluate mode produces annotations without blocking through that condition. However, a separate branch-protection rule requiring comment resolution can still subject those annotations to merge protection, according to the same documentation.
The distinction matters when planning a trial: Evaluate does not itself enforce the license condition, but existing comment-resolution protection can still affect whether the pull request merges. Review both controls before describing an evaluation as nonblocking.
Exceptions require a separate decision
GitHub identifies removing or replacing a dependency, amending policy, and creating a package exception as resolution paths in its GA announcement. These choices have different implications: changing policy and granting an exception are decisions beyond editing the dependency.
A developer’s annotation does not automatically create an exception request. Enterprise Open Source License Managers can review requests, the documentation explains. Assigning that role subscribes reviewers to request notifications, according to the configuration guide. Assign an owner before rollout so an annotation has somewhere to go.
Stage enforcement around reviewable evidence
The configuration guide lists Enterprise Cloud, Code Security on targeted repositories, enterprise policy and ruleset management access, and an enabled dependency graph as prerequisites. It documents repository custom-property values and separate rulesets for inactive, evaluate, and active groups. This is setup guidance, not proof that a particular organization has implemented it.
Our recommendation is to start with selected repositories, inspect representative dependency-change pull requests, and check the comment-resolution interaction before activating enforcement. That is a proposed evaluation, not a test performed for this article.
Use audit and API additions deliberately
The October release adds license data for data-resident GitHub Enterprise Cloud (GHEC), policy-change audit events, policy download/update/replace APIs, and a package-compliance checking API. These are useful surfaces to include in a rollout assessment; their availability does not establish how a team has configured enforcement.
A configured gate is a bounded control
The license picker’s risk categories are informational, not legal advice; GitHub’s setup guide directs organizations to their legal teams. The reviewed vendor sources provide no independent detection measurements, universal package-coverage proof, feature-specific price, or tenant-specific status.
For platform teams, the decision is whether a configured gate enforces an agreed policy against the dependency data available. Comprehensive license compliance remains a broader question. Our Lightwell vulnerability-remediation coverage examines a related software supply-chain verification question.