GPL Compliance Notice Requirements When AI-Copied Code Ships in a Product

What the notice has to do, and what it depends on

A GPL notice is the part of a distribution that tells recipients what licensed code the product contains and what rights come with it. For a compliance team, the elements to plan for are the licence text, the copyright notices attached to the licensed code, a statement of any modifications, a statement of how recipients obtain the corresponding source (the source itself or a written offer), and installation information where the licence applies that requirement to the product.

GPLv2 and GPLv3 do not treat every element identically, and which ones apply depends on how the product is distributed. Treat the list above as the set of fields to resolve with counsel for each release, not as a template to copy between products.

A notice has two separate problems. The first is what the licence requires it to say. The second is knowing which licensed code is in the build, under which licence version, with which copyright holders. Compliance teams usually have a handle on the first. AI-generated code makes the second harder, because the origin of a suggested block of code may never have been recorded.

When obligations are triggered by AI-copied code

Obligations generally attach to the code you distribute, not to the tool that suggested it. If an assistant reproduces GPL-licensed code verbatim or near-verbatim and that code ships in a product, the question is the same one you would ask of code a developer pasted in from a public repository: is it in what you distribute, and how does it combine with the rest of the product?

That second question is where the derivative work and combined work provisions of each licence version come into play. Whether a particular integration is covered is a legal determination, and it needs the facts about how the code is linked, packaged and delivered. It also needs a reliable answer to a prior factual question: which parts of the codebase came from a licensed source at all.

This guide does not give legal advice and no tooling can settle the trigger analysis for you. What engineering and compliance can do is make sure counsel is working from records rather than reconstruction.

Mapping each notice element to the provenance it needs

Each element of the notice can be populated only if a specific piece of information exists. Mapping them before a release, with a named owner for each field, shows where the gaps are.

• Licence text: Needs the identified licence and version for each matched block of code. Without it, the correct text cannot be selected.
• Copyright notices: Needs the origin of the matched code, including the project or file it resembles, so the holders' notices can be carried forward.
• Modification statement: Needs a change record showing what was altered, when and how, including edits made to AI-suggested code after acceptance.
• Source availability or offer: Needs the list of components in the shipped build that fall under the licence, so the source or offer covers the right code.
• Installation information: Needs the product and distribution context, so counsel can decide whether the requirement applies to this release.
• Match to shipped code: Needs a link between each provenance record and the specific build, so the notice can be shown to reflect what shipped.

Why a modification record is worth keeping

Notice conventions outside the GPL show the pattern. NIST's licence terms for its own software, for example, ask that modified works carry a statement that the software was changed, with the date and nature of the change. They also ask that distributions carry the copyright and licence statements of any bundled third-party code. These terms govern NIST software and are not GPL requirements, but they illustrate what a notice pipeline has to be able to produce: a change history and an inventory of third-party code per distribution.

For AI-assisted development, that means the change record should cover edits made to suggested code, not only code written by hand. A developer who lightly rewrites a near-verbatim suggestion has still modified licensed code, and the record should reflect that. Counsel can then decide which modification statements the licence calls for.

Where runtime provenance and enforcement fit

Trussed enforces policy in the execution path of coding assistants, alongside models, agents and tools. For this problem, two shipped capabilities matter. Code provenance supplies the origin, licence and security context of code. Policy enforcement can allow, redact or block a suggestion that matches a restricted licence before it enters the product, and each decision is enforced at runtime, not reviewed after the fact. The enforcement activity produces audit-ready evidence that compliance teams can use as input when assembling a notice and when showing an auditor how a specific suggestion was handled.

This reduces reliance on after-the-fact scanning. It does not replace legal review, and it does not guarantee that a notice is complete or compliant. Trigger analysis, the content of each notice and the handling of GPLv2 and GPLv3 differences remain decisions for counsel. The practical aim is that those decisions are made from a record created when the code arrived, tied to the build that ships.