IP assignment vs IP license in a services agreement

In any services agreement, agency, contractor, consulting, development, there is a single clause that quietly decides who owns the output. Sometimes it's labeled "Intellectual Property." Sometimes "Work Product." Sometimes it hides in the back of the SOW. The IP assignment clause is short, often boilerplate, and materially determines whether the customer walks away with ownership, a license, or something murkier in between.

The distinction between IP assignment and IP license sounds academic. In practice, it's the difference between a customer owning the deliverable outright, with the ability to resell, modify, and build on it forever, and a customer having a narrower right to use what was delivered within the bounds the provider permits. Getting this wrong creates real commercial problems: disputes when the relationship ends, surprise limitations when the customer wants to white-label the output, or unexpected royalty obligations years after the project closed.

This is a walkthrough of what each structure actually does, the hybrid approaches most real agreements use, and the drafting patterns that cause the most post-signing confusion.

The two structures, plain

An IP assignment clause transfers ownership of the intellectual property from the creator (the service provider) to the customer. After assignment, the customer holds the copyrights, patents, and other IP rights in the deliverable. The provider no longer has any ownership stake.

A license leaves ownership with the creator but grants the customer permission to use the IP under defined terms. Licenses can be exclusive or non-exclusive, time-limited or perpetual, royalty-bearing or fully paid, and scoped to specific uses or territories.

A typical assignment clause reads something like:

"Provider hereby irrevocably assigns to Customer all right, title, and interest, including all intellectual property rights, in and to the Deliverables."

A typical license clause reads:

"Provider grants Customer a non-exclusive, perpetual, royalty-free license to use the Deliverables for Customer's internal business purposes."

Those look similar on the page. They aren't. The first hands the asset over. The second hands over a permission slip with a defined scope.

When assignment fits

Assignment is the default expectation for most bespoke services work where the customer is paying for a custom deliverable they intend to treat as theirs. Common cases:

• Custom software development. A company commissioning a product, feature, or system that will become part of its own platform.
• Brand and design work. Logos, identity systems, and marketing assets meant to represent the customer's brand.
• Content production. White papers, video, original research, anything the customer intends to publish under its own name.
• Any deliverable the customer plans to resell, sublicense, or build a commercial product around.

The commercial logic is straightforward: the customer paid for the work, the work was custom, and the customer needs unrestricted control to get the benefit of the bargain. In these contexts, an IP assignment clause is not a negotiating win, it's the baseline the customer probably assumed they had.

When a license fits

Licensing makes sense when the deliverable isn't purely custom, or when the provider has a legitimate reason to retain ownership. Common cases:

• Work built on top of the provider's existing platform or toolkit. The provider retains ownership of the underlying tools and licenses the full deliverable.
• Templated or configurable products. An agency that sells a configurable website framework can't assign the framework to every customer, only the configuration and customer-specific assets.
• Pre-existing IP incorporated into a custom deliverable. Often called "Background IP," this is the provider's own work that predates the engagement.
• Knowledge-work outputs where the provider has an ongoing business reason to use similar methods. A consultancy's frameworks, templates, and methodologies.

Licenses are also what most customers actually need, even when they believe they want full assignment. Few customers genuinely need the right to resell the code that runs their internal ops tool; a perpetual, royalty-free, transferable internal-use license delivers the same practical value.

The hybrid most agreements use

Real services agreements almost never land on pure assignment or pure license. They land on a hybrid that distinguishes between categories of IP.

A typical structure:

