The News, Explained

GitHub announced general availability of open source license compliance on October 16, 2026. It covers GitHub Enterprise Cloud, including data-resident customers, and requires GitHub Code Security on the repositories concerned. Source

Dependencies are outside software components a service uses. Enterprises define permitted licenses centrally and target repositories with rulesets, or collections of rules. Checks examine pull requests (PRs), proposals to combine code changes, when they change dependency manifests. Setup also requires the dependency graph, which records dependency relationships, and access to manage enterprise policy and rulesets. Source

Two settings matter at the merge step, when proposed changes join the existing code:

  • Active mode with the license-compliance merge condition blocks PRs containing policy violations until they are resolved.
  • Evaluate runs checks and adds PR annotations without itself blocking merges.
  • A separate branch-protection requirement to resolve comments before merging also applies to license annotations produced in Evaluate mode. Source

An annotation leaves a choice: change the dependency, or provide information and request an exception for review by Enterprise Open Source License Managers. Creating an annotation and submitting a request are separate steps. Source

Managers approve or deny requests. Approval specifies a package, license or package pattern, and repository or enterprise scope. It closes the alert; merging still requires other mandatory checks to pass. The license picker’s risk categories are informational, and GitHub directs organizations to their legal teams for policy guidance. Source

The release also adds license data for data-resident environments, policy-change audit records, and APIs for policy management and package-policy checks. APIs let other software access these capabilities. Source

OYOPICK’s Take

For a product lead introducing this feature, a useful starting question is who can authorize a change in this repository, and how widely that decision should apply. An exception limited to one repository and an enterprise-wide exception set different boundaries for later reviews. Naming a reviewer is only part of making those boundaries understandable to the team.

Teams starting with Evaluate have a specific reason to examine comment-resolution requirements alongside it. Planning a release around the mode’s name alone could miss the effective merge conditions. A practical measure of this feature’s operational value will be whether the person handling a stopped change can explain the applicable policy, outstanding annotations and exception-request status together.