What Happens If an AI Coding Assistant Suggests GPL-2.0 Code and You Ship It in a Proprietary Product

What GPL-2.0 asks of you and when it applies

GPL-2.0 is a copyleft licence. It lets recipients use, modify and redistribute the code, but conditions redistribution on passing those same freedoms on. In practice that means that when you distribute a work that contains or is derived from GPL-2.0 code, you are generally expected to license the whole work under GPL-2.0 and provide corresponding source to recipients.

The key word is distribution. Internal use of GPL code inside an organization generally does not trigger the same source obligations. Shipping a binary to customers, embedding code in a device or appliance, or delivering an installable client does. SaaS delivery raises different questions that depend on how the software is exposed to users, and you should take specific advice on it.

The harder technical questions are where the boundary of the derivative work sits. Copying a function, statically linking a library and calling a separate program over a defined interface are different situations, and legal opinion varies on some of them. Compatibility also matters. Terms in a proprietary licence, or in another open-source licence in the same product, may conflict with GPL-2.0 conditions, and a conflict can mean the product cannot be distributed in compliance at all. Treat this as a general orientation. Counsel should assess any specific product.

Where existing controls leave gaps

Code review depends on what the reviewer can see. A pull request does not show whether a snippet was typed, pasted or suggested, and a reviewer cannot be expected to recognise licensed code from memory.

Software composition analysis helps with declared dependencies, but it works after the fact. Scanning a repository at merge or release time finds problems once they are already in the codebase, and by then the code may have been copied, edited and built into several components. Matching also depends on how much of the original survives, so modified snippets can be harder to attribute.

Built-in assistant features, such as filters that suppress suggestions resembling public code, are worth understanding but should not be treated as a complete control. Ask what the filter matches against, what thresholds it applies, and what it does not cover. Then decide whether that is enough for the risk you carry. Vendor indemnification is a separate question. The FTC has observed that some large firms may indemnify users of their generative AI tools, but the scope and conditions vary, so read the terms rather than assume coverage.

The common thread is timing. Each of these controls acts after the suggestion has already entered the developer's workflow, and none of them leaves a durable record of what the assistant offered and what was done with it.

If the code has already shipped

Remediation starts with establishing facts. Identify which files contain the code, which releases include them, how they were distributed and to whom, and how the code relates to the rest of the product. Without a record of which suggestions were accepted, this step is slow and uncertain.

Legal assessment follows. Counsel can judge whether obligations were triggered, whether the code is in fact covered by GPL-2.0, and what exposure exists. The options generally fall into three groups: remove and replace the code with an independently written or properly licensed alternative, comply with the licence by releasing corresponding source where that is commercially acceptable, or seek a separate licence from the rights holder. Each has costs, and replacement must be done so that the new code is not derived from the old.

After the fix, the organization still needs to explain what happened. The FTC has said that liability questions around generative AI are open and that conduct consistent with copyright law can still raise issues under Section 5 of the FTC Act. That is a reason to keep a clear account of how output was controlled, rather than relying on an untested assumption that the risk was low.

Controls at the point where code enters the codebase

Three controls reduce both the likelihood and the impact of this scenario. First, treat assistant output as untrusted input that is checked before it is accepted, rather than only after release. NIST has framed generative AI as a risk area, and its AI RMF and Generative AI Profile are voluntary reference structures you can use to organize assistant usage and controls. They are not compliance requirements.

Second, capture code provenance: the origin, licence and security context of code at the moment it arrives. Provenance recorded at entry is far cheaper than reconstruction after a release. Note that the content authentication techniques NIST describes, such as watermarking and digital fingerprints, address content integrity and origin in general, not the licence of a particular snippet.

Third, enforce policy at runtime and keep evidence. Trussed enforces policy in the execution path of coding assistants, on individual interactions and tool calls, with actions to allow, redact, block, rate limit or escalate for human approval. Its code provenance covers the origin, licence and security context of code, and enforcement produces audit-ready evidence mapped to frameworks including NIST. A team could, for example, block a suggestion that carries restrictive licence context and escalate an ambiguous one to a human approver. The decision is then recorded when it is made, not reconstructed later. Trussed is self-managed in the customer cloud, with configurable retention and data residency.