GitHub License Compliance: How to Block Unapproved Dependencies Before Merging

Adding a JavaScript package or a Python library can introduce more than new code into a project: it can also introduce licensing obligations that a company has not approved. On October 16, 2026, GitHub made its open source license compliance feature generally available for eligible GitHub Enterprise Cloud customers, giving organizations a way to check dependency licenses against centrally managed policies before pull requests are merged. The practical change is not simply another security warning. Teams can now connect license rules to their repository merge process, making it harder for an unapproved dependency to slip into a production codebase unnoticed.

GitHub license compliance moves from preview to general availability

GitHub introduced the feature in public preview on June 30, 2026, before announcing general availability in October. It is available to GitHub Enterprise Cloud customers, including customers using data residency, when the relevant repositories have GitHub Code Security enabled. That eligibility requirement matters: this is not a universal feature that every developer can switch on in a personal repository or a standard free organization. For enterprises managing many repositories, however, the central policy can replace a patchwork of manually maintained checks with a consistent process. GitHub also expanded the feature with policy audit events and application programming interface endpoints that make the policy easier to manage and integrate with other systems.

Why dependency licenses can become a programming problem

Most applications rely on code written by other developers, whether it arrives through a package manager, a framework, or a library several layers down the dependency tree. Each component may have a license defining how it can be used, modified, distributed, or incorporated into another product. A permissive license such as MIT generally allows broad reuse subject to conditions, while licenses with stronger obligations can require additional steps when software is distributed. The exact obligations depend on the license and how the software is used, so a label alone is not a substitute for legal review. The engineering problem is scale: a project can depend on packages that depend on other packages, and a developer reviewing one new import may not see every license it brings along.

GitHub's dependency graph tracks relationships between packages and repositories, including indirect or transitive dependencies. Its license compliance feature uses this dependency information to evaluate changes against an organization's approved license policy. The policy can use license identifiers from GitHub's built-in list or a Software Package Data Exchange (SPDX) identifier entered manually when a license is not listed. SPDX is a standard for identifying software licenses and related information in a consistent, machine-readable form. Standardized identifiers help automation compare records, but they do not guarantee that every package has accurate or complete licensing metadata.

What happens when a pull request adds a restricted package

Consider a team whose policy permits a defined set of licenses but does not permit every license encountered in the wider open-source ecosystem. A developer opens a pull request that changes a package manifest, which is the file that records project dependencies. GitHub compares the dependency changes between the base branch and the proposed branch, evaluates the detected licenses against the applicable policy, and reports violations as annotations on the pull request. These messages give reviewers a concrete issue to investigate before the code is merged, rather than leaving the team to discover the package during a later audit. The developer may need to replace the dependency, revise the proposed change, or request an approved exception.

The feature's enforcement depends on the ruleset mode. A ruleset in Evaluate mode runs the license checks and reports findings without automatically blocking the merge through that condition. A ruleset in Active mode can prevent merging when the required license compliance result identifies a policy violation. This distinction gives teams a way to observe what their existing projects would fail before turning on a hard block. One caveat is that a separate branch protection requirement to resolve comments can affect whether annotations from Evaluate-mode checks still prevent merging, so administrators should test the full ruleset configuration rather than assuming Evaluate always means an entirely non-blocking workflow.

How to configure a license policy without disrupting every team

Before enforcement can work, an enterprise needs GitHub Enterprise Cloud, GitHub Code Security enabled for the repositories in scope, permission to manage policies and rulesets, and the dependency graph enabled for the repositories being evaluated. Administrators can then create a default policy from the enterprise's Policies area and choose the licenses that are acceptable under their organization's rules. GitHub categorizes licenses in its picker by general risk for corporate environments, but those labels are informational rather than legal advice. A company should define its allowed licenses with input from the people responsible for software licensing and compliance instead of copying a generic list without considering its own distribution model. Where a license is not available in the picker, an administrator can enter its SPDX identifier manually.

