Printer Friendly

Addressing technology escrow in the RFP stage: a small up-front cost can provide significant value by keeping critical applications running in the face of vendor problems.

Companies in almost every industry license software for their mission-critical applications. From supply chain applications to inventory management, accounting, customer service, or logistics, if you are in a contract management position involved with software licensing, you need to have a good working knowledge of technology escrow agreements. This article will focus on the buyers, or licensees, of software and how they can negotiate the best escrow agreement, starting at the RFP or "request for proposal" phase.

Most contract managers who have been through software licensing negotiations are familiar with technology escrow. However, the issue of technology escrow--which protects the licensee if something happens to the software developer--is often an afterthought and added into negotiations at the last minute. For the best protection, contract managers should include technology escrow as part of the initial RFP and should work to include terms and conditions that will offer the best protection possible.

This article provides contract managers with practical advice on negotiating optimal protection for the software that runs their company's business and points out the pitfalls associated with letting the software vendor drive the process.

Overview of Technology Escrow

Technology escrow is like an insurance policy for your mission-critical software applications that is signed at the same time as the license agreement. However, many companies do not take the time to understand how technology escrow can protect them.

Technology escrow services are imperative when two or more parties are negotiating a license for mission-critical technology. The contracts management group, together with the IT procurement group and the compliance or legal department set up the agreement.

If a technology licensee is concerned that the developer will for some reason in the future no longer provide support, the licensee should request that an escrow agreement be put into place. This means that the technology (usually software source code and any other component necessary to allow the licensee to maintain the technology independently) is placed into an escrow deposit account. Once the escrow agreement is executed, the licensee becomes the "beneficiary" of these materials, contingent on certain release conditions.

If a release condition occurs (such as if the developer ceases operations or stops supporting the technology for other reasons), the licensee gains access to the deposit materials. This enables the licensee to maintain the technology independently and to keep the mission-critical application up and running.

It is important for the contract manager to understand that there are different levels of escrow protection. Some agreements release source code only under the condition of bankruptcy; others take into account much wider reaching release conditions. It is up to the contract negotiators to determine the level of protection required and to make sure the escrow agreement is crafted to their specifications.

Without a technology escrow agreement, a licensee's investment in technology is unprotected. Recovering the source code and maintenance materials by other means, such as through the court system, can take years, and by then, the company's operations and resources that were tied to that technology can be lost.

The Buyer's Side

Knowledge about the best practices surrounding technology escrow is imperative. Buyers, or licensees, are realizing that the face of technology escrow is changing. Where escrow was once just a checklist item, savvy licensees are now using escrow as a tool to protect themselves from any number of unfortunate conditions with the software vendor.

In the past, many contract managers involved in licensing software knew enough to ask, "Will the software source code be held in escrow?" When the answer from the developer was "yes," they happily moved on to the next issue without scrutinizing the terms and conditions of an escrow agreement or specifying exactly what they would need to continue to support an application in the event the vendor could not continue to support it.

To create an escrow agreement that really provides leverage, the contract manager needs to be an active participant in the process. In fact, the licensee organization should be prepared to drive the escrow process and to pay for the coverage to put a comprehensive agreement in place. Simply getting a "yes, we've got escrow" response from a vendor and then letting it handle the details of an escrow agreement without close supervision is a common mistake many user organizations make.

Some basic questions a contract manager should consider before licensing new software include the following:

* Should this software source code be put in an escrow account?

* If so, which release conditions are important to me?

* If the source code is released, will my organization be able to replicate the application?

A good rule of thumb for placing software source code into escrow is if it is considered "mission-critical" for your business. If this particular software application affects revenue, productivity, customer-service levels, or public safety or supports other applications that affect these things, you should execute an escrow agreement. Some licensees, especially in financial industries, make it a practice to escrow all software that is not "out of the box." Others go through a risk assessment to review their tolerance for the loss of an application.

Which release conditions are important? Many vendor-driven escrow agreements specify only "bankruptcy" or "ceasing to do business" as the conditions for releasing source code. However, as a licensee, you can craft release terms around lack of support or other issues important to you. These items give the licensee leverage if the vendor does not provide promised maintenance or support. The terms also can let a user organization define when it upgrades to a new version of the software or can specify what materials should be included in the escrow deposit in addition to just the source code rather than having this controlled by the vendor.

If source code is released, you want to make sure that your IT organization can get the application up and running as quickly and as smoothly as possible. To do this most effectively, some level of verification testing is recommended. Verification strengthens the leverage value of the escrow by ensuring that the materials necessary to recreate the application development environment are in the escrow account.

A properly drafted escrow arrangement that maximizes a licensee's protection will accomplish the following goals:

* Provide leverage after the license has been signed;

* Allow timely access to the source code and maintenance materials;

* Enable quick recreation of the application development environment;

* Give options to control future software upgrade timetables;

* Satisfy legal compliance;

* Avoid litigation; and

* Minimize risk of loss.

Why Start with the RFP?

