When the Vendor Disappears and the System Keeps Running
An Israeli financial services company implemented a core system built by an outside software vendor and structured its entire workflow around it. Three years later, the vendor ran into financial trouble and ultimately ceased operations. The client was left with business-critical software, no access to the source code, no ability to fix bugs, and no way to upgrade the system.
This is precisely the scenario a source code escrow agreement is designed to prevent. It is a legal mechanism under which an up-to-date copy of the source code is deposited with a trusted third party and released to the client only upon the occurrence of predefined conditions. As Israeli SaaS, fintech, and e-commerce companies increasingly build operations around third-party software components, this issue has become relevant well beyond large-scale transactions, extending into everyday engagements with critical vendors.
What Is a Source Code Escrow Agreement
In a standard software licensing deal, the client receives access only to the compiled, binary object code — not the source code from which it was built. This is a legitimate arrangement that protects the vendor's intellectual property, but it creates total client dependence on the vendor for maintenance, bug fixes, and future development.
A source code escrow agreement resolves this tension. The vendor deposits a copy of the source code, along with technical documentation and sometimes the development environment, with an independent, professional escrow agent. The agent does not disclose the code to the client but holds it until one of the release conditions set out in advance in the agreement is triggered. This way, the vendor preserves the confidentiality of its code as long as it remains operational, while the client gains assurance that the material will become accessible if the vendor can no longer meet its obligations.
Under Israeli law, this structure relies on the principles of the Trust Law, 5739-1979, which governs the duties owed by a trustee to the depositor and to the beneficiary. It is essential to clarify in the agreement that the deposited code is a protected work under the Copyright Law, 5768-2007, and to specify explicitly which usage rights are granted to the client in the event of release.
When to Require an Escrow Agreement
Not every software engagement justifies an escrow agreement. The need should be assessed based on how critical the system is to business operations, the degree of dependence on a single vendor, and the real risk of financial or operational instability on the vendor's part.
- Core systems underpinning revenue, operations, or regulatory processes
- Software purchased from a small vendor or startup without an established financial track record
- Situations where the client is the vendor's sole or relatively small customer within its portfolio
- On-premise solutions or software installed on the client's own infrastructure, as opposed to a flexible cloud service
- A regulatory or contractual requirement imposed by the company's own end customers (for example, in banking or insurance)
By contrast, with flexible SaaS services where switching vendors is relatively straightforward, investing in an escrow agreement may be disproportionate. The decision should be made as part of a business risk analysis, not as a generic clause copied from a template agreement.
The Three-Party Structure of the Agreement
A properly constructed escrow agreement is not bilateral but triangular, involving three parties: the vendor (depositor), the client (beneficiary), and the escrow agent (an independent third party). It is essential that the agent be a professional entity specializing in escrow services, not an attorney or accountant affiliated with either party, in order to avoid conflicts of interest when deciding whether to release the code.
The tri-party agreement should precisely define each party's role: the vendor's obligation to deposit regular updates to the code, the agent's duty to verify the integrity of the deposited material, and the client's right to demand release upon the occurrence of a defined condition. It is advisable to include a mechanism allowing the client to periodically verify the adequacy of the deposit, rather than relying solely on a formal confirmation that the code "has been deposited."
One point that should be addressed in advance is what happens if the vendor itself enters insolvency proceedings. The Insolvency and Economic Rehabilitation Law, 5778-2018, limits the validity of contractual clauses that automatically cancel or alter rights upon a party's entry into insolvency proceedings (ipso facto clauses). Release conditions should therefore be drafted carefully, based on objective and verifiable events, and legal counsel should be consulted on the enforceability of such provisions against a trustee or receiver appointed over the vendor.
Events That Trigger Release of the Code
The heart of the agreement is the list of release events, since these determine when the client actually gains access to the code. Drafting them too broadly may prejudice the vendor; drafting them too narrowly strips the agreement of practical value for the client.
- Actual cessation of the vendor's business operations, or the commencement of insolvency or winding-up proceedings
- A material and continuing breach of the service or license agreement, including breach of a critical service level agreement (SLA)
- Failure to maintain or support the software beyond the period defined in the agreement
- Transfer of ownership of the code to a third party that does not commit to continuing support for existing customers
It is advisable to establish a notice mechanism and a cure period before actual release, to prevent hasty release triggered by a contractual dispute that could otherwise be resolved. At the same time, in cases of clear-cut insolvency, a lengthy cure period serves little purpose, and the mechanism should be tailored to the type of triggering event.
Verification and Updating of the Deposit
A one-time deposit of source code, without ongoing updates, has little practical value. Software changes constantly, and code deposited two years ago may bear little resemblance to the version actually running at the client's site. The agreement should therefore include a periodic update obligation, typically tied to each significant release, rather than a once-a-year deposit.
Beyond this, it is advisable to incorporate a verification service, offered by many professional escrow providers, under which the agent confirms that the deposited code actually compiles and runs, rather than merely confirming that it exists on storage media. Without such verification, the client may discover during a crisis, at the very moment the code is needed most, that the deposited material is incomplete, corrupted, or incompatible with the actual runtime environment.
It is also worth including in the agreement a detailed list of all documentation components required beyond the code itself: architecture documents, infrastructure configurations, database scripts, and details of any open-source libraries the software depends on. Without these elements, even a complete source code deposit may be of little practical use.
Practical Recommendations for Proper Implementation
Companies considering a source code escrow agreement, whether as vendors or clients, should address the issue as part of the broader negotiation of the engagement, not as a secondary attachment. A few practical principles can prevent disputes down the road.
- Select a professional, reputable escrow agent, not a party affiliated with either side
- Draft release events that are clear and verifiable, tied to objective conditions rather than subjective interpretation
- Establish an ongoing update obligation and a periodic verification mechanism for the deposited material
- Address the vendor's potential insolvency scenario in advance, including coordination with license terms under the Copyright Law
- Define usage rights in the code following release, including the right to modify, fix, and assign to a subcontractor for maintenance purposes
- Revisit the issue upon each significant renewal of the vendor agreement, particularly if system usage has expanded
A source code escrow agreement is not a substitute for thorough due diligence on vendor stability, but it is an effective legal tool for reducing genuine operational risk. Companies that build critical operations on third-party software should treat it as an integral part of the deal structure, not a clause relegated to the final pages of the schedules.
The information contained in this article is general in nature and does not constitute legal advice. For advice tailored to the specific circumstances of your company, we invite you to contact our firm.
