GitHub License Compliance GA: Setup & Rollout Checklist

Quick answer: GitHub’s open source license compliance feature became generally available on October 16, 2026. It can check new and changed direct or transitive dependencies against a centralized enterprise license policy and, in Active mode, block a pull request until violations are resolved. It is available to GitHub Enterprise Cloud organizations—including data-resident GHEC—with GitHub Code Security enabled on the target repositories. [1] [3]

This is an implementation guide, not legal advice. A tool can enforce the policy your organization defines, but it cannot decide which licenses are acceptable for your products, distribution model, contracts, or jurisdiction.

What GitHub license compliance actually does

The feature adds centralized license policy and ruleset-based enforcement to GitHub’s existing dependency-review capabilities. When a pull request changes a supported package manifest, GitHub compares dependencies between the base and pull-request branches, evaluates detected licenses against policy, and posts annotations for noncompliant results. An Active ruleset can prevent merging; an Evaluate ruleset reports findings without intentionally blocking the merge. [1] [2]

Component	Purpose
Enterprise license policy	Defines permitted licenses using a built-in list or SPDX expressions.
Dependency graph	Supplies detected direct and transitive dependency data.
Branch ruleset	Targets repositories and runs in Evaluate or Active mode.
Pull-request annotations	Show which dependency or license does not comply.
License Manager role	Lets designated reviewers handle policy and exception requests.
Audit log and APIs	Support policy-change records, backup/restore, and package checks.

Eligibility and prerequisites

Before searching the interface for a missing setting, check all prerequisites. GitHub’s setup documentation lists GitHub Enterprise Cloud, GitHub Code Security on each target repository, permission to manage enterprise policy and rulesets, and the dependency graph enabled for repositories being evaluated. The general-availability announcement also explicitly includes data-resident GitHub Enterprise Cloud. [3] [1]

• Plan: GitHub Enterprise Cloud, including data-resident GHEC.
• Repository security: GitHub Code Security enabled for every repository in scope.
• Dependency data: dependency graph enabled.
• Permissions: access to enterprise policy and ruleset management.
• Governance: named reviewers who can approve or deny exceptions.
• Policy input: an approved allow-list expressed with known license identifiers.

If you use GitHub Free, Team, GitHub Enterprise Server, or Enterprise Cloud repositories without Code Security, do not assume this centralized GA feature is available. GitHub’s separate dependency review action may cover some repository-level use cases, but it is not the same enterprise policy product.

Step 1: Create the baseline license policy

1. Open your enterprise from GitHub’s Enterprises page.
2. Select Policies → License compliance → Default policy.
3. Select Add licenses.
4. Use Select from list for GitHub’s built-in choices, or Manual input to import one SPDX expression per line.
5. Save the policy and retain an approved copy outside the UI.

GitHub categorizes licenses by general risk level in the picker, but its documentation says that categorization is informational and is not legal advice. Treat the picker as a data-entry aid, not as approval from counsel. [3]

Policy design checklist

• Document the business owner and legal approver.
• Separate “approved by default” from “requires review.”
• Decide how to handle missing, custom, dual, and compound license expressions.
• Define when a package exception is acceptable and when a policy-wide change is required.
• Record an expiry or review date for temporary exceptions in your external governance process.
• Test applications, libraries, internal tools, mobile apps, and distributed binaries separately if their obligations differ.

Step 2: Assign reviewers

Navigate to People → Enterprise roles → Role assignments, choose Assign role, and select Enterprise Open-Source License Manager. GitHub says assigning this predefined role also subscribes reviewers to notifications for dismissal or closure requests. Use a team rather than a single person so pull requests do not stall during leave or time-zone gaps. [3]

A practical operating model is one primary reviewer from legal or the open-source program office, one engineering-security reviewer, and a documented escalation path. Keep approval standards outside individual reviewers’ memory.

Step 3: Stage repositories with a custom property

GitHub recommends an optional single-select repository custom property for gradual rollout. A clear property name is open_source_license_compliance, with values inactive, evaluate, and active; the documented example uses inactive as the default. You can then target rulesets by that property rather than manually maintaining repository lists. [3]

Property value	Recommended use	Exit criterion
inactive	Not yet assessed or prerequisites missing	Owners, manifests and dependency graph confirmed
evaluate	Observe findings without deliberate merge blocking	Known dependencies pass; exception path tested
active	Enforce the policy before merge	Operational owner accepts enforcement

Step 4: Create Evaluate and Active rulesets

Create two branch rulesets at the appropriate enterprise, organization, or repository scope. Set the first to Evaluate and target repositories whose custom property is evaluate. Set the second to Active and target repositories marked active. In both, enable Require license compliance results before merging. [3]

