GPL Copyleft and AI-Generated Code in Internal-Only Tools
Internal-only use does not, by itself, trigger the source-code obligations of the GPL, which generally attach to conveying copies to others. The AGPL adds network interaction as a trigger. The assumption that internal means exempt is fragile, though. Tools get shared with affiliates, contractors, customers and acquirers, and AI-generated output that resembles licensed code has an unsettled legal status. Enterprises need to record code origin and licence context at generation time. This guide is technical, not legal advice.
Controls in the AI coding workflow
- 1
Define a policy for assistant output
State which licence categories are acceptable, which require approval, and which are blocked for each class of tool, including tools that may later be shared.
- 2
Enforce at generation time
Apply the policy to individual interactions in the path between assistant and developer, so a decision is made before code enters the repository.
- 3
Route exceptions to people
Send ambiguous or high-risk output to human approval instead of relying on a developer's judgement in the editor.
- 4
Keep the same downstream gates
Generated code still goes through vulnerability and quality evaluation, with least-privilege access to stored code and configuration.
- 5
Assign responsibility by contract
Where a third party supplies the assistant, agree who is responsible for which practice and how conformance is attested.
What to capture as code provenance
- Origin: assistant and version, requesting user or service, repository and timestamp of the generation event.
- Licence context: any licence identifier or matched-code indicator available for the output, and an explicit marker where none is available.
- Security context: results of the evaluation applied before acceptance.
- Policy decision: the rule applied and the outcome (allowed, redacted, blocked or escalated), with any approver.
- Disposition: whether the output was accepted, modified or discarded, and where it landed.
- Tool status: whether the tool is internal-only, shared with affiliates or contractors, or externally exposed, updated as that changes.
What actually triggers GPL and AGPL obligations
The GPL family is built around a distinction between using software and conveying it. Running, modifying and studying GPL-licensed code inside one organisation does not oblige that organisation to publish anything. The obligations to provide corresponding source and to license the work under the same terms arise when copies of a covered work are conveyed to another party. GPLv2 frames this as distribution, and GPLv3 uses the term conveying. Both versions are concerned with copies leaving your control.
The AGPLv3 changes one thing. It adds an obligation for modified versions that users interact with remotely over a network, even when no copy is handed over. An internal tool built on AGPL-covered code and exposed to users outside your legal entity is therefore a different case from the same tool used only by your own staff.
The edge cases sit at organisational boundaries. Whether a transfer to a subsidiary, a contractor with its own environment, or a joint venture counts as conveying depends on the legal relationship, the contract terms and the facts of who holds and controls the copy. Those questions belong with counsel. The architectural point is that you cannot answer them for code whose origin you cannot reconstruct.
How AI-generated output complicates the analysis
A coding assistant can produce output that is original, output that closely resembles existing code, or output that reproduces it. For licence purposes these are different situations, and an engineer reading a suggestion in an editor usually cannot tell which one they have.
The legal position on the middle case is open. NIST states that the status of generated content that is similar to, but does not strictly copy, protected work is currently debated in legal fora, and it lists replication of licensed content without authorisation as a generative AI risk. As of November 2026, an enterprise should treat this as an unresolved question and record it as such, rather than assuming either that resemblance carries copyleft consequences or that it does not.
Two practical consequences follow. First, a position of "we did not copy anything" cannot be evidenced when there is no record of what the assistant produced and what a developer accepted. Second, the risk compounds quietly. Output accepted into an internal tool is indistinguishable from hand-written code once committed, so a licence question surfaces only when someone asks for provenance months or years later.
Where internal use becomes external sharing
Most exposure does not come from the original intent. It comes from the lifecycle of the tool. An internal utility is adopted by another business unit, handed to a contractor for maintenance, bundled into a customer deliverable, or packaged into a product. A service built for staff gets an external user group. A company is acquired and its code base goes through due diligence.
Each of these events can move software across the boundary that the internal-use assumption depends on. By then the original generation context is gone unless it was captured when the code was written. Architects should therefore ask of every internal tool not only whether it is distributed today, but whether the organisation could establish its code origin and licence context on the day it is not.
Where Trussed fits
Trussed enforces policy in the execution path of coding assistants, alongside models, agents, tools and MCP servers. Policy is enforced at runtime, not reviewed after the fact, and each interaction can be allowed, redacted, blocked, rate limited or escalated for human approval. Trussed also provides code provenance, covering the origin, licence and security context of code, and enforcement continuously generates audit-ready evidence. It can be self-managed in the customer cloud, with configurable retention and data residency.
That gives a regulated enterprise a record to put in front of an auditor, acquirer or customer when a licence question arises. The licence analysis itself, including the open questions about similar output, remains a matter for your legal team.
From assistant output to audit-ready evidence
Origin
Which assistant, which interaction and which developer produced the code.
Licence context
Any licence signal attached to the output or to code it resembles.
Security context
Evaluation status applied to the code before it is accepted.
Policy decision
Allow, redact, block or escalate, recorded at the moment of generation.
Establish code origin before the question is asked
Talk to us about enforcing policy on coding assistant output and producing audit-ready evidence of code origin and licence context.
Talk to an Expert