GitHub license compliance is generally available

GitHub made open source license compliance generally available on October 16, 2026, for GitHub Enterprise Cloud repositories that have GitHub Code Security turned on. The feature checks the license of every dependency a pull request adds and can block the merge when that license breaks company policy. It matters because license review usually happens late, by hand, after the code is already written.

What license compliance does

Every open source package comes with a license, the legal terms for using it. Some licenses, such as MIT or Apache 2.0, ask little of the user. Others add conditions that a company's lawyers may not accept. "Nearly all software carries some kind of license agreement," GitHub product managers Jeff Luszcz and Eric Sorenson wrote, as quoted by Help Net Security.

GitHub's changelog says the feature extends the dependency review action with one license policy for the whole enterprise. An enterprise is GitHub's top-level account that holds many organizations. Checks run automatically on any pull request that adds or changes a dependency. Each dependency whose license is not allowed gets an annotation, a note attached to the pull request.

A developer then has three ways out, according to the changelog. They can remove or replace the package, change the license policy, or ask for an exception for that one package.

What changed since the June preview

GitHub opened the feature as a public preview on June 30, 2026. The general release adds four things, according to the changelog.

Added at general release	What it does
Data residency support	License data now fills the dependency graph and SBOM exports for data-resident Enterprise Cloud
Audit log events	Changes to the license policy are logged, so outside systems can track them
Policy REST API	New endpoints download, update and replace the enterprise license policy
Package check endpoint	Tells a tool whether packages comply, so coding agents can avoid noncompliant ones

An SBOM, or software bill of materials, is a list of every component inside a piece of software. The last row matters most for AI coding tools. An agent can now ask GitHub whether a package is allowed before it adds one.

How enforcement works

The policy lists the allowed licenses. GitHub's documentation says admins pick from a built-in list or add others by SPDX identifier, the standard short code for a license. The check covers transitive dependencies too, meaning the packages your packages pull in.

Rulesets apply the policy at the enterprise, organization or repository level. A ruleset is GitHub's way to set rules across many repositories at once. The docs describe two modes:

• Active: a ruleset with the "Requires license compliance results before merging" condition blocks the merge until the problem is fixed.
• Evaluate: the same check runs and annotates the pull request, but does not block it.

Exception requests go to a new predefined enterprise role. The changelog calls it Enterprise Open-Source License Manager. Those reviewers get email notices and approve requests from the enterprise console.

GitHub's documentation suggests one broad central policy plus exceptions per repository. Teams can add a custom repository property with the values inactive, evaluate and active. Rulesets then target those values to set enforcement repo by repo.

How GitHub uses it internally

GitHub's own open source program office runs the tool, Help Net Security reported in July. That office moved off internal tools about two months before the article. It ran repositories in Evaluate mode for about a month before turning on enforcement. Most license requests were reviewed "within a few hours," the report said. The starting allowlist was MIT, Apache 2.0 and BSD-3-Clause.

The same report notes a safety valve. A team can switch a repository from Active back to Evaluate for a critical fix, then switch it back.

GitHub has been tightening the pull request this month. It shipped AI Scan for pull requests as generally available on October 15. A day later, workflow lockfiles for GitHub Actions entered public preview.

What this means for developers

If your company runs GitHub Enterprise Cloud with Code Security, you can turn this on today. None of the sources lists a separate price. Check what your current Code Security contract covers before you plan a rollout.

Start in Evaluate mode, as GitHub's own team did. A month of annotations shows which licenses your codebase already depends on before anything blocks a merge. Then move repositories to Active one group at a time with the custom property.

Agree on the allowlist first. MIT, Apache 2.0 and BSD-3-Clause are a common start. Decide who holds the license manager role, because exception requests stall without a named reviewer.

If you build internal tools or coding agents, look at the new package check endpoint. An agent that checks a package before installing it saves a blocked pull request later.

None of the sources lists which package ecosystems are covered. Test one repository from each language your company uses before you depend on full coverage.