Important interaction: GitHub notes that a branch protection rule requiring comment resolution can track license-check annotations. That means an Evaluate-mode finding may still affect merging if unresolved annotations are required to be resolved. Test your complete branch-protection stack rather than assuming “Evaluate” can never block anything. [2]

Step 5: Test with real pull requests

1. Select a low-risk pilot repository with active maintainers.
2. Open a pull request that changes a package manifest and adds a known permitted dependency.
3. Confirm the license compliance annotation appears and passes.
4. In a disposable test branch, introduce a dependency expected to violate the test policy.
5. Confirm the annotation identifies the package and license expression.
6. Exercise the exception-request workflow and verify the assigned managers receive it.
7. Remove the test dependency and close the test request after documenting the result.

GitHub’s documented resolution paths are to change the pull request to use compliant dependencies, approve a package exception, or update the policy when allowing that license is appropriate. Active-mode pull requests remain blocked until required violations are resolved. [3]

Step 6: Handle exceptions without weakening the baseline

A finding does not automatically become an exception request: the developer may simply replace or remove the dependency. If an exception is requested and approved, the License Manager can scope it to a package, license, or package pattern and apply it at repository or enterprise scope. Prefer the narrowest scope that solves a justified case; an enterprise-wide license exception can change the posture of many unrelated repositories. [2] [3]

• Capture requester, package, version range, repository, use case, and distribution context.
• Link the legal or policy decision in your system of record.
• Choose repository scope unless a broader approval was intentional.
• Review broad package patterns carefully.
• Periodically retire exceptions that no longer have a dependency path.

Step 7: Audit and automate

GitHub says policy changes emit audit-log events under the Policy Management category with the license_compliance_policy prefix and create or modify actions. The GA release also adds REST endpoints to download, update, and replace enterprise policy, plus an endpoint that checks whether packages comply. GitHub describes that package check as useful for coding agents so they can avoid proposing packages that violate policy. [1] [3]

Start automation read-only: export the current policy, checksum it in your secure configuration process, and alert on unexpected changes. Do not let an agent silently broaden the allow-list. Policy writes should remain reviewed, attributable, and reversible.

30-minute pilot checklist

• [ ] Confirm the pilot repository is Enterprise Cloud with Code Security.
• [ ] Confirm dependency graph is enabled.
• [ ] Name the policy owner and two reviewers.
• [ ] Load a legally approved baseline license list.
• [ ] Create the three-value repository property.
• [ ] Put one repository in Evaluate mode.
• [ ] Open one passing and one intentionally failing test PR.
• [ ] Verify annotations, notifications, and exception routing.
• [ ] Check interaction with required comment resolution.
• [ ] Review audit events.
• [ ] Promote only after owners sign off.

Common rollout mistakes

• Starting Active everywhere: unknown or unusual license metadata can stop many teams at once.
• Treating risk labels as legal advice: GitHub explicitly says the picker’s risk categories are informational.
• Ignoring transitive dependencies: policy evaluation uses dependency-graph data, including detected transitive packages.
• Using one permanent reviewer: exception queues become an availability bottleneck.
• Approving broad exceptions: enterprise scope or package patterns can affect more code than intended.
• Assuming Evaluate cannot block: required comment resolution may still make annotations consequential.
• Skipping policy backup: the new APIs make backup and restore possible; use them within a reviewed process.

Frequently asked questions

Is GitHub open source license compliance generally available?

Yes. GitHub’s October 16, 2026 changelog says it is generally available for GitHub Enterprise Cloud customers, including data-resident GHEC, on repositories with GitHub Code Security enabled. One GitHub conceptual documentation page still displays a public-preview notice at the time of writing, so the changelog is the newer release-status source. [1] [2]

Does it check transitive dependencies?

Yes. GitHub states that license evaluation uses dependency data including transitive dependencies detected in the dependency graph. [2]

What is the difference between Evaluate and Active mode?

Evaluate runs the check and annotates the pull request without intentionally enforcing the license condition as a merge block. Active blocks pull requests that introduce noncompliant dependencies until violations are resolved. Required comment-resolution settings can make Evaluate annotations consequential, so test the combined configuration. [2]

Can the policy be managed through an API?

Yes. GitHub announced endpoints for downloading, updating, and replacing the enterprise policy and for checking package compliance. Its setup guide also describes policy backup and restore and webhook events around closure requests. [1] [3]

Does this replace legal review?

No. GitHub can compare detected license metadata with the policy you provide. Your organization still needs qualified guidance to decide which licenses, obligations, exceptions, and distribution scenarios are acceptable.

Last checked: October 18, 2026. GitHub product names, eligibility, interfaces, API versions, and documentation can change.

Sources

1. GitHub Changelog: Open source license compliance generally available
2. GitHub Docs: About open source license compliance
3. GitHub Docs: Configuring open source license policies
4. GitHub Docs: REST API endpoints for the dependency graph