IP Ownership clause: meaning, risks, and what to negotiate

No — not in the UK or most common law jurisdictions. Under English law, ownership of intellectual property does not automatically transfer with payment. For employees, work created in the course of employment is owned by the employer. But for independent contractors, freelancers, consultants, and agencies, the creator owns the IP unless the contract expressly assigns it to the client. This is a common misconception. Many clients assume that because they paid for work, they own it. Without an express assignment clause in a written contract signed by both parties, the contractor retains ownership, and the client gets only an implied licence to use the work for its intended purpose. That implied licence may be limited and non-transferable. To avoid disputes, always have a clear written IP clause that either assigns ownership or grants a licence, and make sure both parties understand what they are getting.

Assignment transfers ownership permanently. Once you assign IP, you no longer own it. You cannot use it again without the assignee's permission. You cannot assign it to anyone else. You have lost it entirely. Licensing grants permission to use the IP while you retain ownership. A licence can be exclusive (only that licensee can use it), non-exclusive (you can license it to others), perpetual (forever), or limited in time, scope, or territory. For background IP — your tools, templates, libraries, and know-how — licensing is almost always preferable to assignment. You keep ownership and can reuse those assets across many clients. The client gets what they need (the right to use your work as part of their project). For custom deliverables created specifically for the client, assignment is often appropriate — the client paid for bespoke work and should own it. But even then, you should typically keep a licence to use the deliverables for your own purposes (portfolio, reference, reusing general patterns).

Background IP (also called pre-existing IP or pre-existing materials) is intellectual property you owned or developed before the contract, or developed independently of it. For a software developer, background IP includes code libraries, frameworks, utilities, and tools you built before this project. For a designer, it includes templates, fonts, icons, stock images, and design systems you already created. For a consultant, it includes methodologies, frameworks, assessment tools, and training materials you developed over years of client work. Background IP is often your most valuable asset — it represents past investment that makes you more efficient and effective for current and future clients. If a contract assigns 'all IP created or used in connection with this engagement', your background IP could be at risk. Always carve out background IP explicitly, and only grant a limited licence for the client to use it as embedded in or necessary to operate the deliverables.

Under UK law (Copyright, Designs and Patents Act 1988), authors of copyright works have moral rights: the right to be identified as the author (paternity right), the right to object to derogatory treatment of the work (integrity right), and the right to object to false attribution. Moral rights cannot be assigned, but they can be waived. Many commercial contracts require the creator to waive moral rights. A blanket waiver means the client can modify your work in ways you might consider damaging to your reputation, and they don't have to credit you. A narrower approach is to waive moral rights only to the extent necessary to enable the client to use, modify, and maintain the deliverables for their intended purpose, while preserving your right to be credited where commercially reasonable. For creative work (design, writing, art), moral rights are particularly important. For technical work (software, engineering), they matter less, but a blanket waiver is still a concession you can negotiate.

It depends entirely on your contract. If you assigned all IP in the deliverables to the first client, you cannot reuse that work for another client without permission. However, you can almost always reuse your background IP (tools, templates, libraries, frameworks, know-how) because those are yours. You can also reuse general techniques, approaches, patterns, and solutions that are not specific to the first client's confidential information or unique requirements. For example, you can reuse a billing system library you built (background IP), but you cannot reuse the specific configuration that contains the client's pricing data. To preserve reuse rights, ensure your contract (a) carves out background IP, (b) assigns only custom deliverables, and (c) gives you a licence back to use the deliverables for your own purposes (excluding the client's confidential information). Many consultants and agencies survive and thrive by building reusable assets across client engagements — protecting that right is commercially critical.

This is a common gap in IP clauses. Ideally, your contract should address three scenarios: (1) termination for cause by the client — the client should typically own any completed deliverables they have paid for, but you should own work in progress and have no obligation to complete or assign it. (2) termination for cause by you (contractor) — the client should typically get a licence to use work completed up to termination, with a pro-rated refund for work not completed. (3) termination for convenience or no-fault termination — similar to termination for cause, with payment for work done. Without these provisions, you may have to assign work in progress to a client who stopped paying, or the client may have no rights to work they partially paid for. A clean approach is: 'Upon termination, Client shall pay for all work completed up to the termination date. Contractor shall deliver and assign to Client any completed Deliverables for which Client has paid. Contractor retains ownership of all work in progress for which Client has not paid.'

Not unless your contract gives you that right. If you assigned full ownership to the client, you cannot display, share, or use the work without the client's permission. Many clients will grant permission if asked, but they are not required to. To avoid this, negotiate an express portfolio use clause in your contract. A typical portfolio clause: 'Contractor may display the Deliverables in its portfolio, case studies, and marketing materials, provided that Contractor does not disclose Client's Confidential Information and removes or anonymises such information upon Client's request.' This protects both parties — you get to market your work, and the client's sensitive information remains protected. Some clients may also require that you not display the work until after a launch date or confidentiality period, which is reasonable.

Work made for hire is a US legal concept under US copyright law. It does not apply in the UK. Under UK law, the default position is that the creator (the individual author or developer) owns the copyright in their work. For employees, work created in the course of employment is owned by the employer. For independent contractors, freelancers, and consultants, the contractor owns the IP unless the contract expressly assigns it. Some UK contracts import US 'work made for hire' language. This is legally questionable and may be ineffective. Instead, use clear assignment language: 'Contractor hereby assigns to Client all right, title, and interest in the Deliverables.' That is effective under UK law. Do not rely on 'work made for hire' — it creates unnecessary uncertainty.

If your deliverables incorporate open-source components, those components remain subject to their original licences. You cannot assign ownership of open-source code to the client because you do not own it. Your contract should acknowledge this. Typically, you disclose the open-source components and the client accepts them subject to the applicable licences (MIT, GPL, Apache, etc.). Be careful with copyleft licences like GPL — they may require that any derivative work (including your proprietary code that links to or incorporates GPL code) must also be licensed under GPL, potentially forcing you to open-source your own code. For commercial client work, avoid GPL-licensed components unless the client explicitly accepts the copyleft obligations. Permissive licences (MIT, Apache, BSD) are generally safe. Your contract should include: 'Contractor shall disclose any third-party IP incorporated into Deliverables. Client accepts such components subject to their applicable licences. Contractor warrants that all third-party IP is properly licensed for Client's use as contemplated by this Agreement.'

This is why you should make assignment conditional on payment. If your contract says 'Upon full payment, Contractor assigns ownership to Client,' then assignment only happens when you are paid. If the client never pays, you retain ownership. You can then use the work elsewhere or license it to someone else. Without a payment condition, the client might argue that assignment occurred regardless of payment — they own the work but still owe you money. While you can still sue for the debt, you cannot take back the IP or use it elsewhere. A payment condition protects you: 'Notwithstanding any other provision, assignment of any Deliverable shall be conditional upon, and shall not take effect until, Contractor's receipt of full payment for that Deliverable. If Client fails to pay when due, Contractor retains full ownership and may cease further performance.' This gives you significant leverage if payment disputes arise.