# Who Owns the Code When You Outsource Development?

> By default the contractor owns the copyright in outsourced code — not you. The written assignment, AI ownership clauses, and account structure that fix it.

_Source: https://plenaura.com/blog/who-owns-the-code-outsourcing-development · Last updated: 2026-06-03 · Plenaura_

_By Plenaura Research · Published 2026-06-11 · 10 min read · AI Strategy_

Who owns the code when you outsource software development? By default, the developer does — not you. Under US copyright law, code written by an independent contractor or outside agency belongs to the contractor from the moment it is written, unless your contract contains a written assignment transferring the copyright to you. Paying for the work does not transfer ownership. Neither does an invoice marked paid in full, or the fact that the whole thing was your idea.

If your agreement is silent on intellectual property, the most you can usually claim is an implied license to use the code for the purpose it was built for — a far weaker position than ownership. You may not be free to modify it, build on it, or stop the contractor from reusing it for someone else. The fix has two parts: a properly drafted assignment clause, and an account structure that keeps the code in your hands continuously. This article walks through both, including the AI-specific artifacts — model weights, prompts, evaluation suites — that most generic contract advice never mentions.

The stakes are not small. According to Clutch.co's AI pricing guide, the average AI development project reviewed on the platform cost roughly $120,595 — a six-figure asset. Few buyers would spend that on equipment without confirming the title is in their name, yet companies sign software contracts with ambiguous ownership terms every day, usually assuming the law protects them. It does not.

## Who owns outsourced code by default?

US copyright law answers this question plainly: copyright vests initially in the author of the work. When the author is an independent contractor — a freelancer, an agency, an offshore development firm — the contractor is the initial owner of the code they write. If an agency's employees write the code, the agency owns it, because employers own what employees create within the scope of their jobs. In neither case does the paying client own it automatically.

Getting ownership transferred to you requires more than goodwill. Under Section 204(a) of the US Copyright Act, a transfer of copyright ownership is not valid unless it is in writing and signed by the owner of the rights. A handshake does not transfer copyright; neither does a friendly email, nor payment in full. Without that signed writing, courts will generally find at most an implied, nonexclusive license: permission to use the code for the purpose both sides understood at the time.

An implied license is better than nothing, but its boundaries are fuzzy and it leaves the contractor holding real power: they can reuse your code for other clients, including your competitors, and object if you take the code somewhere they did not anticipate. And if you ever sell your company, an acquirer's lawyers will flag the unowned codebase in diligence — expensive to fix years later, nearly free to prevent up front.

## Doesn't "work made for hire" cover software?

The phrase "work made for hire" causes more false confidence than any other term in software contracting. Most buyers assume it means anything you pay someone to create. The actual definition, in Section 101 of the US Copyright Act (17 U.S.C. §101), is much narrower. A work qualifies as a work made for hire in exactly two situations: first, a work prepared by an employee within the scope of his or her employment; second, a specially ordered or commissioned work that falls into one of nine enumerated categories — a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas — and only if both parties expressly agree in a signed writing that the work is made for hire.

Read that list again: custom software is not on it. Outsourced code generally fits none of the nine categories, so the work-made-for-hire doctrine usually cannot apply to contractor-written software at all — no matter what the contract says. A contract whose only ownership language is "all work shall be considered a work made for hire" can fail completely, because it invokes a doctrine that does not cover the thing being built.

Lawyers who draft software agreements know this, which is why well-drafted contracts use belt-and-suspenders language: the work is deemed a work made for hire to the extent the law allows, and to the extent it is not, the contractor assigns all rights to the client. The assignment does the real work. A contract with work-for-hire language but no assignment sounds protective and may protect nothing.

## What does a proper IP assignment actually say?

A real assignment clause is a few paragraphs of standard language that any competent vendor will sign without drama — and reluctance to sign it is itself useful information. In plain English, here is what the clause needs to contain.

- Present-tense assignment language: the vendor "hereby assigns" all rights, not "agrees to assign" them later. A future promise may require a second document that never gets signed — and the wording difference proved decisive in the US Supreme Court's Stanford v. Roche decision in 2011.
- Work product defined broadly: source code, documentation, designs, database schemas, scripts, configuration — everything produced under the agreement, not just "the software."
- Background IP carved out and licensed: pre-existing tools and libraries the vendor brings should be identified in writing and licensed to you perpetually, irrevocably, and royalty-free, so the system you own can legally run without the pieces you don't.
- Subcontractor flow-down: the vendor needs written assignments from every employee, freelancer, and subcontractor who touches the code. It cannot assign to you rights it never collected from the people doing the work.
- A further-assurances clause: the vendor commits to signing any additional paperwork needed later — copyright registrations, confirmatory assignments — to perfect your ownership.

> **INFO:** This article is general information about how US copyright law treats outsourced software, not legal advice. How these rules apply depends on your facts and your contract's wording — have a lawyer review your agreement before you sign.

## What about AI: who owns the models, weights, and prompts?

Standard assignment clauses were drafted for a world where the deliverable was code. AI projects produce a second category of valuable artifacts that may not read as deliverables at all: model weights fine-tuned on your data, prompt libraries refined over months of iteration, evaluation suites that encode what "good" means for your business, and the pipeline configuration that turns raw data into a working system. If the contract does not name these explicitly, a vendor can argue they are methodology, tooling, or background IP — and walk away with them.

