Who Owns the Code? IP Clauses Every Client Contract Needs

Five clauses help clarify code ownership and handover: 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. Clear clauses can reduce these risks, though they cannot prevent every dispute.

Assignment or license — decide deliberately

There are two common models. A contract can combine them for different components, provided it states the rights to each.

Assignment of transferable economic rights. Define the rights in bespoke code that transfer to the client. Distinguish moral rights and third-party components. “Work made for hire” is a US legal concept, not an automatic equivalent of assignment in an Indonesian contract. 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. Defaults vary by jurisdiction. In Indonesia, Law 28/2014 Article 36 generally places copyright in commissioned or privately employed work with its creator unless agreed otherwise. Article 16 allows transfer through a written agreement; moral rights have separate rules. Assess the actual relationship and components.

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. Specify the rights to run, modify, maintain, and appoint another maintainer, together with term, royalties, and distribution limits. The name of the carve-out alone does not grant those rights. 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 responsibilities for compliance at handover and later use are explicit. The agreement does not automatically release the consultant from earlier violations.

This matters most when the client will redistribute or resell. Copyleft obligations depend on the license and use; AGPL may also impose source duties for modified versions with network interaction, including some internal uses — 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. Include the licenses, operational access, and credentials needed to continue maintenance; possessing source alone does not supply them. 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: the client receives the agreed transferable rights when the payment condition is met. Pre-existing and third-party components retain their separate terms. Specify whether the trigger is per milestone or final payment.

For the consultant, a clear payment condition can help protect against nonpayment before a dispute reaches legal proceedings. The effect still depends on the agreement and applicable law; payment wording does not remove the possibility of a dispute.

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.

Negotiate these clauses around both parties' rights and responsibilities. They exist because the alternative — silence — eventually costs both sides more than the drafting ever would.