• Deliverables (the custom work product) are assigned to the customer.
• Background IP (the provider's pre-existing tools, frameworks, and methods) remains owned by the provider and is licensed to the customer.
• Residual knowledge (what the provider's personnel remember and can reuse for other clients) is expressly preserved for the provider.

A clause implementing this might read:

"Provider hereby assigns to Customer all right, title, and interest in and to the Deliverables, excluding any Background IP incorporated therein. Provider grants Customer a perpetual, worldwide, royalty-free, non-exclusive license to use, modify, and distribute such Background IP solely as incorporated into the Deliverables."

That's the standard pattern. It gives the customer effective ownership of the custom work while protecting the provider's ability to keep running its business.

The drafting patterns that cause problems

Even when the structural choice is clear, a few drafting details cause disputes later.

"Work made for hire" as the only mechanism

US copyright law has a "work made for hire" doctrine that vests ownership in the customer automatically, but only for specific categories of work and only where certain contractual conditions are met. Plenty of custom deliverables, especially software, don't qualify. A clause that says "all work shall be deemed a work made for hire" without a backup assignment leaves ownership ambiguous if the work-for-hire classification doesn't hold.

The drafting solution is a belt-and-suspenders clause: work-for-hire where it applies, and a present assignment as a fallback. Most professional services agreements use this combined form.

Assignment contingent on payment

Some agreements condition the IP assignment on the customer having paid in full. Language like "upon payment of all amounts due, Provider assigns..." means that if there's a payment dispute, the customer doesn't yet own the IP they've been using. This is a negotiating tool for providers; it's a risk for customers who want certainty of ownership from delivery.

Customers often push to separate the two: assignment on delivery, payment obligations as a separate commercial matter.

Ambiguous scope of "Deliverables"

If "Deliverables" isn't clearly defined, the scope of the assignment is unclear. Does it include drafts, iterations, and intermediate work product? Does it include the source code or just the compiled output? Does it include documentation?

Clean agreements define Deliverables in the SOW and cross-reference that definition in the IP clause. Messy agreements leave the scope to be figured out after the relationship ends.

The license carve-out that eats the assignment

A subtle pattern worth watching: an assignment clause followed by a broad license back to the provider. Something like:

"Provider assigns all rights in the Deliverables to Customer. Customer grants Provider a perpetual, worldwide, royalty-free license to use the Deliverables for any purpose, including the provision of similar services to other customers."

That's technically an assignment, but the license-back gives the provider nearly identical rights to what a license-only structure would have. The customer has ownership on paper and competitive exposure in practice. For truly custom or strategic work, customers often push to narrow the license-back to internal tools, portfolio display, or specific reuse, not "any purpose."

Moral rights waivers

In some jurisdictions (less so in the US, more so in Europe and other markets), creators retain moral rights, the right to attribution and the right to object to derogatory treatment of their work. Even after an IP assignment, these can survive. Services agreements that expect to operate across jurisdictions usually include an explicit waiver of moral rights, to the extent waiver is permitted by local law.

Third-party and open-source IP

A clean IP clause handles three categories, not two. Alongside Deliverables and Background IP, most services engagements involve third-party IP, commercial libraries, open-source components, stock assets, that the provider incorporates into the work.

The provider typically can't assign third-party IP because they don't own it. Instead, the agreement usually:

• Requires the provider to disclose all third-party components.
• Requires compliance with the applicable licenses (permissive open-source, copyleft, commercial).
• Allocates responsibility for any additional licensing fees.
• Excludes third-party IP from the warranty of non-infringement.

The failure mode here is a provider quietly incorporating copyleft open-source code (GPL, AGPL) into a deliverable the customer intended to keep proprietary. The customer "owns" the custom portion but the viral licensing terms of the incorporated code may impose obligations the customer didn't plan for.

The exclusivity question in licenses

When an agreement lands on a license rather than an assignment, the next question is exclusivity. A non-exclusive license lets the provider license the same IP to others, including competitors. An exclusive license prevents that, but often at a higher price or tied to volume commitments.

For customers using the deliverable as part of their core competitive differentiation, exclusivity matters. For customers using the deliverable internally, non-exclusive usually suffices. The mistake is defaulting to non-exclusive on strategically sensitive work because the template said so.

The bottom line

The IP assignment clause decides whether the customer walks away with ownership or with a permission slip. Assignment is the right default for custom deliverables the customer intends to treat as their own. Licensing is the right default for work built on top of a provider's existing platform or reused across engagements. Most real agreements use both, split between custom Deliverables and the provider's Background IP.

The clauses that cause problems aren't usually the ones that pick the wrong structure, they're the ones with ambiguous definitions, payment-contingent assignments, license-backs that swallow the assignment, or silent third-party components. Getting the structure right is half the work; getting the definitions and carve-outs right is the other half.

Ten minutes on the IP clause at signature saves months of dispute when the relationship ends or the deliverable becomes more valuable than either side expected.