Detecting GPL-licensed snippets in AI-generated code before merge

Where GPL exposure enters AI-assisted development

An AI coding assistant generates code from patterns it has learned. Occasionally the output may reproduce, or closely resemble, source that was published under a copyleft licence such as the GPL. The developer who accepts the suggestion usually sees only code, with no licence or origin attached. If it is committed and merged, the record of where it came from is lost.

Three entry points matter. The first is assistant output pasted or accepted directly into a file. The second is a larger change generated by an agent, where many suggestions land in one pull request. The third is code a developer adapts by hand after seeing a suggestion, which can leave a derived rather than verbatim copy.

NIST SP 800-218A states that its practices do not distinguish between human-written and AI-generated source code, because all source code needs evaluation before use. That is a useful design principle here. The licence gate should apply to every change, and AI involvement should be recorded as metadata so reviewers know which changes deserve closer attention.

Detection approaches and their limits

Four approaches are in common use. Each answers a different question, and each has failure modes you should test against your own repositories before relying on it. NIST AI 600-1 makes a similar point about fingerprinting and provenance signals: measure their reliability first.

• Code matching against known corpora: Compares submitted code with an indexed body of open source code. It can name the likely origin and licence. It can only find what the corpus contains, and it may miss code that has been renamed or restructured.
• Fingerprinting: Hashes normalised segments of code and looks for overlaps. It is efficient at scale and tolerant of formatting changes. Heavily rewritten code can fall below its detection window, and short common segments can collide.
• Similarity analysis: Scores how close code is to reference material. It can surface near-copies that exact matching misses. It returns scores rather than verdicts, so threshold tuning is required, and common idioms can produce false positives.
• Dependency scanning (SCA): Inventories declared packages from manifests and lockfiles and reports their licences. It is reliable for what is declared. Its input is the dependency graph, so it does not examine code pasted inline into a source file.

Verbatim code, derived code and false results

Verbatim matches are the easiest case. Derived code is harder: a variable rename or a reordered block can defeat exact comparison while leaving the structure intact. Similarity analysis is aimed at this gap, at the cost of more false positives. Whether a given derivation creates an obligation is a legal judgement, so the tooling should produce findings and evidence for reviewers rather than conclusions.

Plan for both error types. False positives cost reviewer time and, if frequent, teach developers to ignore the check. False negatives mean exposure passes unseen. Layering methods reduces the chance that one blind spot defines your coverage. A practical pairing is snippet-level matching or fingerprinting on the diff, plus dependency scanning for declared packages. Review the match results periodically and adjust thresholds based on what reviewers actually confirm.

Defining the response to a match

Decide the responses before the first match arrives. Three are enough. Allow applies when the finding is below threshold, the licence is permitted by your policy, or a reviewer has documented why the match is a false positive. Block applies to high-confidence matches against licences your policy does not accept, with remediation steps documented: remove the snippet, regenerate it, or replace it with an approved library. Escalate applies to ambiguous or derived cases and routes the change to a named reviewer, such as legal or an open source programme office, with the evidence attached.

Write down who can approve an escalation and what they must record. Without that, the escalate path becomes an informal chat thread, and the decision cannot be reconstructed later. Keep the thresholds that separate these outcomes in version-controlled policy, so changes to them are themselves reviewable.

Enforcing policy on code provenance in the execution path

A pull request review happens after code has been generated, accepted and committed. It depends on a reviewer noticing something the code itself does not show. Enforcement in the execution path moves the decision to the interaction where the assistant produces code, so the check happens before the code lands, not after.

Trussed applies policy inside that path for coding assistants. It evaluates code provenance, meaning origin, licence and security context, and enforces policy at runtime with actions to allow, redact, block or escalate for human approval. Scope is individual interactions and tool calls. Each enforcement decision produces audit-ready evidence, which covers the retained record described above without relying on reviewers to reconstruct it. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.

This complements pull request and CI checks rather than replacing them. Runtime enforcement records the decision at the point of generation, and later gates confirm that what merged matches what was checked.