In roughly 60 percent of enterprise software and services contracts, the default IP ownership clause assigns custom configurations, integrations, and work product to the vendor, not the buyer who paid for it. IP ownership clauses govern who owns what is created during an engagement: custom code, configurations, integrations, data models, and derivative works. The vendor standard form almost always claims ownership or broad rights for the vendor, leaving the buyer with a license to use what it funded. Reversing or narrowing that default is one of the highest-value, lowest-cost terms to negotiate. This guide explains what to watch for and how to fix it.
What IP ownership clauses cover
IP ownership clauses allocate rights in the intellectual property created or used during a contract. In a software or services engagement, the relevant categories are pre-existing IP that each party brings, custom developments and configurations built during the work, integrations and connectors, data and the models derived from it, and derivative works that combine vendor IP with buyer-specific build. Each category can be owned, licensed, or jointly held, and the clause decides which.
The category that causes the most disputes is work product: the configurations, customizations, and integrations a buyer pays the vendor or a systems integrator to build. The buyer assumes it owns what it funded. The vendor standard form frequently says otherwise, assigning ownership to the vendor and granting the buyer only a license, sometimes one that terminates with the contract. The gap between assumption and contract is where buyers lose rights to their own investment.
The vendor default and why it matters
The vendor default form is written to maximize vendor rights. It typically assigns ownership of all developments to the vendor, characterizes buyer-funded customizations as derivative works of vendor IP, and grants the buyer a non-exclusive, sometimes non-transferable license to use them. The practical effect is that a buyer who spends millions on a custom implementation owns none of it and cannot take it to a different vendor or integrator if the relationship ends.
This matters most at exit. A buyer that does not own its configurations and integrations is locked in, because leaving means rebuilding everything from scratch. The IP clause is therefore a lock-in mechanism as much as a legal allocation, and it interacts directly with the exit and transition terms covered in our MSA negotiation guide. A weak IP clause can make a contractually clean exit practically impossible.
Ownership is bargaining power at exit: The IP clause decides whether you can leave. If the vendor owns your configurations and integrations, switching means rebuilding, and the vendor knows it at every renewal. Securing ownership or a perpetual, transferable license to buyer-funded work product is what keeps the exit door open and the renewal honest.
How to fix the clause
The buyer goal is clear: own, or hold a perpetual and transferable license to, everything you pay to have built. The strongest position is outright assignment of buyer-funded work product to the buyer, with the vendor retaining its pre-existing IP and any genuinely general tooling. Where the vendor will not assign ownership, the fallback is a perpetual, irrevocable, transferable, royalty-free license to use, modify, and have third parties modify the work product, which preserves the practical ability to leave.
The clause should also separate the layers cleanly. The vendor keeps its platform and pre-existing IP; the buyer gets its own data, its configurations, and the integrations built for it. Derivative-work language that sweeps buyer configurations into vendor-owned IP should be narrowed so that buyer-specific build is not captured. These are standard, winnable points when raised before signature, and they cost nothing but negotiating attention, the same attention described in our software contract negotiation guide.
Ownership by category
The table sets out the buyer target position for each IP category.
| IP category | Vendor default | Buyer target | Why it matters |
|---|---|---|---|
| Pre-existing vendor IP | Vendor owns | Vendor owns (accept) | Fair; vendor built it |
| Buyer-funded configurations | Vendor owns or licenses | Buyer owns or perpetual license | You paid for it; exit depends on it |
| Integrations and connectors | Vendor owns | Buyer owns or transferable license | Needed to switch vendors |
| Buyer data and derived models | Often vendor rights | Buyer owns outright | Your data is yours |
| Joint developments | Vendor-leaning | Clearly allocated, no ambiguity | Ambiguity favors the vendor |
The data row deserves particular attention. Modern contracts increasingly claim rights to use buyer data to train vendor models or improve vendor products. A buyer should own its data outright and grant the vendor only the narrow, specified rights needed to deliver the service, with explicit exclusion of training and product-improvement uses unless separately agreed. This is a fast-moving area and the vendor default is rarely acceptable.
Data rights and AI training
The newest and most contested IP territory is data and AI. Vendor contracts now frequently include rights to use customer data, including derived and aggregated data, to train machine-learning models and improve the vendor product. A buyer that signs the default grants those rights silently. The buyer position should be that its data, and any model trained specifically on its data, remains its property, and that the vendor may not use buyer data to train general models without explicit, separately negotiated permission.
This matters beyond principle, because data used to train a vendor model effectively transfers buyer value into the vendor product, where competitors may benefit from it. The clause should define data ownership, restrict secondary use, and specify deletion on exit. These provisions sit alongside the security and confidentiality terms, and getting them right is part of the contractual protection our software licensing advisory practice builds into every agreement.
Getting IP ownership right
IP ownership is a clause to settle before signature, because it is far harder to reclaim rights after the work is built and the relationship is established. Map every category of IP the engagement will touch, set the buyer target position for each, and negotiate ownership or a perpetual transferable license to everything you fund. Pay special attention to integrations and data, because those are what determine whether you can ever leave.
The cost of getting this wrong is paid at exit, when a buyer discovers it owns none of the implementation it funded and cannot move without rebuilding. The cost of getting it right is a few hours of negotiating attention at signature. For an estate of any size, that is among the best returns available in a software contract, and it is a standard part of the contract review in our contract negotiation work and our MSA negotiation guide.
Open source and third-party components
Modern software is assembled from many components, and IP clauses have to account for open-source and third-party code embedded in a vendor product or a custom build. A vendor that delivers a solution incorporating open-source components must warrant that it has the right to do so and that the open-source licenses do not impose obligations the buyer cannot meet. A custom build that mixes the buyer code, the vendor code, and open-source code needs clear allocation of who owns and who may use each layer, or the buyer can find its own product encumbered by terms it never reviewed.
The risk is concrete. A copyleft open-source license embedded carelessly in a custom build can require the buyer to release its own code, and a vendor warranty is the buyer protection against that outcome. The IP clause should require the vendor to disclose open-source components, warrant compliance with their licenses, and indemnify the buyer against claims arising from them. These provisions sit alongside the general IP indemnity covered in our MSA negotiation guide.
Escrow and source-code access
For business-critical custom software, a source-code escrow arrangement protects the buyer against vendor failure. The vendor deposits the source code with a neutral escrow agent, and the buyer gains access to it under defined trigger events such as vendor insolvency or a failure to support the product. Escrow does not transfer ownership, but it preserves the buyer ability to maintain the software if the vendor disappears, which is a meaningful protection for any system the business depends on and cannot quickly replace.
Escrow is most valuable where the buyer cannot easily switch vendors, which is precisely where lock-in is highest. It complements the ownership and license rights in the IP clause: ownership decides who controls the work product in the ordinary course, and escrow decides what happens if the vendor fails. A buyer negotiating IP terms for a critical custom system should consider both, and the combined protection is part of the contract review in our software licensing advisory practice.
Getting IP terms reviewed
IP clauses are technical enough that buyers frequently sign them without understanding what they concede, and the cost surfaces only at exit or in a dispute. A review by someone who reads these clauses for a living catches the assignments, the derivative-work language, the data-rights provisions, and the missing escrow and open-source warranties that a general read misses. The review is cheap relative to the value at stake, which on a major implementation is the entire investment in the work product.
The pattern across IP negotiations is that the terms are winnable when raised before signature and nearly impossible to recover after, because the buyer negotiating position and the vendor willingness both peak at the deal. Treating IP ownership as a primary term to settle up front, rather than boilerplate to accept, is what keeps the work product and the data the buyer pays for in the buyer hands. The broader contract discipline is in our software contract negotiation guide.
IP clauses in SaaS versus custom development
IP ownership plays out differently in a pure SaaS subscription than in a custom development engagement, and buyers should treat the two distinctly. In SaaS, the buyer is not commissioning bespoke code, so the IP question centers on configurations, custom objects, and above all the buyer data and any models derived from it. The vendor owns the platform, which is fair, but the buyer should own its data and configurations and hold a clear right to extract them on exit. In custom development, the buyer is paying for code to be written and should own or hold a transferable license to that code.
The common thread across both is exit. In SaaS the exit risk is data and configuration lock-in; in custom development it is code and integration lock-in. In each case the IP and data terms decide whether the buyer can actually leave or is held by the cost of rebuilding what it cannot take with it. Reading the IP clause through the lens of exit, rather than as abstract ownership, is what reveals which terms matter, and it connects directly to the termination and transition provisions in our software contract negotiation guide.
The recurring lesson on IP ownership is that the cost of a weak clause is invisible until exit, and by then it is unrecoverable. A buyer that owns its configurations, integrations, and data can leave, switch, or renegotiate from strength; a buyer that does not is held by the cost of rebuilding what it cannot take. Securing ownership or a transferable license to everything you fund, restricting secondary use of your data, and considering escrow for critical systems are the moves that keep that door open. Each is a standard part of the contract review in our software licensing advisory practice.