Open-source license compliance as a merge-time engineering control

The dated change

What GitHub added

For GitHub Enterprise Cloud repositories with GitHub Code Security enabled, an enterprise policy can be targeted through a ruleset condition that requires license-compliance results before merge. When a pull request adds or changes a dependency, GitHub checks its license expression against that policy and annotates noncompliant packages.

A developer can remove or replace the dependency. A policy owner can amend the central policy or approve a narrowly scoped package exception. GitHub also added audit-log events for policy changes and APIs to read or replace policy and check a package before it is introduced.

Control architecture

Put policy on the dependency-change path

1. Define policy centrally. Translate legal guidance into explicit allow, deny and review-required outcomes for SPDX expressions and package exceptions.
2. Evaluate the diff. Run checks when a pull request adds or modifies dependencies, not only in a periodic SBOM export.
3. Enforce with rulesets. Require a compliant result before merge on the repositories in scope.
4. Preserve evidence. Record policy versions, audit events, exception decisions and the dependency graph or SBOM used for review.
5. Keep other gates. Vulnerability, provenance, maintenance and malware controls remain separate decisions.

Governance

Exceptions need owners, scope and expiry

A practical exception record should identify the exact package and version range, repository or product, policy rule being bypassed, business rationale, reviewer and review date. Permanent organization-wide exceptions are easy to create and difficult to revisit; prefer the narrowest scope the platform supports and track any compensating distribution or attribution obligations outside GitHub.

The predefined Enterprise Open-Source License Manager role separates exception handling from repository administration. That is useful only if the assigned team has a documented service level and a clear escalation path to legal counsel.

Agent-aware development

Check before an agent writes the manifest

The package-compliance API creates a better path for coding agents than generating a change and waiting for a failing pull request. The agent can query candidate packages during planning, prefer compliant alternatives and explain the tradeoff to the developer.

candidate package → policy API check
allow → propose dependency
review → ask for human decision
deny → select an alternative

Do not give an agent authority to create its own exception. Package choice and policy approval are separate responsibilities, and the latter should remain attributable to a human or explicitly governed service.

Practical rollout

A safe adoption sequence

1. Export the current dependency graph and SBOMs to understand the baseline.
2. Run the proposed policy in observation mode against representative repositories.
3. Resolve ambiguous or missing license metadata instead of silently treating it as allowed.
4. Create the license-manager role, review workflow and exception record format.
5. Enable merge enforcement in stages, starting with repositories that already maintain dependency manifests accurately.
6. Add policy checks to internal templates, package catalogs and coding-agent tools.
7. Review audit logs and exception aging on a fixed cadence.

The durable shift is not a new license database. It is the ability to make package policy visible, testable and enforceable at the point where software composition changes.