IP Assignment: What It Is and Why Freelancers Must Care

# IP Assignment: What It Is and Why Freelancers Must Care

You spend three weeks designing a brand identity system. The client loves it, pays the invoice, and six months later you see your work on a billboard — credited to their in-house team. Did they steal it? Probably not. They likely owned it the moment the contract was signed, and you agreed to that without fully realising it.

That's IP assignment in action. It's one of the most consequential clauses in any freelance contract, and it's also one of the least understood. Whether you're a graphic designer, developer, copywriter, photographer, or consultant, the way intellectual property is handled in your contracts directly affects your livelihood, your portfolio, and your future business opportunities.

Let's break it down clearly.

What IP Assignment Actually Means

Intellectual property (IP) refers to creations of the mind — designs, code, written content, photographs, music, inventions, and more. When you create something as a freelancer, copyright in that work typically belongs to you by default. You created it, you own it.

An IP assignment is a contractual clause that transfers that ownership from you to your client. Once assigned, you no longer own the work. The client does — fully and permanently. They can modify it, resell it, sublicense it, or never use it at all. You have no ongoing rights unless the contract specifically carves them out.

This is different from a licence, where you retain ownership but grant the client permission to use the work under defined conditions. A licence can be exclusive or non-exclusive, time-limited or perpetual, narrow or broad. With a licence, you keep the underlying IP. With an assignment, you hand it over entirely.

The distinction sounds technical, but the practical consequences are enormous.

Three Scenarios Where This Gets Real

Scenario 1: The reusable code library A developer builds a SaaS platform for a startup. Buried in the contract is a broad IP assignment clause covering "all work product created during the engagement." The developer used a custom authentication module they'd built previously and planned to reuse in future projects. After signing, that module legally belongs to the startup. Using it for another client — even in a modified form — could expose the developer to an infringement claim.

Scenario 2: The portfolio piece that vanishes A copywriter produces a flagship content campaign for a retail brand. The contract assigns all IP to the client and includes a confidentiality clause. When the copywriter tries to add the work to their portfolio, the client sends a cease-and-desist. The copywriter has no legal right to display work they no longer own without the client's permission.

Scenario 3: The logo used beyond its scope A freelance designer creates a logo for a local restaurant's website. The contract is vague — it says the client can "use" the design but doesn't specify assignment or licence terms. Two years later, the restaurant franchises and starts using the logo nationally on merchandise, signage, and packaging. Who owns the right to do that? The answer is unclear, and disputes like this end up costing both parties time and money.

None of these situations involve bad-faith clients. They're the result of contracts that weren't examined carefully enough before signing.

Work for Hire: The US-Specific Wrinkle

If you work with US-based clients, you'll also encounter the term "work for hire" (sometimes written "work made for hire"). Under US copyright law, a work qualifies as work for hire in two ways: either it's created by an employee within the scope of their employment, or it falls into one of nine specific categories of commissioned work *and* there's a written agreement calling it work for hire.

The nine categories include things like contributions to collective works, translations, instructional texts, and compilations — notably, standalone software and general written content don't automatically qualify. Despite this, many client contracts use "work for hire" language loosely, sometimes paired with an IP assignment clause as a belt-and-braces approach.

The practical effect is similar to an IP assignment: the client claims ownership from the moment of creation. But there's a meaningful difference — under a true work-for-hire arrangement, you're never considered the author in the first place. With an assignment, you were the author and then transferred ownership. This matters for things like moral rights (more relevant in the UK and EU than the US) and certain reversion rights that US law gives creators after 35 years.

The takeaway: read both terms carefully, and don't assume they're interchangeable.

What to Look for in a Contract

When you're reviewing a new contract, look specifically for:

- Scope of the assignment — Does it cover only the deliverables, or everything you create during the engagement, including drafts, tools, and background IP? - Timing — Does the assignment happen on signing, on delivery, or on final payment? Payment-contingent assignment gives you leverage if invoices go unpaid. - Background IP carve-outs — A well-negotiated contract will exclude pre-existing IP you bring to the project. If you use your own frameworks, templates, or code libraries, these should be explicitly carved out and licensed to the client, not assigned. - Portfolio rights — If you want to display the work, you need this in writing. Many clients will agree to a simple clause allowing you to show the work in your portfolio. - Moral rights waiver — In the UK and many other jurisdictions, you have the right to be identified as the author and to object to derogatory treatment of your work. Clients sometimes ask you to waive these. Know what you're giving up.

Negotiating these points isn't aggressive or unprofessional. It's standard practice, and clients who work regularly with freelancers will expect it.

How to Protect Yourself Without Losing the Work

You don't need to refuse every IP assignment — in many cases, it's entirely reasonable for a client to want full ownership of what they've commissioned and paid for. The goal isn't to hold IP hostage; it's to ensure you're making an informed decision and protecting what matters to you.

Here's a practical approach:

1. Inventory your background IP before every project. List any pre-existing tools, code, templates, or frameworks you plan to use. Raise these before the contract is signed, not after.

2. Price IP assignment into your fees. A full, perpetual assignment of ownership is worth more than a licence. If a client wants to own the work outright, that's legitimate — but it should be reflected in what they pay.

3. Request a licence-back if you need ongoing access. If you're assigning IP but need to keep using elements of it, ask for a non-exclusive licence back to yourself covering those specific uses.

4. Get portfolio rights in writing. A single sentence — "Freelancer retains the right to display deliverables in their professional portfolio" — is enough. Most clients won't object.

5. Read the whole clause, not just the headline. "Limited licence" contracts sometimes contain language so broad they function like assignments. "Full IP assignment" contracts sometimes include carve-outs that preserve meaningful rights. The label isn't the contract — the words are.

The Bottom Line

IP assignment isn't a niche legal concern for big agencies — it affects every freelancer who creates anything under contract. The good news is that once you understand what you're looking at, these clauses aren't difficult to spot or negotiate. The risk is in treating a contract as a formality and skimming past the section that determines who owns your work.

Make it a habit to read IP clauses the same way you read payment terms: carefully, before you sign, with a clear sense of what you're agreeing to.

If you want to speed up that review process, tools like JuriScans can help you identify and flag key contract clauses — including IP assignment language — so you're not starting from scratch every time a new contract lands in your inbox.