All too often a business person comes to me and says “we need to include escrow in that agreement we’re working on.” Sometimes it makes sense, sometimes it doesn’t. Sometimes it can be more trouble than it’s worth.

If your company licenses a piece of mission-critical software, it’s your job as the attorney (read: the risk manager) to ensure that the licensor continues to support and maintain the software (e.g., by releasing bug fixes and updates) for the term of your license. That’s typically done by adding terms to the license to ensure that they will make updates available to you either at no charge or a mutually agreed-upon charge (e.g., upgrade fees for feature releases and no charge for maintenance releases, bug fixes, new releases which correct security issues or are needed to comply with applicable law, etc.), or by executing a separate maintenance agreement for the software that gives you all updates for a monthly or yearly fee. You’ll also want to ensure that you are entitled to software support from the licensor (email, phone, in-person visits, user conferences in Bermuda, etc.).

That’s all well and good, but it rests on a very important assumption — (1) the company stays in business, and (2) the company doesn’t breach the agreement and you terminate (thereby terminating the license), either of which could leave your company hanging high and dry. The solution most often suggested? Software escrow. (There are other protections you can implement as well, such as ensuring you have a perpetual license and ensuring you have 365(n) language in your license agreement, but those are topics for another entry.)

Software escrow is, essentially, a form of insurance. A third party (such as Iron Mountain, called the “escrow agent”) will hold a copy of the source code for the software and other related materials “in escrow,” and release it to a party (such as the licensee of the software) if certain release conditions (usually called “release triggers”) are met. This way, if a release trigger occurs, you (the licensee) can go directly to the escrow agent and request a release of the escrowed materials, without necessarily involving the licensor. If the software is released from escrow, the licensee can use the source code to continue to update and support the software.

The simplest way to address escrow is to add an escrow provision directly into the license agreement. At a high level, the typical escrow provision (if you are the licensee) should contain the following at a minimum: (1) agreement on who the escrow agent is, (2) agreement on who will negotiate the agreement with the escrow agreement and pay for escrow services, (3) agreement on what materials will be escrowed, (4) agreeent on the release triggers, and (5) agreement on the licensee’s rights to escrowed materials upon release (make sure this is pretty broad if you’re the licensee).

I’ll note a couple of important considerations when drafting an escrow provision:

• Materials to be escrowed. I’ve seen too often where an escrow provision says that the source code for the licensed application will be escrowed, and that’s it. That’s going to make escrow pretty useless, and result in your ops team yelling at you later on (and if an escrow release is needed, you can bet that it’ll be a “fire drill” situation so nerves will be on edge anyway, and they may be looking for someone to throw under the bus.) You want to ensure that the software in the escrow is updated regularly to ensure that the escrowed version is as close to the current release as possible (say, every quarter or six months); otherwise, you could be left with a significant out-of-date version of source code released from escrow. You also want to ensure that the software that’s escrowed is tested by the licensor (i.e., that they’ve taken the source code, compiled it, and have verified that it works). Most importantly, you want to ensure that the escrowed materials include detailed instructions on how to compile the software to make it usable, and what third party tools are needed to compile and use the source code. Otherwise, escrow is pretty useless. You should also ensure that any open source tools used in connection with the source code are included in the escrowed materials, to save your team the trouble of having to go find them.
• Ensure you have access to licensor personnel for help. If there’s an escrow release, the best way to ensure you can work with the materials is to get help, ideally from the licensor’s own personnel. However, if your contract has a nonsolicitation or non-hire provsion, you could be prohibited from contracting with them. You should ensure your escrow provision allows you to engage the licensor’s personnel for assistance with use of the escrowed materials.

One other very important thought here…you can’t escrow a service or environment. I’ve seen requests for software escrow for the codebase for a licensed ASP application or other software as a service used by a company. A standalone software application is one thing, but an outsourced environment is a whole another ball game. The source code is all well and good, but if you don’t have the ability to replicate the platform and environment in which it resides, the source code won’t be much help to you. If you’re really willing to go there (and it’s that mission-critical), ensure that the escrowed materials includes network diagrams, lists of third party software/hardware needed to replicate the environment, and all other materials your business and operations teams will need to make a significant go at replicating the environment in which the escrowed code will reside. You may also want to consider requiring the licensor to meet with your operations team to walk through how this would work, and provide documentation on this outside of escrow, so that your ops team can hit the ground running.

Lots of agreements involving technology have both an express warranty of non-infringement, as well as a third party indemnity against non-infringement. For instance, if you’re licensing a piece of your company’s software to a third party, the third party might ask for both a warranty of non-infringement, as well as a third party indemnity obligation. Sounds innocuous enough, right? An easy give in the negotiation? Maybe not.

Think about what could happen if someone comes out of the woodwork and asserts an infringement claim against your client. They’ll most certainly tender the claim to you for indemnification. However, if you have an IP warranty as well, they could conceivably also assert a breach of warranty claim against you for breach of the non-infringement warranty. This could allow the other side to “double dip” on damages, seeking both indemnification and direct damages.

“Good information,” you say. “No more warranties, just indemnification.” Not necessarily. An IP warranty does something that the indemnity does not…for certain types of IP claims, it can give the recipient of the warranty an “innocent infringer” defense to a claim of infringement, as they would allege that their allegedly infringing behavior was in reliance on the warranty. So, what you can do is give the warranty (it should be a “to the best of its knowledge” warranty ideally), but specifically state that the sole and exclusive remedy for breach of the IP warranty is indemnification pursuant to the IP infringement indemnity elsewhere in the agreement. This gives your client the best of both worlds, while ensuring you’re protecting your client.

On the flip side, if you’re licensing software, you always want to request both an IP warranty and an IP indemnity, and if the other side gives you trouble, just explain why the warranty is needed in addition to an indemnity, and offer the exclusive remedy language to placate any “double dipping” concerns they may have.