GitHub Licence Compliance: Explain Exceptions

An unfamiliar dependency licence often becomes somebody else's problem until it blocks a release. The developer wants the build to pass, the reviewer wants more information and nobody has recorded how the package will be used.

GitHub's open-source licence compliance feature became generally available on 16 October 2026. It brings policy checks and exception handling into pull requests. Its current availability is GitHub Enterprise Cloud, including data residency, with GitHub Code Security enabled for the relevant repositories. Check that eligibility before planning a rollout for a small team.

The useful preparation is the same whether this feature is available to you or not: identify the dependencies, decide who can interpret the organisation's policy and give developers a clear route for questions.

Give the reviewer the package's context

Start with one service and its actual dependency inventory. Include the package name, version, upstream project, recorded licence, dependency path and where it appears in the delivered system. A name in a manifest is a starting point; the reviewer also needs to understand why the project uses it.

Use standard identifiers where available. The SPDX Licence List provides identifiers and corresponding licence texts, which is more precise than a spreadsheet entry such as “BSD-like”. It identifies the text; it does not decide whether your particular use meets its terms.

Do not turn this inventory exercise into an improvised legal judgement. The technical team should collect the evidence and apply the organisation's approved policy. Ambiguous terms or distribution questions need the person responsible for that policy to decide them.

Separate policy from enforcement scope

GitHub's feature documentation distinguishes the enterprise licence policy from the rulesets that enforce it. Checks use detected dependency data, including transitive dependencies. In Active mode, the relevant rule can prevent a merge; Evaluate mode provides findings without that rule blocking it.

There is a practical qualification: a separate requirement to resolve comments can still make an annotation relevant to merging. Before promising a harmless observation period, inspect the repository's combined rules. The pilot needs to reflect the effective configuration across those rules.

Pick a repository whose owner can review findings promptly. Establish the normal path for adding a permitted dependency, introducing a disallowed dependency and asking about an unknown licence. Keep the initial scope narrow enough that a mistaken policy choice can be corrected without holding up unrelated teams.

An exception should answer a real question

The following record is a proposed working template for the team, not a claim that every field exists in GitHub's interface.

A package exception for one repository and a licence-wide enterprise exception have very different effects. Prefer the narrow scope that reflects the actual decision. If the business later wants a broader policy, review that explicitly rather than accumulating accidental approvals through release pressure.

Also record what would invalidate the decision: a changed licence, a new package version, a different distribution method or a transfer of ownership. A review date alone will not catch a material change the day after approval.

Prove the decision path before expanding

GitHub documents the configuration and reviewer role, including enterprise licence managers and repository targeting. Use those controls to give the decision to an appropriate reviewer rather than granting broad administrative access just to clear alerts.

In a pilot repository, prepare disposable pull requests that exercise permitted and non-permitted cases under your own policy. Confirm that the reviewer receives the request, can see the evidence and can apply the intended scope. Then inspect the effective policy at the repository. Close the test changes without merging unwanted dependencies.

Keep a dated export or record of the policy before activation. If the rollout blocks legitimate work unexpectedly, return the affected pilot to the previously agreed enforcement state and investigate the rule interaction. Do not solve it by silently allowing every licence or distributing blanket bypass rights.

For ongoing operation, review the age of pending requests and exceptions whose assumptions have changed. Those measures reveal whether the process is usable. A large count of automatically checked packages says much less about the quality of the decisions.

Our audit evidence guide explains the lightweight recording discipline: keep the scope, date, owner and reason beside the evidence. Licence decisions benefit from the same clarity.

References

• GitHub Changelog: Open-source license compliance generally available — 16 October 2026; checked 17 October 2026.
• GitHub Docs: About open source license compliance — checked 17 October 2026.
• GitHub Docs: Configuring open source license policies — checked 17 October 2026.
• SPDX: Licence List — checked 17 October 2026.