The safer rollout is to start with observation rather than immediately blocking every repository. GitHub's documentation describes using repository custom properties to classify repositories as inactive, evaluate, or active, then targeting rulesets according to those values. An organization can first inspect the findings from Evaluate mode, investigate unusual or missing license records, and agree on an exception process before changing selected repositories to Active mode. Once the policy is stable, the ruleset condition called Require license compliance results before merging connects the check to the pull request workflow. This staged approach reduces the risk of suddenly blocking a release because a legacy dependency has not yet been reviewed.

Exceptions need an owner, not an automatic approval

Not every policy violation means a package must be removed permanently. A dependency may be essential, an alternative may be impractical, or the organization may decide after review that a particular use is acceptable. GitHub provides a predefined Enterprise Open-Source License Manager role for people responsible for reviewing and approving exception requests. Policy managers receive email notifications about pending requests and can review them through the enterprise console. An approved exception can apply to a package, a license, or a package pattern, with scope choices that include repository or enterprise level.

This workflow is useful only if the organization defines who can approve an exception and what evidence that person needs. A blanket exception can weaken the same policy that the check was meant to enforce, while a narrowly scoped exception can document a deliberate decision. Teams should record the reason for an exception and revisit it when the dependency changes or the project is distributed differently. GitHub's tooling provides the mechanism for handling requests; it does not decide whether a license is legally acceptable for a particular product or business arrangement.

New APIs and audit events make the policy easier to govern

The general-availability release adds REST API endpoints for downloading, updating, and replacing an enterprise license policy, along with an endpoint for checking whether packages comply with that policy. These capabilities allow teams to back up policy configuration, manage it through internal automation, or ask whether a proposed package would violate the rules before incorporating it. GitHub also records policy changes in the audit log, giving administrators a way to review when a policy was created or modified and connect those events to external records. For organizations with many repositories, this is more useful than a setting that exists only in a web interface because the policy can become part of a wider governance process.

The package-check endpoint has a particularly relevant role as coding tools suggest more dependencies. An automated coding assistant can propose a library that solves a programming task but may not know the organization's internal licensing rules. GitHub says the new API can help coding agents avoid recommending or incorporating packages that violate those policies. That is a policy-aware check, not proof that an agent will always select a suitable dependency or that every license has been detected correctly. Developers still need to review the package's maintenance, security, compatibility, and actual license terms.

What the feature does not guarantee

Automated license compliance is only as dependable as the dependency information and policy behind it. If a package has missing, ambiguous, or incorrect license metadata, a check cannot reliably replace a careful examination of the package and its licensing files. A passing result means the detected information satisfied the configured policy; it does not certify that the entire application is legally compliant or that the organization has met every obligation associated with distributing software. Likewise, an organization that permits a license without understanding its conditions can encode the wrong decision into every repository at once. Teams should treat the feature as an enforcement layer supported by human review, not as a replacement for legal advice or a complete software supply-chain audit.

Existing projects also need a measured migration plan. Start by enabling the dependency graph where required, establishing a policy with the appropriate reviewers, and running Evaluate-mode checks against representative repositories. Examine the findings before switching important branches to Active mode, and verify how required comment resolution and other branch protections interact with the license annotations. Finally, document an exception route and review policy changes through the audit log. Those steps turn a new platform capability into a repeatable development practice rather than an unexpected obstacle during a release.

Who should adopt GitHub's license checks first

The clearest fit is an organization that ships commercial software, manages a large portfolio of repositories, or needs a consistent way to review third-party code across multiple engineering teams. Smaller teams can still benefit from dependency review and other available license-checking tools, but this particular enterprise-wide feature has a specific GitHub plan and security-license requirement. The decision is therefore not just whether automated license checks are useful; it is whether centralized enforcement and governance justify the required GitHub setup. For eligible enterprises, the next practical step is to trial the policy on a small group of repositories, measure the quality of its findings, and only then decide which projects should be blocked from merging when a dependency falls outside the approved rules.