Notes / Software & IP
Who owns AI-generated code?
What software suppliers can promise their customers.
Your company can own copyright in software developed with AI, but that does not mean it owns every generated element. Ownership depends on the applicable law, the human contribution, the rights obtained from contributors and the provider’s terms. Third-party code needs a separate licence review.
Your team has built a product with AI coding tools. The customer sends its standard contract:
“The supplier owns all intellectual property in the software.”
The tool’s terms seem reassuring. But that warranty concerns the whole product, including your developers’ work, generated code, existing supplier materials and third-party components. The provider’s output clause covers only part of that picture.
This article focuses on copyright and the contract promises around it. A warranty covering all intellectual property may also reach patents and other rights that need separate review.
What the AI provider actually gives you
Anthropic’s Commercial Terms allocate output rights to the customer as between the parties, within the limits of applicable law. They also assign any rights Anthropic has in the output, subject to compliance with the terms. The qualifications matter: the clause deals with the provider’s position. It does not create copyright where the law does not recognise it or transfer another author’s rights. Anthropic Commercial Terms, section B.
The plan matters. Anthropic states that Claude Code use under Free, Pro and Max plans is governed by its Consumer Terms, while Team, Enterprise and direct Claude API use falls under its Commercial Terms. The Consumer Terms also assign any rights Anthropic has in output, but do not provide the same IP indemnity. Claude Code legal agreements; Anthropic Consumer Terms, section 4.
If a developer subscribes in their own name, check how any rights acquired from the provider reach the supplier. Ownership of the developer’s own work also depends on the relevant agreements and applicable law, which may make an employer the first owner. CDPA, section 11(2).
OpenAI’s business agreement uses a similar ownership structure. It also explains that other users may receive similar output. That qualification does not itself defeat copyright, but the ownership clause is no promise of a unique result. OpenAI Services Agreement, sections 4.1 and 4.4.
In a review, I would first identify the actual contract: the provider, product, account holder, subscription and terms in force when the tool was used. A company paying for a developer’s account does not, by itself, answer all those questions. Product-specific conditions and separately negotiated terms may change the result.
Does the generated code have copyright protection?
The answer depends on the applicable law and the contribution to the particular work. Using AI does not automatically strip protection from a program written with its help. Equally, approving a generated result does not automatically establish authorship of everything in it.
United States
The US Copyright Office’s January 2025 report distinguishes human expression from material generated by AI. Human-authored material that remains perceptible in the result, creative modifications, and sufficiently original selection or arrangement can receive protection. For the technology it examined, prompts alone did not provide enough control over the resulting expression. The Office treats mixed works case by case. US Copyright Office, Copyright and Artificial Intelligence, Part 2, sections II.C–F.
In Thaler v. Perlmutter, the D.C. Circuit upheld the refusal to register a work that named an AI system as its sole author. The court did not decide how much human contribution is enough in a mixed work. The Supreme Court declined to hear the case on 2 March 2026; that refusal was not a ruling on the merits. D.C. Circuit, 18 March 2025, pages 18–20; Supreme Court docket 25-449.
The practical question is what original expression a person contributed to the finished code. A feature request, hours of prompting or a final approval are not reliable substitutes for that assessment. There is no safe percentage of lines to rewrite. Development records can help identify the contribution; a commit count cannot establish its legal significance.
For software, distinguish expression from function. Copyright does not protect an algorithm, a function or a system design merely because it was difficult to develop. US Copyright Office, Circular 61, page 1.
United Kingdom
UK legislation contains a specific rule for certain computer-generated works without a human author: authorship is attributed to the person who undertakes the arrangements necessary for creation. Applying that rule to modern generative AI remains uncertain. CDPA, section 9(3); section 178.
The government’s March 2026 report proposed removing this special protection in the absence of evidence of its continuing value, while continuing to monitor its use. A proposal does not repeal the statute. Neither the US approach nor a headline about UK reform is a sufficient basis for an unqualified ownership promise. UK government report, section I.
European Union
The Software Directive requires a program to be the author’s own intellectual creation and distinguishes the program’s expression from its underlying ideas and principles. A provider’s contract cannot replace that requirement. The assessment must address the particular contribution and applicable law. Directive 2009/24/EC, article 1(2)–(3).
For a product used internationally, I would check the relevant countries before promising exclusive rights in every generated element. An English-law contract clause does not settle copyright protection everywhere the software will be used. Berne Convention, article 5(2).
Could the output contain someone else’s code?
A generated passage might lack new copyright protection and still reproduce protected expression from an existing program. Those are separate questions. The absence of new rights does not extinguish the original author’s rights. US copyright law expressly preserves the separate position of pre-existing material in a derivative work. 17 USC, section 103(b).
OpenAI’s Service Terms expressly contemplate third-party licences, including open-source licences, applying to code-generation output. An output ownership clause therefore cannot be treated as a licence clearance certificate. OpenAI Service Terms, section 4.
Using an AI tool does not itself trigger copyleft. The question is whether relevant licensed material is present and how it is used. For example, the MIT licence requires its copyright and permission notices in copies or substantial portions. AGPLv3 has different conditions. Where section 13 applies, a modified version must offer its network users access to that version’s Corresponding Source at no charge. Neither means that any use of AI requires publishing the whole repository. MIT licence; AGPLv3, section 13.
Code checks help, but their limits matter. GitHub says Copilot code referencing uses an index of public GitHub repositories; private repositories and code outside GitHub are excluded, and the index is updated periodically. For inline suggestions, this check does not cover code the developer wrote or suggestions they subsequently altered. My conclusion for a contract review is that the absence of a reported match does not prove that no third-party rights exist. GitHub documentation on code referencing.
Will the provider defend an IP claim?
Some business contracts promise a defence against specified intellectual property claims and payment of specified resulting liabilities. This is an indemnity. Read it separately from the ownership clause, including who receives protection, which claims qualify, the exclusions and the claims process.
Anthropic’s Commercial Terms cover specified claims involving authorised paid use and resulting outputs. Its exclusions for modifications and combinations are linked to the extent to which the claim arises from those circumstances. That is different from saying any edit automatically removes all protection. The exclusions also apply to the extent a claim arises from practising a patented invention contained in an output. A customer warranty covering all intellectual property can therefore extend beyond the provider’s protection. Anthropic Commercial Terms, sections K.1–K.4.
OpenAI’s Service Terms provide output indemnities for the API and the Enterprise services defined in those terms. Their exclusions expressly address modified or combined output and use broader wording than Anthropic’s causal formulation. Do not assume every paid ChatGPT plan has the same protection. Beta services also have separate exclusions. OpenAI Service Terms, sections 1–3.
Features matter as well as plans. Anthropic’s service-specific terms, for example, exclude Beta Services from its indemnity. Anthropic Service Specific Terms, section B.
For a finished product, I would compare the actual development process with these conditions: what was submitted, changed and combined, and which features were used. A provider’s general statement about IP protection cannot answer whether a particular claim is covered.
What should the customer contract say?
Consider two different problems. A third-party developer alleges that the delivered product copies their code. Or the customer discovers that a component lacks the exclusive protection you promised and claims a breach of contract. Both concern rights, but the legal basis of the claims differs.
My contractual conclusion is that liability for your own ownership warranty should not be assumed to fall within the provider’s output infringement indemnity. The actual claim and wording decide the issue. The provider’s protection may also leave gaps in the promises you make about exclusivity, remedies or the customer’s own losses.
I would begin the negotiation by identifying what the customer needs to do with the software:
| Customer’s requirement | What the agreement needs to address |
|---|---|
| Own the bespoke development | Identify the work and copyright to be assigned, establish the supplier’s title, and specify when the transfer takes effect. |
| Use and maintain the whole product | Provide sufficient rights in retained supplier materials and check that third-party licences permit the intended use. Agree source access and handover. |
| Appoint another developer | Cover modification and maintenance by replacement providers, subject to the applicable component licences. |
| Keep a competitive feature exclusive | Identify what protection exists in the relevant markets and whether the promised exclusivity is achievable. |
For a SaaS subscription, ownership of the underlying code may not be the commercial objective. For bespoke development, the ability to modify and maintain the application may matter as much as the assignment. An exclusive product requires a closer look at which elements can actually be protected from copying.
As an illustrative structure, separate customer-specific work to be assigned, existing supplier materials to be licensed, and third-party components subject to their own terms. AI assistance is a fact about how material was made; it is not a single legal category that determines the rights in every component.
This does not make “owns or is licensed to use” a complete replacement warranty. A licence allowing the supplier to use a component might not permit the customer’s intended use, modification or distribution. The rights need to support the agreed delivery model.
Likewise, adding “if any” to an assignment does not solve the customer’s business problem. It may limit what transfers while leaving the customer without the protection it expected. Agree the required result and what happens if the available rights cannot support it.
Five checks before signing
- Identify the tool contract. Record the account holder, product, subscription, relevant terms and features used. Keep the version that applied to the work.
- Establish the human contribution and the supplier’s title. Use development records to identify relevant original work. Check employee and contractor arrangements as well as provider terms. My article on contractor-written code covers that part of the review under English law.
- Review third-party material. Examine dependencies, known copied fragments, relevant code matches, licences and required notices. Record unresolved issues and decide whether to obtain permission, comply with the licence or replace the component.
- Match the promises to the delivery. Distinguish assignment, licensing, permitted uses and exclusivity. Check any separate requirement to disclose, restrict or obtain approval for AI use.
- Agree how claims will be handled. Address defence, settlement control, obtaining a licence, replacement, correction, refunds and liability limits. Compare these promises with the protection actually available upstream.
The useful outcome is a short rights schedule, supporting documents and a list of gaps to resolve. That gives the business a basis for deciding what it can sign and gives the customer a clearer account of what it will receive.
Reviewing a software ownership clause?
I review code rights and software contracts, including the gap between a team’s development arrangements and its promises to a customer. Code rights review · Contact.
This article explains general principles and a practical review approach. The result for a particular product depends on its development, components, contracts and applicable law. Provider terms were checked on 2 October 2026; the contract governing your account may differ.