Who owns the code you paid for

The default rule runs the opposite way from the intuition

Almost every buyer assumes that if they commissioned software and paid the invoice, they own it. Under US copyright law that assumption is usually wrong. The statute defines a “work made for hire” two ways: work prepared by an employee within the scope of employment, or work specially commissioned that falls into one of nine enumerated categories — and only then if both parties sign a written agreement saying so. The nine categories are a collective work contribution, part of a motion picture or audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, and an atlas. Software is not among them.

The practical consequence is blunt. When an independent contractor or an outside firm writes code for you and the agreement contains no express transfer of copyright, the copyright generally stays with them. You paid, they own. What you hold is typically an implied license to use what you commissioned — and the scope of an implied license is exactly the kind of question that becomes expensive when the two sides remember the conversation differently three years later.

The Supreme Court settled the employee-versus-contractor question in 1989, in a case about a sculpture, using ordinary agency-law factors: who controlled the manner of the work, who provided the tools, tax treatment, benefits, the right to assign other projects. A firm you engaged on a statement of work, that uses its own laptops and pays its own payroll taxes, is not your employee under that test, and no amount of day-to-day direction makes it one.

None of this is a problem. It is a fact pattern with a standard fix, and the fix is one clause. The problem is only ever that the clause is missing, or that it is drafted in the weaker of the two available forms.

Ownership is four questions, not one

A delivered system is never one thing owned by one party. It is four layers, each with a different default, and a contract that addresses only the first has addressed the easiest one.

The commissioned code. What was written for you, on your money, to your requirements. This is the layer everyone negotiates and the one you should own outright.

The vendor's background IP. The libraries, scaffolding, deployment tooling and internal frameworks the firm brought with them. Every competent firm has these, and their existence is why your project took four months instead of nine.

Third-party components. Open-source packages and commercial libraries. Nobody owns these; everybody licenses them, including you, on terms nobody negotiated with you.

Data and anything derived from it. Your raw data, the labels somebody paid to create, the embeddings, the fine-tuned weights, the evaluation set. This is the layer that is newest, most valuable, and most often unmentioned in contracts written from a template that predates it.

Layer	Default if the contract is silent	What to ask for
Code written for you	Vendor holds copyright; you likely have an implied license of contested scope	Present-tense assignment of all right, title and interest, effective on payment
Vendor background IP	Vendor owns it, and reasonably so	Perpetual, irrevocable, worldwide, royalty-free, sublicensable license to use and modify it as delivered
Open-source components	Governed by each package's own license, which binds you directly	A component inventory with licenses, and a warranty that no license conflicts with how you will ship
Your data	Usually yours, but vendor terms of service may claim broad usage rights	Explicit ownership, no training on your data without written consent, deletion on termination
Models, weights, embeddings	Frequently unaddressed, which is the worst outcome	Named as deliverables, with the artifacts and the procedure to reproduce them
Labels and evaluation sets	Often treated as vendor working papers	Yours, delivered in an open format, with the labeling guidelines

Two words decide whether the assignment worked

This is the highest-value paragraph here. There is a long-settled distinction in US intellectual property practice between an agreement that says a party “agrees to assign” and one that says a party “hereby assigns.” The first is a promise to do something in the future — it creates, at most, an obligation and an equitable interest. The second is a present transfer that operates on its own terms as the work comes into existence.

The difference is not academic. The Supreme Court's 2011 decision in the Stanford v. Roche patent dispute turned on exactly this: an inventor had signed an agreement promising to assign to his university, then later signed one that presently assigned to a company. The later present assignment won, despite being second in time, because the earlier promise had never actually moved anything. That case is about patents, but the drafting lesson carries into copyright practice, and it is why competent IP counsel writes hereby assigns and never agrees to assign.

Three companions to that clause are worth insisting on. A further assurances obligation, so the vendor is contractually required to sign registration paperwork later without renegotiating. A waiver of moral rights where the jurisdiction recognizes them, which matters if you have contributors outside the US. And a clean statement that assignment is effective upon payment — that condition is normal, fair to both sides, and a vendor asking for it is not being difficult.

One more thing that gets missed on both sides: the vendor's own subcontractors and contract staff have the same default as the vendor does. If your firm assigned you rights it never obtained from the freelancer who wrote the reporting module, the chain has a hole in it, and that hole is exactly what an acquirer's diligence checklist is built to find. Ask for a flow-down warranty that every contributor has assigned their rights upstream.

Background IP is not a trick, and total assignment is a bad ask

The instinct when a vendor says “that part is our framework” is to demand it be assigned along with everything else. Resist that instinct, because winning it is usually worse for you than losing it.

If a firm assigns you its internal framework outright, one of three things happens. They price the loss of a reusable asset into your quote, and you pay for it. They refuse, and you lose a good vendor. Or they agree, and you become the sole owner of an unmaintained library that the only people who understand it are now contractually barred from improving for anyone else — which means they stop improving it at all, and you inherit maintenance of a general-purpose tool you did not want.

What you actually need is not ownership. It is the certainty that nobody can ever switch off your system or hold it hostage. A perpetual, irrevocable, worldwide, royalty-free, transferable and sublicensable license to use, modify and create derivative works from the background IP as embedded in the deliverable gives you all of that. Transferable matters more than it looks: if you sell the company, the license must go with it, and an acquirer's counsel will check.

