GPL vs AGPL vs EPL: Copyleft Risk When AI Coding Assistants Generate Code

How the three licenses differ

The three licenses differ on three axes that matter to an engineering team: what activates the obligation, how far the obligation reaches into surrounding code, and what it costs to fix a violation.

GPL is triggered by distribution. If an organization conveys a program that incorporates GPL-covered code, the license expects the resulting work to be offered under GPL terms with corresponding source. The reach is broad, because the obligation attaches to the work built on the covered code, not only the copied lines. Where that boundary falls in a given architecture is a legal judgment.

AGPL keeps that broad reach and changes the trigger. Its network use clause extends obligations to users who interact with the software over a network, so a service that never ships a binary can still be affected. This is the property that makes AGPL different for SaaS.

EPL is weak copyleft. Its obligations attach to the covered file or module and to modifications of it, rather than to the entire combined program. Separately developed code that merely links to or calls an EPL module is treated more favorably than it would be under GPL.

Remediation burden follows the same pattern. Under GPL and AGPL, remediation can mean removing or rewriting the code, or releasing source for a much larger body of software. Under EPL, remediation is usually bounded to the affected module.

Relative exposure by delivery model

Organizing by delivery model gives a more useful answer than a single most-risky verdict. The rankings below reflect the trigger conditions described above and should be confirmed with counsel for specific architectures.

• Distributed software (installed, embedded, shipped to customers): GPL carries the highest exposure because distribution is its trigger. AGPL applies as well. EPL obligations are real but scoped to the covered module.
• Network-served software (SaaS, hosted APIs): AGPL carries the highest exposure because network interaction is its trigger. GPL is generally not triggered by hosting alone. EPL remains module-scoped.
• Internal-only tools: Exposure is generally lowest for GPL and EPL when nothing is distributed. AGPL needs a closer look if internal users interact with the tool over a network, and that reading should be confirmed with counsel.
• Mixed delivery (a SaaS product that also ships a client or agent): Treat the stricter trigger as the governing one. The shipped component brings in GPL exposure that the hosted component alone would not.

Where AI-generated code creates ambiguity

Traditional license review assumes a developer knows where code came from: a dependency manifest, a vendored directory, a copied snippet with an attribution comment. Code from an AI coding assistant has none of those markers. A suggestion may be original, may closely resemble licensed source, or may be a near copy, and the developer who accepts it usually cannot tell which.

The legal side is unsettled. NIST's Generative AI risk profile states that the copyright status of generated content that is similar to, but does not strictly copy, protected work is currently being debated in legal fora. A policy therefore cannot rely on a fixed similarity threshold that separates safe from unsafe output. It should assume uncertainty and define how partial and low-confidence matches are handled.

The ambiguity also hits the three licenses unevenly. A short snippet from an EPL module creates a contained question. The same snippet from a GPL or AGPL project can raise a question about the scope of the entire program, and under AGPL it can do so for software that is never distributed. Because a suggestion becomes ordinary repository code once accepted, later scanning has to reconstruct a history that was never recorded.

Enforcing at generation time instead of reviewing later

Post-hoc review has a structural weakness. By the time a scanner flags a license match in a merged pull request, the snippet may be built into other code, released, or shipped. For AGPL in particular, a hosted service can be exposed the day it deploys.

Enforcing at the point of generation changes the decision from cleanup to prevention. A workable policy maps license class and match confidence to an action. Permissive or no-match suggestions are allowed. Exact matches to GPL or AGPL source are blocked in distributed and network-served contexts. EPL matches might be allowed with a recorded notice or escalated, since the obligation is module-scoped. Partial matches, where legal status is least settled, can be redacted or sent for human approval.

The policy should vary by delivery model, not only by license. The same AGPL match may be tolerable in a prototype and unacceptable in a hosted product. Whatever the rules, each decision needs a durable record that ties the generated code to its repository and dependency history, so a later reviewer can trace it.

Where Trussed fits

Trussed enforces policy in the execution path of coding assistants. It provides code provenance, meaning the origin, licence and security context of code, and applies policy to individual interactions with allow, redact, block, rate limit or escalate for human approval. Enforcement happens at runtime, not after the fact.

Each enforced decision produces audit-ready evidence, so a regulated enterprise can show what its coding assistants were allowed to do and what they did. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. Deciding which licenses to block in which delivery model remains a legal and policy question for the organization.