GitHub’s license compliance can now block dependency merges — start in Evaluate mode

GitHub made [open source license compliance generally available](https://github.blog/changelog/2026‑10‑16‑open‑source‑license‑compliance‑generally‑available/) on October 16, 2026. The feature applies to GitHub Enterprise Cloud, including data‑resident Enterprise Cloud, but a repository needs GitHub Code Security enabled before policy can be enforced. That scope matters. This is not a new universal block on open source packages, and GitHub is not declaring any particular license acceptable for every company. An enterprise defines its own allow policy, then targets repositories through rulesets. The control evaluates new or changed dependencies in pull requests, including transitive dependencies detected in the dependency graph. The useful change is timing: a license‑policy conflict can now enter the same review path as the code change that introduced it. Teams no longer need to discover every issue later from an inventory export, but the quality of the result still depends on the enterprise policy and the dependency metadata GitHub can see.

GitHub’s [license‑compliance documentation](https://docs.github.com/en/enterprise‑cloud@latest/code‑security/concepts/supply‑chain‑security/open‑source‑license‑compliance) distinguishes two rollout states. An Active ruleset using `Requires license compliance results before merging` blocks a pull request until a violation is resolved. An Evaluate ruleset runs the check and annotates the pull request without making the license result a merge gate. Evaluate mode is the safer first deployment for a large portfolio. It reveals which manifests, package ecosystems and transitive dependencies would trigger the proposed policy, while developers can still merge. The result is evidence for adjusting policy, fixing missing metadata and identifying teams that will need an exception workflow. There is one interaction to test: GitHub says a branch‑protection rule that requires comment resolution can make annotations actionable even when the license rule itself is only evaluating. A staging repository should therefore test the complete ruleset and branch‑protection combination, not assume that the word Evaluate guarantees zero merge friction.

When a dependency violates policy, the developer can remove or replace the package, the enterprise can amend the policy, or an authorized reviewer can approve a package or license exception. GitHub added an `Enterprise Open‑Source License Manager` role for the people or teams responsible for those closure requests. Pending requests appear in enterprise security views and can generate email notifications. Those paths are not interchangeable. Replacing a dependency changes engineering work. Amending the enterprise policy changes the baseline for every targeted repository. An exception preserves the baseline but creates a local decision that needs an owner and rationale. Teams should record which path resolved each alert rather than treating every green check as the same outcome. A practical rollout needs a service‑level target for exception review and a fallback when the assigned reviewers are unavailable. Without that operating path, Active mode can convert a legal‑policy signal into an unpredictable delivery queue.

The general release adds audit‑log events for license‑policy changes and API endpoints to download, update or replace the enterprise policy. GitHub also added an API that checks whether packages comply with policy, which it says can help coding agents avoid recommending or adding packages that an organization would reject. The [dependency graph REST reference](https://docs.github.com/en/rest/dependency‑graph?apiVersion=2026‑03‑10) remains the broader API entry point for dependency changes, submissions and software bills of materials. The agent use case is preventive: query policy before proposing a dependency, then show the result to the developer. It should not silently turn a policy response into legal advice or invent an exception. API callers also need to pin the API version, authenticate with the minimum permission, retain the policy revision that produced the answer and fail visibly when the policy service is unavailable. Audit events solve a different problem. They can feed a system of record when policy changes, but an event stream does not by itself explain why a license was allowed or who accepted the downstream risk. Pair the event with the human decision record and the affected repository scope.

Start with a representative repository set in Evaluate mode. Include more than one package ecosystem, repositories with and without generated lockfiles, and at least one project whose dependency graph contains transitive packages. Measure unsupported or unknown licenses, false policy conflicts, review time and the number of requested exceptions before enabling a merge gate. Then promote by repository class rather than all at once. GitHub documents a pattern that uses repository custom properties to distinguish inactive, evaluate and active groups, with enterprise policy as a common baseline and repository‑specific exceptions layered on top. Preserve an emergency bypass process with named authority and audit evidence. The release gives enterprises a native enforcement path, not proof that their license policy is legally complete. The operational win comes from testing the policy, staffing the exception queue and making both human and agent decisions traceable. Follow further GitHub platform changes on the [GitHub organization page](https://opentools.ai/organizations/github). *Image: GitHub’s official license‑compliance interface showing a non‑compliant dependency and its resolution timeline; cropped and resized without generative alteration or artificial upscaling.*