Desktop version

Home arrow Computer Science

  • Increase font
  • Decrease font


<<   CONTENTS   >>

Key Issues for Escrow Agreements

This section presents key considerations and risks presented by escrow agreements.

Hie software license agreement with the vendor should clearly identify the following obligations and rights for the escrow:

■ The vendor has an obligation to establish and maintain the escrow during the term of the agreement. For perpetual licenses, it is not uncommon to limit the obligation to the period in which support is purchased and, perhaps, a year or two thereafter.

■ The software and all updates and bug fixes must be promptly deposited on their general availability. At minimum, the deposit should be updated on a quarterly basis.

■ Tire vendor contract should specify the party responsible for the fees for establishing and maintaining the escrow.

■ Tire vendor contract should expressly permit the customer to request verification services from the escrow agent. For a fee, the escrow agent will compile the deposited code and compare it with the version of the object code currently being licensed by the vendor to ensure they match (i.e., that the deposit isn’t out of date or, worse yet, a blank CD with nothing on it). If the verification is correct, the cost of the escrow agent’s services is the responsibility of the customer. However, if the verification shows the vendor has not fulfilled its obligation to ensure the deposit is up to date, the cost of the verification services should shift to the vendor. This is a key protection to ensure the vendor has the incentive to keep the deposit current.

■ Reject arguments by the vendor that verification services are unnecessary in that if they fail to keep the deposit current, they will be in breach of contract. The problem with that argument is that when the customer needs the source code the most (e.g., when the vendor has filed for bankruptcy protection), it will be too late to seek damages.

  • - In the event a release condition occurs, the vendor contract should make clear that the customer will have the right to modify the source code and otherwise use it to provide its own maintenance and support.
  • - Vendors sometimes include language that if they “cure” whatever conditions resulted in the release of source code, the customer must return the source code. While this seems fair, it actually presents a significant problem. If a release occurs, the customer will likely spend thousands, if not tens of thousands, of dollars to review and understand the source code and prepare to provide its own support. If the customer knows it may have to return the source code at any time if the release condition is cured, it will be very reticent to make that investment greatly diminishing the value of the escrow.
  • - In certain highly critical applications, it may be appropriate to include in the software license a right for the customer to engage a third-party consultant to assess and evaluate the source code to determine if it is well written and documented (i.e., that it is not “spaghetti code”—code that was not developed using accepted programming practices and that is poorly written and documented). In these situations, the customer would have no access to the source code. Only the third-party consultant would have access. The consultant would typically sign a nondisclosure agreement (NDA) directly with the vendor to ensure the source code remains confidential.
  • - Frequently, this right is exercised at the outset of the agreement. If the consultant issues an adverse report, the customer should have a termination right.
  • - All release conditions should be identified:
  • • Bankruptcy or insolvency of the vendor
  • • Vendor ceasing to do business
  • • Vendor abandoning its support and maintenance obligations
  • • Breach of the agreement by vendor

This last release condition is generally the most difficult to achieve. It is, however, an excellent incentive for the vendor to avoid breaching the contract and, therefore, a strong protection for the customer.

  • - The vendor contract should include a statement that it is amending the underlying escrow agreement with regard to the release conditions.
  • - Include a detailed definition of what constitutes “source code.” That is, source code is not just the software, itself, but related files necessary for the code to work properly and all related programming documentation. A typical definition may include “the source code of the licensed software and all related compiler command files, build scripts, scripts relating to the operation and maintenance of such application, application programming interface (API), graphical user interface (GUI), object libraries, all relevant instructions on building the object code of such application, and all documentation relating to the foregoing, such that collectively the foregoing will be sufficient to enable a person possessing reasonable skill and expertise in computer software and information technology to build, load- and operate the machine-executable object code of such application, to maintain and support such application and to effectively use all functions and features of the licensed software.”
  • - In some transactions, particularly those involving small vendors, it may be appropriate to require the vendor to include in its escrow deposit the names and contact information for all key development personnel. This will allow the customer to potentially locate and hire (either as an employee or as a contractor) one or more of the developers to assist the customer in understanding and using the source code.

Always make sure to use a recognized escrow company that specializes in source code escrow engagements.

  • - Avoid small companies who lack appropriate financial wherewithal and may, themselves, go out of business.
  • - Avoid banks, lawyers, and others who offer source code escrow services as a side business.
  • - Obtain and review the escrow agents form agreements. They should be readily available on their website or on request.
  • — Identify whether a two- or three-party agreement will be used. In most cases, unless the customer is willing to pay the additional fees to establish a new escrow arrangement, the customer must use the vendor’s existing escrow agreement.
  • • Three-party agreements are generally preferred because they afford the customer potentially greater ability to negotiate release conditions. However, because they require a new agreement for each customer, the customer may be required to pay higher fees to establish the escrow.
  • • In two-party arrangements, the vendor generally portrays them as nonnegotiable, offering the same uniform release conditions and other terms to all of its customers.

■ Identify any fees to be paid by the customer/beneficiary.

- In general, in two-party agreements, the customer should decline to pay any fees associated with establishing and maintaining the escrow. If pressed, the customer should only commit to paying the fees associated with becoming a beneficiary and any copying costs associated with a release of the source code.

■ In three-party agreements, depending on the size of the engagement, many vendors will bear the escrow’s costs. However, it is not uncommon for the parties to equally share the costs.

Summary

An escrow agreement should not be looked on as a panacea. The code could be so poorly written and documented that it could take months to understand its operation. The cost to the customer of understanding the source code and providing its own support may well exceed the cost of simply licensing and implementing a replacement product.

Escrows can provide important additional protection to customers, particularly when the licensor is small, financially unstable, or when a critical application is involved. Customers, however, should understand the realities of actually trying to provide their own support using what could be hundreds of thousands of lines of code written by a third party and for which there may be little or no documentation. In addition, in order to make the code work, the customer may have to purchase numerous third-party license agreements for embedded software within the licensor’s original code. Finally, for cloud engagements, the code is set up for a multi-tenant hosted environment. If a customer gains access to the source code for a cloud solution, implementing it on its own systems for a single user may prove very difficult.

 
<<   CONTENTS   >>

Related topics