Software Escrow Under Dutch Law

If your business depends on software you did not write, you depend on the company that did. You hold object code and a licence; the supplier holds the source code, the build pipeline and the knowledge. That asymmetry is tolerable while the supplier is solvent and competent, and stops being so the moment it is not. Software escrow is the standard answer, but it works only if drafted with Dutch insolvency law in mind — and most arrangements are not.

What escrow is and the risk it addresses

The supplier deposits the source code and supporting materials with an independent third party, which holds them until a defined event occurs and then releases them to the customer, who may use and modify the code to keep the software running. The risk is continuity, not ownership: a customer running its order processing, patient records or production planning on one supplier’s product cannot switch overnight, because migration takes months and usually needs the outgoing supplier’s help. Escrow buys the time to exit in an orderly way. Three situations matter:

• Insolvency. The supplier is declared bankrupt, a trustee is appointed, staff leave and support stops. The scenario escrow is written for, and where Dutch law does the most work.
• Discontinuation. The supplier withdraws the product, sunsets your version, or is acquired by someone with no interest in your deployment. More common than bankruptcy, and often left out of the release clause.
• Persistent failure to maintain. The supplier still exists and still invoices, but no longer fixes defects, ships security patches or keeps the product compatible with its dependencies.

Two-party and three-party arrangements

A two-party arrangement is a promise in the main contract that the supplier will hand over the source code if a defined event occurs. It is cheap and weak: nobody independent checks that anything was deposited or kept current, and — decisively — on bankruptcy you are asking the trustee to perform an obligation of the estate, which it is not obliged to do.

A three-party arrangement adds an escrow agent as a contracting party. The agent takes custody, checks the deposit, keeps it, and owes you a direct obligation to release it. That is the whole reason to pay for one: release becomes performance by a solvent third party under its own contract, not by a bankrupt estate. The agent also decides whether a release event has occurred, taking that away from a trustee with no incentive to help you.

What is actually deposited

The commonest failure is not legal. It is a deposit containing source code and nothing else. Source code alone does not compile: handed to a developer with no build instructions and no dependency list, a large codebase can take weeks of reverse engineering before it yields a running binary — time you do not have when the system is already unsupported. A deposit without build instructions is worthless.

Add an update obligation. A deposit made once at signature ages out within a release cycle or two. Tie deposits to the release schedule — every major release, or a fixed interval — and take a right to be told when one is late.

Verification: what you are paying for

Buy the middle option below as standard, and the full test where an outage would be existential. The file-level check alone is close to buying nothing.

• File-level check. The agent confirms the deposit is readable, virus-free and matches a file list. It proves something arrived, not that it works.
• Completeness and documentation review. The agent checks build instructions and dependencies against the deposit and reports gaps. This middle option is right for most customers: it catches the common failures — missing build steps, undocumented dependencies, a component you have no right to use — at a fraction of the cost of a full test.
• Full build and run test. The agent compiles the deposit in a clean environment and runs it against test data. The only level that proves the deposit works, but slower, dearer, and needing repetition as the software changes.

Release events, drafted so they cannot be argued about

A release clause is a trigger the escrow agent must apply under pressure and without legal advice. Every event should be establishable from a document or the passage of time, not from a judgment about the supplier’s conduct.

Two points do most of the work. Put the burden of contradiction on the supplier: the customer notifies the agent with evidence, the supplier has a short fixed period to object, and absent objection the agent releases. And fix the dispute route in advance — expert determination or arbitration on a short timetable — so an objection buys days, not months.

The Dutch insolvency question

Everything above is contract design. What follows decides whether it holds when the supplier is bankrupt.

What the trustee may refuse

Under art. 37 Fw, where a reciprocal contract has not been fully performed by either side at the time of the bankruptcy order, the counterparty may set the trustee a reasonable written period to declare whether it will perform; if it does not, it loses the right to demand performance in return. What art. 37 Fw does not do is terminate the contract or give the trustee a power to terminate. The contract survives; the trustee is simply not obliged to perform, and the counterparty is left with a claim in the bankruptcy under art. 37a Fw.

For software this means the trustee can decline maintenance, support, updates, hosting and further deposits: active performances that cost the estate money. Expect refusal. The question is whether it can go further and stop you using what you already have.

Nebula, Berzona and Credit Suisse/Jongepier

For a decade this was genuinely uncertain. In Nebula (Hoge Raad, 3 November 2006, ECLI:NL:HR:2006:AX8838) the Supreme Court held that although bankruptcy does not itself terminate existing agreements, a counterparty holding a right of use could not continue exercising it against the trustee as though no bankruptcy had occurred; that would let one creditor disregard the bankruptcy at the expense of the others. It was widely read as letting a trustee set aside a pre-existing right of use, and it alarmed licensees.

That reading did not survive. In ABN AMRO/Berzona (Hoge Raad, 11 July 2014, ECLI:NL:HR:2014:1681) the Supreme Court held that bankruptcy has no effect on existing reciprocal agreements or the obligations arising from them, and gives the trustee no power that the law or the contract does not give it — it cannot, for instance, terminate a lease that is still running.

