Open source is not rule-free: check licenses before merge

The problem starts at npm install, not at the audit

A new library can enter a product in seconds. The pull request is green, the bundle is smaller or a feature is finally complete. Months later, a customer asks for a software bill of materials, procurement asks about licence terms, or a security review needs every transitive dependency. Only then does the search for packages, versions and exceptions begin.

On 16 October 2026, GitHub made open source license compliance generally available. Enterprise teams can define a central licence policy and block pull requests when new or changed dependencies do not comply. The feature is available for GitHub Enterprise Cloud, including data-resident GHEC, and requires GitHub Code Security for repositories where policy is enforced.

The interesting part is not another red icon in a pull request. Licence review moves to the moment when a decision is still inexpensive: before code, data models and product design depend on a new package.

This article is not legal advice. It describes a technical and organisational process that gives developers, product owners and the responsible legal advisers the same verifiable evidence.

A licence is not a quality label

“Open source” means source code may be used, modified or distributed under specific conditions. It does not mean every licence fits every product model.

The useful question is not Is this licence good or bad? It is Are its conditions compatible with how we actually use and distribute this software?

An internal analytics job, a SaaS application, a mobile app, a shipped SDK and an on-premise installation have different risks and obligations. The way a dependency is incorporated matters too. An engineering team should therefore not copy a universal “allowed” and “prohibited” list based on intuition.

A policy needs at least three inputs:

• which products and artefacts the company distributes;
• which direct and transitive dependencies enter those artefacts;
• which conditions the responsible legal or compliance function accepts for that use.

SPDX identifiers give those decisions unambiguous technical names. They do not make the decision themselves.

Inventory before policy

A rule built on an incomplete inventory creates false confidence. GitHub's central compliance check uses Dependency Graph data and includes detected transitive dependencies. That is a useful starting point, but not proof that every ecosystem, vendored source tree or runtime-loaded component has been captured.

Before enforcement, we ask:

1. Which package managers and manifests exist in each repository?
2. Are lockfiles complete and current?
3. Are base container images, vendored libraries, mobile frameworks and build tools represented?
4. Which dependencies appear only in generated artefacts?
5. Which repositories are active, archived or experimental?

We then export an SBOM for each relevant repository. GitHub can export the Dependency Graph in SPDX format. The export includes information such as versions, package identifiers, licences, transitive paths and copyright data. With the GA release, licence information is also populated in Dependency Graph and SBOM exports for data-residency customers.

An SBOM is a snapshot of detected inventory, not automatic approval. Its first job is to expose gaps and questions before a policy can affect merging.

Three states instead of an immediate hard stop

GitHub enforces the central policy through rulesets. A rule using Require license compliance results before merging can target the enterprise, organisation or repository level.

Three rollout states are useful:

Inactive: The repository has not been classified or its inventory is incomplete. The team fixes the foundation first.

Evaluate: GitHub reports and annotates violations without blocking the merge. Teams collect real cases, correct package metadata and exercise the exception process.

Active: New or changed non-compliant dependencies block the pull request until the conflict is resolved.

GitHub's documentation suggests repository custom properties as a practical way to classify repositories and target rulesets by those values. This is safer than enabling enforcement across an enterprise on a Friday afternoon.

We would run representative projects in Evaluate for two weeks: a web app, backend service, mobile app and library. Active follows only when detection quality, ownership and decision time are acceptable.

Every finding needs four possible exits

When a pull request introduces a non-compliant dependency, the process cannot end at “build failed”. The developer needs a clear set of options:

1. Remove it: The dependency adds too little value or is not actually needed.
2. Replace it: A functionally suitable alternative complies with policy.
3. Implement the small part: For a narrow, well-understood need, owned code may cost less than a difficult dependency.
4. Request an exception: Document the concrete use and send it to the responsible reviewer.

GitHub introduces the predefined Enterprise Open-Source License Manager role for reviewing and approving closure requests. Policy managers receive notifications and can process requests in the enterprise console. An exception should not become an indefinite “looks fine”.

A useful request records:

