Remediating GPL-2.0 Code Found in AI-Generated Commits: Rewrite, Relicense, or Remove

Triage before choosing a path

AI coding assistants can emit code that matches or closely resembles GPL-2.0 licensed source, and that code reaches a proprietary repository through ordinary commits. It is usually found after merge, sometimes after release. The first hour matters less than the first record. Before anyone reverts, rebases, or deletes, preserve the repository history that shows which commit and which developer account introduced the code. Version control that tracks every change to an individual account is the basis for that trace, and remediation actions will alter the trail if you act first.

Next, establish the facts that drive every later decision. What is the origin of the matched code, and under what licence is it published? Which files, functions, and commits are affected? Was the commit AI-assisted, and do you still hold the prompt context and the reviewer decision? Many teams will find that last answer is no, because assistant sessions are rarely captured by default.

Then establish exposure. Identify every build, release, container image, or hosted service that contains the code. Whether the code was only committed internally or was distributed in a binary or delivered to a customer changes the legal analysis, and counsel should make that call. Also check contracts. Some customer agreements grant broad rights in delivered source code or restrict resale. One federal clause, 48 CFR 1552.239-71, asserts unlimited rights in custom source code and requires written consent for resale. It applies only to that contract work, but it shows why delivery terms should be read before you choose to relicense or remove.

Scanning tools help here, but confirm what yours actually detects. A tool built to find vulnerable open-source components will not necessarily detect a snippet-level licence match.

How the three paths compare

The paths differ in preconditions, effort, and the risk that remains afterward. None of them removes the need to document what happened.

• Remove: Precondition: the function can be dropped or replaced with a component whose licence is already approved. Effort: lowest, though released versions may still contain the code. Residual risk: copies in earlier releases and in history. Evidence: the finding, the removal commit, and the affected release list.
• Rewrite: Precondition: the function is needed and can be reimplemented without reference to the matched code. Effort: moderate to high, with process overhead. Residual risk: the new code may still resemble the original if independence cannot be shown. Evidence: the specification, the separation of roles, and the reviewer sign-off.
• Relicense: Precondition: the copyright holder is identifiable, consents in writing, and the new terms fit the other licences in the codebase. Effort: depends on the holder, and often impractical. Residual risk: consent scope disputes and incompatibility. Evidence: the written permission and counsel's compatibility review.

Criteria for choosing

Four questions narrow the choice. First, was the code distributed or only used internally? If it shipped, removal from the current branch does not address what customers already hold, so release remediation becomes part of the plan under any path.

Second, is the match substantive? A few lines of boilerplate, a common idiom, or a trivially short function raise a different question from a distinctive routine reproduced almost verbatim. Whether a match is copyable expression is a legal judgement. Engineers can support it by documenting how long the match is, how distinctive it is, and whether the logic could reasonably be written in only one way.

Third, can the copyright holder be identified and will they consent? Relicensing rests on permission, and general copyright principles say copying software requires permission. Without an identifiable holder who agrees in writing, relicensing is not a working option. Even with consent, counsel should confirm the new terms are compatible with the other licences in the codebase.

Fourth, can the function be reimplemented independently? Independence is a process question as much as a code question. A common clean-room pattern separates the person who studies the original behaviour from the person who writes the new code. The writer works from a functional specification and never sees the matched source. Using the same assistant to regenerate the function defeats that purpose, because it may reproduce the same output.

In practice, remove is the default when the feature is optional, rewrite fits when it is not, and relicense is the exception.

Reducing recurrence at the execution path

Everything above is after-the-fact work. Review and scanning find problems once code is committed, and the evidence has to be rebuilt from partial records. The alternative is to enforce policy where the code is generated.

Trussed enforces policy in the execution path of coding assistants and provides code provenance, meaning the origin, licence, and security context of code. A licence policy can allow an interaction, redact part of it, block it, or escalate it for human approval, enforced at runtime, not reviewed after the fact. Each decision produces audit-ready evidence of what was allowed, redacted, blocked, or escalated, which supplies the records a remediation file would otherwise lack.

This shifts detection earlier and makes the decision trail consistent. It does not remediate code already in your repositories, and it does not provide legal determinations. The triage, the rewrite-relicense-remove decision, and counsel's conclusions remain with your teams.