Most freelance disputes about IP start the same way. A client assumes that paying for something means owning it. The freelancer assumes the law backs them up. Both are partly right and mostly wrong. The proposal is where you settle it before it matters.
The IP section doesn’t have to be long. One short paragraph covers most situations. The trouble is the freelancers who skip it entirely, or paste in something they found on Reddit and don’t actually understand. Here’s a working framework.
The default state (which is not what most clients think)
In the US, UK, Canada, Australia, and most of the EU, the person who creates a work typically owns the copyright by default. Paying someone to make a thing doesn’t automatically transfer that ownership. There are exceptions (employees, certain commissioned works under specific statutory categories), but for most freelance design, code, writing, and consulting work, the default is: you made it, you own it, until you sign it over.
Clients almost never know this. They assume payment equals ownership. The proposal is the only place to correct that assumption without it becoming a fight later.
What the IP section needs to cover
A clean clause answers five questions:
- Who owns the final deliverables?
- When does ownership transfer?
- What can the client do with the work during the project?
- What rights does the freelancer keep?
- What third-party or pre-existing IP is included on a license basis?
That’s it. Five questions, one paragraph or short list.
A working template
Intellectual property: The freelancer retains ownership of all work product until receipt of final payment. Upon final payment, all custom deliverables created specifically for this project transfer to the client. The freelancer retains the right to display the work in portfolios and case studies. Any pre-existing tools, frameworks, or templates used to create the deliverables remain the property of the freelancer and are licensed to the client on a non-exclusive, perpetual basis for use within the delivered work. Third-party assets (stock images, fonts, plugins) are licensed under their respective terms; the client is responsible for any ongoing license fees.
That paragraph covers most freelance situations. Read it twice, edit it to fit your work, and have a lawyer in your jurisdiction look at it once. This is not legal advice.
Why ownership transfers on final payment, not signature
Final payment as the trigger does real work. It gives the freelancer leverage if a client tries to disappear at the end of the project, and it ties ownership to the moment money actually changes hands.
Compare the alternatives:
- Transfer on signature: client owns everything before doing anything, including paying you
- Transfer on delivery: client owns it before final payment; if they ghost the invoice, you’ve already given it away
- Transfer on final payment: client gets what they paid for, when they paid for it
Final payment is the cleanest trigger. Just be sure your invoice flow and follow-up actually close out final payments quickly.
Portfolio rights (the one freelancers forget)
Default law often doesn’t give you the right to show client work publicly, even if you made it. The proposal is where you carve that out.
Two phrasings:
- Liberal: “Freelancer retains the right to display the work in portfolios, case studies, and promotional materials at any time after launch.”
- Conservative (for sensitive clients): “Freelancer may display the work in portfolios and case studies six months after launch, subject to any confidentiality terms. Specific metrics and proprietary information will be omitted unless approved in writing.”
Pick the one that fits the client. Some industries (defense, healthcare, finance) will push back on either. Negotiate the delay or anonymization rather than dropping the right entirely.
Pre-existing IP and reusable components
A lot of freelance work uses tools, scripts, frameworks, or templates the freelancer has built up over years. You don’t want to accidentally transfer ownership of your reusable codebase to one client just because they signed a vague IP clause.
The fix: a sentence carving out pre-existing IP.
Any pre-existing code, design systems, methodologies, or templates owned by the freelancer prior to this project remain the freelancer’s property. The client receives a non-exclusive, perpetual license to use such pre-existing IP within the delivered work.
That sentence is small but does heavy lifting. Without it, a strict IP transfer clause can sweep up your library.
Third-party assets
Stock photos, paid fonts, plugins, SaaS subscriptions. None of these belong to you, and none of them transfer cleanly to the client.
The clause:
Third-party assets (including but not limited to stock imagery, fonts, plugins, and SaaS subscriptions) used in the deliverables are licensed under their original terms. The client is responsible for maintaining any ongoing licenses or subscriptions required after delivery.
Pair that with a list (in an appendix or the project brief) of which third-party assets were used. Saves a year of “why did our images disappear?” emails.
Exclusive vs non-exclusive usage rights
For some work (illustration, photography, music, certain types of writing), freelancers grant a license instead of transferring ownership. The license should be specific:
| Dimension | Example |
|---|---|
| Scope | Use on website and social media |
| Territory | Worldwide / US only / specified countries |
| Duration | Perpetual / 2 years / for the duration of the campaign |
| Exclusivity | Exclusive in [industry] / non-exclusive |
| Modification | Right to modify / no derivative works |
If any of these are left blank, the client may assume the broadest interpretation and you’ll spend energy clawing it back.
What to do when a client wants their own IP clause
Big-company clients often paste their standard IP language into your proposal. Read it before agreeing. Common red flags:
- “All work product, including methodologies and tools used during the engagement, becomes the property of the client” (sweeps up your library)
- “Freelancer assigns all moral rights” (in some jurisdictions, moral rights can’t be assigned, but the clause may still cause issues)
- “Work for hire” applied to categories where it doesn’t legally apply
- No portfolio carve-out
- IP transfer on signature, not payment
You can usually negotiate. Counter-proposals to push for:
- Carve-out for pre-existing IP
- Transfer on final payment, not signature
- Portfolio rights with reasonable delay
- Limit the assignment to deliverables created specifically for the project
If they refuse all of it, decide whether the project is worth the IP cost. A few are. Most aren’t, and a $30,000 project that quietly hands away your reusable codebase can end up being the most expensive deal you ever closed.
A short, plain-English version
Some freelancers don’t want a legalese paragraph in a friendly proposal. A plain version that still works:
Quick note on ownership: I own the work until you’ve paid the final invoice. After that, the custom pieces I made for you are yours. I keep the right to show the work in my portfolio (let me know if anything’s confidential). Any reusable tools or templates I bring in stay mine, but you can use them inside this project forever. Stock photos and fonts come with their own licenses, which you’ll need to maintain.
Less formal, same coverage. For small-business clients, this often reads better than a wall of clauses.
The audit
Open your most recent proposal. Find the IP section. Check:
- Does it state who owns the final work?
- Does it specify when ownership transfers?
- Does it preserve portfolio rights?
- Does it carve out pre-existing IP?
- Does it handle third-party assets?
If three or more are missing, the next dispute will cost more than the hour it takes to fix the template. IP language isn’t glamorous, but it decides who owns the work you’re actually selling.
Ready to send stronger proposals?
Build, send, and track proposals in one place so follow-up is easier.
Start your free trial →
