Owning the model you paid for

The question that surfaces it

The discovery almost never happens during the build. It happens at a renewal, in an acquisition data room, or on the morning someone decides to move the work to a second vendor. A buyer asks where the model is, and the answer arrives one layer at a time. The weights sit inside the vendor's cloud account. The labeled data lives in the vendor's annotation tool. The training code is in a private repository because it shares a library with three other clients. The evaluation set that produced the accuracy number in every steering-committee deck was assembled by a contractor nobody can now name. What the buyer holds is an endpoint, a monthly invoice, and a slide.

This is rarely dishonesty. It is the ordinary consequence of a contract that treated "the model" as a single object when a model engagement produces at least seven separable ones. Each of them travels under different law, sits in different physical custody, and moves only if a specific sentence moves it. A deliverables clause that says "all work product" and then defines work product as "the software described in Exhibit A" transfers whatever Exhibit A happens to list, and nothing else.

The base model. Almost every custom build starts from someone else's checkpoint. The terms attached to that checkpoint bind everything downstream of it, including your fine-tune.

The training and tuning data, with its labels. Frequently the most valuable and least protected asset in the engagement, because labeling happens inside a vendor platform and nobody asks for an export until the relationship is ending.

The pipeline code. Ingestion, cleaning, tokenization, the training loop, and the config that ties them together. This is what makes a result reproducible.

The weights. A full checkpoint, or an adapter measured in megabytes that is useless without the exact base checkpoint it was trained against.

The evaluation suite and the held-out set. The only artifact that can prove a rebuilt model is the same model, and the one most often built for a demo and never handed over.

The serving stack. Prompts, retrieval indexes, guardrail configurations, feature transformations, and the secrets that make the endpoint answer.

The documentation. Model card, data lineage, known failure modes, and the record of what was tried and rejected, which is worth more than it sounds when a second team inherits the work.

The default rule points away from the buyer

Paying for something does not create ownership of it. Under 17 U.S.C. § 101 a work made for hire is either a work prepared by an employee within the scope of employment, or a work "specially ordered or commissioned" that falls into one of nine enumerated categories and is covered by a signed written agreement calling it a work for hire. Those nine categories are 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, and an atlas. Computer software is not among them, and neither is anything that resembles a training pipeline.

The Supreme Court settled the employee question in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), holding that courts apply general common law agency principles to decide whether a hired party is an employee or an independent contractor. A sculptor who was commissioned, directed, and paid kept the copyright in his own sculpture. An outside AI vendor sits on the contractor side of that line in almost every arrangement a buyer would recognize.

Which leaves assignment, and assignment has its own formality. Section 204(a) provides that "a transfer of copyright ownership, other than by operation of law, 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." Verb tense matters here in a way that has decided real cases. In Board of Trustees of the Leland Stanford Junior University v. Roche Molecular Systems, 563 U.S. 776 (2011), the Court compared two agreements signed by the same researcher: one said he "agrees to assign," the other said he "will assign and does hereby assign." The promise to assign in the future lost to the present assignment. That case concerned patents and Bayh-Dole, but the drafting lesson transfers cleanly. A clause saying the vendor will assign on final payment leaves a window, and windows close badly.

The practical form is three sentences rather than one. A present assignment, in the words "hereby assigns," of the artifacts listed by name. A fallback license, effective if any assignment fails, that is perpetual, irrevocable, worldwide, royalty-free, and sublicensable. And a delivery obligation, because a right to something you have never received is a right to file a lawsuit.

Weights are a strange asset under U.S. law

Buyers often assume a weight file is protected the way source code is protected. The honest answer is that this is unsettled, and a contract should not lean on it.

The U.S. Copyright Office has published three parts of its report on copyright and artificial intelligence. Part 2, on copyrightability, was published on January 29, 2025, and concluded that existing law is adequate, that purely AI-generated material is not protected, and that "prompts do not alone provide sufficient control" to make a human the author of an output. Part 3, on generative AI training, was released in a pre-publication version on May 9, 2025.

Part 3 is the one that speaks to weights, and it speaks carefully. The Office observed that training "may result in model weights that contain copies of works in the training data," and that where a model can reproduce a training example without that expression being supplied in the prompt, "it must exist in some form in the model's weights." Its conclusion is narrower than either side wanted: "Whether a model's weights implicate the reproduction or derivative work rights turns on whether the model has retained or memorized substantial protectable expression from the work(s) at issue," and "copying the resulting weights will only infringe where there is substantial similarity." The report notes that courts have divided, contrasting rulings that treated a trained model as too transformed to carry copies against Andersen v. Stability AI, 744 F. Supp. 3d 956 (N.D. Cal. 2024), where claims proceeded against a party that had only downloaded and used an already-trained model.

All of that concerns whether other people's works survive inside your weights. The separate question, whether the weight file is itself an original work of authorship owned by whoever produced it, has no clean U.S. answer. So the instrument that actually protects a model in commercial practice is trade secret law plus possession. Under 18 U.S.C. § 1839(3), a trade secret covers technical information including "program devices, formulas, designs, prototypes, methods, techniques, processes, procedures, programs, or codes," but only where "the owner thereof has taken reasonable measures to keep such information secret" and the information "derives independent economic value" from not being generally known.

Read those two conditions as operational requirements rather than legal background. Reasonable measures presuppose that you hold the thing. A model you have never taken delivery of, stored under your own access controls, and inventoried is a model whose secrecy you are asserting on someone else's behalf.

Who holds what when nobody wrote it down

The table below is the working version of the argument. The middle column is the resting state of a typical custom build; the right column is what has to be true instead.

Artifact	Where it sits when the contract is silent	What makes it the buyer's
Base model	Licensed by a third party to whoever accepted the terms; the license, not your vendor, sets the outer limit	Model and version named in writing, license text attached, and the deployment cleared against it
Training and tuning data	With whoever collected and labeled it, usually inside the vendor's annotation platform	Delivery of raw and labeled sets, labeling guidelines, and the annotator agreements behind them
Pipeline code	The vendor, under the default contractor rule, unless a signed present assignment moves it	"Hereby assigns" language naming the repositories, plus a perpetual fallback license
Weights or adapter	The cloud account that ran the customization job	Export rights in the contract, an exported copy in your storage, and a rebuild you have run
Evaluation suite and held-out set	Often nowhere durable; built for a demo and never packaged	Named as a deliverable, with the held-out set, the scoring script, and the recorded baseline
Serving stack and secrets	The vendor's deployment repository and secret store	Infrastructure in your cloud organization, credentials issued to your identities

The upstream license rides along with the fine-tune

No vendor can grant more than it received. When a build starts from an open-weight checkpoint, the terms of that checkpoint follow the derivative, and buyers are frequently surprised by what those terms require.

The Llama 4 Community License is a clear example because its conditions are specific rather than atmospheric. It requires a separate license from Meta where, on the version release date, "the monthly active users of the products or services made available by or for Licensee, or Licensee's affiliates, is greater than 700 million monthly active users in the preceding calendar month." It requires that a licensee "prominently display 'Built with Llama' on a related website, user interface, blogpost, about page, or product documentation." And it requires that a distributed derivative model carry the word "Llama" at the beginning of its name. Using outputs to train or improve another model is permitted, subject to those same attribution and naming conditions.

Google's Gemma Terms of Use take a different shape. Google states that it "claims no rights in Outputs you generate using Gemma," which is helpful. The obligations attach to distribution instead: pass the use restrictions through to recipients, supply a copy of the terms, mark modified files with prominent notices, and include a notice stating that "Gemma is provided under and subject to the Gemma Terms of Use found at ai.google.dev/gemma/terms." A fine-tune is a model derivative, so the same obligations follow it.

Three questions settle this before a build starts. Which base model and which exact version. Which license version applies to that release, since terms change between model generations. And whether that license permits the deployment you actually intend: resale, sublicensing to your own customers, running on premises inside a customer network, or delivering under a government contract. Ask in writing and keep the answer with the contract, because the person who knows is the engineer who ran the job, and that engineer will move on.

Where the weights physically live

Managed customization services are the normal way a fine-tune gets built now, and their documentation is explicit about custody. Amazon's Bedrock documentation states plainly that "your custom models are managed and stored by AWS," and that when a customization job completes, the service writes "the resulting custom model artifacts in an S3 bucket controlled by AWS." Encryption defaults to an AWS-owned key, with an option to use a customer-managed KMS key. The same page carries a memorization warning worth reading twice: "fine-tuned models can replay some of the fine tuning data while generating completions." If the tuning data was confidential, that has contractual consequences.

None of that is a criticism of the platform. It is documented, it is ordinary, and it is a reasonable engineering tradeoff. The point is that ownership language and physical custody answer different questions. Where the artifact cannot be exported, "you own the model" resolves in practice to "you own the right to rebuild the model." That is a real right, and it is worth having, but it changes which deliverable matters. The asset becomes the recipe: the exact base checkpoint and version, the training and validation data, the hyperparameters, the random seeds, the code, the environment specification, and the evaluation suite that can prove the rebuild landed in the same place.

Buyers who understand this negotiate differently. They stop arguing about the word "own" and start listing files.

The clauses that quietly move value

Most ownership leakage in AI contracts happens in provisions that never mention models. These six do the most work, and they are worth reading against each other rather than one at a time.

• The improvements carve-out — a sentence reserving all improvements, enhancements and derivatives of vendor background technology. If the pipeline was built as a plugin to the vendor's framework, this can absorb the deliverable it sits inside.
• The aggregated-data license-back — a grant to use customer data in "aggregated and de-identified" form. Read what it authorizes rather than what it sounds like; the authorized use is frequently model training.
• Residuals — a right to use anything retained in the unaided memory of vendor personnel. Reasonable for general skill, corrosive when the residual is your labeling scheme.
• Feedback — a perpetual license to anything you tell the vendor about its product. In an annotation workflow, your corrections are feedback.
• Production-traffic training rights — permission to train on inference inputs and outputs. Separate this from the right to use logs for support and debugging, which is legitimate and narrower.
• Escrow limited to source — a release condition covering the repository only, which in a model engagement releases the least valuable third of the system.

It is worth knowing that the terms at the top of the stack have moved in the buyer's favor. Anthropic's commercial terms state that "Customer retains all rights to its Inputs, and owns its Outputs," and that Anthropic "may not train models on Customer Content from Services." Integrators building custom systems on top of those platforms have not uniformly followed, and in a custom build it is the integrator's paper that governs. Reading the foundation model provider's terms is not a substitute for reading the ones you are about to sign.

On a federal contract the default flips

Buyers who work on both sides find this reversal disorienting. In commercial work the builder keeps what is not expressly assigned. On a federal contract the funding source drives the license, and the government's share is set by clause rather than by negotiation from a blank page.

Under FAR 52.227-14, Rights in Data-General (May 2014), the government takes unlimited rights in data first produced in performance of the contract, with limited rights data and restricted computer software carved out under the clause's alternates. On the defense side, DFARS 252.227-7013 and 252.227-7014, both carrying an August 2025 revision date, split the outcome by who paid. Software developed exclusively with government funds carries unlimited rights. Software developed exclusively at private expense carries restricted rights. Mixed funding lands on government purpose rights, which DFARS 227.7103-5(b)(2) sets at a nominal five-year period, after which the government's rights become unlimited.

SBIR and STTR work sits in its own lane. DFARS 252.227-7018 (August 2025) gives the government limited rights in technical data and restricted rights in software during the SBIR/STTR data protection period, and DFARS 227.7104-2(a)(2) sets that period at twenty years after contract award unless the agency and contractor negotiate otherwise. When it expires, the clause provides that the government holds government purpose rights perpetually. Twenty years is one reason research-funded model work can stay commercially useful long after the award closes.

