Software Escrow in Nepal: How Source Code Escrow Arrangements Actually Work
Software escrow in Nepal: how a tripartite source code escrow protects buyers of custom software, which clauses matter, and how it fits Nepali copyright law.
A Kathmandu hospital runs its patient records on a system one local vendor wrote and hosts. The vendor's founder leaves the country; the updates stop; nobody can build the code. The hospital owns a licence to software it cannot fix, and Nepal's copyright law — which protects the code perfectly well — has nothing to say about that continuity problem.
Software escrow is the contract that solves it. Nepal has no statutory escrow regime, which makes the drafting, not the statute, the whole game.
In short
Software escrow in Nepal is a tripartite contract — developer, buyer and escrow agent — under which the developer deposits source code, build documentation and credentials with a neutral agent, released to the buyer only on defined triggers such as insolvency, abandonment or material breach. Nepali law adds no escrow statute: the Copyright Act, 2059 (2002) protects the code automatically, and the arrangement lives entirely on its clauses. The clauses that decide everything are the deposit and update obligations, the release triggers, verification rights, and the licence that survives release. Buyers of core operational systems should insist on escrow; vendors who offer it sell trust.
The continuity problem copyright does not solve
Nepal's Copyright Act, 2059 (2002) protects software from creation, automatically — the code the hospital depends on is a protected work. But protection answers a different question: who may copy. It does not answer the operational one: can the buyer keep the system alive if the developer cannot? For custom systems with no second source, the answer without escrow is usually no.
That is why escrow appears wherever Nepali organisations depend on one vendor for core operations — enterprise ERPs, hospital and lab systems, logistics platforms, and the custom builds that sit behind institutional workflows. It is a contract for continuity, not a transfer of rights.
The three parties and what goes into the deposit
The arrangement has three parties: the developer (who deposits), the licensee (who benefits) and the escrow agent (who holds). The deposit is more than a zip of code: source code with build instructions, deployment scripts, database schemas, third-party licence lists, and the credentials or procedures needed to rebuild the system — a deposit that compiles is a deposit worth anything; one that does not is theatre.
The agent can be a law firm, a bank's trust function or a specialised provider; in Nepal the role is often filled contractually by a professional firm. The agent's duties are mechanical by design: hold, verify on demand, release only on the contract's triggers.
| Clause | What it fixes | Failure mode without it |
|---|---|---|
| Deposit and update obligations | What is deposited, and when updates land | Stale code that no longer matches the live system |
| Release triggers | Insolvency, abandonment, material breach, loss of maintenance | Arguments while the buyer's system rots |
| Verification rights | Periodic build tests of the deposit | A deposit that compiles for the first time in a crisis |
| Licence continuity | Rights on release, at pre-agreed fees | Release of code the buyer still cannot legally use |
| Confidentiality | Agent's and buyer's duties over the source | The escrow becoming the leak |
How escrow sits inside Nepali copyright law
Escrow transfers no copyright. The developer keeps the rights; the buyer's licence — ideally a written licence recording scope and term — continues, and the release clause usually provides that on a trigger the licence becomes irrevocable and royalty-free for the buyer's own use, so the code can actually be run and maintained. Nepal's requirement that copyright transfers be in writing applies to any assignment in the structure; the escrow contract itself carries the licence terms.
Two adjacent instruments do quiet work. The NDA protects the source from the agent and the buyer's staff — enforceable in Nepal as a contract even before a dedicated trade-secret statute. And the third-party licence list in the deposit matters because open-source components carry their own conditions: an escrowed rebuild that violates an upstream licence solves one problem by creating another.
When software escrow earns its cost in Nepal
Buyer-side, the test is consequence: if the vendor vanishing means the organisation's core operations degrade within months, escrow is cheap insurance against a small annual fee. Procurement teams can make it standard — the same way diligence expects IP assignment clauses in employment contracts. Vendor-side, offering escrow is a sales asset: it tells an institutional buyer the vendor is serious about longevity, and it removes the objection that kills otherwise competitive bids.
Where the stakes are lower — a marketing site, a small app — escrow is overhead. Escrow is for the systems that cannot be re-bought quickly.
Setting up an escrow that will actually work
Most escrow failures are visible at signing: a deposit list nobody verifies, triggers nobody can prove, fees nobody priced. The sequence below is the difference between a document and a safety net.
Define the deposit, item by item
Source, build docs, schemas, credentials, third-party licences — with an update schedule tied to releases.
Set triggers that are provable
Insolvency filings, missed maintenance windows, breach notices — facts an agent can verify without a lawsuit.
Build verification in
An annual build test of the deposit, documented, so the code is proven to compile while everyone is still friends.
Fix the post-release licence
On release: irrevocable use rights for the buyer's own operations, at fees agreed today.
The rest of the buyer's software diligence
Escrow sits inside a larger checklist. Buyers should confirm the vendor actually owns what it is licensing — Nepal's creator-first default means unassigned developer and freelancer work is the most common defect in Nepali software deals — and that the product's name is not walking into a registered trademark conflict. Escrow protects continuity; assignments and a clearance search protect ownership and the brand.
Want this handled for your brand?
IP Watch monitors new trademark publications in Nepal and alerts you to potentially conflicting marks — with the context needed to review them.
This article is general information, not legal advice.