GitHub Open Source License Compliance: GA, Setup, Rulesets & API
SOURCEGitHub
PUBLISHEDOctober 16, 2026
LAYEROpen Source
SIGNAL SCORE40/100
SXF TECHNICAL BRIEF
On October 16, 2026, GitHub made open source license compliance generally available for GitHub Enterprise Cloud, including data-resident GHEC, on repositories with GitHub Code Security enabled. Enterprises can define an allowed-license policy and enforce it through pull-request rulesets; the release also adds audit events and policy/package-check APIs.
WHY IT MATTERS
Engineering and open-source program offices can detect license-policy conflicts when pull requests introduce or change dependencies, before code is merged. The checks draw on the dependency graph, including detected transitive dependencies. An Evaluate ruleset reports findings; an Active ruleset can block merging until violations are resolved.
WHAT TO VERIFY
Confirm GitHub Enterprise Cloud and repository Code Security eligibility, an enabled dependency graph, the enterprise's allowed SPDX license expressions and effective exceptions, the ruleset's Evaluate or Active mode, and the authority of designated Enterprise Open-Source License Managers. Automated checks support policy enforcement but do not replace legal review.
SXF TECHNICAL EXPLAINER / OFFICIAL GITHUB SOURCES
GitHub license compliance is now GA. What does it actually enforce?
Updated October 30, 2026
Short answer: GitHub's open source license compliance feature lets an enterprise maintain a policy for permitted dependency licenses, check new or changed packages in pull requests, and stop merges that violate that policy. GitHub announced general availability on . It is available to GitHub Enterprise Cloud customers, including data-resident GHEC, for repositories with GitHub Code Security enabled. Read GitHub's GA announcement.
This is software supply chain license-policy enforcement, not a new AI model, an open-weights release, or a tool for measuring GPU requirements. The distinction matters: the feature addresses the legal and governance risks of software dependencies, while model-weight and dataset licensing may require different checks.
ACCESS & PREREQUISITES
Who can use GitHub open source license compliance?
Account
GitHub Enterprise Cloud, including data-resident GHEC. The feature is not described as generally available to all personal or free repositories.
Repository license
GitHub Code Security must be enabled/licensed on repositories subject to enforcement.
Dependency data
Enable the GitHub dependency graph; license checks use its detected direct and transitive dependencies.
Permissions
Enterprise policy administrators and ruleset managers configure controls; the Enterprise Open-Source License Manager reviews and handles requests.
These eligibility requirements come from GitHub's feature documentation and setup guide. A repository does not automatically block merges merely because it belongs to an eligible enterprise: its effective policy and ruleset configuration determine behavior.
CONFIGURATION WALKTHROUGH
How to set up an enterprise license policy in GitHub.
Check prerequisites. Confirm Enterprise Cloud, GitHub Code Security coverage for target repositories, an enabled dependency graph, and permission to manage enterprise policies and rulesets.
Create the default policy. In the enterprise console, open Policies → License compliance → Default policy. Choose allowed licenses from GitHub's list or add recognized SPDX identifiers or expressions using manual input. Save the permitted-license baseline.
Assign responsible reviewers. Under enterprise People → Enterprise roles → Role assignments, assign the Enterprise Open-Source License Manager role to the appropriate users or team. These reviewers receive notifications about exception requests.
Pilot with an Evaluate ruleset. Create a branch ruleset with the condition Require license compliance results before merging and set its enforcement status to Evaluate. Target a controlled set of repositories before expanding coverage.
Turn on Active enforcement. When false positives, policy coverage, and exception routing are understood, use an Active ruleset to block pull requests that introduce noncompliant dependencies.
Test a real manifest change. Open a pull request that adds or updates dependencies. Check annotations, effective policy, whether the intended merge gate triggers, and the exception-approval process.
GitHub suggests using repository custom properties such as inactive, evaluate, and active to roll out controls in stages. The exact ruleset labels and available policy controls should be checked against the current GitHub setup documentation.
PULL REQUEST ENFORCEMENT
Evaluate vs Active: when does a license check block merging?
GitHub branch ruleset modes for the license compliance condition
Ruleset mode
What developers see
Effect on merges
Evaluate
License-check findings and annotations on pull requests.
Does not itself block merging; other protections, including required comment resolution, may still apply.
Active
Findings against the effective allowed-license policy.
Blocks affected pull requests until policy violations are resolved.
When a pull request changes package manifests, GitHub compares dependency changes between the base and proposed branches and evaluates detected licenses. The dependency graph can include transitive dependencies, not only packages named directly in a manifest. A finding can be addressed by replacing/removing the dependency, obtaining an authorized package exception, or changing policy where appropriate.
Important: A license annotation is not the same as an automatically submitted exception. GitHub prompts developers who choose to request an exception, and approved reviewers decide how to handle it. Effective policy and exceptions can be viewed under the repository's Settings → Security → License policy, subject to permissions.
SPDX & POLICY DESIGN
What should a license allowlist include?
Use a documented legal and engineering policy, not a blanket assumption that any license is universally safe or prohibited. For example, MIT, Apache-2.0, and GPL-3.0-only are SPDX identifiers for different licenses; whether any is permitted depends on product distribution, obligations, company policy and legal advice. SPDX identifiers standardize the names used in policy; they do not decide the legal outcome.
01 / BASELINE
Document allowed licenses.
List approved SPDX identifiers or expressions and record why the policy permits them. Include who can approve changes and when they are reviewed.
02 / EXCEPTIONS
Scope approvals deliberately.
Review package-level or license exceptions with context; distinguish a narrow exception for a package from broad policy permission across the enterprise.
03 / AUDITABILITY
Keep the change history.
GitHub's GA release added license-policy audit events. Connect them to your existing governance records if the organization needs traceable approvals.
API & AUTOMATION
How to check package license compliance with the GitHub REST API.
GitHub provides a repository-level endpoint to check package URLs (PURLs) against the effective policy. It can help internal dependency bots or AI coding agents screen packages before recommending or adding them, when those systems have permission to call it:
POST /repos/{owner}/{repo}/license-compliance/package-checks
The request body contains a purls array of up to 40 package URLs, for example pkg:npm/lodash@4.17.21. Responses describe a policy outcome for each supplied package, such as allowed, subject to the repository's current policy and the information GitHub can resolve. Fine-grained tokens for the check require Repository license policy: read permission.
Enterprise policy management also has REST endpoints for getting and setting the default policy; these require appropriate enterprise license-policy permissions. Policy writes are privileged administrative actions, not something an autonomous coding agent should perform merely to bypass a failed dependency check. Refer to the official license compliance REST API reference for supported payloads and authorization.
DEPENDENCY GRAPH & SBOM
Does license compliance replace dependency review or an SBOM?
No. Dependency review helps teams inspect dependency changes. License compliance builds on dependency analysis with a centralized enterprise license policy and ruleset-based PR enforcement. A software bill of materials (SBOM) is an inventory that supports review, but it is not itself a verdict on what a company may legally distribute.
GitHub's October GA announcement says license information is available to GitHub Enterprise Cloud data-residency customers and can populate the dependency graph and SBOM exports. Teams should still verify their inventories and identify dependencies, binaries, vendored code, containers and assets that may not be represented in a particular dependency graph snapshot.
SCOPE & LIMITATIONS
What the GitHub license check does not prove.
Not a legal opinion. An allowed policy result is not proof that every attribution, notice, source-offer, patent or redistribution obligation has been satisfied. Legal and open-source program office review remains important.
Not universal component discovery. Coverage follows recognized repository manifests and dependency graph data. Review separately installed software, copied source, binaries, datasets or assets outside that view.
Not a blanket AI model license scanner. License terms for model weights, datasets and hosted AI services are distinct from ordinary package dependency metadata. For that distinction see SXF's AI model licensing guide.
Not necessarily a merge gate until configured. Only an appropriately targeted, Active license-compliance ruleset provides the documented blocking behavior; Evaluate is designed for testing and observations.
Not the same as a security vulnerability scan. License compliance concerns license policy. Continue reviewing Dependabot findings, code security, provenance and vulnerabilities through their respective controls.
FREQUENTLY ASKED QUESTIONS
GitHub open source license compliance: practical questions.
Is license compliance available on GitHub Free?
No. GitHub documents it for GitHub Enterprise Cloud organizations with GitHub Code Security coverage on the repositories being checked.
Can Evaluate mode block a pull request?
The Evaluate-mode license condition does not itself block merging, but another branch protection control such as required comment resolution may affect annotated pull requests.
Does the license policy check transitive dependencies?
Yes, for transitive dependencies detected by the repository dependency graph. Detection coverage and manifest support still matter.
Who can approve a license exception?
Designated Enterprise Open-Source License Managers can review and handle license alert requests according to enterprise permissions and policy.
Can an AI coding agent check a package before using it?
Yes. GitHub's PURL package-check API can evaluate up to 40 packages in a request against repository policy when the caller has the necessary permissions.
Does an allowed result mean a dependency is legally safe?
No. It means the detected package/license satisfies the configured policy check. Other compliance obligations and complete asset coverage still require separate assessment.
PRACTICAL ROLLOUT CHECKLIST
Six checks before switching a repository to Active.
Confirm license and dependency-graph eligibility for each repository.
Get the allowed SPDX list and exception criteria reviewed by legal/OSPO stakeholders.
Test Evaluate-mode annotations on representative manifest changes, including transitive dependencies.
Assign an Enterprise Open-Source License Manager and establish exception response ownership.
Check whether custom properties and rulesets target exactly the intended repositories.
Enable Active after a staged review; monitor false positives, policy audit events and PR merge outcomes.