Who owns the code when outsourcing development: 2026 checklist

TL;DR

Who owns the code when outsourcing software development in 2026 is settled by a document, and by default that document is not your invoice. Under section 101 of the US Copyright Act, a commissioned work counts as work made for hire in only nine categories, and software is not one of them. Without a signed written assignment, the copyright stays with whoever typed the code. The checklist below turns that into twelve controls you can verify before signing.

• A present-tense assignment ("hereby assigns") that takes effect as each commit is written, not on final payment or final acceptance.
• A repository under your organization account from the first commit, with the vendor's engineers as collaborators you can remove.
• A written inventory of what the assignment does not cover: the vendor's pre-existing tools, open source components, and code an AI tool generated.
• Escrow only where the vendor hosts the product or holds the only build that works.

Paying for code does not buy it

The money settles who owes whom. It says nothing about who owns what.

Gartner forecast worldwide IT services spending at $1.570 trillion for 2026, up 5.3% on the prior year. A large share of it is custom development bought on templates whose ownership clause nobody read.

The default rule is public. Under section 101 of the US Copyright Act, a work made for hire is either the work of an employee within the scope of employment, or a commissioned work in one of nine listed categories: a contribution to a collective work, part of a motion picture, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas. Software is absent from the list. The Copyright Office is blunt about the consequence: "If a work fails to satisfy any of these requirements, it is not a work made for hire."

So the label "work-for-hire" does less than you think. What moves ownership is an assignment, and section 204 says a transfer of copyright ownership "is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed."

Outside the US the shape is the same. The UK's Copyright, Designs and Patents Act makes the author the first owner and carves out only employees. The EU Software Directive gives an employer the economic rights in a program written by an employee, "unless otherwise provided by contract", and says nothing about a client who commissioned it. Everywhere you are likely to sign, the commissioned case is left to the contract.

The 2026 ruling that made part of your codebase unownable

On March 2, 2026 the US Supreme Court declined to hear Thaler v. Perlmutter, docket 25-449. That left standing the D.C. Circuit's holding that copyright requires a human author. An AI system cannot be one.

Your vendor's engineers use AI assistants, whether or not the proposal says so. The Copyright Office concluded in January 2025 that "prompts alone do not provide sufficient human control to make users of an AI system the authors of the output." Code produced that way has no copyright owner, and an assignment cannot transfer what nobody owns. A clause that "assigns all code" quietly assigns less than the whole codebase.

The same report keeps the door open: human authors hold copyright in "the creative selection, coordination, or arrangement of material in the outputs, or creative modifications of the outputs." Reviewed and reworked AI output can be yours. Raw output pasted in cannot. The contractual answer is a disclosure duty plus a review duty, in the same clause as the assignment.

How we built this checklist

Four rules, applied to every item below.

• It fails a real contract. Each control corresponds to a clause we have seen missing or drafted wrong in agreements clients brought us to review.
• It can be verified before money moves, in the draft, in a repository setting or in an account screen.
• It has a legal or documentary source you can read yourself. Opinions are labeled as opinions.
• Where our own data appears, a pattern counts only when it shows up in at least three statements from two independent sources. Anything thinner is not published.

One disclosure. Mercury Development sells outsourced development, so every control here is one a client should apply to us. The wider list of things to ask before signing sits in our 15 questions for a development agency; this article goes deep on the three of them that cover ownership.

The ownership checklist at a glance

The contract: an assignment that takes effect on creation

The clause is short. The mistakes are shorter.

1. Ask for a present assignment, in the present tense

In Stanford v. Roche the Federal Circuit read "agree to assign" as a promise to transfer later and "do hereby assign" as a transfer already made, and the Supreme Court left that reading in place in 2011. The case was about a patent; the drafting lesson carried over to copyright whole. Allen sets out the operative words as "agrees to assign, and hereby does assign". A vendor who resists the second half is telling you when they intend the transfer to happen: later, on their terms.

