Code provenance and licence exposure in AI-generated code

Licence exposure in AI-generated code is three separate questions, and a diligence review has to ask all three because each has a different source of evidence. Can the generated code be owned? Did the generator reproduce code that carries someone else's licence? And what do the terms of the tool that generated it say about who owns the output and what the provider may do with the input?

The general open-source review in open-source licence due diligence still runs. This page is about what it misses when most of the code came out of a model.

Can AI-generated code be owned at all?

AI-generated code can be owned to the extent a human contributed protectable expression to it, and purely generated code, with no such contribution, is not protected by copyright under current US guidance. That is the conclusion of the US Copyright Office's report on copyrightability, published in January 2025 after a consultation that drew more than 10,000 comments [1].

Reveneau's provenance check on an AI-written codebase asks for the record of human contribution, not because every file needs a human author, but because a company that cannot show which parts of its code a person shaped cannot say which parts it owns. The report's conclusions, quoted from its summary, are the test.

The Office concluded that "copyright does not extend to purely AI-generated material, or material where there is insufficient human control over the expressive elements"; that "based on the functioning of current generally available technology, prompts do not alone provide sufficient control"; that "the use of AI tools to assist rather than stand in for human creativity does not affect the availability of copyright protection for the output"; and that whether human contributions are sufficient "must be analyzed on a case-by-case basis" [1]. It also concluded that human authors are entitled to copyright in their own contributions that are perceptible in the output, and in the creative selection, arrangement or modification of it.

For a startup, the practical reading is this. Code a developer wrote with an assistant suggesting lines is assisted and protected. Code an agent generated from a prompt, unmodified, is at the weak end of the scale. Most codebases are a mix, and the diligence question is whether the company can say which is which. The report is US guidance; other jurisdictions differ, and the report itself says it will revisit its conclusions as the technology changes. The finding for the investor is the same in every jurisdiction: the ownership of generated code is a live question, and the target's answer should be a record rather than an assumption.

Did the generator reproduce licensed code?

The generator may have reproduced public code, and the tool's own logs are the evidence. GitHub's documentation for Copilot describes a code-referencing feature that compares a suggestion and the surrounding code, a window it gives as 150 characters, against an index of public repositories on GitHub.com, and says that when a matching suggestion is accepted the log entry includes the URLs of files containing matching code and the name of the licence that applies to that code, or NOASSERTION if none was found [2]. The same documentation describes a setting that blocks suggestions matching public code.

So the questions are direct. Was the matching filter on or off, and since when? If it was on and set to allow, where are the logs, and what licences appear in them? If it was set to block, can the company show the setting's history? If the tool was one that offers no such feature, what did the company do instead?

The standard legal checklist will not ask these. Morgan Lewis's June 2026 summary of common open-source areas of inquiry in M&A diligence lists six: whether the company has a written open-source policy, whether it trains employees on licence obligations, whether it contributes to open-source projects, whether it tracks open-source usage, whether it runs regular scans, and whether it has an approval process for copyleft-licensed software [3]. It is a good list and it does not mention AI-generated code once. A target that passes all six can still have a generator that reproduced a GPL-licensed function into a proprietary module with no record of it.

The fix is a scan that the general open-source tools already do, pointed at the right question. A snippet-level match against public code, rather than a package-level dependency scan, is what finds a reproduced function. Ask whether one has been run and read the results.

What do the tool's terms say about output?

The tool's terms decide who owns the output and what the provider may do with the input, and a target should be able to name the terms that applied to each tool it used. The two are different questions. Ownership of output is about whether the company can claim what was generated. Training use is about whether the company's own code, sent as context, may have been used to improve the provider's models, which matters when the code contains a customer's data or a trade secret.

Anthropic's commercial terms of service state that the customer "retains all rights to its Inputs" and "owns its Outputs", and that "Anthropic may not train models on Customer Content from Services" [4]. Terms differ between a provider's consumer products and its commercial API, and they differ between providers, so the target's answer needs to be specific: which tool, which account type, which terms, from which date. A team that used personal accounts for a year before moving to a commercial plan has a year of input under different terms.

For the models the product itself calls in production, rather than the tools used to write it, the same question applies to customer data flowing through the API, and it belongs on the security page as well as here.

How do you run the provenance check?

Run the provenance check by asking for a record and then testing it against the tools' own logs and settings.

1. Ask for the provenance record. Which tool generated which parts of the codebase, from when to when, under which account and terms. A good answer is a document. A weak answer is a guess about proportions.
2. Ask for the human contribution record. Which modules were designed, modified or reviewed by a person, and how that is evidenced. Review history and specification documents are the usual evidence.
3. Read the tool settings and their history. For each generator: the public-code matching setting, the logs it produced, and the date the setting last changed.
4. Run a snippet-level scan against public code. On the current commit. Read every match with a copyleft licence and trace it to a module.
5. Read the terms for each tool and account type. Confirm output ownership and training use. Note any period on consumer terms.
6. Document the models the product calls. The SPDX 3.0 specification, released by the Linux Foundation on 16 April 2024, includes an AI profile whose properties for an AI package include the type of model, information about training, limitations, a safety risk assessment, and whether sensitive personal information is used [5] [6]. A target does not need SPDX, but it needs to be able to answer those fields.
7. Write the exposure by module. Which parts of the codebase are assisted and owned, which are generated and unrecorded, and which contain a match to licensed code.

What goes in the report?

The report states the exposure by module and the cost of closing it. The table below is the shape.

Finding	Evidence	Consequence
Human contribution recorded for core modules	Specs, review history, commit messages naming the reviewer	Ownership defensible under the Copyright Office's case-by-case standard
Generated modules with no contribution record	Provenance record says agent-generated, no review trail	Ownership uncertain; recommend a documented review pass post-close
Public-code matching was off	Tool settings history	Reproduced code possible; run a snippet scan before close
Copyleft match in a proprietary module	Snippet scan output	Rewrite or relicense the module; cost in the model
Consumer terms used for a period	Account history	Input may have been used for training in that period; disclose to affected customers if data was involved

Each of these findings is common and each has a fix. What decides the deal is whether the company knew, because a company that knows has a record and a plan, and a company that does not has a lawyer's afternoon ahead of it after close.

Diligence on an AI-written codebase covers the other five artefacts the provenance record sits beside, security of AI-written code in diligence covers the data-flow half of the terms question, and handing over AI-written software is the engineering view of what a clean provenance record makes possible. The AI startup due diligence guide places all three in the engineering read.