Code ownership and escrow: protecting your investment
What owning the code means in a contract, when escrow adds protection, and why the repository in your account beats both.
The short answer
Owning the code you paid for has three layers, and a contract addresses only the first. Legal ownership is the clause assigning rights to you, with third-party licences listed. Possession is a complete, current repository in an account your company controls, with the supplier as a removable collaborator. Practical ownership is the ability to build, run and change it from the documentation without the supplier. Escrow, depositing code with a third party for release if the supplier fails, addresses possession for software you do not hold yourself. For custom software built for you, a repository in your own account makes escrow largely unnecessary. For software you license and depend on, escrow is the protection that remains.
The three layers
| Layer | What it is | How it fails | How to secure it |
|---|---|---|---|
| Legal | The contract assigns the code to you on payment, with third-party components and their licences listed | A vague clause; components under licences that restrict use; rights only after final payment of a disputed invoice | A clear assignment clause reviewed by an advisor; a component list |
| Possession | The repository, with full history, in your company’s account | Code in the supplier’s account; a zip at hand-over; history missing | Repository in your organisation account from day one; supplier as collaborator |
| Practical | Documentation and a reproducible build so another team can take over | Undocumented setup; a private dependency only the supplier provides; a build only their machine can do | The eight documents; the stranger test; no hidden supplier dependencies |
When escrow earns its cost
- You license software rather than own it, and the supplier keeps the code.
- The software is built on the supplier’s proprietary platform or framework that you could not otherwise obtain.
- The business depends on it in a way that a supplier failure would be severe.
- The agreement includes verified deposits: the agent confirms the deposit builds and matches the version you run.
- Release triggers are clear and the licence after release lets you actually use and modify the code.
For software built for you
The stronger protection is simpler: the repository is created in your organisation account before the first line is written, the supplier is added as a collaborator, every change lands there through the pipeline, and the documentation and reproducible build are conditions of each stage payment. You possess everything, always, at the current version. If the supplier disappears, you remove a collaborator and hand the repository to the next one. Escrow adds nothing to that; the contract’s assignment clause and the component licence list complete it.
What this means for you
Secure all three layers: a clear assignment clause with a component list, the repository in your own account from the start, and documentation that passes the stranger test. Use escrow for software you license and depend on, with verified regular deposits and clear triggers. For software built for you, possession in your own account is the protection that actually works on the day you need it.
Frequently asked questions
If the contract says we own the code, are we protected?
Legally, if the clause is well written: assignment of rights on payment, including third-party components' licences listed. Practically, only if you also possess a complete, current repository in your account and can build it from documentation. A right to code you do not have and cannot run is a right to a lawsuit.
When is escrow worth it?
When you depend on software whose code the supplier keeps: a licensed product, a platform, a system built on the supplier's proprietary framework. Escrow with regular verified deposits and clear release conditions means that if the supplier fails, the code is released to you. For software built for you and held in your own repository, escrow duplicates what you already have.
What should an escrow agreement cover?
What is deposited: complete source, build instructions, dependencies, documentation. How often, and verified by the escrow agent to actually build. The release triggers: insolvency, cessation of support, breach. Who may use the released code and how. And a test of the deposit at the start; an unverified deposit is frequently unbuildable.