Paying for software does not automatically transfer its intellectual property. Ownership depends on an explicit written assignment, and even then most contracts carve out the vendor background IP, third-party components and open source dependencies, so the practical question is what you can actually operate without the vendor.
What software ownership actually means
Copyright vests in the author by default. Commissioning and paying for software does not move that ownership unless the contract says so. The phrase work made for hire has a specific meaning in some legal systems and is interpreted strictly, so relying on it without an express assignment is a common and expensive mistake.
Ownership also comes in layers. The compiled application, its source code, its architectural design, its data model, its documentation, its brand assets and its deployment configuration are distinct works, and a contract that assigns the application but not the documentation has left you dependent.
Finally, ownership is not the same as operability. You can own source code and still be unable to run it if you lack the credentials, the build environment or the knowledge of how it deploys.
Background IP and third-party components
Vendors sensibly protect their pre-existing intellectual property. A software house that has built the same authentication module for a dozen clients will not assign it to you, and it is unreasonable to expect otherwise. What matters is the licence you receive and what happens if the relationship ends.
Ask for the boundary to be documented: an inventory listing the deliverables, the vendor background IP and its licence terms, and the third-party components with their licences. Without that inventory, the first serious diligence exercise will be a surprise.
Negotiate the licence for background IP as perpetual, irrevocable, worldwide and royalty-free for your internal and commercial use, and make sure it is transferable if the business is sold.
- Require a written inventory of deliverables, background IP and third-party components.
- Licence background IP perpetually, irrevocably and royalty-free.
- Make licences transferable in the event of a merger or acquisition.
- Explain the consequence of each component rather than listing licences only.
Open source and source code escrow
Open source is the largest source of unintended obligations. Permissive licences such as MIT and Apache 2.0 impose few conditions, while copyleft licences can require that derived works be distributed under the same terms. A single strong copyleft dependency inside a proprietary product is a business decision, not a technical detail.
Automate licence detection in the pipeline and fail the build on licences that have not been explicitly approved. Generate a software bill of materials so that obligations can be reviewed as dependencies change rather than once at go-live.
Where the vendor retains ownership, source code escrow is the standard mitigation. It should specify the trigger events, the verification process, the release method and the licence granted on release, with periodic verification so the deposit is not stale.
| Asset | Typical position | What to negotiate |
|---|---|---|
| Custom application code | Assigned to client | Express written assignment, all deliverables |
| Vendor framework | Licensed to client | Perpetual, irrevocable, transferable, royalty-free |
| Open source dependencies | Governed by their licences | Automated detection, approved list, SBOM |
| Third-party commercial libraries | Named-user or runtime licence | Transferability and renewal price cap |
| Documentation and design | Often overlooked | Include explicitly in the assignment |
| Hosting and certificates | Vendor account | Transfer accounts, domains and certificates |
Making handover real
A handover clause that promises source code and nothing else is not a handover. What a competent new team needs is the repository with full history, the build and deployment pipeline as code, infrastructure definitions, environment variables and secret management, database access, third-party account ownership, runbooks and architecture documentation.
Make handover a contractual milestone with an acceptance test: the client or a third party of the client choosing can build, deploy and run the system from the delivered artefacts without vendor assistance. If they cannot, handover has not occurred.
Include a knowledge transfer period during which named vendor engineers are available for questions, and require that key personnel information be maintained so a mid-project departure does not orphan your knowledge.
- Define handover as a milestone with a build-and-deploy acceptance test.
- Transfer accounts, domains, certificates and pipeline ownership.
- Require runbooks, architecture documentation and data model documentation.
- Include a knowledge transfer window with named engineers.
Frequently asked questions
Do I own the software I paid a vendor to build?
Only if the contract contains an explicit assignment of the relevant intellectual property. Copyright vests in the author by default, so paying for development does not transfer ownership without a written clause.
What is background IP and why does it matter?
Background IP is material the vendor created before, or independently of, your project, such as reusable frameworks. It is normally licensed rather than assigned, so the terms of that licence determine whether you can keep operating the system without the vendor.
Is source code escrow worth it?
Yes when the vendor retains ownership, provided the agreement names clear triggers, is verified periodically, and grants a specific licence on release. An unverified, stale escrow deposit provides little real protection.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.