AI-Generated GPL Code: Does Internal-Only Use Count as Distribution?

What the GPL ties its obligations to

The GPL is a copyright licence, and its copyleft terms are written around particular acts rather than around use in general. GPLv2 frames the trigger as distribution of copies. GPLv3 uses the term conveying. In both cases the practical question for a compliance leader is the same: has a copy of the covered code, or a work based on it, been handed to a party outside the boundary you rely on?

That is why "we only use it internally" is an incomplete answer. It is a claim about where a boundary sits, and it holds only if the boundary is defined precisely and nothing crosses it. Whether two entities count as one party, and whether a transfer to a contractor is a handover of a copy, depends on the licence text, the governing law and the facts. Those are questions for counsel, and they should be answered before an engineering team relies on the assumption.

The same caution applies to analogies. Other instruments define "internal" in their own ways. One NIST site licence, for example, permits integration into internal intranet applications for institutional use and requires a separate agreement for public Internet access. That shows a licence can define internal contractually. It says nothing about what the GPL means, and a definition from one instrument should not be carried over to another.

Why AI-generated code adds uncertainty

Foundation models are used across the software development lifecycle, including code generation, assistance, review and test case development. In ordinary development, a developer knows where a snippet came from: a library, a repository, a colleague. With an assistant, the developer receives output that may resemble or derive from licensed source, and nothing in the editor tells them which licence, if any, applies.

This changes the compliance problem in two ways. First, the origin of a given block is often invisible at the moment it is accepted, so licence review tends to happen late or not at all. Second, code accepted into a repository loses its association with the assistant interaction that produced it. Months later, when a service is packaged for a customer or a repository is considered for open sourcing, nobody can say which blocks were generated, what they resembled, or what was decided at the time.

How copyleft applies to AI output that reproduces or derives from GPL-licensed code is not something this article resolves, and it should be treated as an open question in your own risk assessment. The practical response is to avoid depending on any single reading. Build a boundary that holds under the stricter interpretation, and keep the evidence to revisit decisions if the position changes.

Where internal use may end

The scenarios below are the points at which internal AI-generated code most often moves toward other parties. Each is a prompt for legal review, not a conclusion about whether obligations arise.

• Subsidiaries and affiliates: Confirm whether your policy and counsel treat related entities as inside or outside the boundary. Do not assume corporate family equals one party.
• Contractors and outsourced teams: Code shared with or received from external developers is a transfer to review, particularly where they work in their own environments.
• SaaS delivery: Running code on your own servers for customers differs from handing them a copy. Counsel should assess how the specific licence and version treat that distinction.
• On-premises customer deployments: Shipping binaries, containers or source to a customer is the clearest case of code leaving the boundary.
• Open-sourcing internal tools: Publishing a repository exposes every generated block in it, including ones nobody reviewed for origin.
• M&A and code transfer: Diligence, divestitures and asset transfers move code to a new owner and require a record of what the code contains.

Defining the internal-use boundary

Treat internal-only use as a policy that is written down, not a default. Start with a definition of internal that names the legal entities, the categories of personnel and the environments inside it. State explicitly how affiliates, subsidiaries and contractors are handled, and what happens to code that could be shipped, contributed externally or transferred.

Then define the release gate. Code that stays inside the boundary follows one path. Code that is headed outside, whether in a product build, a customer deliverable or a public repository, follows another, with a required licence and origin check and a named approver. One US federal agency's governance model for its generative AI platform illustrates the pattern in a different context: staff must independently review and verify AI-generated output before relying on or distributing it, must add a disclosure note when AI-assisted work product is shared internally, and need supervisory approval before sharing outside the agency. Prompts and outputs are also kept within authorised environments, supported by training, acceptable use requirements and access reviews. That is not a GPL requirement, but the structure of review, disclosure, approval and containment transfers well to an internal-use boundary.

Finally, decide what you will be able to show. For any block of generated code, a compliance team should be able to answer what the assistant produced, what origin and licence context was known, what policy applied and who approved any exception.

Enforcing the boundary at the coding assistant layer

Written policy and after-the-fact review are weak against the volume of assistant interactions an engineering organisation generates. The boundary is more reliable when it is enforced at the point of generation, in the path between the developer and the assistant, so that the decision is made before code enters a repository.

Trussed enforces policy in the execution path for coding assistants. For each interaction or tool call, policy can allow, redact, block or escalate for human approval, enforced at runtime, not reviewed after the fact. Trussed also surfaces code provenance: the origin, licence and security context of code, so a reviewer sees the licence context when the code is generated rather than discovering it at release. Enforcement produces audit-ready evidence of what was permitted, what was blocked or escalated, and what happened. This is evidence of code-level decisions only. It does not describe model or dataset provenance.

Whatever tooling you choose, evaluate it against the same criteria:

• Does it act before code is accepted, or only report afterwards?
• Does it show origin and licence context for the generated code itself?
• Can policy differ by repository, team, contractor group or release target?
• Can it route risky output to a human approver and record the outcome?
• Does evidence persist per interaction, with retention you control?
• Can it run in your own cloud environment to meet data residency needs?