The one thing to insist on is that background IP is identified in writing before delivery, not asserted afterward. A schedule listing what the vendor considers pre-existing, updated at each milestone, costs nothing during the project. Without it, the boundary between “yours” and “ours” is settled after the relationship has ended, which is the worst time to settle anything.

Open source is where the actual surprises live

Your system contains code nobody in the room wrote, under licenses nobody in the room negotiated. Most of it is permissive and boring — MIT, BSD, Apache 2.0 — requiring attribution and little else. A minority is not, and the difference only bites under specific conditions.

The condition that matters is distribution. Strong copyleft licenses in the GPL family attach obligations when you convey the software to someone else; a purely internal tool typically never triggers them. The network variants change that calculation, because making the software available to users over a network can itself trigger the obligation to offer source. If your plan is an internal application, most of this is theoretical. If your plan is to ship a binary, an appliance, a mobile app, or an embedded device, it is not theoretical at all, and the time to know is before the code is written.

The ask is small: a component inventory, generated automatically, listing every dependency and its license, delivered with each release. Scanning tools produce this in minutes and cost nothing meaningful. Pair it with a vendor warranty that no included component's license is incompatible with the distribution model stated in the contract — and make sure that distribution model is actually written in the contract, because a warranty against an unstated plan protects nobody.

The layer most contracts still do not mention

If there is a model anywhere in the system, three artifacts decide whether you can keep operating without the vendor: the trained weights or adapter files, the training and evaluation data with its labels, and the procedure that turns the second into the first. Owning the code and none of these means owning a car with no engine.

Weights and adapters. Name them as deliverables, in a standard format, at each release. A fine-tuned model that lives only in the vendor's account is not something you own in any practical sense.

Labels and evaluation sets. Frequently the most expensive artifact in the whole project, because a human being was paid per item to create it, and frequently treated as vendor working papers. Ask for the labels, the labeling guidelines, and the inter-annotator agreement if it was measured. Your evaluation set is also the only thing that will ever let you compare a replacement vendor's work to the incumbent's.

The reproduction procedure. Weights without the pipeline that produced them are a dead end at the first retrain.

Then read the usage terms — the vendor's, and those of every model provider underneath them. Terms permitting a provider to use submitted content to improve their services are common, are sometimes on by default, and are frequently switchable. Whether that matters depends entirely on what your data is. Deciding it deliberately takes twenty minutes. Discovering it during a customer's security review takes considerably longer.

Escrow is mostly theater, and there is a better version

Source code escrow — a third party holds the source, releasing it if the vendor goes bankrupt — is a familiar comfort with a specific weakness: what gets deposited is usually a source archive, and a source archive is not a running system. No credentials, no infrastructure definitions, no build pipeline, no seed data, and a deposit that is often a year stale by the time anyone reaches for it.

The version that works costs less and is available continuously: the source lives in your repository from the first commit, the build runs in your accounts, and infrastructure is defined as code alongside it. Then you do not need a trigger event, because you already have everything on the day you need it rather than ninety days after a bankruptcy filing. Where a customer or regulator specifically requires escrow, deposit the whole environment and verify a release annually. An unverified escrow is a receipt, not a plan.

The mistakes we see in signed contracts

• “All work is work made for hire” and nothing else — which, for software by a contractor, may transfer nothing
• “Contractor agrees to assign” where “hereby assigns” was one word away
• No background IP schedule, so the boundary is drawn after the relationship ends
• Assignment from the firm but not from its subcontractors, leaving a hole in the chain
• Silence on models, weights, embeddings and labels in a contract that is entirely about an AI system
• No component inventory, so the license position is unknown until a customer asks
• Escrow instead of possession, unverified, and stale by construction
• No further-assurances clause, so any later filing needs goodwill you may not have

If you already signed something silent

Start by reading what you have rather than assuming the worst. Many agreements contain a serviceable assignment buried in a general terms section, and plenty of vendors will confirm intent in writing without drama, because it costs them nothing and they would like the next project. A short, friendly clarifying amendment during a good relationship is the cheapest fix available and it is available today.

If the vendor will not confirm, you are probably operating under an implied license, which usually covers using the software for its intended purpose but is a genuinely contested question when it comes to modifying it, handing it to a competing firm, or selling the business that depends on it. Get counsel to look at the actual document. Then use the natural openings: a renewal, a new statement of work, a support agreement. Ownership language is far easier to add to the front of the next engagement than to the back of the last one.

Before you sign

• The agreement says “hereby assigns,” not “agrees to assign”
• Assignment is effective on payment, and further assurances are required
• Every contributor, including subcontractors, has assigned rights upstream
• Background IP is listed in a schedule, updated at each milestone
• You have a perpetual, irrevocable, transferable license to that background IP
• A component inventory with licenses ships with every release
• The distribution model is stated, and warranted compatible with those licenses
• Your data is yours, with no training use absent written consent
• Weights, labels, evaluation sets and the reproduction procedure are named deliverables
• Source lives in your repository from the first commit, not in an escrow account

Bottom line

The rule to carry away is that payment does not transfer copyright in the United States, that the transfer is one clause, and that the clause has a strong form and a weak form separated by two words. Everything else is scope: what the vendor brought with them, what the internet contributed, and what your own data produced. Ask for outright ownership of the code, a broad and transferable license to the rest, an inventory of the components, and explicit naming of the model artifacts. Most good firms will agree to all of it in an afternoon, because they have been asked before. The ones who will not have told you something useful for free.

Frequently asked questions