Decision
Where Should a Founder Own Software IP?
Where Should a Founder Own Software IP?: short answer
Last reviewed
The company that funds the development should own the code. Ownership split from funding produces a weak nexus fraction, a transfer pricing problem and an assignment gap at diligence. Deciding this before the spending starts is worth more than any restructuring afterwards.
| General rule | The entity that funds development should own the resulting code |
|---|---|
| Qualifying expenditure | Own staff and genuinely unrelated contractors |
| Dilutive expenditure | Related-party outsourcing and acquisition cost |
| Effect of acquiring IP | Enters overall expenditure without improving the numerator |
| Founder-written code | Copyright vests in the individual and requires written assignment |
| Cheapest point to decide | Before development spending begins |
Most founders decide IP ownership implicitly, by writing code before forming the company that will own it, and then spend money correcting it at the worst possible moment.
The rule that resolves most cases
Ownership should follow funding. The entity that pays for the development should hold the resulting intellectual property.
That single principle disposes of most of the question, because the preferential IP regimes are all built on the OECD modified nexus approach, and the nexus approach measures what the claimant itself spent. An entity that owns an asset it did not pay to create has ownership without nexus, which is ownership without the funded development the benefit depends on.
The corollary is uncomfortable but useful: if a founder cannot say which entity funded a given piece of development, the structure has a problem that no amount of documentation drafted later will fully resolve.
The three positions founders actually arrive in
Code written personally before any company existed. Copyright vests in the individual who wrote it. Nothing transfers to the company automatically, not even where the founder is the sole shareholder. A written assignment is required, and its absence is one of the most common findings in technology diligence.
Code written by a company that will not own it. A group where one entity employs the engineers and another holds the asset creates related-party expenditure. That spending enters overall expenditure without entering qualifying expenditure, so it dilutes the nexus fraction while still costing the same cash.
Code written by contractors. Whether the copyright transferred depends on the contract. Many standard consultancy agreements grant a licence rather than assign ownership, and some are silent, in which case the developer may retain it. This is worth checking before it is relied upon.
What to do before the spending starts
- Decide which entity will own and commercialise the asset.
- Have that entity employ or contract the developers directly, so its expenditure is qualifying.
- Put written assignments in place for every contributor, including founders, before work begins.
- Keep the technical record: commit history, issue tracker, design decisions and sign-offs.
- Record the commercial decisions in board minutes of the owning entity, not of the group parent.
Step three is the one skipped most often and worth handling early. A missing assignment from a contractor who has since left, and who now understands the leverage, is a conversation best avoided during an acquisition.
Moving IP later is possible, and it starts from behind
Transferring an existing asset into a new owner is a normal transaction. It requires an independent valuation, transfer pricing documentation and arm's length contractual terms.
What it does not do is create nexus. Acquisition cost enters overall expenditure and leaves the qualifying numerator untouched, so the transferee begins with a low fraction. The uplift, capped at 30 percent of qualifying expenditure, softens this but does not remove it.
The fraction improves only as the new owner funds further qualifying development, and because it is measured cumulatively over the life of the asset, that improvement is gradual. A company that acquires its codebase and then continues to invest heavily will get there. A company that acquires and then stops developing will not.
Common questions
I wrote the code before forming the company. Does it belong to the company?
Not automatically. Copyright vests in the individual who wrote it, and nothing transfers by implication, not even where that individual is the sole shareholder. A written assignment is required, and its absence is one of the most common findings in technology diligence.
Do contractor agreements transfer ownership by default?
Frequently not. Many standard consultancy agreements grant a licence rather than assign copyright, and some are silent, in which case the developer may retain it. Each agreement has to be read before ownership is relied upon, particularly for contributors who have since left.
Can I move the IP into a new company later?
Yes, and it is a normal transaction requiring independent valuation, transfer pricing documentation and arm's length terms. What it does not do is create nexus: acquisition cost enters overall expenditure without improving the numerator, so the transferee starts from a weak position that only future qualifying development repairs.
What if one group company employs the developers and another owns the asset?
That produces related-party expenditure, which enters overall expenditure without entering qualifying expenditure. The group pays the same cash and dilutes the fraction, which is why ownership should follow funding wherever the structure allows it.
Technical definition
Under the OECD modified nexus approach, the benefit of a preferential IP regime is limited by the proportion of qualifying expenditure the claimant itself incurred. Ownership without funded development produces a low nexus fraction, and acquisition cost enters overall expenditure without improving the numerator.
Practical implications
Where founders write code personally before incorporation, the copyright vests in them and must be assigned. Where a related company funds development for another to own, the expenditure is dilutive for nexus purposes and requires transfer pricing support. Both are fixable, and both are cheaper to avoid.
Common misconceptions
The most common belief is that IP can simply be moved later once revenue justifies it. It can, but acquisition cost does not improve the nexus fraction, so a transferred asset starts from a weak position that only future qualifying development repairs. The second belief is that a contractor agreement transfers copyright by default. Often it does not.