Chapter 03 / 06
There Is No Single Legal Ownership of Context
Copyright, trade-secret, employment, privacy, and data-access rules divide Context into different objects rather than assigning one universal title.
There Is No Single Legal Ownership of Context
Current law does not generally recognize a unified object called "context" with one owner. In the United States, California, and the European Union, a knowledge base would instead be disassembled into different legal objects, interests, duties, and remedies. The discussion here is structural analysis, not legal advice for a particular contract, jurisdiction, person, or dispute.
Documents, code, and the particular expression of a company-specific skill file created within the scope of employment may often be treated as work made for hire, with copyright initially held by the employer under 17 U.S.C. Section 201(b). That does not mean the employer receives a copyright monopoly over ideas, procedures, processes, systems, or methods of operation. 17 U.S.C. Section 102(b) separates protectable expression from those uncopyrightable methods. Owning the document's copyright does not, by itself, privatize every capability described by the document.
The absence of copyright protection does not make a method freely portable. A process, model, customer list, pricing rule, or operational method can qualify as a trade secret under 18 U.S.C. Section 1839 when it derives value from not being generally known and is subject to reasonable efforts to preserve secrecy. California decisions likewise distinguish a former employee's general knowledge, skill, and experience, which the employee may use, from trade secrets and confidential customer information, which the employee may not use or disclose. Morlife, Inc. v. Perry shows how customer information can cross that boundary.
The EU Trade Secrets Directive 2016/943 similarly states that trade-secret protection should not restrict employees' use of experience and skills honestly acquired in the normal course of employment or be used to impose unwarranted restraints on labor mobility. The point is not that all methods belong to workers, but that secrecy rules must distinguish protected business material from general professional capacity.
The boundary for software and inventions can also depend on specific state law. California Labor Code Section 2870 gives limited protection to an invention developed entirely on personal time without employer resources. That protection can narrow when the invention relates to the employer's business or anticipated research, or results from work performed for the employer. The computer on which an artifact was created is therefore one evidentiary factor, not a universal switch that assigns every right in the surrounding context.
Data-protection rights add another layer but do not settle ownership. Access, correction, deletion, or portability rights under the GDPR or the CCPA are procedural rights concerning personal data. They do not give a worker title to the employer's entire knowledge base, nor do they automatically override the privacy rights of colleagues and customers, trade-secret protections, retention duties, or other lawful limits. The EDPB portability guidance generally distinguishes data actively provided by a person and data observed from that person's activity from inferences or derived data generated through the controller's analysis. Customer, colleague, and supplier records also implicate other people's rights; the company may itself be a purpose-bound controller or steward rather than an absolute owner.
Derived artifacts do not automatically escape these constraints. Turning protected source material into an embedding, summary, adapter, behavioral profile, knowledge graph, or model weight does not "wash away" the underlying secrecy, privacy, copyright, contractual, or licensing restrictions. A representation that enables reliable reconstruction or extraction of protected facts remains risky even if its file format is novel. The relevant inquiry includes what the artifact reveals, reproduces, or permits a model to do, not merely whether it contains verbatim text. Conversely, fixing a worker's general judgment in model weights should not make that judgment permanently free to the company merely because its format changed.
The rough present-day baseline is therefore this: the company often controls fixed work product and protected business secrets, while the individual retains general knowledge, skill, and experience. The emerging legal rupture is that abilities once held only in a worker's mind are now fixed in prompts, skill files, behavioral traces, fine-tuning records, memories, adapters, and model weights. Once fixed, they can be pulled toward the company side by existing rules for work product, confidential information, trade secrets, and broad contract assignments, even when they embody capabilities that previously would have followed the worker as general skill.
Current law has not produced stable answers to several resulting questions. May a company run a worker's judgment model forever after departure? May the worker demand a representation that removes company facts while preserving general capability? How should revenue from a jointly produced adapter, embedding, or agent memory be allocated? Is consent meaningful when continuous behavioral monitoring occurs inside an unequal employment relationship? Can a personal cognitive profile be sold with the assets when a company is acquired or becomes insolvent? International Labour Organization research on workers' data rights identifies the gaps created by structural power asymmetry. The EU Platform Work Directive 2024/2831 supplies precedents in algorithmic transparency, human review, and worker-representative participation, but it is not a unified law of context ownership.
That rupture cannot be solved by calling every artifact "company data" or, conversely, by labeling every learned capability "personal memory." It requires attention to source, expression, inferential power, purpose, identity replication, and the rights of third parties. It also requires contract terms that separately address AI training and post-employment model use rather than hiding those permissions inside a general assignment of work product.