2. Make the assignment take effect as the code is written

Templates transfer ownership on final acceptance or final payment. Both dates are wrong. A project that stalls in month seven leaves you with invoices and no copyright; a dispute over the last invoice leaves the vendor holding your product as leverage. Ask for an assignment that attaches to each deliverable as it is created. The vendor's protection against non-payment is a payment clause, and it does not need to be your copyright.

3. Add the boring sentences

Two of them. A waiver of moral rights, which in many jurisdictions cannot be assigned but can be waived, so nobody can later object to how the code is modified. And a further assurances clause: the vendor signs whatever confirmatory documents you need later, at your request, without a new negotiation. Both are standard. Both are absent from most agency templates.

4. Check that the chain reaches the person who typed

Your contract is with a company. The company's rights depend on its own agreements with its engineers and subcontractors. Under the Copyright Office rules for commissioned work, the written agreement must be with the "individual(s) who actually created the work" and "must be signed by all parties." Ask the vendor to warrant that every person who touches the code has signed an assignment to the vendor, and to name subcontractors before they start. A gap anywhere in that chain is a gap in your title.

The repository: your account from the first commit

A clause proves you own the copyright. A repository proves you have the code. You need both, and the second is easier to check.

5. The repository belongs to your organization account

Create the organization, create the repository, invite the vendor. Not the other way round. If the vendor creates the repository, you are a guest in their house, and moving out depends on their cooperation. GitHub transfers a repository with its issues, pull requests, wiki, stars and watchers, but only the current owner can start the transfer, and a repository "forked from a private upstream network cannot be transferred" as a single unit at all.

6. Vendor engineers are collaborators you can remove

Grant the vendor's people write access, never the admin rights that let them transfer or delete the repository. When someone rolls off, remove them the same day. GitHub deletes an outside collaborator's forks of private repositories on removal, but notes that "the person will still retain any local clones of your repository" and that you are "responsible for ensuring that people who have lost access to a repository delete any confidential information or intellectual property." The access list is a control; the confidentiality clause covers what it cannot.

7. Commits land daily, and a mirror you control catches every merge

Milestone deliveries as archives are a red flag, whatever the contract says: work is happening in the vendor's repository and you receive a snapshot when they choose. Require day-to-day work in your repository, plus a mirror in a second account you own, updated on every merge. If the relationship ends on a Friday afternoon, the mirror is what you build from on Monday.

8. The build runs without the vendor's account

Code that only builds in the vendor's CI is code you half own. Put the pipeline, the package registry and the secrets store in accounts you pay for, and run one build from a clean machine before the first milestone is accepted. The same logic covers store accounts and signing keys, and the account-by-account version of that list sits in our vendor continuity plan.

What the assignment cannot cover

Every codebase contains code the vendor never owned and so cannot assign. Good contracts say so. Bad ones pretend the whole thing is yours.

9. Background IP is listed, then licensed

Vendors reuse their own libraries and deployment scripts across clients, and they should. What you need is a schedule that names each component, plus a perpetual, irrevocable, royalty-free license to use, modify and sublicense it inside your product. An exclusion for "vendor tools" without a list is an exclusion for whatever the vendor later decides to call a tool.

10. Open source components carry their own terms

Your assignment covers the code the vendor wrote. It does not touch the packages the vendor pulled in, each under its own license, some with duties on distribution. Ask for a dependency inventory with license per component as a deliverable, and a rule for which license families need your written approval. Nobody should discover the license on the payments module during due diligence for a funding round.

11. AI output is disclosed and reviewed

Ask three things in writing. Which tools are in the pipeline and at which license tier, because some tiers train on what your team submits. That every generated block is reviewed and reworked by a named engineer before merge, which is what turns unownable output into a human-authored work. And that the vendor does not warrant title to anything it cannot own, because a warranty nobody can honor is a lawsuit you will lose.

