Open-Source Licensing Is Moving Into the Merge Gate

On 16 October, GitHub made open-source licence compliance generally available for GitHub Enterprise Cloud repositories using GitHub Code Security. The capability allows enterprises to define a central licence policy, apply it through repository rulesets and block pull requests when new or changed dependencies do not comply.

This is more than another supply-chain control. It shifts licence management from periodic audit into the daily engineering workflow.

Licence risk has traditionally arrived too late

Many organisations discover licensing problems during procurement, a customer due-diligence exercise, an acquisition or a release audit. By then, an unsuitable dependency may be deeply embedded in the product. Replacing it can require architectural work, retesting and an awkward conversation about why the issue was not identified earlier.

The failure is rarely that engineers ignored policy. More often, the policy lived in a legal document, spreadsheet or specialist scanning tool disconnected from the point of change. Developers could see a package's version and vulnerabilities while remaining unclear whether its licence was acceptable for a hosted service, distributed application, internal tool or commercial SDK.

GitHub's new control moves that decision into the pull request. When a change adds or modifies a dependency, the platform checks its licence against an enterprise policy. Non-compliant dependencies are annotated and must be removed, replaced, covered by a policy change or approved through a package exception before merging.

Policy as code is only as good as the policy

Automating enforcement does not resolve the underlying legal judgement. A licence can be acceptable in one product context and unacceptable in another. Distribution model, linking behaviour, modification, attribution duties and whether software is provided as a service may all matter. A single organisation-wide allowlist can therefore be either too permissive or so restrictive that teams route around it.

The engineering task is to translate legal advice into policies that match product architecture. At minimum, distinguish between internal tooling, server-side services, client-distributed software and libraries shipped for customer use. If one policy cannot express those differences, use repository segmentation or narrowly governed exceptions rather than pretending the risk is uniform.

Policy owners should also define what happens when licence metadata is missing, ambiguous or expressed as a compound SPDX expression. Treating unknown as automatically safe defeats the control. Treating every unknown as permanently blocked creates friction and encourages dependency vendoring, manual copying or other behaviours that reduce visibility.

Exceptions are part of the control, not a failure of it

GitHub has introduced an Enterprise Open-Source License Manager role for reviewing closure requests, alongside audit events and APIs for managing policy. This is important because healthy governance requires an explicit exception path.

An exception should record the package, version range, affected repositories, product context, rationale, approver and review date. It should not become an unbounded waiver for every future version. A dependency can change licence, ownership or distribution model, so exceptions need an expiry or periodic reassessment.

The service-level objective matters too. If a routine review takes a fortnight, engineers will either avoid useful packages or seek unofficial workarounds. Publish a response target based on risk. A common permissive licence with incomplete metadata may need a quick operational decision, while an unusual copyleft dependency in a distributed product deserves specialist review.

Engineering leaders should redesign dependency intake

Start with an inventory rather than immediately enabling a blocking rule across every repository. Export the current Software Bill of Materials, identify dominant licence families and measure how many existing dependencies would violate the proposed policy. Historical debt should not be allowed to prevent controls on new debt, but teams need to understand the baseline.

Next, run the policy in observation mode where possible. Review several weeks of pull requests and classify alerts as valid blocks, acceptable exceptions, metadata defects or policy design problems. This reveals whether the proposed governance matches how teams actually build software.

Then introduce enforcement by risk tier. Begin with customer-distributed products and high-change repositories, while retaining a documented rollout plan for the rest. Make the approved-package path easy: internal templates, architectural guidance and dependency catalogues should recommend well-supported options whose licences are already understood.

Finally, add licence compliance to technology selection and architecture reviews. Package choice is not merely a developer convenience decision. It creates maintenance, security, legal and continuity obligations. Staff and Principal Engineers should model those trade-offs when setting standards, not leave them to be discovered by an automated gate after implementation.

Agentic development raises the stakes

The newly available API can check whether a package complies with enterprise policy before a coding agent recommends or incorporates it. That detail is strategically significant. Agents optimise for task completion and may select dependencies based on popularity, API fit or examples in their training context. Without machine-readable policy, they can generate technically correct changes that are organisationally unacceptable.

Do not rely solely on the merge gate to catch this. Feed compliance checks into agent instructions and development tooling so disallowed choices are avoided earlier. The same principle applies to security posture, data classification and approved services: policy should be available at decision time, not only as a rejection at the end.

Measure outcomes, not blocks

A successful programme is not one that rejects the most pull requests. Track time to resolve licence findings, repeat exceptions, dependencies with unknown metadata, policy bypasses and remediation work avoided. Review whether controls concentrate delay in particular teams or product types.

Licence compliance belongs in engineering governance because dependencies are part of the product. Moving policy into the merge path can reduce late surprises and create auditable decisions, but only if legal, security and engineering leaders jointly own the rules. The tool can enforce an answer. Leadership must ensure it is the right answer for the software being built.

Source note: GitHub announced general availability on 16 October 2026. The release covers ruleset enforcement, pull-request annotations, package exceptions, audit events, policy APIs and a compliance-check API for development tools and coding agents.