The position was settled in Credit Suisse/Jongepier q.q. (Hoge Raad, 23 March 2018, ECLI:NL:HR:2018:424). The trustee may passively decline to perform, but bankruptcy does not give it the power to undo a performance rendered by the debtor before the bankruptcy, nor to end a continuing performance in so far as it consists of tolerating or refraining from something.

That phrase is what matters for software. A licence is in substance an undertaking by the rightholder to tolerate use that would otherwise infringe copyright — a continuing performance consisting of tolerating. On the current law, therefore, a licence validly granted before the bankruptcy survives it, and the trustee cannot revoke it. The trustee can refuse everything active, but cannot switch off a right of use you hold.

What that means for your arrangement

Two things follow. Keep the release obligation on the escrow agent, not the supplier: set up as an independent custody held by a third party, the release is the agent’s own performance, and the trustee’s power under art. 37 Fw bites on performances owed by the estate rather than on a solvent agent, whereas a two-party promise requires performance by the estate, which the trustee can decline. And grant the licence up front rather than on release — the single most important drafting point, dealt with below.

In a restructuring rather than a bankruptcy, art. 373 Fw restricts reliance on ipso facto clauses — provisions letting a counterparty amend, suspend or terminate a contract merely because a restructuring procedure has started. That restriction operates in the scheme procedure, not in bankruptcy, and the answer to it is again structural: where the arrangement is drafted as an independent custody by a third party, the release trigger operates on the agent’s own obligation and does not amount to an ipso facto provision open to being set aside, in a WHOA restructuring any more than in a bankruptcy.

How the licence must be structured

Escrow gives you a copy of the source code, not the right to do anything with it. Source code is a protected work; compiling it, modifying it and running the result are restricted acts. Without a licence covering them, a released deposit is a folder you may not open. Pair the escrow with a licence expressly permitting the customer, on release, to use, compile, modify and further develop the source code, and to have that done by a third party — in practice you will not do the work yourself.

Then the timing. A licence granted on release is fragile. If the release event is the bankruptcy itself, the grant would have to be made by a debtor who, from the day of the bankruptcy order, has lost the power to dispose of assets in the estate; art. 23 Fw and art. 35 Fw stand in the way, and the trustee will not make the grant for you. Credit Suisse/Jongepier means the trustee cannot revoke a licence you already had — but there is nothing to revoke if you never had one.

Grant it in the contract itself, before any insolvency, subject to a condition precedent: granted now, taking effect on a release event. The right exists from the date of the contract; only its effect is deferred. Dutch law is generally receptive to this structure. In Rabobank/Reuser (Hoge Raad, 3 June 2016, ECLI:NL:HR:2016:1046) the Supreme Court accepted that where a conditional right was created before the bankruptcy, fulfilment of the condition afterwards took effect without any further act by the debtor. That case concerned a conditional transfer of goods and a pledge over the conditional right. Applying it to a conditionally granted copyright licence is an extrapolation supported in the legal literature rather than a point settled by the courts, and it should be presented as such.

Confirm also that use of the released material needs no further consent from the supplier or its trustee, and that sub-licensing to a successor developer is permitted.

SaaS and cloud: source code is not enough

For software you run yourself, source code plus build instructions plus a licence is close to a complete answer. For a service it is not. If the supplier’s platform goes dark you have lost the application, the environment it ran in and your data — and source code restores only the first, slowly. A SaaS continuity arrangement must add three things:

• The operational environment. Container images, infrastructure-as-code definitions, configuration, network and security settings, runtime dependencies — enough to stand the platform up elsewhere.
• The data. Regular exports of your own data in a documented, non-proprietary format, with the schema. Data you cannot read is not data you have, and the exports should run throughout the contract, not only on release.
• The hosting relationship. A route to step into the supplier’s contract with its hosting provider, or notice to that provider that you may take over the account and pay directly.

Alternatives, and who pays

Escrow is not always the best value, particularly for standard products where you are one customer among thousands and the realistic risk is a sunset rather than a failure. Three lighter options are often more useful: a data exit right — periodic exports in a documented format, tested at least once — covering much of the exposure at almost no cost; a right to a running copy, a deployable image you can run for a transitional period, restoring service far faster than a rebuild; and direct payment to the hosting provider, keeping the environment running while you migrate — the cheapest cloud continuity, and most often overlooked.

Where you do use escrow, expect a one-off set-up fee, a recurring annual custody fee, and separate charges per verification that scale with the depth of the check. Cost sits with whoever wants the protection, normally the customer, though a supplier offering escrow as a selling point may carry it, and a multi-beneficiary arrangement covering several customers of one product spreads it — the usual landing point where a supplier resists. Make non-payment something the agent must notify to you, with a right to pay in its place.

A checklist for negotiating an escrow arrangement

• Is it a genuine three-party arrangement with an independent agent owing you a direct release obligation?
• Is the licence to use, compile, modify and further develop the source code granted now, subject to a condition precedent, rather than promised on release?
• Does the deposit list include build instructions, dependencies, licence keys and documentation, not just source code, updated on each release?
• What verification level is contracted, and how often is it repeated?
• Are the release events determinable from a document or the lapse of time, with a short objection period and a fast dispute route?
• For SaaS: are the environment, the data and the hosting relationship covered, or only the code?
• Who pays, what happens if the supplier stops paying, and does the escrow agreement fit the main contract’s governing law and IP clauses?