When purchasing a million dollar software product with a quarter-million dollar implementation and 18% annual maintenance fee, it’s probably reasonable to guess that the buyer expects to keep the product around for a little while. The fear is that the vendor, however well intentioned, won’t be able to survive in this interesting world of mergers, acquisitions and bankruptcies. So the buyer asks for a little insurance policy known as “source code escrow.”
For those of you who don’t already know, software is developed in a 2-step method. What you install on your computer (the executable) is actually the result of the second step, the object code. It’s machine readable only. The developers code in a human-readable version known as “source code” and go through a process called “compiling” to convert the source into object.
In the event that a future developer would want to modify an application, then, they need the source code to do so. There are some specialized tools (known as decompiliers) to help in the event that you don’t have the source code, but generally speaking, having access to all of the original source files is the easier way to go. And in fact, most license agreements expressly prohibit reverse engineering or decompiling.
But the source code is really the crown jewel of the software company. Giving it to everyone and anyone who asks isn’t a good idea. Recognizing the fear discussed earlier, though, the vendors are sometimes willing to place their code into escrow. Source Code Escrow is a service offered by a variety of organizations (such as GuardIT, Iron Mountain and others), called escrow agents. The vendor can “deposit” copies of the source code and then have an agreement with the Escrow Agent to only release the Source Code to specific recipients in the event of a “Release Condition.”
In theory, if the vendor were to suffer a Release Condition (usually something catastrophic to the vendor’s health, such as bankruptcy), the buyer could send a notice to the Escrow Agent that such a Release Condition has happened. The Escrow Agent, through a contractually-detailed process, confirms the condition and then would release the source code to the buyer.
Through contractual restrictions between the buyer and the vendor, the buyer is normally then allowed to use the source code to maintain their copy of the software. This doesn’t allow the buyer to sell or otherwise divest themselves of the source code – it merely offers the buyer a way to continue to help themselves in the event of a problem with the executable. In some rare cases, the buyer might also have the ability to create derivatives of the source code – new versions of the product, so to speak, but again, this is almost always limited to the buyer’s own use and not for resale to others.
Practically, though, source code escrow is a bit more tricky. First is the source code escrow agreement and the various things that have to be properly defined, such as the Release Conditions and the process by which the Escrow Agent would release the code in the event of one of these conditions. Buyers always want to play a bit more fast and loose than the vendor (for obvious reasons). But for the most part, these issues are resolved in favor of the vendor.
Second, the Escrow Agent doesn’t provide escrow services for free. Some vendors will offer to pay for the service, but most require the buyer to pay the annual costs involved. These are usually relatively nominal – $1500/year or so. But some Escrow Agents charge a small fortune. This cost may be easily forgotten when budgeting – or may be overlooked in later years and the service then lapses.
Third, the quality of the code placed into escrow is important. Most good escrow agreements have stated periods upon which the vendor is supposed to update the code or re-deposit new code. This could be on an annual basis (which is usually fine for software that’s not updated frequently or is less expensive) – but the buyer’s perspective says that they always want the source code equivalent of the most recent released commercially-available product. So there are times where the vendor will have to pay for multiple deposits and will want the buyer to share in that cost. Remember, though, that HUNDREDS (or thousands) of buyers may be beneficiaries of an Escrow Agreement – so buyers generally shouldn’t have to pay for deposits (as one deposit can satisfy all buyers).
Perhaps most important in the escrow discussion, however, is the ability of the buyer to actually make use of what they’ve received in the event of a release. Unless you, as a buyer, have an IT staff that’s educated on the programming language used to write the code in the first place – and have the tools to debug and then compile any changes you were to make, source code access might not do you any good.
In the age of ASPs and SaaS vendors, having source code escrow is seen as a remedy for the problem of not having the executable running at your physical location. But, consider whether you have all of the other back-office requirements needed to effect a product’s use. Having the source code to their product might get you that product – but if that product also requires, for example, a SQL or Oracle backend database, do you also get THOSE products as well? Probably not. So source code won’t help you as much as you would hope.
Overall, then, when considering source code escrow, make sure that:
- it will actually provide you what you need to stay operational;
- cost a reasonable sum in relation to the value (just like any other purchase);
- that the terms of an Escrow Agreement are reasonable and that Release Conditions are clearly defined and not unduly burdensome to prove or meet;
- your in-house IT staff has the ability to make use of the code.
If the answer to any of those questions is NO, look for other solutions to the possible problem of the vendor shuttering its doors. By way of example, one creative idea I’ve seen is to have the vendor (in an SaaS model), actually host the physical server within the buyer’s IT facilities. The vendor would remotely access the box for maintenance and service, just like they probably would if the box sat in a hosted data center. The only difference is that in the event of trouble with the vendor, the box was sitting in the buyer’s IT shop – readily accessible by the buyer without having to negotiate with an Escrow Agent that a release condition was met.
Anyone have other creative solutions to this problem?
LicensingHandbook Archive 