Who Owns the Code? IP Clauses Every Client Contract Needs

Who Owns the Code? IP Clauses Every Client Contract Needs

Five clauses prevent nearly every code-ownership dispute: a named ownership model, a toolkit carve-out, open-source flow-through, escrow or its equivalent, and payment-linked transfer. Without these five, the contract stays silent on who owns what — and silence ends up the most expensive option. (Usual note: engineering-practice guidance, not legal advice — have a lawyer draft the actual language.)

Every freelance software engagement produces intellectual property. Most of the contracts I review either don't say who owns it, or say it so broadly that one side gets badly hurt. The disputes are predictable: a client discovers the consultant is reusing "their" code on another project, or a consultant discovers they've signed away the toolkit they spent years building.

Both are contract failures. Both are preventable with a handful of clauses.

Assignment or license — decide deliberately

There are two clean models, and a contract should name one.

Full assignment (work-for-hire). The client owns the copyright outright. The consultant keeps no rights to the delivered code. This is what most clients assume they're buying, and for bespoke business logic it's usually the right answer — they paid for it, it encodes their processes, they own it.

License grant. The consultant owns the code and the client receives a license — perpetual and irrevocable if the client is sensible, sometimes exclusive within their industry. This fits productized consulting: the same engine delivered to many clients, configured per engagement.

Contracts go wrong not by picking either model but by not picking. "Consultant will develop the software for Client" says nothing about ownership. The legal default varies by jurisdiction in ways neither party wants to discover in court.

The toolkit carve-out

Think of a carpenter who brings their own toolbox to every job. The house they build belongs to the homeowner, but the saw and the drill stay theirs, carried home for the next job. A consultant's code works the same way.

No consultant writes from a blank page. Every delivery contains pre-existing material — utility libraries, deployment scaffolding, an auth module refined across a dozen projects. A naive "all deliverables are assigned to Client" clause assigns that toolkit too, and the consultant has technically lost the right to use their own tools on the next engagement.

The standard fix is a carve-out: pre-existing IP stays the consultant's property, and the client receives a perpetual, non-exclusive, royalty-free license to it as embedded in the deliverable. The client loses nothing — they can run, modify, and maintain the full system. The consultant stays in business.

The clause only works if "pre-existing IP" is identifiable. List the components in a schedule, or keep them in separate repositories the contract can point at.

Open-source obligations flow through

Most of any modern deliverable is open-source code neither party owns, and you cannot assign what you don't own. The contract should say three things: third-party components remain governed by their own licenses, the consultant delivers a dependency inventory, and compliance obligations transfer to the client along with the software.

This matters most when the client will redistribute or resell. A copyleft dependency that is harmless in an internal tool becomes a real constraint in a shipped product — the categories and traps are covered in open-source licenses in commercial software.

If the deliverable itself will be released as a product, the client's own license strategy deserves a decision rather than a default. See choosing a license for your product.

Escrow for the disappearing-vendor fear

Sophisticated clients ask the uncomfortable question: what happens if you close shop or simply stop answering? For a small consultancy the fear is rational. The classical answer is source-code escrow — code, build instructions, and deployment documentation deposited with a neutral third party, released to the client on defined triggers: insolvency, abandonment, sustained failure to support.

For most freelance engagements, formal escrow is overkill. The pragmatic equivalent is simpler: full source and documentation delivered with every milestone, into a repository the client controls. The client already holds everything escrow would ever release. Say so in the contract — it converts a fear into a listed feature.

Tie the transfer to payment

The assignment should take effect when payment clears, not when code is delivered. Until then, the client holds a license to evaluate and test. This is a fair clause, not an aggressive one: a client who has paid in full owns everything the moment they pay; a client who hasn't paid doesn't own work they haven't bought.

For the consultant it is also the only real leverage against nonpayment that doesn't involve lawyers. Ownership follows money, automatically, in either direction.

The five clauses, in short

1. A named ownership model — assignment for bespoke work, license for productized work, chosen explicitly.
2. A toolkit carve-out — pre-existing IP stays with the consultant, licensed to the client.
3. Open-source flow-through — inventory delivered, upstream obligations acknowledged.
4. Escrow or its equivalent — source and docs in the client's hands at every milestone.
5. Payment-linked transfer — ownership moves when money does.

None of these clauses favors one side. They exist because the alternative — silence — eventually costs both sides more than the drafting ever would.