GPL-2.0 vs GPL-3.0 vs AGPL-3.0: Which Copyleft License Creates the Most Exposure for AI-Generated Code?

Obligation triggers: distribution versus network interaction

Treating GPL-2.0, GPL-3.0 and AGPL-3.0 as one "copyleft" category hides the differences that drive policy. The core question for each is what event creates the obligation to offer corresponding source under the same license.

GPL-2.0 and GPL-3.0 are triggered by distribution of the covered work, which GPL-3.0 describes as conveying. Running modified software privately or providing it as a hosted service does not, by itself, trigger the source-offer obligation. AGPL-3.0 keeps the GPL-3.0 structure but adds a provision for modified versions: users who interact with the program remotely over a network must be offered the corresponding source. That moves the trigger from shipping software to serving it.

For AI-generated code the mechanics are the same as for human-written code. If a suggestion reproduces or closely resembles covered source, and it is incorporated into a work that is then distributed or network-served, the license's terms may be engaged. The assistant does not change the license analysis. It changes how likely it is that covered code enters a codebase without anyone noticing.

Side-by-side: patents, anti-tivoization and compatibility

The three licenses differ in more than their triggers. These differences shape which compatibility and deployment questions an architect must answer.

• GPL-2.0: Trigger: distribution. No express patent license grant comparable to GPL-3.0. No installation-information requirement for locked-down devices. Compatibility: GPL-2.0-only code cannot be combined with GPL-3.0 code in a single work, while GPL-2.0-or-later can move to GPL-3.0.
• GPL-3.0: Trigger: distribution (conveying). Includes an express patent license from contributors and patent-related conditions. Requires installation information for user products, which targets devices that prevent modified software from running. Compatible with AGPL-3.0 through the AGPL's combination provision.
• AGPL-3.0: Trigger: distribution, plus remote network interaction with a modified version. Carries the GPL-3.0 patent and installation-information terms. Combining with GPL-3.0 code is permitted, with the network-use provision continuing to apply to the AGPL portion.

Which deployment models raise the most exposure

For distributed binaries, all three licenses can create obligations, so the difference lies in the terms that come with them. A GPL-2.0-only match in a codebase that already contains GPL-3.0 components is a compatibility problem, not just a source-offer problem. A GPL-3.0 or AGPL-3.0 match brings patent terms that a legal team may want to review separately.

For embedded or device software, GPL-3.0 and AGPL-3.0 are the most demanding because of the installation-information requirement for user products. Where firmware is signed or locked, that requirement interacts directly with product design. GPL-2.0 still applies on distribution but lacks this term.

For SaaS, GPL-2.0 and GPL-3.0 are generally not triggered by hosting alone, which is why AGPL-3.0 stands apart. A single AGPL-derived snippet in a modified, network-served component can matter even though no binary leaves the company.

Internal services are the least clear. Whether obligations arise can depend on who uses the service, and whether code or binaries are provided to affiliates, contractors or customers. Counsel should decide these cases, and policy should be written so the question is raised rather than assumed away.

Contractual constraints also vary by license. A federal acquisition clause on contractor open source software, 48 CFR 1552.239-71, lists GNU GPL version 3 among permitted licenses alongside CC0, MIT, LGPL-2.1 and Apache 2.0, and routes other licenses through agency approval, as of November 2026. It addresses the licenses contractors use, not AI output, but it shows that license-specific policy has precedent.

Why this is a generation-time problem

Review after the fact is a weak control for this risk. By the time a pull request is reviewed, the snippet looks like any other code, and the reviewer usually has no information about where it came from or what license its origin carries. Scanning later can identify matches, but it cannot tell you what the assistant was asked, what it returned, or who accepted it.

The more reliable pattern treats provenance as metadata attached to each suggestion at the moment of generation: where the code appears to originate, which license it appears to carry, and what security context applies. With that context, a license-specific rule can be applied before the code reaches a branch, and the decision can be recorded as it happens.

This also lets policy follow the deployment model. The same GPL-3.0 match may be acceptable in a prototype that is never distributed and unacceptable in firmware. The rule needs to know both the license and the destination.

Defining license-aware runtime policy for coding assistants

A workable policy maps each detected or suspected license to one of four actions at the point of interaction. The mapping should be set per license and per deployment model, not per category.

• Allow: Permissive or approved licenses, and matches in code that will never be distributed or network-served, with the decision recorded.
• Redact: Remove the matched portion of a suggestion, or strip identifying content from a prompt, where the rest of the output is still usable.
• Block: Licenses that policy excludes for a destination, such as AGPL-3.0 in network-served services or GPL-2.0-only where GPL-3.0 components are present.
• Escalate for human approval: Ambiguous matches, license-version uncertainty such as GPL-2.0-only versus or-later, and any case touching device software or contractual license limits.