Who really owns the code an AI writes for you?

Two questions wearing one coat

“Who owns this code?” is two questions that get asked as one. The first is a contract question: what do the terms you accepted say about the output the tool gave you? The second is a copyright question: is that output the kind of thing copyright protects at all, and if it is, who counts as the author?

The first question is settled and fairly dull. The second is unsettled and has consequences that turn up years later, usually in a data room or in a letter from a competitor’s solicitor. Treating the two as one is the most common error here, and it leaves people either falsely reassured (“the terms say it’s mine, so we’re fine”) or needlessly alarmed (“Microsoft owns our product”). Neither is right.

The contract layer: vendors hand you the output

Every major AI coding tool takes essentially the same position. The vendor does not claim ownership of what the model produced for you, and assigns to you whatever rights it might hold in it.

GitHub is explicit in its GitHub Copilot Product Specific Terms. GitHub permits commercial use of Copilot-assisted code, and adds IP indemnification at the Business and Enterprise tiers.

OpenAI’s business terms say that OpenAI assigns to the customer its right, title and interest, if any, in the Output. The consumer terms use near-identical wording. OpenAI also flags something specific to code, which most readers skip: output from code generation features may be subject to third party licence terms, including open source terms.

Anthropic’s commercial terms provide that Anthropic assigns its right, title and interest, if any, in Outputs to the customer, and the Claude Code legal and compliance documentation is the place to check the current wording for that product.

Other tools follow the pattern. If your worry was that a vendor would turn up claiming a stake in your product, the terms answer it. That is the easy half.

The two words doing the real work: “if any”

Read those assignment clauses again and the qualifier stands out. OpenAI and Anthropic both assign their right, title and interest “if any”.

That is not padding. A vendor can only give you what it actually has. If purely machine-generated output attracts no copyright in the first place, then the vendor holds nothing, assigns nothing, and the clause transfers an empty set. You still have the files. You still have the right to use them commercially, which is what most teams actually needed. What you may not have is an exclusive right you can enforce against someone who copies them.

So the contract protects you from the vendor. It cannot manufacture a property right that the law does not recognise.

The copyright layer: is there anything there to own?

This is the layer that decides whether “ownership” means anything durable, meaning enforceable against a copycat, saleable as an asset, or listable as intellectual property in an acquisition.

The analysis by Skadden is a readable summary of what the Report says and does not say.

The Office’s line rests on the Copyright Act’s distinction between protectable works and unprotectable ideas.

This is not a blanket ban, and it is worth being precise about that. Where a human and a model both contribute, the human contributions can still be protected. Using AI as an assistive tool does not render the whole work uncopyrightable, and the Office has described the routes through: AI as an assistive tool rather than a replacement for human creativity, human-created elements incorporated into AI output, and creative arrangement or modification of AI-generated elements.

What a thin authorship record actually costs

If your codebase was largely generated with little human iteration, three costs follow, and none of them show up on the day you ship.

The first is enforcement. A competitor who copies your code has a defence available that would not exist for hand-written work: that the material was not copyrightable to begin with, so copying it infringed nothing. You would be arguing about how much human authorship shaped the files, with the burden on you and the evidence long cold.

The second is valuation. Line count is a poor proxy for asset value at the best of times, and it is a worse one when an unknown share of those lines may carry no protection. A codebase that cannot be defended is worth less than one that can, regardless of whether it runs well.

The third is diligence. Acquirers have started asking for authorship evidence, including prompt logs, as part of code review. That is a request you can answer easily if your workflow produced a record, and cannot answer at all if it did not. Trade secret protection is sometimes offered as a fallback for AI-heavy codebases, since it does not depend on copyright status, but it only works while the code stays undisclosed, which rules out anything you publish or ship as source.

The commonly given recommendation is the same one that produces better software anyway: treat model output as raw material rather than a finished product, and add your own logic and structure on top.

The separate problem: where the training data came from

There is a third question hiding behind the first two, and it is about input rather than output. Code that a model reproduces from its training data may carry obligations from the source it came from. OpenAI says so directly in its own terms.

The litigation on this is narrower than the headlines suggested. BakerHostetler’s case tracker is a useful running record of the Doe v GitHub case. Whatever the eventual outcome, note the shape of the risk: it is not that someone else owns your generated code, it is that a fragment of it may have arrived with licence terms attached that your project does not comply with. That is a scanning and review problem, and it belongs in your pipeline rather than in your terms. We covered where those checks sit in what your AI code policy must say on security and IP.

Keeping a human in the record

The two layers point at the same working habit from different directions. Copyright wants visible human creative control. Security and correctness want someone who has actually looked at the change. Both are served by a loop where a person shapes, reads and modifies each increment rather than accepting a large generated block whole.

That means reviewing changes as they land, which is exactly the step that pure vibe coding drops by definition, as set out in reading the diff is the review vibe coding lacks. It means keeping the commit history honest, because a history of small, human-shaped changes is the cheapest authorship evidence you will ever produce, and it costs nothing extra if you were working that way already. And it means knowing the point at which the generated draft stops being a prototype and becomes something you maintain, which we looked at in when to stop vibe coding and take the wheel yourself. The trade-off is speed: a reviewed increment

---

Written with AI assistance and reviewed under our editorial policy. Vibe coding changes quickly; details reflect sources current on 2026-09-26. Some passages are the author's opinion. Spotted an error? tell us.