Organizations rarely invoke software escrow clauses or agreements, but they should consider them when negotiating with new, marginal or small software vendors if the application is business-critical. Software asset managers and negotiators can use the tactical guidelines in this research to help their organizations ensure that they can obtain the software source code when they need it.

• Licensees that include a "source code clause" in a standard software license agreement will have limited protection and reduced chances of actually obtaining the source code when required.
• A third-party escrow agreement with a major escrow agent will provide more protection to a licensee, particularly if the software the company wants to license would be difficult to replace and the software vendor's long-term viability is precarious.
• Organizations generally do not need to use escrow agreements for large software vendors that have many customers, unless the product they are licensing is customized code or a specialized market product that few customers use.

Software negotiators and managers should:

• Investigate an escrow agreement, if the application you are licensing through a small software vendor is mission-critical to the business, not easy to replace with a substitute product and/or represents a significant investment.
• Document what can trigger the transfer of software source code from an escrow agent to a licensee.
• Stipulate rights to the most current version, as well as to any back versions currently in production. Also, specify rights to all documentation and any third-party software that the organization needs to use the escrowed software effectively.
• Include rights to audit and run verification of the escrowed software.
• Assign skilled personnel to maintain and manage the escrow relationship, monitor release conditions (such as significant financial difficulties) and test the software in escrow.

The economic downturn has placed some marginal software vendors at risk of going out of business. Software asset managers and licensing-agreement negotiators need to obtain updated financial information about smaller vendors to determine if they will remain viable. This is particularly important if the software that they are using is mission-critical to their organization, represents a significant financial investment or is not easy to replace with an alternative product.

Organizations that license software ("licensees") from software vendors ("licensors") need protection when the licensor no longer provides technical support for the software because it has gone out of business or has discontinued technical support for some specific software products. However, licensees may encounter problems when they try to obtain software code from the escrow agent. Licensees can prevent most of these problems if they develop and sign a well-defined agreement with the software vendor and escrow agent. This research provides software negotiators and managers with guidelines to ensure that escrow agreements are effective.

An important note: Gartner is not a legal firm and does not provide legal advice. The information contained in this research may not apply to your company, and should be used for the purpose of identifying and discussing potential areas of risk with your legal department.

Software license agreements are usually slanted in favor of the vendor, and may contain vague or ambiguous terminology when addressing the rights of the licensee because software vendors write the escrow clauses in standard license agreements. Because the license agreement is the contract that controls the customer's use of the software, software-licensing negotiators must carefully negotiate the agreement to clearly document rights to use the source code in case an event occurs that triggers the release of the source code. The escrow agent does not own the intellectual property (IP) — the source code; therefore, organizations need to include the rights to the software in the license agreement and not in the escrow agreement.

Advice: Understand that you will need to negotiate and define the following issues, which this research covers in more detail, in your software license agreement:

• The "release" criteria and statements, such as: "the vendor is no longer providing support for the software." This generally includes the vendor going out of business, no longer supporting the software and ceasing to pay the escrow fees.
• The releases that will be included (current and back releases) and how soon you expect the vendor to deposit the next version after general release.
• Audit and verification rights.
• The right to modify the source code.
• The right to expand the usage of the software. For example, if the license agreement is for 500 named users and you obtain rights to the source code, you will want to be able to expand usage rights in the future if necessary. This right also needs to state that, if you obtain the software escrow, the licensee can expand usage rights at no additional cost.
• Dispute resolution processes and escalation paths (for example, via court or arbitration).
• What the deposit will include. This will often not only include the source code, but also:
  • Names, addresses and phone numbers of personnel who have been supporting the code
  • Any third-party code, including open source, that is needed to run the software
  • Compliers
  • Documentation about the software
  • Any customization made to the code for the licensee

Once the organization has determined that it will pursue escrow agreements due to concerns about the software vendor, it must understand that most organizations handle escrow agreements in one of two ways. The easiest way involves including a clause in the software license agreement that makes the licensee a beneficiary of an escrow agreement that is between the vendor and the customer. The other method is a three-party agreement with the software vendor, the customer and the escrow agent, who all sign the contract. This method gives more rights to the customer to receive notification that the software has been deposited, and perhaps to run verifications on the software that has been escrowed. When using the first option, the licensee will include an escrow clause in the software-licensing agreement, and generally this clause states that the customer can obtain the escrowed software if the software vendor goes out of business or fails to provide product support. The software vendor will add the customer's name to its agent's list of customers who have rights to escrowed source code, and the software vendor pays the yearly escrow fees for each customer added to the list.

The licensee generally does not receive any type verification that the licensor has deposited any new releases of the software or rights to verify the software, when using a clause in the software licensing agreement. In general, the licensee does not have to pay additional fees to ensure that these rights are included in the agreement. It is also usually easy to negotiate the inclusion of these types of clauses into a software contract, but this arrangement provides little in the way of assurance for the licensee. In fact, there is generally no method that enables the licensee to even ensure that the licensor has actually listed the organization with the escrow agent, or that the licensor is continuing to deposit the software or continues to pay the escrow fees.

A two-party agreement between licensor and escrow agent does not offer the licensee (who is simply a "beneficiary" to the agreement) the same level of protection as a three-party agreement. For example, if the licensor is failing, and does not pay the agent the annual escrow fee, the licensee may never know, and will not get a release of the source code in the event of the licensor's bankruptcy, since the licensor breached the escrow contract. The licensee may also try to obtain the source code and find out that the only version available is a different version than the one that the organization is running, or, even worse, the licensee may discover that the software deposited is not complete and will not run.

The three-party agreement, which is between the licensee, the licensor and the escrow agent, provides the licensee with the most rights to the source code. In these agreements, the licensee pays an annual fee of between $1,500 to $2,000 a year to an escrow agent, who acts on behalf of the licensee and who may also charge the licensee an initial "setup" fee. In these agreements, the licensee is party to the deal, and will generally have a higher chance of actually obtaining the source code. In addition, most three-party arrangements usually include rights to additional services. For example, the agent will notify the licensee when the vendor makes a new software deposit for new software versions, and the licensee will have the right to verify that the source code will compile and run. However, these services can be expensive; depending on the licensee's requirements, the cost for each verification can range from $15,000 to more than $30,000 for each verification.

Advice:

• Evaluate third-party escrow agents and their agreements in the first instance and compare these to vendors' standard contracts.
• Negotiate pricing for verification services in a three-party agreement, even if you do not expect to do such verification, because it is much more difficult to negotiate discounted pricing once you have signed the agreement.
• Review escrow clauses included in software contracts if you are not choosing to engage in a three-party agreement. Modify these clauses, if necessary, to ensure that you have access to the software source code if the licensor does not meet certain conditions, such as in the case of financial bankruptcy or no longer maintaining the code.

Given the current economic downturn and its impact on businesses, including organizations that may no longer be viable, licensees need to follow best practices in evaluating and selecting software escrow companies, and must proactively revisit critical vendors' financials to ensure that they select and continue to work with secure escrow agents. This involves using a consistent, structured and repeatable methodology for IT services, as well as a combination of financial metrics and qualitative measures to provide the most complete, accurate picture of vendor risk.

Potential escrow agents that licensees may consider include the largest escrow company, Iron Mountain. Other escrow companies include Escrow Associates, EscrowTech India and InnovaSafe. Some local banks and law offices have also agreed to be escrow agents. However, if the law firm that is agreeing to escrow software is the same law firm that represents the software vendor, then it may be difficult to obtain the software source code unless the software vendor has agreed to its release. Therefore, it is best to avoid these types of arrangements with banks and law firms.

It is also important that the licensee continue to track the software vendor's financials and viability annually, because any signs of financial problems would justify the cost of verification services. For example, if the vendor has any pending infringement claims, then this could affect the licensee's business. Even if a costly infringement claim is against a different product than the one the licensee is using, then it can put a small vendor out of business. If the infringement claim is against the same software product that the licensee is using, then this will also probably impact the company's ability to continue to use the software.

Advice:

• Apply best practices in the evaluation and selection of escrow agents.
• Start gauging the financial viability of the software vendor by verifying how many customers it has. For example, a vendor with 100 customers, each averaging $250,000 per year in support and maintenance, may have a better chance of being acquired than a software vendor with 1,000 customers that pays $10,000 per year in support. In the first example, the profitable revenue stream is higher and fewer customers will require support, thus reducing the number of paid personnel required to support the software. Of course, every software product is different and, in some cases, the second example may be more appealing than the first.
• Investigate whether your vendor has been paying its bills or has any infringement claims pending and follow Gartner's guidelines to assess its financial performance.

Escrow agents cannot grant automatic access rights to a vendor's source code because agents do not own the software vendor's IP. Some licensees only discover this after signing a license agreement with a vendor, then signing an agreement with an escrow agent. The escrow agent's role is to store a copy of the software's source code and act on the licensee's behalf as an intermediary if the software vendor fails to support the software for a specified period of time or if the vendor goes out of business.

Software vendors want to minimize the number of conditions that warrant releasing source code. Generally, the software vendor will want the ultimate right to determine if a trigger has occurred. A license agreement will often state that the licensor can sue the licensee to obtain the source code, if the licensee obtains source code and the licensor disagrees that the trigger occurred. Therefore, it is up to the licensee to broaden the list of "trigger" conditions under which the software vendor is obliged to release the code. When licensees broaden this list, they will increase their chances of actually obtaining source code.

