What dependency licence gates check

A dependency licence gate checks the licence of each package a change adds or updates. On 16 October 2026, GitHub made its open source licence compliance feature generally available for GitHub Enterprise Cloud customers with Code Security enabled. In GitHub's words, the check "ensures each new or changed dependency has an acceptable license", and an enterprise can apply a ruleset condition to "require license compliance results before merging".

Licence policy at the dependency level is becoming part of the default developer workflow. A team defines which licences it accepts, and a pull request that adds a package outside that policy is annotated before it merges. GitHub has also added an endpoint that lets coding agents check a package against the policy before recommending it.

The open question for compliance leaders is what sits outside the dependency list.

Licence obligations that arrive without a dependency

A licence attaches to code, and code does not have to arrive as a package. A developer copies a parsing function from a public repository into a helper file, or vendors a library by copying its source into the tree instead of declaring it. A coding agent writes out a routine it reproduced from code it was trained on. None of these changes touch a manifest, so none of them appear in a dependency diff.

So a pull request can pass a dependency licence gate with no findings while adding code under a copyleft licence. Nothing in the change looks like a dependency, and the licence terms apply all the same. A licence programme that relies only on declared dependencies covers the part of the codebase that was easiest to see. The obligations most likely to surprise a legal team are the ones nobody declared.

Coding agents widen the gap. They produce more code, faster, with less of it written line by line by the developer who commits it. A developer who pastes a function usually knows they did. An agent that reproduces a function gives no signal at all, and the commit looks like any other. As agent adoption grows, so does the volume of undeclared code, while the review effort per line shrinks. Pull request review was designed for a person reading a person's change. It was never designed to recognise that thirty lines match an existing open source project.

The Cyber Resilience Act raises the stakes. Under the regulation, a manufacturer that integrates components from third parties "needs to exercise due diligence so that those components do not compromise the cybersecurity" of the product, according to the European Commission. Annex I, Part II of the regulation also requires manufacturers to identify and document the components a product contains, including by drawing up a software bill of materials in a machine-readable format that covers at the very least its top-level dependencies. Vulnerability reporting obligations under Article 14 have applied since 11 September 2026, and the regulation will be fully applicable from 11 December 2027.

Top-level dependencies are the legal floor, and component inventories are becoming evidence a manufacturer may have to stand behind. Undeclared code is still a component, and the security and licence questions about it do not disappear because it never appeared in a manifest. An inventory built only from declared dependencies records what the team chose to list. An inventory built from the code records what the product contains.

How Earnie covers the code a manifest misses

Earnie runs detection on the code itself, at the point where a change enters the repository. It reads the dependencies declared in package manifests, and it also fingerprints every file and matches those fingerprints against the knowledge base of open source code. That is how Earnie finds components, licences and obligations down to the snippet someone pasted, including code that never appeared in a manifest. Earnie never sends source code to the knowledge base, and your code stays on your server.

What happens to each finding is the team's decision. You set your rules once per project, point-and-click in the interface or as code through the API and MCP, and assign the project's repositories and people. From then on, that policy decides whether each finding is allowed, warns or blocks, wherever code enters. A coding agent asks Earnie what is allowed before it writes a line, and checks its own output in context through MCP before the commit. A developer sees the result at pre-commit, on the changed files, before anything leaves their machine. At merge, the gate is based on the findings the change introduces, and Earnie posts it on the pull request. The same policy applies at every step, so nobody has to translate the rules between tools.

Every finding, decision and fix ends up in one record: SBOMs, notice files and an audit log of decisions, versioned and available on demand. Because the findings come from the code, a dependency licence gate and Earnie do not compete for the same job. The gate covers the packages a change declares, and Earnie covers everything the change contains.

Dependency licence gates are a sound baseline, and teams that have them should keep them. The decision for engineering and legal leaders is whether the licence programme stops at declared packages or extends to the code itself. Start by agreeing one policy that applies to both: the licences the organisation accepts, and what happens when an undeclared match appears. Then put detection where the code changes, at pre-commit and at merge, so findings reach the author while the context is still fresh. Finally, make sure the record that comes out of those checks is one an auditor or an acquirer can read without a reconstruction exercise.

Earnie runs those checks on every change, whoever or whatever wrote it. See it on your kind of codebase: request a demo.