Buying and accepting
Source and build instructions held by a third party, released on stated events — insurance against a supplier that stops existing rather than one that stops replying.
Also called Software escrow · Эскроу исходного кода
It solves a narrow problem well: the supplier goes out of business, is acquired, or refuses to hand over, and the buyer holds no copy. The agreement names the release events, the deposit contents and how often the deposit is refreshed.
Where it fails is verification. A deposit is worth what a competent third party could do with it, and most are never opened until the day they are needed — at which point it emerges that the build instructions are stale, a dependency was private, the environment variables were never included, or the whole thing does not compile. An escrow with a verification step costs more and is the only kind that is insurance rather than a receipt.
For most engagements the cheaper instrument is better: the buyer simply owns the repository and the accounts from day one, and the question does not arise. Escrow is for the cases where the supplier genuinely cannot hand over their platform, which is rarer than it is claimed to be.
An unverified deposit is a filing cabinet. Pay for the verification, or ask the supplier to prove the handover works by having a second party build from the deposit once — and if that is refused, the refusal is the finding. It is the same test as the untested backup, applied to a contract instead of a database.
The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.