So, you've decided that establishing an escrow account is important for a certain software application. Why should you introduce escrow at the time of the RFP? Starting the escrow agreement process early cannot be emphasized enough. This lets you drive the process, formulate a budget for escrow, and include the appropriate budget in the total licensing cost.

As with car insurance, a relatively small up-front cost can prevent major expenditures down the road in the event of problems. An escrow agreement and verification testing should be evaluated and included in the budget. If escrow is an afterthought, you are likely to hear, "This wasn't part of our budget."

When you have determined your shortlist of vendors, you can set certain bid conditions in regard to escrow. First, you should request that the software source code be placed into escrow; more importantly, it needs to be a condition of your escrow agreement, not the vendor's. Second, you will want potential vendors to fill out a deposit questionnaire to specify what elements are included in the escrow deposit. This lists the necessary deposit materials and an explanation of the time and investment required to recreate the application development environment. If these elements are set forth as a condition of doing business, you are likely to get agreement from the vendors. Remember, they are trying to win your business, and this is one condition that they can accommodate to do that.

As you start to narrow the playing field to choose a vendor, you will be testing its software and evaluating pricing. You will want to determine a cost for escrow and verification of the deposit contents from your escrow agent. This cost can then be built into the overall program budget.

If you have assumed ownership of the escrow process from the very beginning, closing the deal should be a cinch. The escrow agreement should be signed at the same time as the licensing agreement and should be filed as an exhibit to the license. All parties who receive a copy of the license also should receive the escrow agreement.

By negotiating a strong escrow agreement, you are supporting your software license agreement and decreasing your total cost of ownership.

Gartner, Inc., reports,
Enterprises that focus primarily on purchase price often end up
overpaying for software. Price represents no more than 50 percent of the
value in a software negotiation. Total cost of ownership is determined
largely by terms and conditions that accompany a contract. (2)

With an effective escrow agreement in place, you are adding to the value of your software license.

A Three-Party Agreement

Three parties are usually involved in an escrow agreement: the company licensing the technology (the licensee), the company that developed the technology (the developer), and the escrow agent--a neutral third party that vaults the source code and administers the agreement. Attorneys also generally represent the licensee and the developer to help them craft the most favorable terms for their client. As stated previously, whichever party initiates and drives the escrow agreement is typically the party that maintains the more favorable position with respect to the terms and conditions.

Although three parties are usually involved, escrow agreements can take the form of either "two-party agreements" or "three-party agreements." The two-party agreement is signed by the developer and escrow agent only, although a two-party agreement may have a large number of licensee beneficiaries. The developer, having pre-negotiated the escrow terms, simply names the licensees and maintains total control over licensee enrollments and terminations. The licensees do not sign, and are not party to, the agreement.

Two-party agreements exist to satisfy relatively simple requirements for escrow. This allows a developer to put an escrow agreement in place quickly and inexpensively to cover multiple licenses to different licensees when the licenses are sufficiently similar to be nearly "off-the-shelf." Two-party agreements are routinely paid for by the developer. Often, these types of agreements are triggered by one release event, such as bankruptcy or court order.

Unless your software is fairly basic and the only condition you are concerned about is bankruptcy, you should insist on a three-party agreement, even though this generally means that you will need to accept some or all of the costs.

A three-party agreement involves the developer, the licensee, and an escrow agent negotiating and signing an escrow agreement. Many larger organizations set up a master agreement and have new vendors sign onto this master agreement to simplify the process. The terms and conditions for escrow and the licensee's right to verify the escrow contents should be negotiated before the execution of the license agreement, and the two documents--license agreement and escrow agreement--should be signed at the same sitting. To simplify matters, the escrow agreement can be inserted as an exhibit or rider to the licensing agreement.

Licensees should never sign a license agreement without signing an escrow agreement at the same time; otherwise, the escrow agreement may become a distant and abandoned afterthought to be remembered only when it is too late. As a contract manager for a licensee, insist on a three-party escrow agreement that enables you to review, modify, and sign the agreement, even if you have to pay for the privilege.

Terms and Conditions

Terms and conditions generally are customized for each agreement. Any concerns you have about the developer should be addressed in the agreement.

At the very least, the following line items should be clearly defined and enforceable:

* Deposit update process and frequency,

* Release conditions,

* Objection period limited,

* Contrary instructions,

* Release process,

* Right to use after a release,

* Deposit contents,

* Verification rights,

* Payor of fees, and

* Dispute resolutions and controlling law.

These items will not be covered in detail in this article, but your escrow agent and attorney can assist you with these terms.

One aspect of an escrow agreement that is particularly important is "Under what conditions is the software source code released?" To strengthen your escrow protection, ensure that the release language is not tied to only one release event, such as bankruptcy or court order.

A commonly held misconception about technology escrow is that bankruptcy is the only release event. Although some simple agreements can be set up this way, it benefits the licensee to strengthen its escrow protection by using a more wide-ranging set of release conditions. Your attorney and escrow agent can provide a comprehensive listing of release conditions that can be used for better protection and leverage against lack of developer support.

Table 1 demonstrates the wide range of reasons that licensees request an escrow release. (3)

