Every freelance contract that involves creative or technical work will have some version of an IP assignment clause. This is expected — your client is paying you to produce something, and they want to own it. That's a reasonable position.
The problem is when the language of that clause extends far beyond what you're actually delivering. A poorly written IP assignment can hand over ownership of tools you built before this client existed, frameworks you use across dozens of projects, and work you'll continue creating for other clients long after this engagement ends.
Understanding exactly what you're agreeing to — and what to change — is one of the most important things you can do before signing any creative or technical services agreement.
What is an IP assignment clause?
An IP (intellectual property) assignment clause transfers ownership of work you create from you to the client. In U.S. copyright law, the default is that the creator owns their work — so without an explicit assignment, you'd technically retain copyright over everything you produce, even if the client paid for it.
A standard, fair assignment clause transfers ownership of the specific deliverables you create for that specific project. That's entirely reasonable. The danger comes from language that reaches further.
The language that should concern you
Three words in that clause are doing serious damage: "used or improved."
If you use a code library you've been building for five years, that clause says the client now owns it. If you use a design system you've refined across 30 projects, they own it. If you use your standard proposal template to communicate scope, technically they own that too.
This isn't what the client usually intends — they want to own the website, the app, the design system you built for them. But the template their lawyer drafted doesn't make that distinction, and if you sign it as written, you've agreed to something much broader.
Three types of IP freelancers commonly bring to projects
Before you sign any IP clause, it's worth thinking clearly about what you're actually bringing to a project — because all of it could be at risk.
1. Background IP (pre-existing work)
Code libraries, design systems, templates, frameworks, photography presets, audio samples, writing style guides — anything you created before this engagement started. This is the most important category to protect because you likely use it across many clients.
2. Tools and processes
Your workflow tools, project management systems, internal documentation, and proprietary methods. These are rarely what a client is actually paying for, but broad IP language often sweeps them in.
3. Improvements to pre-existing work
If you improve your own code library while working on a client project — even as a side effect of doing the work — some contracts claim ownership over those improvements. This is particularly dangerous for developers who build on top of their own open-source or commercial frameworks.
The difference between a good and bad IP clause
- Assigns all IP "developed or used"
- No carve-out for pre-existing tools
- Includes "methodologies" and "processes"
- Applies to anything "related to" the project
- Assigns future improvements automatically
- Assigns only the defined deliverables
- Explicitly retains freelancer's background IP
- Grants client a license to use background IP
- Clear Schedule A listing what's being delivered
- No assignment of pre-existing tools or frameworks
How to negotiate an IP clause
In most cases, you don't need to fight the entire clause — you just need to add a carve-out for your background IP and clarify that assignment applies to deliverables only.
Request a background IP exclusion
"I'm happy to assign ownership of all deliverables described in Schedule A. I'd like to add a carve-out for my pre-existing tools, frameworks, and IP that I bring to this project. The client would receive a perpetual, royalty-free license to use these as incorporated into the deliverables, but ownership would remain with me. Happy to list the relevant background IP in an exhibit if that helps."
Narrow the assignment to deliverables only
"I'd like to narrow the IP assignment in Section [X] to apply only to the specific deliverables listed in Schedule A — not to tools, methodologies, or pre-existing work I use to create those deliverables. This protects work I've built for other clients and intend to continue using."
Add a license instead of an assignment for background IP
Sometimes the cleanest solution is to keep the broad assignment language but add explicit language preserving your ownership of pre-existing work:
"Notwithstanding the foregoing, Contractor retains all right, title, and interest in and to any tools, frameworks, libraries, or other intellectual property created prior to this engagement ('Background IP'). Contractor hereby grants Client a non-exclusive, perpetual, royalty-free license to use the Background IP solely as incorporated into the deliverables."
A note for developers specifically
If you work with open-source code, your IP situation has an additional layer of complexity. Many open-source licenses (MIT, Apache, GPL) require that any software incorporating them be distributed under the same or compatible terms. If a client's IP clause assigns them full ownership of everything you built, including code built on GPL-licensed libraries, you may be creating a conflict between the client's IP claim and the obligations of the open-source license.
This is worth flagging explicitly during negotiation: "Some of the libraries I'm incorporating are open-source under [license]. That affects how the code can be distributed — happy to walk through the implications."
The bottom line
A fair IP clause says: the client owns what you built for them. That's it. Anything that expands beyond that — reaching back into your pre-existing work, your tools, your methods — is worth pushing back on. Most clients will accept a reasonable narrowing, and it protects something you've spent years building.
Before you sign, make sure you know exactly what you're assigning.
Not sure what your IP clause actually says?
Upload your contract to ClauseGuard and get a plain-English breakdown of every IP provision — plus counter-language if anything looks off. Free, no credit card required.
Analyze your contract free →