A chain of title you can show
Every contributor connected to the company by a document, and the gaps closed before somebody else finds them.
Technology
Software ownership.
Most companies discover the state of their code ownership at the worst possible moment, when a buyer, an investor or a lender asks them to prove it. An invoice is not an assignment, and a repository full of work is not a chain of title. The question is never who wrote it. It is who can show they own it.
What this looks like when it goes wrong
The classic version surfaces in diligence. The product was built quickly by freelancers, an agency and a couple of friends, invoices were paid, and nothing was signed that transferred anything. The company has been selling a product it cannot demonstrate it owns, and the people who could fix it with a signature are no longer easy to reach or no longer motivated to help.
The next version starts before the company existed. A founder wrote the first version at home, or during another job, or while studying, and never formally put it into the business. Whether it was ever theirs to give depends on the arrangements that applied at the time, and the company has been building on top of it ever since.
Then there is code nobody chose. Components pulled in during a sprint, each carrying its own licence and its own conditions, none of them read. Nobody kept a record of what is in the build. The conditions attached to some of that code can matter a great deal depending on how your product reaches its users, and the moment somebody looks is rarely a moment of your choosing.
The quietest version is the developer who leaves holding the keys. Repository access, cloud accounts, deployment credentials and domains registered in a personal name. Nothing was stolen, and the company still cannot reach its own infrastructure without asking.
What actually decides it
The default position depends on how the person was engaged. Work created by an employee in the course of their employment ordinarily belongs to the employer. Work created by a contractor, a consultancy or a freelancer ordinarily stays with them unless there is a written assignment, and paying an invoice does not supply one. Where a contractor works through their own company, the assignment has to come from that company and not from the individual, which is a detail that quietly breaks a great many otherwise tidy paper trails.
What buyers and investors test is the chain, not the code. Every contributor, agency, subcontractor, intern and acquired component needs to connect to the entity that claims to own the result. A single missing link matters out of proportion to the amount of work involved, because the person holding it has leverage and knows it. Fixing a gap while everybody is still on good terms costs almost nothing. Fixing it during a transaction costs whatever the other side decides to ask for.
Open source is a licence, not an absence of one. The conditions vary widely between licences, and the ones that matter commercially are those triggered by distributing the software or by making it available to others, which means your delivery model can decide whether a condition applies at all. How a component is combined with your own code matters as well. Compliance is mostly a matter of knowing what is in the build and honouring the notice and source obligations that come with it, and the answer sits in the specific licence attached to the specific component rather than in a general rule.
There is also a limit on what ownership of code buys you. Copyright protects the way something is written rather than what it does, so functionality, behaviour and ideas are much harder ground. Confidentiality, contract and the discipline of controlling access carry a large part of the real protection. Where material has been generated with substantial machine involvement, the ownership position is contested and moving, and it should not be assumed that such material sits in the same place as code written by a person.
What we do
Contractor and employee terms
Engagement documents that assign what is created, from the right party, at the right time.
Founder and earlier code
Work created before incorporation or elsewhere brought into the company properly rather than assumed.
Open source position
What is in the build, what conditions attach to it, and which of them your delivery model actually triggers.
Access, accounts and leavers
Repositories, credentials, domains and infrastructure held by the company rather than by an individual.
Ready before diligence
The ownership questions answered in advance, so a transaction is not the moment they get asked.
When to spend nothing
An internal tool that never leaves the building rarely justifies a full component review, and a small team should not stop shipping to catalogue every dependency. The cheap discipline is the one that compounds: sign the assignment before the work starts, keep a record of what has been brought in, and register accounts and domains to the company from the first day. None of that requires a budget and all of it is difficult to reconstruct later.
It is also worth being honest about when ownership is not the problem. A competitor with a similar product built independently is not an ownership issue, and no amount of paperwork addresses it. What the documents protect is your ability to prove your own position and to keep what you paid for.
Before anything is sent
Positions harden the moment the other side takes advice, and the quiet routes stop being available once a demand has gone out. While nothing has been sent, everything is still open.