Source Code Escrow in France: Protecting Critical Software if the Vendor Disappears

Key Takeaways

• Source code escrow (séquestre or entiercement in French) means a trusted third party holds a copy of a program's source code and releases it to the customer only if an event defined in the contract happens: the vendor goes out of business, stops maintaining the product, or abandons it.
• It only makes sense when you don't own the code: licensed software, SaaS, or an agency's pre-existing components. If the rights were assigned to you and the code lives in your accounts, you don't need it.
• A plain deposit (APP, INPI e-Soleau, a bailiff's record) dates a creation; it gives you no access. Don't confuse the two.
• For SaaS, code alone is almost never enough: you also need deployment scripts, operating documentation, the database schema and access to your data.
• Write the release triggers around actual failure (maintenance not delivered, service down), not only around the opening of insolvency proceedings, which French commercial law partly neutralises.

Source code escrow is a three-party agreement: the vendor deposits the source code of its software with a trusted agent, the customer is named as beneficiary, and the agent releases the code only if a pre-agreed condition is met. It is the insurance a business takes out when a critical activity runs on software it doesn't own. This guide covers when escrow is worth it, what actually needs to be deposited, how to draft the clauses under French law, and why many escrow deposits turn out to be useless on the day they're needed. It is a practical guide, not legal advice; have a lawyer review significant contracts.

Deposit, escrow, assignment: three different things

In France, the Agence pour la Protection des Programmes offers both of the first two: timestamped deposits and an escrow service giving users conditional access to deposited software. The INPI's e-Soleau envelope only dates a creation: according to the INPI it is kept for 5 years, extendable in 5-year periods up to 20, and the option that stores the files is limited to 2 GB and 100 files. Neither gives you any right to use the code. Copyright in software arises when it is written, with no formality, as we explain in who owns the code.

Do you need escrow?

Ask one question: if this supplier vanished tomorrow, could we keep this software running and keep changing it?

Escrow is useful when:

• you depend on licensed software or a SaaS whose loss would stop the business (production planning, billing, a customer platform, regulatory software);
• the vendor is small or young, or depends on one or two key people;
• your custom development agency built your product on pre-existing components it keeps ownership of and licenses to you;
• a lender, investor, acquirer or large customer requires a continuity guarantee. In France the request often comes from a bank or a public buyer rather than from IT.

It is unnecessary, or nearly so, when:

• the software was built for you and the rights were assigned to you in writing;
• the repositories, hosting and third-party accounts are in your company's name;
• the product is easily replaceable, or open source you could pick up yourself.

In those cases the best guarantee isn't a deposit with a third party. It is having the current code, in your own accounts, every day. That is our default for custom projects.

What to deposit (and what everyone forgets)

An escrow holding a ZIP of source code from eighteen months ago protects nobody. What matters is whether another team could rebuild and run the software from the deposit alone.

For installed or licensed software:

1. The complete source code, including internal modules, scripts and template configuration files.
2. The dependency list with exact versions (lock files), and third-party licensed components.
3. Tested build and deployment instructions, with the tool versions they need.
4. Technical documentation: architecture, data model, key decisions.
5. Keys and certificates needed to build, or the procedure to regenerate them.

For SaaS, add:

1. Infrastructure as code (Terraform, Docker Compose, Kubernetes manifests) or a complete installation procedure.
2. The database schema and migration scripts.
3. The operations runbook: backups, monitoring, certificate renewal, scheduled jobs.
4. A regular export of your data in a documented format, or a right to access its backups. Without your data, recovered SaaS code doesn't give you your service back.
5. The list of third-party services (email delivery, payments, storage) and how to replace them or take over the accounts.

That last block separates a useful SaaS escrow from a symbolic one. Some providers call it "continuity escrow", where the arrangement also covers access to hosting accounts during a transition period.

Release triggers: the clause that matters most

The agreement must say, unambiguously, when the agent hands the code to the customer. Usual triggers:

• the vendor ceases trading or is dissolved;
• the vendor fails to provide the maintenance promised in the contract, after formal notice left unanswered for a set period;
• the product is abandoned (end of life announced with no migration path);
• the vendor is acquired and the buyer won't honour the maintenance commitments.

Be careful with insolvency. Article L622-13 of the French Code de commerce provides that, notwithstanding any contractual clause, no termination of an ongoing contract can result solely from the opening of safeguard proceedings, and the rule extends to receivership and liquidation. We found no case law settling the point for source code escrow specifically, but a trigger drafted only around "the opening of insolvency proceedings" is open to challenge, and the administrator may choose to continue the contract. The prudent approach is to tie release to observed failure: maintenance not delivered, service interrupted, no response to formal notice. Have an insolvency lawyer check this clause.

What you may do with released code

Receiving the code is not enough; you need the right to use it. On release, the escrow agreement or the licence should grant the customer a licence to:

• use, fix and develop the software for its own needs;
• have that work done by a third-party supplier of its choice;
• do so for long enough, usually the term of the original licence or without limit.

Without it, you hold a copy of code you are not legally allowed to modify.

Verification: the weak link

Most escrow deposits fail because nobody ever checked what was in them. Three levels of verification are common:

For truly critical software, ask for at least a build check at signature and at each major version. It is the same question, on a broader scale, that a technical audit answers: can another team take this system over?

How often to update

A deposit freezes one version. If the vendor ships weekly and updates escrow once a year, you'll recover software a year behind, incompatible with your current data. Agree on:

• an update at every major version, and at least quarterly for an active SaaS;
• a notification to the beneficiary at each update;
• ideally, automated deposits from the vendor's continuous integration pipeline.

What it costs, and who pays

Prices depend on the agent, the volume, update frequency and verification level, so check the APP's or a specialist agent's current rates directly. In practice the cost is negotiated: the customer pays when it alone asks for the guarantee, and the vendor builds it into its price when several customers require it. Weigh it against months of disruption while a replacement is built; our guide on whether to rescue or rewrite gives a sense of what a rebuild involves.

Checklist before you sign

• The software is genuinely critical and the supplier is a continuity risk.
• The deposit contents are listed, including build instructions, infrastructure and data (for SaaS).
• Triggers rest on observed failure, not only on insolvency proceedings.
• A licence to use and modify, including through a third party, applies from release.
• Update frequency is fixed and updates are notified.
• At least one build verification is planned.
• The release procedure (timing, documents required, dispute resolution) is written down.

Frequently asked questions

Does an APP deposit or an e-Soleau envelope protect me if my supplier goes bankrupt? No. Those deposits date a creation and serve as proof of prior existence. Only a three-party escrow agreement, or an assignment of rights with the code in your own accounts, gives you access to the code.

We're having custom software built. Do we need escrow? Usually not, if the rights are assigned to you in writing and the code lives in your accounts from day one. Escrow still helps for pre-existing components the agency keeps. See how to vet a software development agency.

Does escrow make sense for SaaS? Yes, provided it includes infrastructure, operating procedures and access to your data. SaaS code alone is rarely usable by another team within a reasonable time.

The supplier has already disappeared and there is no escrow. What now? Gather everything still reachable (hosting, repositories, backups), secure access, then have what remains assessed. Our handover checklist lists the steps, and our software rescue page explains how we step in.

---

At FNB Solutions, the client owns the code and IP from day one, and repositories and hosting stay in the client's accounts, which makes escrow unnecessary for the code we write. Our contract terms are public. If your business depends on software whose code you don't control, talk to us.

Sources

• Agence pour la Protection des Programmes (APP): timestamped deposits and escrow (conditional access to deposited software)
• INPI, preparing an e-Soleau deposit (French): retention periods and size limits
• Code de commerce on Légifrance, article L622-13: ongoing contracts in insolvency proceedings
• Code de la propriété intellectuelle on Légifrance: copyright protection of software