Loss of support (not bankruptcy) is the number-one reason for requesting an escrow release. By including "loss of support" as a release condition, licensees can use their escrow agreement as leverage, if necessary, and can request a source code release to get a developer to respond quickly to previously unrecognized concerns. The source code does not always end up being released in these situations, but the developer knows the customer has this option, and this situation may trigger it to start providing the promised support.

Note that bankruptcy--the basic release condition used in many two-party agreements--represents only 20 percent of the release requests. Ceasing business operations (without actually filing Chapter 11 or Chapter 7 bankruptcy) comes in second, with 22 percent, and is a release condition that is not covered by some basic agreements.

A real-life example demonstrates the power that a licensee can have by defining the terms of an escrow agreement. A large oil company licensed in excess of $100 million worth of software each year, and approximately 15 software packages were in escrow at any time. To ensure that its mission-critical applications were protected, the oil company negotiated a "we decide" clause in its escrow agreements. This clause meant that it could request the release of the source code for any reason. The oil company admits this was a difficult term to negotiate, and if used, it would allow an arbitration process that could allow the vendor to seek damages after the deposit was released.

However, this clause paid off for the oil company, when it requested source code after discovering that the supplier of its imaging software was being acquired by another firm. The oil company invoked the "we decide" clause and had the vendor's source code within two weeks.

A Process Timeline

The process chronology for creating the escrow agreement should occur along the lines of the bullets that follow. (Again, remember to start early and budget for escrow!)

* Conduct a risk assessment to determine the need for escrow and verification; (4)

* Include technology escrow as a bid condition in your RFP;

* Require a three-party agreement drafted by your organization as a condition of doing business;

* Have potential vendors fill out a deposit questionnaire (5) during the vendor selection process;

* Obtain a quote for escrow and verification testing from your escrow agent;

* Include the cost of escrow and verification in your budget;

* Negotiate a well-defined, fair, and balanced escrow agreement;

* Include your escrow agreement as an exhibit/rider to the license agreement;

* Execute both at the same time;

* Verify deposit contents immediately;

* Address and cure any deficiencies immediately after the verification test and retest (retesting is typically done at the expense of the developer, but only if you make it a term of your agreement);

* Work with a reliable escrow agent; and

* Stay involved!

Escrow as Leverage for Licensees

More and more licensee organizations are developing escrow best practices to safeguard their technology and intellectual property assets.

PricewaterhouseCoopers believes that intellectual property is one of the most important elements in the value of major corporations. Some analysts estimate that as much as 90 percent of the value of the world's top 2,000 enterprises in 2007 will consist of intellectual property of one sort or another. (6)

Licensees are starting to pose questions, such as "What if my front-end point of sale software isn't supported tomorrow?" and "What if the vendor for my logistics software is acquired?" The escrow process is beginning to play a pivotal role in the software acquisition process as licensees realize their dependence on missioncritical applications.

If positioned as a condition for doing business, most vendors will agree to an escrow agreement with specific terms and conditions that you negotiate to win your business. If you drive the process, technology escrow not only provides catastrophic insurance (i.e., if the vendor goes bankrupt) but also gives your company leverage with the vendor in the case of lack of support or other damaging scenarios.

Licensees also are realizing that by taking control of the escrow process and paying for escrow and verification on their terms, a small up-front cost can provide major value by keeping critical applications up and running in the face of vendor problems.
Reason for the Release of Escrowed  Percentage
Source Code                         of Requests

Loss of support                             30%
Cease business operations                   22%
Bankruptcy                                  20%
Depositor's request                          9%
Demand release                               6%
Payment                                      2%
Court order                                  1%
Breach of obligation                        <1%
Merger                                      <1%
Transfer of assets                          <1%

Table 1. Escrow Release Reasons


1. Gartner, Inc., Midsized Enterprise Summit Continuity Questions, Feb. 6, 2003.

2. Gartner, Inc., Management Update: Lower TCO through Effective Software Contract Terms and Conditions, Sept. 3, 2003. Accessed at

3. Research by DSI Technology Escrow Services on historical requests for escrow. Statistics do not include requests for releases processed by acquired companies Fort Knox and SourceFile before 2000.

4. A risk assessment formula created by DSI can be found at

5. A reputable escrow agent can provide you with a deposit questionnaire.

6. PricewaterhouseCoopers, Building and Enforcing Intellectual Property Value: An International Guide for the Boardroom 2003.

About the Author

FRANK BRUNO is a business strategist with DSI Technology Escrow Services, an Iron Mountain Company. He consults with corporations and contract management professionals throughout the United States on intellectual property protection. Send comments on this article to
COPYRIGHT 2004 National Contract Management Association
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2004 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:request for proposal
Author:St. Bruno, Albert Francis
Publication:Contract Management
Geographic Code:1USA
Date:Jul 1, 2004
Previous Article:Protecting proprietary information submitted in a proposal: explore the methods available to prospective contractors to protect proprietary...
Next Article:Invisible terms in international contracts and What to do about them: contractual literacy avoids unnecessary problems, builds a stronger foundation...

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters