Full-stack intellectual property ownership is a project objective: holding the rights and access needed to build, run, maintain, and transfer the actual system. It is not a legal category, and no single instrument delivers it.
Four questions get collapsed into one. Who possesses the asset. Who owns rights in it. Who is licensed to perform which acts. And who can practically operate or rebuild it. A buyer can hold all the files, own all the copyright, and still be unable to run the system.
Possession is not ownership
US copyright law distinguishes ownership of a copyright from ownership of the material object in which the work is embodied, and transfer of the object alone does not convey the copyright.
Delivery of a repository is therefore evidence about possession. The assignment is a separate act, and section 204 requires a signed writing for a transfer of copyright ownership other than by operation of law.
Work made for hire is narrower than the phrase
Work made for hire is a specific US statutory concept covering work prepared by an employee within the scope of employment, or a specially commissioned work that falls within one of the enumerated categories and is subject to an express signed agreement.
Paying for a commissioned work does not satisfy this. Nor does writing the words into the contract. A commissioning agreement that labels all contractor output work made for hire has made a claim that either meets the statutory criteria or does not, and the label carries no weight either way.
Jurisdiction changes the starting point. Canadian law begins from author ownership with a qualified employment exception, permits whole or partial assignments subject to signed-writing requirements, and does not contain the same enumerated commissioned-work categories.
Two further provisions constrain drafting. US section 203 permits termination of certain author grants under specified conditions and excludes works made for hire from that provision — so the classification has consequences long after signature. And Canadian moral rights are non-assignable, waivable, and expressly not waived by a copyright assignment.
Licence-back is a second transaction
Assignment moves rights to the customer. Licence-back returns defined permissions to the supplier, so it can reuse components across engagements.
These are separate deals and need separate terms: the rights holder, the permitted acts, the recipient, the duration, what happens on termination, the access required to exercise the licence, and any third-party restrictions. Customer-confidential material is the standard exclusion from the reuse scope, and excluding it is not automatic.
The inventory that actually matters
Rights attach asset by asset, and the assets are not just code.
Application and infrastructure code needs creators identified, employment or assignment evidence, dependency licences, and build access. Prompts and configuration need provenance, permitted reuse, and their runtime dependencies. Fine-tunes or weights, where they exist at all, need base-model rights, permitted modification and distribution, export availability, and an inference environment. Evaluation data and reference answers need source permissions, contributor rights, and recipient use terms. Embeddings and transformed corpora need source restrictions and rebuild dependencies. Logs need custody, authorised use, and retention terms. Third-party services need the subscription holder, continuation terms, transfer consent, and a replacement route.
The gap this exposes is the usual one. A buyer receives its application code and a clean assignment of the supplier’s rights in that code, and operation still requires a separate model service and a licensed evaluation corpus. Code delivery was not operational independence, and the inventory says so before the handover rather than after.
Escrow, and what it cannot hold
Escrow preserves access when the supplier cannot provide agreed support. Procurement guidance treats it as a tailored arrangement rather than an automatic inclusion, covering release events, deposit updates, validation, version control, and cost, and identifying cases it considers unsuitable.
For an AI system the deposit has a hole in it. A deposit containing application source and prompts, where the application depends on a hosted model that is no longer available, does not restore the original behaviour on release. The recovery trial establishes that, and the honest response is to record the limit and test an authorised substitute against agreed questions rather than treat the deposit as proof of continuity.
So an escrow schedule names the depositor, beneficiary, agent, covered versions, update trigger, release conditions, verification depth, permitted post-release acts, and funding — and acceptance records what an operator actually recovered, plus what remained unresolved.
The rule
What stays fixed is that each asset is assessed on all four questions. What changes is which question fails, and it is seldom ownership: the recurring failure is a dependency that cannot be assigned, exported, or replaced under present terms.
Not to be confused with
A paid invoice. Payment evidences a transaction. It does not resolve rights, and treating a delivered file or a settled invoice as their resolution is how unresolved rights reach the receiving team unrecorded.
A determination. Which law governs initial ownership, whether every creator is accounted for, and what survives termination are questions about specific facts and jurisdictions. The inventory identifies them; it does not answer them.