Two mechanical steps decide whether any of it applies. The first is marking. Under the same clause, data delivered "without restrictive markings shall be presumed to have been delivered with unlimited rights." A correct legend on the wrong file, or no legend at all, gives away the position the rest of the contract was written to protect. The second is pre-award assertion. DFARS 252.227-7017 (January 2025) requires an offeror to identify and assert restrictions with its offer, on a signed and dated attachment, and states that failure to submit, complete or sign it "may render the offer ineligible for award."

Patents follow their own track. Under the Bayh-Dole framework at 35 U.S.C. § 202(c)(4), a contractor that retains title to a subject invention grants the funding agency "a nonexclusive, nontransferrable, irrevocable, paid-up license to practice or have practiced for or on behalf of the United States any subject invention throughout the world." Section 202(c)(1) and (2) impose the disclosure obligation and a two-year window to elect to retain title, and missing either can hand the invention to the government.

One caution on citations for 2026. The Revolutionary FAR Overhaul is being implemented through agency deviation text alongside formal publication, and section numbering is moving in places. Confirm the deviation text your contracting activity is applying before quoting a number in correspondence. The substance described here has not changed: funding source drives the license, markings control, and assertions are made before award, not after.

Partners on a team inherit all of this through flow-downs. A subcontractor asserts its own restrictions and marks its own deliverables. Assuming the prime will protect a sub's private-expense position is a habit that gets discovered at delivery, when the correction is expensive.

The rebuild test

Every argument above collapses into one exercise, and the exercise is cheap while the relationship is still warm. Take the delivered artifacts to an environment the vendor has no access to. Install from the delivered environment specification. Run the pipeline against the delivered data. Score the result on the delivered evaluation suite. Compare it to the recorded baseline within a tolerance both parties agreed to in advance.

The failures are informative and they repeat. A tokenizer version that was never pinned. A data file that "will come over next week." A base checkpoint that turns out to be a variant no longer published. A license file that permits research use and not the deployment already in production. A pipeline step that reads a credential from an engineer's local environment. Every one of these is a small fix during performance and a project during a transition.

Make the rebuild a milestone with payment attached, run it once at midpoint and once at close, and record the result. A buyer who has done this owns the model in the only sense that matters operationally: it keeps working after the people who built it stop answering email.

What to write down

The following belongs in the agreement itself rather than in a statement of work that expires with the task order.

• A named artifact inventory covering weights or adapters, training and evaluation data with labels, pipeline code, environment specification, evaluation suite and held-out set, prompts and retrieval configuration, and documentation.
• A present assignment using "hereby assigns," not a promise to assign later or on final payment.
• A fallback license that is perpetual, irrevocable, worldwide, royalty-free and sublicensable, effective if any assignment fails for any reason.
• Delivery mechanics: the storage location you control, the format, the frequency, and acceptance tied to the rebuild test rather than to a demonstration.
• Base model disclosure: model, version, license version, and a representation that the license permits the intended deployment, including any resale or sublicensing.
• Data use limits stated as a closed list, with training on customer content, production traffic and feedback each addressed by name.
• A background-IP schedule listing what the vendor is bringing, so the improvements carve-out has a defined boundary instead of an open one.
• Transition assistance priced in advance, with a defined number of hours and a named point of contact, so the exit is not a negotiation held at the worst possible moment.
• Federal clause alignment where applicable: assertions listed before award, markings applied at delivery, and flow-downs matched between the prime agreement and the subcontract.

Bottom line

Ownership of a model is not a single legal fact. It is a set of separate holdings, several of which no statute grants by default, and one of which, the weight file itself, sits in a part of copyright law that has not been resolved. Commercial practice compensates with trade secret protection and possession, which makes custody and access controls ownership work rather than IT work. Federal practice compensates with clauses that assign rights by funding source and punish missing markings, which makes the paperwork the position. The same discipline serves both: name the artifacts, take delivery, assign in the present tense, check the upstream license against the real deployment, and rebuild the system once before anybody needs you to. A buyer who can rebuild has ownership. A buyer who can only cite a clause has a claim.

Frequently asked questions