An entirely contractual concept
English law contains no statutory definition of background IP or pre-existing IP. The concept is whatever the contract makes it - which is exactly where problems begin. How the parties define, identify, and ring-fence background IP determines who retains their pre-existing assets and what rights the other side gets, and this is true wherever the IP originates.
Three definitional approaches dominate, and they are not synonyms. The provided approach (used in the UKIPO's Lambert Toolkit) captures only IP actively handed over for use in the project - the narrowest. A used approach catches any IP deployed during performance, whether or not formally contributed. The needed approach (used in EU Horizon 2020 agreements) is broadest, capturing IP required to exploit the results even if never provided or used during the project.
Why the definition choice matters
These are materially different allocations. From the foreground-IP owner's perspective, needed secures access to everything required to commercialise the deliverables downstream. From the background-IP owner's perspective, provided limits exposure to only what was deliberately contributed. Treating them as interchangeable boilerplate is a real error - the word chosen decides how much of each party's pre-existing IP is in play.
Choose the definition deliberately, by reference to which side you are on and what the deliverables will need after the project ends.
What courts imply when the contract is silent
If the contract says nothing, the courts imply only the minimum. Robin Ray v Classic FM plc [1998] FSR 622 laid down the governing principles for commissioned works: the court implies the minimum necessary for business efficacy, so if the commissioner's needs can be met by a licence rather than an assignment, only a licence is implied. The nature of the deliverable drives the result.
Compare two outcomes. In R Griggs Group Ltd v Evans [2005] EWCA Civ 11, a freelance designer commissioned to create the Dr Martens logo was held to have assigned beneficial ownership, because a brand logo inherently needs to exclude competitors. But in Clearsprings Management Ltd v Businesslinx Ltd [2005] EWHC 1487 (Ch), a client that commissioned bespoke software received only a non-exclusive licence, not an assignment - because developers routinely reuse generic code, and an assignment would have prevented that reuse.
Silence can expand the client's rights: Wilkinson
Silence does not always favour the IP owner. In Wilkinson v London Strategic Health Authority [2012] EWPCC 48, a consultant owned pre-existing works but was commissioned to create a new programme that depended on them. The contract was silent on the client's rights to the underlying background IP - and the court implied a licence to use it that was wide and unfettered in scope, because nothing in the contract restricted it. The lesson is counterintuitive: silence on restrictions can expand the client's implied rights in your background IP, to make the foreground IP usable.
In cross-border deals, these English implied-licence principles apply where English law governs the contract - but local IP laws may override them, and some civil-law systems construe ambiguous grants narrowly in favour of the author. The safe course everywhere is the same: never rely on implied terms; define the scope of background-IP licences expressly.
The M&A trap and the schedule
Background IP defined as IP owned or controlled by a party and its Affiliates creates a hidden exit risk: if Affiliate is defined dynamically, a change of control could sweep an acquirer's entire portfolio into the licence grant - so that buying the vendor hands the client a licence to the acquirer's IP. Freeze the definition of Affiliate for IP-licensing purposes, or add a carve-out that IP owned by an acquirer before the acquisition is not background IP.
Then schedule background IP with care. A robust definition balances certainty (what is it?) with safety (what if we forgot to list it?). Vendors should avoid an exhaustive list - if engineers reuse unlisted pre-existing code, the assignment clause may transfer it to the client; clients should push for full disclosure or insist on a sweeper licence over any unlisted background IP embedded in the deliverables.
Use at the desk
Practical checklist
- Define background IP expressly - English law has no statutory definition.
- Choose deliberately between 'provided', 'used', and 'needed' - they are not interchangeable.
- Never rely on implied terms - courts imply only the minimum (Robin Ray v Classic FM [1998] FSR 622).
- Remember silence can expand the client's implied rights in your background IP (Wilkinson [2012] EWPCC 48).
- Freeze 'Affiliate' for IP-licensing, or carve out an acquirer's pre-acquisition IP, to avoid the M&A trap.
- Schedule background IP - vendors avoid an exhaustive list; clients seek disclosure or a sweeper licence.
This guide is informational only and is not legal advice. It does not replace advice from licensed counsel on the facts of a specific transaction.
Product demo
Use the guide for context. Use Veqtor for the Word documents.
Watch Claude compare negotiation drafts and create a separate Word document with proposed tracked changes.
See Veqtor work with Word redlines