When a company hires a vendor to build something — a custom software module, a marketing deliverable, a dataset, a design system — the default question about IP is who owns the work product. That question is important, and most vendor MSAs address it. The less-discussed question is what else the IP assignment language sweeps in that was never intended to transfer.
Vendor MSAs, particularly those drafted on vendor paper, often contain IP assignment language written to protect the vendor's interests in a way that creates unintended exposure for the customer. The specific patterns are consistent enough that they can be identified systematically — but they require reading beyond the ownership headline into the definitional structure underneath it.
Background IP: The Core Risk
The most important distinction in vendor IP provisions is between background IP and foreground IP. Background IP is intellectual property the vendor brought to the engagement — its existing tools, methodologies, software libraries, frameworks, and know-how. Foreground IP is what gets created under the specific engagement.
The standard commercial position is that the customer owns foreground IP created for and delivered to the customer, while the vendor retains background IP. The vendor licenses its background IP to the customer to the extent needed to use the deliverables. Both parties keep what they came in with; the customer gets what they paid for.
Vendor paper frequently departs from this in specific ways:
Undefined "Deliverables": the IP ownership section assigns ownership of Deliverables to the customer, but "Deliverables" is defined narrowly in the agreement — sometimes only as the specific items listed in an attached Statement of Work, sometimes as items "accepted" under the acceptance procedure. Everything else the vendor creates in the course of the engagement, including tools, scripts, data structures, and intermediate work product, remains vendor property. For customers who expect to receive and own the full scope of work product, this structure produces an ownership gap on anything not explicitly enumerated.
License-back requirements: the vendor assigns ownership of work product to the customer but retains a license to use that work product for other customers, for its own product development, or to develop competing products. This is not always disclosed prominently. The IP ownership section says "customer owns work product"; the License section, three sections later, says "vendor retains a perpetual, irrevocable, worldwide license to use work product in connection with vendor's products and services." The customer owns the work product in name but cannot prevent the vendor from using it.
Employee and contractor IP flow-through issues: some vendor MSAs contain representations that the vendor has the right to assign the IP in question, but do not include affirmative covenants about how the vendor manages its own contractors' IP assignments. If a vendor uses independent contractors who have not signed IP assignment agreements with the vendor, the vendor may not have clear title to assign. This is a due diligence issue rather than a drafting issue, but the MSA can contain language that either protects the customer (vendor warrants and represents that all work product will be assignable) or does not.
The Derivative Works Problem
Derivative works language is one of the most frequently missed IP risk patterns in vendor agreements. The provision typically appears in vendor paper as part of the background IP section: the vendor assigns ownership of deliverables to the customer but retains all rights in derivative works of vendor background IP, regardless of who paid for their creation.
This matters most in software development engagements. If the vendor uses its existing framework or codebase as the foundation for custom development, enhancements to that framework that are created during the engagement may be classified as derivative works of vendor background IP. The customer paid for those enhancements; the vendor owns them.
The acceptable structure is a clearly bounded definition of what constitutes background IP, combined with a covenant that the vendor will not incorporate background IP into deliverables in a way that limits the customer's use of the deliverables. If background IP is incorporated, the vendor should provide a license to that background IP that is co-extensive with the customer's intended use of the work product.
We're not saying that vendors shouldn't retain rights in their background IP — that is both commercially reasonable and practically necessary. The issue is when "derivative works of background IP" is defined so broadly that the customer ends up with a restricted right to use work product they paid to create.
Data and Training Set Provisions
For technology vendors, particularly those offering platforms, analytics tools, or any service where the vendor processes customer data, the IP assignment language intersects with data use provisions in ways that create distinct risks.
The pattern to flag: vendor IP provisions that include "improvements to vendor's products and services derived from customer's use" or "aggregated and anonymized insights derived from customer data" as vendor-owned IP. The vendor is asserting ownership of insights, model improvements, or product enhancements that derive — in some form — from what the customer brought to the engagement.
This is not categorically unacceptable. Many customers understand that a SaaS vendor's product improves partly through usage data. The questions are: how is "derived from" defined, how is "anonymized" defined and who verifies it, and is the customer's proprietary information protected from use in improvements that also benefit the vendor's other customers?
A vendor serving multiple customers in a specialized industry — say, a company that offers contract analytics to professional services firms — can potentially extract competitive intelligence from aggregated customer behavior. "Anonymized" protects individual record attribution; it does not prevent the vendor from learning patterns about how a specific industry negotiates specific clause types, which is itself commercially valuable information that the customer may not have consented to share.
Playbook positions on this need to specify: permissible uses of customer data for product improvement, required anonymization standards and verification, and explicit exclusion of customer-proprietary methodology or proprietary data structures from training or model improvement uses.
Red Flag Patterns Worth Flagging Every Time
Across vendor MSA review, the following IP provision patterns should trigger a HIGH or REVIEW flag regardless of the specific business context:
- Vendor retains license-back to use customer-owned work product — particularly if the license is broad (not limited to internal use or to serving the customer), irrevocable, and includes competitive use.
- Deliverables defined by reference only to accepted or enumerated items — any definition of deliverables that excludes intermediate work product, tools, or derivative works created during the engagement.
- Derivative works of vendor background IP excluded from customer ownership — especially if background IP is broadly defined to include any pre-existing vendor methodology or tooling.
- Vendor owns "improvements" or "enhancements" derived from customer data or use — without a clear definition of what qualifies and what protections apply to customer-proprietary information.
- Absence of a warranty that vendor has right to assign — if the vendor does not warrant that it holds clear title to assign the work product, the customer has no contractual basis to enforce the assignment against third parties.
How to Position Counter-Language
When redlining IP assignment provisions in vendor MSAs, the priority hierarchy is: (1) clear, broad ownership of all work product including intermediate deliverables, (2) license to background IP co-extensive with the intended use of the deliverables, (3) explicit prohibition on vendor's use of deliverables or customer data for competitive purposes, (4) representation and warranty of right to assign.
On the license-back question specifically, the acceptable counter-position is usually a limited license — vendor may use deliverables internally, or to serve the customer, but not to develop competing products and not in any form identifiable as customer-specific work product. This is negotiable with most vendors and is a reasonable protection for the customer's investment in the engagement.
The deeper issue with IP provisions in vendor MSAs is that attorneys reviewing them often focus on the ownership headline and move on. The structural risks — derivative works carve-outs, broad license-back language, data use in improvements — live in the definitional layers and in cross-references to other sections. Playbook positions that address only the ownership question leave the structural risks unreviewed. The decomposition into specific checkable elements — ownership scope, license-back, derivative works definition, data use, and warranty of assignment — is what produces consistent protection across a high-volume agreement pipeline.