Gartner finds very few clients who have actually obtained source code from a software vendor that has gone out of business, because another software vendor will often "buy" an unprofitable software company, then fire the sales, marketing, back-office and other personnel and keep some of the technical staff to provide minimum support of the software. The revenue stream for software maintenance and support in such an arrangement can be highly profitable.

A licensor that is failing will typically cut back on support services and support staff long before filing for bankruptcy. To address this, negotiators must include a clause in the software escrow agreement that covers what will happen if the licensor files for bankruptcy, enters into receivership or fails to support the software. When licensees include such a clause, they are less likely to have to wait until bankruptcy to start maintaining the code themselves.

Advice:

• Take responsibility to ensure that the agreement clearly delineates the triggers and provides the licensee with the rights to obtain the source code.
• Ensure that the rights to obtain the source code include the vendor's failure to support the software, going out of business and selling the company to another software vendor that does not support the software.
• Define in the contract what "no longer providing support" will mean, such as providing upgraded versions to run with supported versions of operating systems and database versions.
• Define "going out of business" to include bankruptcy and ceasing operations.
• Adequately define being acquired by another entity through merger, acquisition or divestiture activity.
• Agree with the licensor about the triggers to releasing source code.
• Engage a third party with expertise in negotiating and reviewing software escrow agreements, if you do not have this expertise in-house.

Although including an escrow clause in a software licensing agreement will give the licensee limited rights to the software, software negotiators that choose this option must ensure that they include the right provisions if they opt to include an escrow clause in a licensing agreement. Escrow clauses should include provisions to provide the licensee with the right to audit the software in escrow and require the source code agent to notify the licensee of when the software vendor has made a deposit. These clauses should also cover the provision of support and the purchase of additional licenses when the vendor discontinues a product, not only if they go out of business.

It is essential to include the right to audit in the agreement or clause. This clause should include the right to audit any third-party software that is part of the "system." The clause should specify the right to test the installation and compatibility of the software with the hardware and operating systems the licensee may be using, as well as which party will pay for auditing and testing and at which location. These costs are normally the responsibility of the licensee.

The original license agreement must also include the right to modify and expand usage at no additional cost. If the customer purchased licenses for 500 named users, but after the software vendor goes out of business and the licensee has obtained the source code, then the customer needs 600 licenses. If the licensing agreement did not grant the licensee the right to increase usage, then the licensee will need to locate the previous owners of the software company (to pay for the additional 100 licenses). If the licensee cannot locate the previous owners, then the licensee may need to arrange an "escrow" account with money set aside for the additional payment for the new licenses in case the owners of the software can be located in the future. Seek legal advice on how, or whether, this should be done. When negotiators include rights to expand usage in the initial agreement, they can avoid this type of problem later.

Some agreements state that the vendor must default on the license agreement before the licensee can obtain the application's source code, but also include another clause that states that the vendor can cancel maintenance and support with written notice within a specified time frame. These clauses protect the licensor from being "in default," which exempts the vendor from its obligation to provide the licensee with the source code if it goes out of business or fails to support the software. Watch for any such clauses and be sure these do not reduce your chance of obtaining the source code.

Advice:

• Include audit provisions that state that, with some reasonable notice, you will have the right to audit the contents of the deposited escrow to ensure that it includes all media, documentation and correct versions.
• Include time frames in the contract that the software vendor must honor regarding the deposit of new versions of the software within some reasonable time frame (for example, within 60 days from general availability).
• Include perpetual rights to use the source code with no additional fees, even if your organization would like to expand usage rights.
• Include the right to hire staff from the software vendor's company to support the software. If your software license agreement includes "no hire" provisions, then include an exception for when you have to evolve the source code clause.
• Watch for language in the agreement that states that the software vendor must breach the license agreement to obtain source code, but has another clause that states that the vendor can cancel maintenance and support with, for example, a 90-day written notice.
• Ensure that the licensing agreement gives your organization the rights to the software code.
• Push for the purchase of the actual source code, rather than rights to use the object code, if this software is mission-critical and you are licensing it from a small software vendor.

The list of items that the licensee will place in escrow must contain everything required to self-maintain the software. If anything is missing from the escrow deposit list negotiated into the escrow agreement, then there is little value in obtaining the code that is in escrow, because the licensee will not have the IP rights to deliver the application's functionality. Licensees need to ensure that they compile and verify the complete list before signing a two- or three-party escrow agreement. It is also essential to stipulate that the escrow is cumulative, so that prior versions are also kept in escrow. This will ensure that if a licensee decides to run a back-level version, then it will have the necessary code to maintain it.