• package and exact version;
• repository, product and distribution model;
• direct or transitive use;
• why removal or replacement is disproportionate;
• accountable owner;
• scope and expiry date;
• link to the technical or legal decision.

This keeps an exception as a traceable product decision rather than a shadow policy.

Policy changes are production changes

A central licence policy controls which software can enter products. Changes deserve the same care as branch protection or deployment permissions.

GitHub now emits policy changes to the audit log and offers APIs to download, update and replace the enterprise policy. A dependable operating model follows:

• every policy change starts as a reviewable request;
• two appropriate roles examine legal and technical impact;
• audit events feed the system of record;
• a change runs in Evaluate before it blocks existing teams;
• exceptions are reviewed for expiry and actual use;
• an owner responds to false positives and missing package metadata.

The API is not an invitation to overwrite policy blindly from a laptop file. It enables teams to version the approved state, detect drift and roll out a change reproducibly.

Coding agents should check before suggesting a package

A coding agent can suggest and install several packages in minutes. Without policy context it naturally optimises for capability, popularity or API quality, not the organisation's specific licence rules.

GitHub now provides an API endpoint for checking packages against the enterprise licence policy. That check belongs in two places in an agent workflow.

Before the change: The agent evaluates candidates and drops non-compliant packages before writing code and tests around them.

After the change: The normal pull-request check evaluates the complete dependency diff, including transitive changes. It remains authoritative because a candidate lookup cannot guarantee that the package resolver produces the same final graph.

An agent must not approve its own exception. On conflict, it can provide package, version, purpose, alternatives and affected code path. A named human owner makes the decision.

What smaller teams can do without the enterprise feature

The process is not limited to GitHub's new enterprise capability. GitHub's dependency-review-action can check pull requests for newly introduced vulnerabilities and invalid licences. It is available for public repositories and private repositories with the applicable GitHub security licence.

The action supports, among other controls:

• an allowlist using SPDX-compliant licence identifiers;
• exceptions for specific packages in Package URL format;
• separate handling of runtime, development and unknown scopes;
• summaries in the workflow and optional pull-request comments;
• rules for blocked packages or namespaces.

One current detail matters: the action's deny-licenses option is marked as deprecated. New configurations should not build a permanent model around a denylist. An explicit, reviewed allowlist exposes unknown cases instead of silently passing them.

The workflow file is still not the policy itself. It enforces a decision that needs an owner, a defined scope and a documented exception route.

Do not merely generate the SBOM — use it

Many teams export an SBOM, attach it to a build and consider the task complete. It becomes valuable only when connected to real events.

We use an SBOM to answer four questions:

• What was actually present in this release?
• Which versions and transitive paths are affected by a new issue?
• Which licence decision applied at build time?
• Which customers or distribution variants received the artefact?

For a releasable product, the SBOM should be tied to the commit, build and version. If an exception or policy changes later, the team can still reconstruct what it shipped at that time. A continuously regenerated inventory with no release identity cannot answer that question.

A pragmatic ten-step start

1. Inventory product types and distribution models.
2. Name owners in engineering, product and legal/compliance.
3. Check Dependency Graph coverage and lockfile completeness.
4. Export SBOMs for representative repositories.
5. Document licence decisions with SPDX identifiers.
6. Define repository groups for Inactive, Evaluate and Active.
7. Run checks in Evaluate first.
8. Test a narrow, time-limited exception process.
9. Let coding agents check policy before suggesting packages.
10. Expand merge blocking only after the process is demonstrably stable.

Success is not the number of blocked pull requests. Better signals are fewer unknown licences, short decision times, rare permanent exceptions and an SBOM that matches every release.

GitHub's new capability makes licence compliance technically easier. The real work remains organisational: a comprehensible policy, complete inventory and people who decide edge cases before they become emergencies. That is precisely why the check belongs in the pull request. At that point, choosing another library is still a small change — not a late release problem.

Sources

• GitHub Changelog: Open source license compliance generally available
• GitHub Docs: About open source license compliance
• GitHub: dependency-review-action
• GitHub Docs: Exporting dependencies as an SBOM
• SPDX License List