Summary:
- Paying for work does not automatically make you the owner; the contract has to say so.
- Broad vendor retention language can quietly cover the product itself.
- Background IP is legitimate; what the client needs is a perpetual license to it.
- Assignment should trigger on payment, not on some ambiguous notion of completion.
A founder sent us a development contract for a second opinion. She had already negotiated the price and the timeline and was ready to sign.
The IP section contained a sentence that read, in substance: the vendor retains ownership of methodologies, frameworks and reusable components developed during the engagement.
Read casually, that sounds like the vendor keeping its own toolbox. Read carefully, in a project whose product is a framework for a specific industry, it covered the thing being built.
The three categories that must be separated
Almost every IP dispute comes from a contract that does not distinguish between these.
| Category | What it is | Correct treatment |
|---|---|---|
| Work product | Written specifically for this client, for this project. | Assigned to the client on payment. |
| Background IP | Existed before the project or is generic vendor tooling. | Stays with the vendor; client gets a perpetual, irrevocable license. |
| Third-party components | Open source and commercial libraries. | Governed by their own licenses; the vendor must disclose them. |
The problematic clause worked by leaving the boundary between the first two undefined and then writing the second one broadly.
Why background IP is legitimate
It is worth defending the vendor's position here, because some clients over-correct.
Any experienced development team carries reusable pieces: authentication scaffolding, deployment scripts, internal utilities. Assigning those to a client would mean the vendor could not use its own tools on the next project. No serious vendor will agree to that, and one who does either has no such tools or is not reading the contract.
What the client legitimately needs is not ownership of those pieces. It is certainty that they can keep using the delivered system, modify it, and hand it to another team, forever, without needing permission.
That is a license, and it should say perpetual, irrevocable, worldwide, sublicensable. Those four words do the entire job.
What we changed in that contract
Three edits, all small.
- Defined background IP by listing it. An annex naming the specific components the vendor was bringing. Anything not on the list is work product by default.
- Added the license language for whatever remained on the vendor's side.
- Tied assignment to payment of each invoice rather than to completion of the engagement.
The vendor accepted all three without argument, which is usually what happens. The clause had come from a template, not from a strategy.
Frequently asked questions
What is background IP and why does it matter?
It is what the vendor brings to the project rather than creates for it: internal libraries, boilerplate, tooling. Clients cannot own it, and that is fine. What clients need is a perpetual, irrevocable license so they can keep using and modifying the delivered system without asking permission.
Does paying for work automatically make you the owner?
Not necessarily, and this surprises people. Ownership depends on what the contract says and on the applicable law. Absent a written assignment, the default in many jurisdictions leaves rights with the author, not the payer.
What about open source components in my product?
They stay under their own licenses and nobody can assign them. What the contract should require is a list of the components used and their licenses, so the client knows what obligations came bundled with the delivery.
When does the assignment take effect?
It should be on payment, and that timing should be explicit. An assignment tied to "completion of the engagement" is ambiguous if the engagement ends in dispute, which is exactly when ownership matters most.
Is a signed NDA enough to protect confidential information?
It covers disclosure, not ownership. A vendor can be perfectly compliant with an NDA and still retain rights to reuse code written for you. The two clauses do different jobs and both need to be right.
The practical test before signing
Skip the legal analysis and ask one question: if this vendor disappeared tomorrow, could I hand everything to another team and continue, without needing anyone's permission?
If the answer is yes, the IP section is adequate whatever its wording. If the answer is no, or if nobody can tell, that is what needs fixing before signature.
And a related check that costs nothing: make sure the repository and every third-party account are in the client's name from day one, with the vendor added as a collaborator. Contracts describe who owns what. Account ownership determines who can actually do what on a Tuesday morning.
The clause in context: why templates get this wrong
Development contracts circulate. A vendor adapts a template from a previous engagement, which was itself adapted from something found online, and language drifts from its original purpose.
The retention clause in this case almost certainly began as a reasonable protection for a vendor's internal libraries. Over several copies it lost its boundaries and ended up covering anything the vendor might describe as a framework.
That is why the productive move is not to accuse the vendor of bad faith. It is to say: this sentence, as written, covers the product. I assume that is not the intent. Can we list what you are actually protecting?
In our experience, that framing gets the clause fixed in one exchange. An accusatory framing gets a defensive vendor and a slower negotiation.
What a founder should keep in a folder
Independent of the contract, four things should live somewhere the founder controls.
- Repository access under a company account, with the vendor invited as a collaborator.
- Every third-party service registered to a company email address, not to an individual developer.
- A one-page deployment note describing where the system runs and how it gets there.
- A dated list of open source components and their licenses.
None of it costs anything. All of it turns a difficult separation into an administrative one.