The fine-tuned model is the sharpest example. A model trained on your documents, your customer interactions, or your operational data encodes your institutional knowledge in its weights. If the vendor keeps those weights, you keep the outputs and they keep the intelligence. Worse, whether model weights are even protectable under copyright is genuinely unsettled law — exactly why you should not rely on legal defaults here. When the law is unclear, the contract has to do all the work: name the weights, prompts, eval suites, training-data derivatives, and pipeline config as deliverables assigned to you, or licensed to you irrevocably where assignment is not possible.

Contract ownership is also only one layer. A vendor can assign you every artifact on paper and still keep you operationally dependent — on their platform, their hosting, their proprietary glue. That dependency layer deserves its own scrutiny; our vendor lock-in checklist covers it. The short version: ownership on paper and independence in practice are different tests, and you want to pass both.

## Can you actually enforce a US contract against an overseas vendor?

Here is the honest answer most articles avoid: cross-border enforcement is slow, expensive, and often impractical. The question matters because outsourcing economics push much of the work overseas — most AI development companies listed on Clutch charge $25 to $49 per hour, according to Clutch.co's pricing data, a fraction of typical US agency rates. If your vendor has no US assets, winning a judgment in a US court is only step one. The United States has no treaty in force making its court judgments automatically enforceable in most other countries, so you would then need a court in the vendor's home jurisdiction to recognize and enforce the judgment under local rules — a process that can take years and routinely costs more than the project did.

Some contractual choices genuinely help on paper. US governing law and a US forum keep the first round of a dispute on familiar ground. An arbitration clause helps more: foreign arbitral awards are enforceable under the New York Convention across more than 170 countries, making them far more portable than court judgments. In a cross-border development agreement, arbitration is usually the more enforceable choice.

But notice what these options share: they are ways of winning a fight, and the fight itself is the loss. For a project in the low six figures, spending years and a comparable sum on cross-border proceedings rarely makes sense — and sophisticated vendors know it. That does not make contracts worthless; the assignment clause defines what you own. It means you should structure the engagement so you never need to enforce anything. You want ownership that does not require winning a lawsuit.

## What protects your ownership without going to court?

Structural protections put the assets in your possession continuously, so a dispute would find you already holding everything the contract says you own. None of this is paranoia — it is ordinary hygiene for a mainstream business practice. According to Deloitte's 2024 Global Outsourcing Survey, skilled talent and agility have joined cost reduction as the key drivers of outsourcing; access to specialized expertise now rivals cost as a primary reason companies outsource at all. For a practice this central to how software gets built, the mechanics below are table stakes, not exceptional caution.

- Code committed to your GitHub organization from day one: the vendor works as a contributor inside repositories your company owns. The latest code is always already yours, and offboarding a vendor is a permissions change, not a negotiation.
- Infrastructure in your cloud accounts: AWS, Google Cloud, or Azure accounts opened in your company's name, on your billing. The running system should never live somewhere you can be locked out of.
- Credentials, domains, and third-party accounts in your name: domain registrations, API keys, secrets, and SaaS accounts belong to your organization, with the vendor granted scoped access — not the other way around.
- Continuous delivery instead of a big-bang handoff: code merges into your repositories weekly or continuously. There is no final "delivery" moment to hold hostage, because delivery already happened, every week.
- Documentation as a contracted deliverable: architecture overviews, runbooks, environment setup, and model documentation, written into the statement of work. Code you cannot operate is ownership in name only.

Each item removes a failure mode no contract clause can fully patch. When the code already sits in your repositories and the system already runs in your cloud accounts, ownership stops being something you would have to prove and becomes something you simply have. The contract defines your rights; the account structure makes them self-executing.

## What should you ask a development partner before signing?

These questions fit in one email, and how a vendor answers them tells you nearly everything. A partner with clean terms answers each with an unqualified yes; hedging or "our standard terms handle that" without specifics is a signal worth taking seriously.

1. Does your contract contain a present-tense written assignment of all intellectual property in the deliverables to us — "hereby assigns," not "agrees to assign"?
2. Will all development happen in our GitHub organization and our cloud accounts from the first week, with continuous delivery rather than a final handoff?
3. Are fine-tuned model weights, prompts, evaluation suites, training data derivatives, and pipeline configuration explicitly named as deliverables we own?
4. Is any background IP you retain identified in writing, with a perpetual, irrevocable, royalty-free license to us?
5. Will anything in the system require a license fee, a subscription to you, or your ongoing participation to keep running after the engagement ends?
6. Do your agreements with employees and subcontractors assign their rights to you, so those rights can be assigned through to us?

## The bottom line

Ownership of outsourced code is not a default you can assume; it is a contract clause plus an account structure. The clause is a present-tense assignment covering everything the project produces, including the AI artifacts — weights, prompts, evals, pipelines — that generic templates miss. The account structure is your repositories, your cloud, your credentials, and continuous delivery, so what you own on paper is what you hold in practice. Neither costs much to ask for before signing. Both are painful to retrofit after a relationship sours.

These are Plenaura's standing terms, not concessions you would need to negotiate: a written assignment of 100% of the IP in everything we build, all work in your GitHub organization and your cloud accounts from day one, and no license or dependency on us required to keep anything running after handover. Scope and price are fixed and agreed up front, so the contract you sign is the contract you get. If you are evaluating development partners — us or anyone else — take the six questions above into every conversation. And if you want to see what clean ownership terms look like on a real project, talk to Plenaura: a short scoping call ends with a fixed scope, a fixed price, and every ownership commitment in this article in writing.