ReferenceInternational Business Law
IP clauses in contracts: who owns what, and who may use it
Background, foreground, and joint IP, ownership versus the right to use: how an IP clause allocates rights between the parties, with notes on US copyright from derivative works to fair use.

The most valuable asset of many companies cannot be touched. It sits in brands, data, software, processes, and know-how. Economists Jonathan Haskel and Stian Westlake call this the intangible economy: for the first time, the major developed economies invest more in intangibles than in machines and buildings. According to Ocean Tomo’s Intangible Asset Market Value Study, intangibles account for roughly 90 percent of the market value of the S&P 500; in 1975 it was 17 percent.
This kind of asset has a special property that Haskel and Westlake call spillover: its benefits flow easily to others, and proving who owns it is often hard. That is strength and weakness at once. The same process can work in a thousand products at the same time without wearing out; just as easily, it works in other people’s products. A machine can be locked away; a process or a dataset cannot. The fence around intangible assets is not a lock — it is the contract. Allocate the rights to it wrongly, and you lose them, often unnoticed and usually for good.
This rarely happens through theft. It happens through two sentences that surface again and again in negotiations, and both are wrong. “We paid for it, so we own it.” “We are co-owners, so we may use it.” Both confuse two questions a contract must answer separately: who owns a right, and who may do what with it. The wrong answer costs not elegance but market share, bargaining power, and, in the worst case, the indemnity you owe a deep-pocketed customer.
This article shows how a sound IP clause allocates rights between the parties, throughout from both sides, the licensor and the licensee. What artificial intelligence makes of these questions, from training to competing products, I address separately in the article “Data and AI in contracts: what may your counterparty do with your data?”.
Two questions, not one: ownership and right to use
Every IP clause answers two questions, and they are not the same. The first is ownership: who holds title to the right? The second is the right to use: who may use it, and for what? A contract that answers only the first leaves the commercially decisive one open.
Ownership sounds like security, but it carries cost and burden: registration, maintenance, defense, and enforcement. In most situations a party needs no title at all, only permission to do exactly what its business requires. A well-scoped right to use delivers that permission while cost and control stay with a single owner.
Ownership is expensive. Permission is usually enough.
Hence the basic pattern of every good IP clause: ownership and use are decoupled. One party becomes sole owner and bears the cost; the other receives a license as far as its business purpose reaches. From the licensor side that means keeping title and drawing the license narrowly. From the licensee side it means not insisting reflexively on ownership, but making sure the right to use is broad and secure enough to carry the investment.
What each party brings: background IP
At the start of every project sits what each side already holds. This pre-existing intellectual property, the background IP, stays in principle with its owner. The other party receives at most a license, and only as far as the project requires. The standard formula: each party keeps its background; the other gets a right to use it within the project, not beyond.
Two points decide the dispute here. First, the boundary: what counts as a modification or improvement of the background, and who owns it? The line between a derivative work and an independent new creation is not clean, so it belongs in the contract. The usual, clean choice is to assign modifications of a party’s background to the party whose background was modified. Second, containment: the right to use someone else’s background must not live on detached from the project results, or it can be carved out of the project and used elsewhere.
From the licensor side, the background is to be held firmly and the license confined sharply to the project purpose. From the licensee side, the danger is a project-bound license that ends with the project: anyone who wants to exploit the results afterward needs a background license that covers that later use, not just the creation.
What the project creates: foreground IP
Foreground IP, often called results, is what the project creates. Here the ownership question arises, and the contract decides it, not the payment. Three patterns are common: sole ownership by one party, which bears all the IP costs and licenses the other; full assignment to one party; or joint ownership. Whoever holds title bears the cost.
The most robust pattern is usually the first: sole ownership with one party, combined with a broad, irrevocable license to the other, tailored to its field of business. That gives each side certainty over use without the imponderables of joint ownership. From the licensor side, assigning the foreground to itself plus a license back is attractive; from the licensee side, what matters is that its license back reaches far enough to actually exploit the results it paid to create.
The joint IP trap
Joint ownership arises when both sides contribute to the results so that the contributions can no longer be separated. It sounds fair and is the most dangerous allocation, for one reason: only an active creative contribution counts, mere assistance, suggestions, or routine work create no co-ownership, and the statutory default rules diverge from one jurisdiction to the next. Write “jointly owned” and say nothing else, and you import, unintentionally, the default rule of whatever law applies, and that rule is different everywhere.
How far apart shows in the most practical question: may one co-owner license the joint right alone?1
| Question | USA (17 U.S.C.) | Germany (Section 8 UrhG) | UK (CDPA 1988) |
|---|---|---|---|
| Grant a non-exclusive license alone? | Yes, with a duty to account | No, exploitation only jointly | No, all owners must consent (s. 173(2)) |
| Consent of all for an exclusive license? | Yes | Yes, not to be refused contrary to good faith | Yes |
| Share revenue with the others? | Yes, duty to account | Yes, by share of the creation | Yes |
| Sue for infringement alone? | Yes | Yes, but performance only to all | Yes |
The same clause “jointly owned” produces three different legal worlds. A US-minded party that assumes “I am a co-owner, so I may license” infringes the others’ rights in Germany and the United Kingdom. The lesson is clear: avoid joint ownership where you can, and use sole ownership plus a cross-license instead. Where it cannot be avoided, the contract must expressly govern the five points the defaults treat inconsistently: exploitation rights, consent to licensing, accounting for revenue, enforcement and standing, and the resolution of deadlock.
Right to use: tailoring the license
Do you even need a right to use?
Before drafting a license, it is worth asking whether you need one. It depends on whether the contract transfers a thing or permits the use of protected intellectual property.
On a pure sale of goods, such as a machine, no right to use is needed. The power to use the machine follows from ownership: the owner may deal with the thing as it pleases (Section 903 sentence 1 BGB). Reselling the device is free too, because the distribution right is exhausted once the item is put on the market (Section 17(2) UrhG; in US law the first-sale doctrine, 17 U.S.C. § 109(a), and patent exhaustion).2 It is different for embedded software: buying the machine acquires ownership of the thing, not the copyright in the program. The work stays with the rightholder, and the buyer needs a license (Sections 31, 69c UrhG) to the extent the supplier wants to restrict use beyond the intended use that is permitted anyway (Section 69d(1) UrhG). And with SaaS no copy is handed over at all; the software runs on the provider’s servers.3
That is why, from the licensee side, the precise term in SaaS is not a “right to use” a copy but a “right to access and use the service”: there is nothing to reproduce and nothing that could be exhausted or resold. Import the software-license logic here, and you draft past the subject matter.
| Type of deal | What is transferred | Right-to-use clause needed? |
|---|---|---|
| Sale of goods (machine) | ownership of the thing | No, use follows from ownership |
| Embedded software | the hardware only, not the work | Yes, a license (Sections 31, 69c, 69d UrhG) |
| SaaS / cloud / AI service | nothing, only access to the service | Yes, as an access right; no exhaustion |
The levers of a license
Where a right to use is needed, its reach decides its worth. A license is tailored along eight levers: field of use, territory, exclusivity, sublicensing, term, revocability, consideration, and transferability. The principle behind them is hard: whatever is not expressly granted stays reserved.
How sharply these levers cut shows in a typical licensor-side formula that closes every gap: “a limited, non-exclusive, revocable, non-assignable, non-transferable, and non-sublicensable right to access and use”. Every word shifts the risk, and for the licensee every restriction is a breaking point.
| Restriction | What it gives the licensor | What the licensee must watch |
|---|---|---|
| limited | use only within the defined scope | Is the scope enough for the real business purpose? |
| non-exclusive | the same rights can be granted again | no protection from competitors with the same license |
| revocable | the right can be withdrawn at any time | no security for investment; insist on withdrawal only for cause |
| non-assignable / non-transferable | bound to this exact licensee | the license falls away on a sale or restructuring; include successors and affiliates |
| non-sublicensable | control over the license chain | passing it to the group or end customers must be expressly allowed |
| access and use | in SaaS only access, no copy | secure data export and the survival of access |
Notes on US copyright: derivative works, work for hire, fair use
Three concepts of US law shape international IP clauses so strongly that they surface even in contracts governed by German law. Knowing how to place them makes for sharper negotiation.
Derivative works: adaptation is an exclusive right
A derivative work is a work based on one or more pre-existing works that recasts, transforms, or adapts them (17 U.S.C. § 101): the translation, the revised database, the newly aggregated map, the integration into a software product. The right to adapt rests exclusively with the author (17 U.S.C. § 106(2)); without a license or a limitation, the adaptation is an infringement.4 Two consequences are regularly overlooked: the adapter’s copyright covers only the material it added itself, not the original taken over (§ 103(b)). And whoever adapts on the basis of an unlawful taking receives no protection at all for the parts taken over (§ 103(a)). A flawed license base thus devalues your own product line twice over.
Work for hire does not apply automatically
In US law the work-for-hire doctrine makes the commissioning party the author, but only within narrow limits: for employees within the scope of their work, or for commissioned works that fall into one of nine statutory categories with a signed agreement.5 The mere commission does not suffice; the independent contractor is simply not an employee. German law does not know work for hire at all; it works through the grant of rights of use (Sections 31 et seq. UrhG). A cross-border clause must therefore serve both systems and make the choice of law expressly, rather than rely on a figure that exists in only one legal order.
Fair use will not cover it
Whoever adapts without asking hopes, in US law, for fair use (17 U.S.C. § 107): if your own use is “transformative” enough, no license is needed. The US Supreme Court narrowed that hope in 2023 in Warhol v. Goldsmith. A new meaning or message alone does not suffice; what matters is the comparison of purposes, and where both works serve the same commercial purpose, the first factor weighs against fair use. The core sentence of the decision: the transformation needed for transformative use must go beyond what already makes a work derivative.6 For commercial actors the limitation is therefore no reliable anchor; what is reliable is the lawful provenance of the material and a clean license.
A model clause that bundles the core points on background and foreground. It is deliberately customer-friendly: the receiving party is granted the rights in the foreground; from the provider’s side, reverse the allocation. The highlighted terms are placeholders for the providing and the receiving party, not defined contractual terms; replace them with the contract’s own designations.
Across borders: one right, many legal orders
There is no worldwide copyright. Protection is territorial: each state protects only for its own territory, and what governs is the law of the country for which protection is claimed (the lex loci protectionis, Article 8(1) Rome II Regulation; at treaty level Article 5(2) Berne Convention).7 That connecting factor cannot be set aside by a choice of law (Article 8(3) Rome II Regulation). A worldwide license therefore engages the IP law of every target country in parallel, and no governing-law clause consolidates that.
In practice the risk concentrates in two places: in the EU and the EEA, where the sui generis database right (Sections 87a et seq. UrhG) protects a substantially invested database independently of copyright, and in the country the data comes from. From this follows a shift in the question, and it hits both roles: the licensee asks “may we use this everywhere?”, while the licensor must ask “can we warrant this worldwide?”. Anyone who promises large licensees worldwide rights and indemnities should limit the warranties to what can truly be warranted: documented provenance per dataset, and otherwise delivery “as is” and a cap on liability. How the associated indemnity is confined from the indemnifying party’s side, I set out in the article “Indemnity: how the supplier can reduce its liability”.
What you should do
- Separate ownership and the right to use into distinct clauses, and decide deliberately whether you really need title.
- Assign each right to a bucket: background stays with its owner, foreground is expressly allocated, and you avoid joint ownership.
- Settle first whether you need a right to use at all (a thing, a work, or a service), and choose the word access for SaaS.
- Tailor the license along the eight levers; whatever is not granted stays reserved.
- With a US nexus, check the special rules: work for hire requires the signed agreement, and adaptations without a license enjoy no protection of their own.
- Do not rely on fair use; secure the lawful provenance and the license.
- Limit worldwide warranties to what you can actually warrant.
Conclusion
A good IP clause does three things: it assigns each right to a bucket, it tailors use precisely, and it limits the warranty to what can be kept. Assign, tailor, secure. Leave any one of the three to chance or to the statutory default, and you give away rights or promise what you cannot keep. These are exactly the clauses I draft and review, for both sides and with an eye to the law that actually governs in a dispute.
Häufige Fragen
Background IP, foreground IP, joint IP: what is the difference?
Background IP is what a party brings into the contract pre-existing; it stays with that party, and the other side gets at most a purpose-bound license. Foreground IP arises only in the project; who owns it is decided by the contract, not by paying. Joint IP is jointly and inseparably created; it is risky, because the statutory default rules diverge from one jurisdiction to the next.
Ownership or right to use: what should I ask for?
Often a well-scoped right to use is enough, because ownership carries cost and burden (registration, maintenance, enforcement). From the licensee side, what counts is that the right is broad and secure enough (term, transferability, revocability); from the licensor side, that it stays narrow. Whatever is not expressly granted stays reserved.
Do I have to grant a right to use when I sell a machine?
For the machine itself, no. Use follows from ownership (Section 903 BGB), and resale is covered by exhaustion (Section 17(2) UrhG). For embedded software, yes, because the copyright does not pass with the thing; that needs a license (Sections 31, 69c, 69d UrhG). With SaaS no copy is transferred at all; there the precise term is access, not the use of a copy.
What is a derivative work?
A work that recasts, transforms, or adapts a pre-existing work (17 U.S.C. § 101), such as a translation, a revised database, or a newly aggregated map. Creating it is the author’s exclusive right (§ 106(2)). The adapter’s protection covers only what it added itself (§ 103(b)); where the taking was unlawful, no protection arises for the parts taken over at all (§ 103(a)).
What happens to licenses in insolvency?
They are not automatically safe. In the licensor’s insolvency, German law lets the administrator elect non-performance of contracts not yet fully performed on both sides (Section 103 InsO); whether a license survives that is not conclusively settled in German law. US law expressly protects the licensee if the contract is rejected (11 U.S.C. § 365(n)). Whoever depends on the right existentially takes precautions: an irrevocable, fully paid-up license, escrow, or indeed title. Insolvency is the one case where ownership is not overrated.
Notes
-
On the divergent default rules of co-ownership: United States, 17 U.S.C. § 201(a) (joint authors as tenants in common; the power to grant a non-exclusive license subject to a duty to account rests on House Report No. 94-1476); Germany, Section 8 UrhG (exploitation only jointly, consent not to be withheld contrary to good faith); United Kingdom, Copyright, Designs and Patents Act 1988, s. 10, s. 173(2). ↩
-
17 U.S.C. § 109(a) (first sale); Impression Products, Inc. v. Lexmark International, Inc., 581 U.S. 360 (2017) (patent exhaustion). ↩
-
Section 17(2) and Section 69c no. 3 UrhG (exhaustion of the distribution right); CJEU, Judgment of 3 July 2012 — C-128/11 (UsedSoft v Oracle), on exhaustion for downloaded program copies; CJEU, Judgment of 19 December 2019 — C-263/18 (Tom Kabinet), no exhaustion for the online making-available of other works. ↩
-
17 U.S.C. §§ 101, 103, 106; U.S. Copyright Office, Circular 14: Copyright in Derivative Works and Compilations (2020); in German law Section 23(1) UrhG. ↩
-
17 U.S.C. §§ 101, 201(b); Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989). ↩
-
Campbell v. Acuff-Rose Music, Inc., 510 U.S. 569 (1994); Andy Warhol Foundation for the Visual Arts, Inc. v. Goldsmith, 598 U.S. 508 (2023). ↩
-
Article 8(1) and (3) Rome II Regulation (Regulation (EC) No 864/2007); Article 5(2) Berne Convention; on the sui generis database right Sections 87a et seq. UrhG (Directive 96/9/EC). ↩
Reference: Poleacov, P. (2026). IP clauses in contracts: who owns what, and who may use it. INN.LAW. https://inn.law/en/perspectives/ip-clauses/