Escrow, and the cases where it earns its fee

Escrow is a three-way agreement: you, the vendor and a neutral agent who holds the source and releases it on a named event.

12. Escrow where the vendor hosts, a repository everywhere else

The standard release events at Escode, the NCC Group escrow business, are bankruptcy, administration and breach of maintenance. Deposit frequency is negotiated, anywhere from daily to yearly, and verification that the deposit actually rebuilds is a separate service to agree and pay for. Codekeeper puts agents at $89 a month for Software-Escrow.com, $179 for its own plans, $275 for Escrow London and $375 for PRAXIS, with verification an additional fee at Escode and Escrow London.

Opinion: if items 5 through 8 are in place, escrow duplicates what you already hold. It earns its fee in two cases. The vendor hosts the product as a service and you never see the source in normal operation. Or the product includes firmware or a build environment that cannot be reproduced from the repository alone. In both, insist on the verification tier. An unverified deposit is a zip file with a legal opinion attached.

Which controls matter for your situation

Twelve controls is a long negotiation. Sequence them by what you lose first.

First build with no technical staff of your own: items 1, 2 and 5. Both cost nothing at signature and months in a dispute.

Rescue after a failed vendor: items 5 through 8, applied to the code you have today, before the new contract. If your previous vendor holds the repository, the first deliverable is a transfer, not a roadmap. The continuity plan has the account-by-account drill.

Product with a long life ahead of it: items 9 through 11. Background IP, open source and AI output are where a clean-looking assignment leaks, and all three surface in a buyer's or investor's due diligence.

Vendor-hosted product: item 12, with verification, and a data return clause beside it.

What public buyer discussions show

These are our own observations, from public sources. In 2026 we analyzed 9,246 statements from buyer discussions on Hacker News, Reddit and Capterra, filtered them to 261 signals from large-ticket contexts ($50,000 or more in spend, or an explicit enterprise, franchise or multi-location marker) and kept 40 patterns that appeared in at least three statements from two independent sources.

Ownership did not surface as a pattern of its own. It surfaces as a precondition inside other discussions: a buyer describing an in-house team built "to essentially increase ownership and remove reliance on external vendors", a buyer noting that a switch was possible because "we owned the code because it was a bespoke solution from the start", and a founder stating the requirement in one breath, "it has to be completely owned, we own the code, we own everything."

The advice buyers give each other matches the checklist above almost line by line. One warns that nothing moves "unless you have a written contract specifically assigning you the copyright." Another tells a founder to "make sure the work-for-hire contract puts the code in a repo under your account from the first commit." A third frames the test in plain terms: "make sure the code is yours legally and you can bring it to another shop whenever you want." The failure they describe is the one they fear most, an "offshore agency resold your proprietary code."

The finding is uncomfortable for vendors. Buyers do not ask whether they will own the code. They assume it, and discover otherwise after the relationship has gone wrong.

Ownership is a state of your accounts, not a paragraph

Opinion, stated plainly. The contract decides who wins a dispute. The accounts decide whether there is a dispute at all.

A vendor who holds the repository, the CI and the store accounts has leverage in every conversation about scope and price, whatever the IP clause says. A vendor invited into your repository on day one and removable on day two has none. Most vendors accept the second arrangement without argument, because it costs them nothing. The ones who argue are showing you something useful.

A perfect assignment with the repository in the vendor's name is a lawsuit you might win. A repository in your name with a weak assignment is a title problem one confirmatory document fixes. Get the accounts first, then the paragraph, and never sign a template that contradicts what the accounts already say.

Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The assignment, repository and escrow terms this checklist tests are the ones he negotiates into the firm's own contracts.

Your contract is on the table? Have us redline the ownership terms first

Send us the draft, or tell us what the vendor has proposed and where the repository sits today. We come back in writing with the clauses we would change, the account moves to make before signing and the items on this list your situation can skip.