How to Prove to an Acquirer That AI-Generated Code Is Free of GPL Obligations

What the acquirer is actually asking

In technical due diligence, a buyer wants to know whether any part of the codebase carries GPL or other copyleft obligations that could attach to the acquired product. AI coding assistants add a specific difficulty. An assistant can produce code that resembles licensed code without attribution, and the developer who accepts it may not know. A claim that the codebase is clean is an assertion. Diligence teams generally look for evidence that someone other than the seller can inspect.

Buyers tend to ask a consistent set of questions. Which assistants were used, over what period, and under what policy? For specific code, where did it originate and what licence context applied when it was generated? What review or analysis was applied, and how were issues recorded and triaged? What is the remediation process for flagged output, and is there proof it was followed? How long are the records kept, and who attests to them?

Two scoping points help. First, NIST SP 800-218A does not distinguish between human-written and AI-generated source code, because all source code is assumed to need evaluation before use. Apply one evaluation process to both rather than building a separate story for AI output. Second, U.S. Copyright Office registration guidance concerns human authorship and disclosure of AI-generated material. It does not address open source licence obligations such as GPL, so it does not answer this question.

What each evidence type can and cannot show

Treat each evidence type as answering one question. The mistake to avoid is asking one type to answer a question it was not built for.

• Point-in-time repository license scan: Shows licences and licence-related findings in the code as it exists on the scan date. It does not record which assistant produced a snippet, when, or under what policy, and it says nothing about code that was removed before the scan.
• Provenance records captured at generation: Show origin, licence and security context for AI-generated code when it was produced. They cover only the period and tools in which capture was active, so earlier code needs another basis.
• Records of enforced policy: Show what rules applied to assistant interactions and what action was taken: allow, redact or block. They show the control that was in place, not that every output was free of licensed code.
• Remediation documentation: Shows that flagged output was triaged and resolved through a defined process. It is only as persuasive as the records showing the process was followed.

Scanning versus provenance: the core distinction

A scan of a finished repository examines code as it is. It can surface licence text, known component matches and similar findings. It does not capture the event that created each line. For AI-generated code, the questions a buyer cares about concern that event: which assistant, which request, what context, and what policy applied. Only a record made at the time can answer them with specificity. Reconstructing the answers afterward from commit history and developer recollection is weak evidence.

The inverse also holds. Provenance and policy records do not replace a scan. They describe the generation path, while the scan checks the resulting code, including code written by people and code imported from elsewhere. NIST's generative AI guidance suggests documenting the origin and history of generated data, including copyright and licence information, and documenting compliance with legal requirements. It also treats analysis and review as separate steps from provenance documentation. Pairing the two is consistent with that framing. No guidance states that either one alone establishes freedom from GPL obligations, and the package should not claim that it does.

If third-party assistants or vendors are involved, keep the due diligence you performed on them and any audits against contractual commitments. NIST's draft also describes the parties agreeing which of them is responsible for each practice and how each will attest to conformance. Writing down who attests to what makes the package easier for a buyer to evaluate.

Retention, attestation and what a buyer's team will test

Retention is a decision to make with counsel, based on your expected deal timeline and any contractual or regulatory duties. Set the period before the records are needed, apply it consistently, and document it. Records that existed but were deleted on an undocumented schedule weaken the package.

Expect the buyer's technical team to sample. They may pick specific files or modules and ask you to trace them through the scan, the provenance record, the policy record and any remediation. Build the package so that trace works end to end, with stable identifiers linking the records. NIST's secure software guidance describes producers supplying artifacts, the low-level outputs of their practices, and attesting to conformity. That model comes from federal procurement, but the principle carries over: an attestation is stronger when it points to artifacts.

What the buyer's counsel will accept is their decision and varies by deal. Do not present the package as a legal opinion or promise a deal outcome. Have counsel review the coverage statement and the language of any representation before it is given, and keep external statements about code provenance accurate and supportable.

One way to produce this evidence with Trussed

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 actions include allow, redact and block at the level of individual interactions and tool calls. Trussed's code provenance supplies origin, licence and security context for code. Enforcement generates audit-ready evidence continuously, so records of what policy applied and what action was taken exist as a by-product of the control rather than being reconstructed for a deal.

Trussed deploys self-managed in the customer's cloud, with configurable retention and data residency, which lets you align the retention period with the decision made with counsel. These capabilities support the provenance and policy-record steps above. They do not replace the repository scan, the review process or legal judgement, and they cover only the interactions that pass through the enforcement path.