Copyleft License Evidence for AI-Generated Code to Retain for M&A Due Diligence

What counts as copyleft evidence for AI-generated code

Copyleft evidence for AI-generated code is the set of records showing what an assistant produced, what origin and license signals applied at that moment, what policy governed it, and what was decided. Assistants can produce code that resembles material under licenses such as GPL, LGPL, AGPL or MPL, and developers often accept suggestions without recording where they came from.

NIST describes supply chain due diligence as researching and verifying information about a product so that informed decisions can be made on acquisitions. It lists provenance as a research category and defines pedigree as provenance validated with evidence. Its examples of inputs include license documentation and source-code repositories. The practical point is that an assertion such as "we reviewed our AI-generated code" carries less weight than a record that can be checked.

The most useful distinction is between two kinds of evidence. Contemporaneous evidence is created when code is generated and a policy decision is made. Reconstructed evidence is assembled afterward from codebase scans, commit history and developer interviews. Scans can find matches in the final codebase, but they cannot show which code came from an assistant, what license signal existed at the time, or who decided to keep it. Counsel, not the engineering team, determines whether a given match creates an obligation.

How the evidence maps to diligence questions

Organizing retention around the questions a diligence team asks keeps the program practical. NIST's due diligence guidance also notes that research may be performed across most suppliers regardless of criticality, so sellers should not assume only high-risk assets will be examined.

• Which code was AI-generated or AI-assisted, and how do you know?: Needs per-event generation records tied to repository and commit identifiers. Interviews alone are weak substitutes.
• What license signals existed at generation time, and what was decided?: Needs origin and license match signals together with the enforcement decision for each suggestion.
• Which assistants, models and policies were in use, and when?: Needs dated configuration records, including changes over time.
• Who approved flagged suggestions, and how is that record protected?: Needs reviewer records with integrity controls such as hashes, signatures or attestations.
• Do you have commit-time SBOMs and scan results, and what was remediated?: Needs SBOM and dependency-scan outputs plus remediation records for identified copyleft items.

Retention, integrity and cross-referencing

NIST's generative AI guidance suggests documenting each instance where content is generated, modified or shared, to create a tamper-proof history that supports traceability. NIST's due diligence guidance adds that contributor attribution may be validated by cryptographic hash, signature or digital certificate. Together these point toward signed, per-event records rather than editable spreadsheets or exported chat history.

Keep SBOM and dependency-scan output generated at commit alongside generation-time records. NIST's DevSecOps guidance recommends generating an SBOM with dependency scanning on the first commit and preserving signed attestations and their storage. An SBOM reflects declared dependencies. It does not capture a snippet an assistant suggested and a developer pasted in, so the two record types answer different questions and should be cross-referenced by repository and commit.

Retention periods, data residency and the length of any post-closing indemnification window should be set with counsel. The NIST material is voluntary guidance, not a legal retention or disclosure mandate. Because generation-time records may include code content, where they are stored and who can access them is a design decision, and retention should be configurable rather than fixed by a tool default.

Assess gaps in your current retention practices

A gap assessment is easiest when it starts from a sample rather than a policy document. Take a set of recent commits and try to answer the buyer questions above using only records that already exist.

• Select a sample of recent commits from repositories where coding assistants are enabled.
• For each, try to show whether code was AI-generated and which assistant and model produced it.
• Identify what license or match signal existed at generation time and whether it was recorded then or inferred later.
• Locate the decision and reviewer record for any flagged suggestion, and check how its integrity is protected.
• Compare commit-time SBOM and scan output with generation-time records to see whether they can be linked.
• Review retention and residency settings with counsel, and list each category as contemporaneous, reconstructed or missing.

Producing this evidence continuously at runtime

Reconstruction during a deal is slow and rarely complete, because the context at generation time is gone. The alternative is to produce evidence where the code is produced. NIST's generative AI guidance suggests recording generation events as they occur and taking action on outputs that reproduce licensed content. That implies a decision point in the path between assistant and developer, with the outcome recorded as evidence.

Trussed implements this as policy enforcement in the execution path for coding assistants. Policy is enforced at runtime, not reviewed after the fact: suggestions can be allowed, redacted or blocked, or escalated for human approval. Code provenance captures the origin, license and security context of code, and the enforcement decisions generate audit-ready evidence continuously, including reviewer approvals for escalated items. Scope is individual interactions and tool calls.

Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, so those settings can follow counsel's guidance and deal requirements. It does not decide whether a license creates an obligation. It supplies the record that counsel and a buyer's diligence team can evaluate.