Advice:

• Ask your escrow agent to indicate what is appropriate to include in a specific arrangement.
• Account for all elements required to self-maintain the software. (In addition to the source code, for example, include external subroutines, documentation, special compilers or linkage editors.)
• Include all versions of the software that are in use, as well as any customized code that the software vendor has developed for the organization. For example, if the software vendor has released v.9 of its software, but the organization is still running v.7, then it will want v.7 in addition to the follow-up version.
• Ensure that the agreement requires the software vendor to provide the escrow agent with a media copy of the correct version of the third-party software, which runs with the escrowed software because the licensee will not usually receive the source code for this software.

The software vendor should diligently maintain source code in escrow. However, if the vendor falls behind on source code deposits, and has incomplete or unusable deposits, then the escrow agreement will be useless. Therefore, licensees need to look for demonstrable proof that the escrow will work if exercised. They can achieve this by auditing the software in escrow or requiring the escrow agent to do so.

The extent to which a licensee conducts escrow audit activities (if done it at all) typically depends on a few factors:

1. Whether or not the licensed software is "mission-critical" to the business
2. How easily the licensed software could be replaced with a substitute product
3. How large an investment the software represents to the licensee

If the licensed software is not mission-critical, is easily replaced and is relatively inexpensive, then many licensees may forgo any audit activities beyond reading the report from the escrow agent stating what the vendor reports is in the escrow deposit. However, if the software is mission-critical, and/or is difficult or impossible to replace, and/or represents a large investment, the licensee should take more steps to ensure that the escrow is usable, in case a release condition occurs.

Audit activities include compiling the source code and testing the object code for accuracy of results against the production version the licensee is running. Audit activities should also involve making a "test" maintenance change to the source code using the escrowed tools, to ensure that the materials required to make alterations work properly.

As part of auditing, the licensee should also check that all items necessary to maintain the software are in escrow. This may include third-party software, development tools, documentation of standard and modified code, the required compiler, and any data maps or other schematics.

Audits of mission-critical software in escrow may involve additional steps, such as traveling to the escrow agent's site to view the contents and conduct a higher-level verification. This would involve witnessing the escrow agent testing the source code to see that the code compiles into operationally compliant object code. Alternatively, both the licensee and the licensor can sign and seal the container with the media and documentation, then send it directly to the escrow agent. Another option involves the licensee requiring the escrow agent to ship the object code that it compiled from the source code, so that the licensee can run it and compare results with its copy of the licensed software.

Advice:

• Include audit provisions that stipulate that, with reasonable notice, you or your software escrow agent will have the right to audit the contents of the deposited escrow.
• Indicate clearly what audit activities will include and stipulate that you can audit to ensure that all media, documentation and correct versions of the software are included. If any third-party software is part of the "system," then include your right to audit that software too.

A licensee must identify the individual(s) in the organization responsible for administering the contract; verifying, testing and, if necessary, maintaining the escrowed software and associated tools; and monitoring the release conditions. The employee(s) responsible must maintain familiarity with the escrow agreement and the licensee's rights and obligations under it, and administer that agreement to maximize the negotiated provisions. The organization must also develop and carry out an escrow test plan as the software vendor releases new versions. The designated employee or team should also monitor the situation for evidence of a release condition, and provide the appropriate written notice in compliance with the procedures documented in the escrow agreement.

Individuals assigned to execute an escrow release need specialized software source code and contracting knowledge and skills. Many organizations lack these skills. Some companies recognize the futility of receiving source code they cannot use, and will forgo tough negotiation on an escrow agreement for that reason. Ideally, however, in a situation where it is critical that the escrow works effectively, licensees should identify third-party contractors with experience in the software that can be hired to maintain the software. Alternatively, licensees can include a clause in the escrow agreement that requires the software vendor to supply the names, addresses and contact numbers of those employees who have been trained to maintain the software. Without one of these two solutions, there is no point in paying for source code escrow that will never be used.

Advice:

• Understand the skills and competencies inherent in your organization to decide whether to assign and/or train staff or to contract third parties to manage stakeholder relationships that will ensure a successful escrow arrangement ("New Roles and New Competencies: Blurring Boundaries").

Licensees will have the most chance of obtaining the right source code when they need it if they:

1. Negotiate a third-party escrow agreement.
2. Pay particular attention to the release conditions and the deposit list when negotiating the contract.
3. Assign an employee in the organization responsible for the escrow relationship.
4. Develop and carry out an escrow test plan for each new version of the software.
5. Identify internal or external resources that will be available and equipped to use the source code if released.
6. Investigate alternative products to replace the subject software.