Source Code Escrow

Here's a nightmare you'll wish would end with you waking up. Your company spends $500,000 to license some software. Then the company you paid half a million dollars to goes bankrupt. Now you have $500,000 worth of orphaned software. I'll take a rain check on being you while you're explaining this one to the board.

Here's the problem in a nutshell. When you license software, you typically get a license to use what's called the "object code." Object code is the machine-readable code. Not even the nerdiest computer nerd you know can read object code.

Mere humans read and work in source code. Source code is simply computer code humans can read.

If your software developer goes under or can't support you, you'll need the source code if you're going to have any hope of hiring your own programmer to fix bugs, develop new features or make any changes in the computer code you're using.

Here's the rub. You want to have the source code in case you need it. Your developer doesn't want to give it to you because they consider it their ultimate trade secret. The problem is that from their perspective, they're right.

Developers never want to give you the source code because it's their lifeblood. It's the secret sauce that prevents you from easily stealing their intellectual property.

The compromise is a source code escrow.

The typical setup will have the developer deposit the source code in escrow with a trusted third party. The escrow agreement requires the escrow agent to not release the source code to you unless certain release conditions are met. These conditions will typically be things like the developer's bankruptcy or failure to support you as required by your agreement.

While the basic outline of a software escrow may sound simple, it turns out that these are relatively complex deals. Many of the companies that handle escrows have model agreements on the Web, which make for a good starting point and certainly an improvement on reinventing the wheel. But the key word is "model" agreement.

Every deal is different. There are traps for the unwary and inexperienced throughout the process.

As you delve into this area, you'll find that many areas of the law are implicated, including bankruptcy and intellectual property law. Do it wrong and a bankruptcy court may prevent the release from escrow although you have an agreement that would appear to require it. Screw up on the intellectual-property side and you may find out that you don't have the license you need to do what you thought you could with the source code.

Here are three quick tips on doing this right:

Make sure that your agreement requires them to promptly deposit revised source code once they release a new version.

When you negotiate for this requirement, don't do what almost everybody does in this situation, which is, of course, forget about it. You have to insure that somebody in your organization is responsible for monitoring these future deposits. If you don't, my experience tells me that the developer will usually forget to make the deposits.

Verify that they've escrowed everything that is supposed to be escrowed and that the CD-ROM or other media is holding what it purports to be holding. To verify, you'll need to have an agreement with your developer to have a trusted third party work with the source code to confirm that it is what it purports to be and that it's complete. The problem with verification is that it can be expensive.

The last cautionary word is to avoid the developer's already established escrow setup. Every arrangement I've ever seen like this has an escrow agreement in place that's extremely one-sided in favor of the vendor.