Open source risk in a code escrow.

Open source risk in a code escrow is the exposure a buyer carries even after doing what looks like the prudent thing. The logic of an escrow is sound: a customer depends on software from a vendor that might fail, so the source is deposited with a neutral third party and released to the customer if the vendor goes under or stops supporting the product. What the arrangement quietly assumes is that holding the source is the same as being able to use it. For modern software, built on a deep tree of open source components, that assumption does not hold. The deposit is full of code the vendor did not write, governed by licenses the escrow agreement never touches.

This is a compliance and diligence question, and it belongs to the wider work of finding and pricing open source exposure in a transaction. The full treatment lives in the pillar on open source M and A and compliance. Here the focus is the escrow itself: what it covers, what it does not, and what a buyer should verify before treating it as protection.

What a code escrow actually protects

A code escrow is a delivery mechanism. It answers a single question: if the vendor disappears, can the customer still get the source to keep the software alive. The agreement sets the release conditions, names the deposit, and binds a third party to hold it. That is genuine protection against one specific failure, the loss of the vendor. It is worth having for any business that depends on software it cannot itself maintain. The mistake is treating it as protection against every failure, because the escrow is silent on the most common one in practice, which is the license terms attached to the code inside the deposit.

An escrow grants you possession. It does not grant you rights. Possession of the source and the right to run, modify, and continue shipping that source are separate things, and the second is governed by the licenses of every component the deposit contains.

Why escrow does not cover open source license obligations

When an escrow releases, every open source license inside the deposit comes with it, unchanged. A copyleft obligation that applied to the vendor applies to you the moment you take over the code. A source available component, such as one under the Business Source License or the Server Side Public License, still restricts how you may use it in production, and the escrow does nothing to lift that restriction. If a component was relicensed after the vendor adopted it, you inherit the new terms, not the ones the vendor started with. The escrow agreement is between you, the vendor, and the escrow agent. The component licenses are between you and projects that are not party to the deal at all.

This is where a release can disappoint. A buyer triggers the escrow expecting to keep the product running, then finds that doing so means honoring copyleft source sharing obligations, or buying a commercial license for a source available component, or rebuilding a piece outright. The recent relicensing wave, covered across the pillar on license change and relicensing, made this far more likely than it was a few years ago, because components that were open at deposit time may carry restrictive terms by the time the escrow releases.

What a release really gives you, and what it does not

Picture the release happening. The deposit lands, and an engineering team opens it. The first surprise is usually scope: the vendor's own code is a thin layer over a large tree of open source it pulled in. The second is state, because nobody has checked whether the deposit even builds, or whether it matches the version running in production. The third is licensing, the question this article exists to raise, because no one mapped the license of each component at deposit and no one tracked changes since. A release that should have been a safety net becomes a discovery exercise, run under time pressure, by people who did not write the code.

The fix is to do that discovery before you ever need the release, not after. The same systematic walk of the tree used in a deal, set out in the open source due diligence checklist, applies to an escrowed codebase. Map it once at deposit, and a future release becomes an asset you understand rather than a box of unknowns.

What to add to a standard escrow arrangement

A few additions turn an escrow from a delivery promise into reliable protection. Require a current bill of materials to be deposited alongside the source, so the contents are documented rather than discovered. Require a record of the license state of every component, direct and transitive, refreshed when the deposit is refreshed. Require a build verification, so the escrow agent or a neutral party confirms the deposit compiles and matches the production version. And review the highest risk components, the strong copyleft and source available ones, the same way you would in a deal, so you know in advance what a release would oblige you to do. These steps cost little at deposit time and save a great deal at release time. The quantification approach is the same one used for transactions, described in quantifying open source risk for a deal.

Open source risk in a code escrow is the gap between holding source and being able to use it. The escrow secures the source. The licenses inside still govern what you may do with it. Map the tree at deposit, document the license state, verify the build, and review the components that carry real obligations, so a release protects you rather than surprises you. This article is commercial and licensing risk advisory, not legal advice. For interpretation of an escrow agreement or any license inside the deposit, your own counsel is the right place to turn.