Why we don't do "joint IP" — and what to do instead

A question came up recently with a SaaS client that's worth setting out properly, because the same pattern shows up from time to time in tech and payments deals.

The client licenses their core product to business customers. For one particular customer, the platform had been adapted: some workflow tweaks, a different data model for that customer's sector, and a co-branded front end. Reasonable enough commercially. The trouble started when the customer's lawyers proposed that the IP in the adapted version should be "jointly owned" between the two parties, on the basis that both had contributed to it.

It's a tempting compromise on paper. Both parties feel they're being treated fairly. Nobody has to argue about who "really" owns it. Perhaps counterintuitively though, it's almost always the wrong answer.

The basic problem with joint ownership

Joint ownership sounds like a 50/50 split of value. It isn't. What you actually get is two parties who each need the other's permission to do useful things with the asset — and the rules about exactly when that permission is needed are inconsistent, easy to get wrong, and rarely what either side expects going in.

Take patents and copyright as an example of how differently the default rules can land. With patents, each co-owner can generally use the invention themselves without asking the other, but cannot license it to a third party or assign their share without the other's consent. With copyright, the position is typically stricter: a co-owner often cannot exploit the work at all — not even use it themselves — without the agreement of every other co-owner, unless a contract says otherwise. Software, and the documentation and designs around it, will usually pick up copyright protection at a minimum, alongside any database rights, design rights, or (rarely, but possible) patents depending on what the customisation actually involved.

So "joint ownership" doesn't mean that each party is free to get on with it. It means a permanent relationship where commercial decisions — licensing it elsewhere, raising investment, selling the company, even basic maintenance — may need sign-off from a person or persons whose interests won't always align.

For a SaaS vendor specifically, this is a serious problem. The whole business model depends on being able to keep developing the core platform and deploying it (and improvements built from any one customer engagement) across the customer base. A joint ownership claim sitting over even part of that codebase is the kind of thing that shows up in due diligence on a fundraise or an exit and slows everything down, because a buyer or investor has to get comfortable that the vendor genuinely controls what it's selling.

Why it comes up in customisation scenarios specifically

The instinct toward joint ownership tends to surface in exactly this situation — an existing product adapted for one customer — because both sides can point to a contribution. The vendor built the platform; the customer's input shaped the customisation, maybe even paid for the development time, and might reasonably feel they own a piece of the result.

But "we both contributed" is a question about value, not about ownership structure. There's no requirement that contribution be rewarded through co-ownership. It's far cleaner — for both parties — to keep ownership unified and deal with the customer's contribution through the contract terms: pricing, licence scope, exclusivity, or a fee structure that reflects their input. That gets the customer the commercial benefit they're actually after, without anyone inheriting a permanently encumbered asset.

What to do instead

Keep the platform under sole ownership, and license it.

The vendor owns the core platform and any customisations. The customer gets a licence to use the customised version — exclusive to their sector or use case if that's the commercial deal, for a defined term, on whatever terms reflect what they've paid for or contributed to. This is the standard SaaS structure for a reason: it gives the customer everything they need commercially, while the vendor retains a clean, sellable, investable asset.

If the customisation is genuinely customer-specific and won't be reused, consider a narrower licence-back instead. 

Where a customer has paid specifically for bespoke development that the vendor won't deploy elsewhere, it's still usually better for the vendor to own it and grant the customer a broad (even exclusive, within their field) licence, rather than to co-own it. The practical effect for the customer is similar; the ownership position stays clean.

Where IP is genuinely separable, separate it.

For example, where the customer's team built a connector or some other distinct piece of software, allocate ownership of that piece to them, and cross-licence each other for what's needed to make the combined product work. This keeps each party in sole control of what they actually built, rather than blending everything into a joint pot.

If joint ownership really is unavoidable, spell it out

This does happen, particularly in genuine 50/50 joint ventures with no natural "lead" party. Even so, it's better to be explicit than to rely on the statutory default rules. Expressly set out each party's right to use, license, and sub-license without needing the other's consent (or exactly what consent process applies and on what timeline), how prosecution and maintenance costs are split, how disputes get resolved, who controls enforcement against third parties, and what happens to the IP if the relationship ends. Going in with eyes open to all of this is a world away from drifting into joint ownership because it felt like the fair compromise at signature.

The takeaway

"Joint ownership" feels even-handed, but it tends to create a worse outcome for both parties than the alternatives. A clean licence structure usually gets everyone what they actually want without saddling the relationship with permission requirements neither side fully understands until they need to rely on them.

If you're a SaaS or platform business working through a customisation or co-branding arrangement, it's worth getting the ownership structure right before the contract is signed rather than after a dispute forces the question. Get in touch fox@talkingfox.co.uk

if you'd like a second pair of eyes on a draft.