Contract language: the "Ts and Cs" of technology escrow; As technology escrow becomes a routine part of risk management strategies, contract managers need to be familiar with the terms and conditions of these agreements and know when they should be modified to afford their organization the best protection.
To optimize your organization's protection, you will need to be prepared, knowing what language is favorable and which sections of the contract are most critical. This article will focus on some of the top areas of negotiation, including release conditions and the release process--it will also briefly cover rights to use and limitations of liability. I'll also discuss verification services, which can be used as a way to ensure that any release that occurs delivers executable source code.
Technology Escrow Trends
With the advent of the Sarbanes-Oxley Act and today's stringent compliance requirements, a lot of people are looking to mitigate risk and liability as they undertake investments in new technology. Technology escrow is thus becoming an integral component in many corporate risk management strategies. In addition, contract managers are looking to maximize the value of technology escrow through specific contract language and the use of services, such as verification testing, which ensures that the software source code deposited into the escrow account can indeed be recompiled and executed in the event of a deposit release. The most advanced escrow services also provide customers with on-line access and the ability to complete audits or updates on a 24/7 basis.
For the licensee, technology escrow provides greater protection, ensuring access to proprietary source code should the developer cease to support the technology. For the developer, it can serve as a way to protect ownership of intellectual property--but more likely--is used at the request of the licensing party to complete the software licensing deal.
In a recent survey sent to 20,000 licensees, developers, and attorneys who use escrow, (1) 60 percent of licensee respondents report that the two main reasons for using escrow are (1) worries that the software developer will go out of business, and (2) the need to ensure business continuity, in the event anything should happen to the developer. Interestingly, 37 percent of licensees say they use escrow as part of a risk management strategy--only further proof that technology escrow is becoming an integral component of corporate risk management plans.
Seventy-four percent of developer respondents report that their customers demanded technology escrow. Furthermore, 65 percent agree that technology escrow is a routine request made by those who license their technology. Escrow is often requested by licensees who work with smaller or new developers because they are considered more risky.
Today, escrow is a routine consideration for many companies that want to protect their technology assets. To obtain the best protection possible, it is important to closely review, understand, and modify (when necessary) the terms and conditions (Ts and Cs) of the technology escrow agreement.
Importance of Ts & Cs
Knowledge about the best terms and conditions for technology escrow is imperative.
Simply signing on the dotted line of a technology escrow agreement does not guarantee adequate protection of a company's assets. Several key factors must be considered to produce an agreement that effectively meets each party's unique requirements.
Since licensees are typically the beneficiaries of an escrow arrangement, they need to pay close attention to those sections of the agreement that deal with the following issues:
* Release conditions -- What are the circumstances under which the agent can release the source code to the licensee of the technology?
* Release process -- How quickly will the materials be released, in the event that a release condition has been met, and what is the process for release?
* Rights to use -- What specific rights does a licensee have regarding use of the software source code once they obtain ownership of it through a release?
* Verification -- In the event of a deposit release, can the technology be quickly and successfully recreated from the materials that reside in escrow?
* Deposit updates -- How can you ensure you have the most up-to-date materials in your deposit?
Without careful attention to these details, licensees may find that even though they have taken the precaution of establishing an escrow account, they won't have the leverage to request actions by either the escrow agent or the vendor that would protect their investment.
Two Opposite Release Request Case Studies
The following examples are case studies of two real companies who needed to request an escrow release--but each had a different result and ultimate outcome.
Company A -- which we'll call the "good scenario--is a major entertainment studio that licensed an animation tool to create its high-grossing movies. It had initiated an escrow agreement with comprehensive release conditions that covered many possible risks. Verification was also part of the agreement. In this case, the developer of the animation tool was acquired, and the acquiring company planned to stop support of the product. This triggered an uncontested release of the source code.
The release was processed flawlessly. Verification testing performed at the time the agreement was signed ensured that the release was functional, and the escrow agent assisted in rebuilding the code. This software, which cost millions of dollars, was critical to the functioning of the entertainment studio. When the unexpected happened, the disruption was extremely minimal, due to the effective escrow agreement that had been negotiated upfront.
Company B -- which we'll call the "bad scenario"--is a major insurance provider. It licensed software from a small developer, which was mission-critical in running its business. Unfortunately, the escrow agreement's terms and conditions were inadequate. The release conditions only included bankruptcy, court or trustee order, or release upon developer instruction.
One day, the developer closed its doors. Because the developer never filed bankruptcy for Chapter 11 (reorganization) or Chapter 7 (liquidation), the source code could not be delivered to the insurance company on a technicality. And, because the developer was no longer around, there was no court or trustee to take care of asset allocation. The insurance company could have fought for the source code in court, but this would have required a six- to nine-month wait and was much too lengthy and costly to pursue. They lost their original investment and needed to start over with a new developer.
As you can see, even though both companies had escrow agreements in place, the difference between the "good" and the "bad" scenarios is a result of the terms and conditions negotiated in each situation.
Release conditions define the circumstances under which the source code will be released. This is the key to a functioning escrow--ensuring that a software licensee can obtain access to the source code in a timely manner, without delay.
You will want to avoid conditions that only allow release under very specific circumstances. For example, if your only release condition is "bankruptcy," what happens if the vendor does not file for bankruptcy but only closes its doors, as in the example above? Additionally, in some instances, bankruptcy itself may not be the sole driver of a source code release, but rather a prequel to what may lie ahead (i.e., failure to do business in the ordinary course or failure to honor support requirements). Be detailed, to account for a wide range of circumstances. The most common cause for an escrow release is when a vendor fails to provide support for their technology, and when that happens, licensees are suddenly grateful they have a strong escrow agreement with language that carefully discusses release conditions.
The obvious question is: "What release conditions should a licensee address when negotiating the escrow elements of a software license?" You should first analyze the cost associated with the potential loss of the technology product. This will determine the level of protection needed against various events.
In addition to bankruptcy, here are a few other factors to consider.
This is the failure to provide support. All products go through a life cycle curve, and many products are still being effectively used by licensees well into the period where a developer plans to "sunset" or phase out the product. As a developer refocuses its concentration onto newer more profitable products, a support release condition can ensure product support for the version you are using.
Mergers or Acquisitions
When a vendor is acquired, the new company may not be as dedicated to meeting the user's support requirements. Or the acquisition may result in duplicate products that the new company doesn't want to support. Any change in business status should be included as a release condition.
Loss of Key Staff
Especially in the case of a small organization, where one individual could dramatically alter support capabilities, loss of personnel--whether key management, development, or maintenance staff--should be considered as a release condition.
Other release conditions to consider include death of the owner; failure of the developer to continue to do business in the ordinary course; or assignment of maintenance obligations through merger or acquisition, or other transfer of assets to another company that the licensee solely considers unsatisfactory to maintain the software. Licensees should be aware of terms that are too limited and avoid wording that ties the release to a unique event. They should also be wary of any terms where the release must be authorized by the developer.
Many licensees will find that one of the unexpected benefits of escrow is that just a request for a source code release can serve as a catalyst for the developer to meet its obligations. When a software developer is at risk for releasing its most valuable asset, they often are under more pressure to provide the needed support to the licensee. Table 1 shows the most common release conditions for many escrow customers today.
The Release Process
Defining the release conditions, however, is only the first step to ensure ample protection. Licensees must also consider how the materials will be released in the event that a release condition is met. Will the materials be released on demand? Or will a dispute resolution by a third party be required?
A standard release process requires that the licensee contact the escrow agent to notify them that a release condition has occurred. The escrow agent will then directly notify the developer of the release request. The developer has a predetermined "objection period" (usually 10 days) to oppose the release. If the agent does not receive an objection from the developer during the predetermined time, the release occurs. If the developer does object to the release, the two parties resolve the issue through the resolution process defined in the escrow agreement, and the escrow agent does not release the source code at that time.
[FIGURE 1 OMITTED]
Specifics in the contract language should state that this process starts from the date the release request is sent by the escrow agent, not received by the developer. The role of the escrow agent is to serve as a neutral and trusted third-party administrator and, as such, processing of the request should adhere to dates that can be clearly administrated by the agent. Figure 1 shows how a standard release process works.
It's important to note that developers may want to negotiate for a longer objection period and licensees may want a shorter one. In some instances--and only when the criticality of the technology demands it--the licensee may have enough negotiating leverage to persuade the developer to agree to an expedited or "demand" release, which allows for access to the source code immediately after the licensee has notified the escrow agent that a release condition has occurred.
Should the developer object to an expedited release option, the licensee expedited release option, the licensee may negotiate for a solution that provides a short time period (often within a week) for both parties to select a member of their companies to agree on a third party to resolve the issue. In some cases, licensees may negotiate in advance for terms that permit them to pay a fee to continue to use the technology during the resolution period.
To maximize their protection, developers will always want to include a "timeframe to cure" clause for rectifying any damage done by releasing the source code. Upon "cure"--that is, the developer remedies the situation--the licensee must return the deposit, along with any and all copies, derivative works, or any partial copies (made by licensee) to the escrow agent or developer.
Rights to Use
First, it is important to note that the rights to use the released materials must be addressed in both the escrow agreement as well as the license agreement. Often, the original license agreement addresses rights to object code and not source code (object code is only readable by a computer, whereas source code is readable by human beings). And in many instances, language for rights to use is contained in the escrow agreement, but not in the license agreement. To avoid potential problems, use rights in both agreements should mirror each other.
If the agreement does not grant the licensee the right to modify and otherwise maintain the licensed technology upon release, then the licensee will only be able to use the technology in the condition delivered to the licensee by the developer. This could be a major issue if a release occurs, and the licensee needs to modify and maintain the software.
In addition, the agreement should include the right to make a backup copy, transfer to an outsourcer or sister company that may be working with the licensee to maintain the software, and move the software to another location or computer. If the licensee wants to be able to use the software indefinitely, you should also make sure the term of the license is "perpetual," and that this is included in the use rights.
Limitation of Liability
There are currently more than 40 technology escrow agents worldwide--not all of them are reputable. Some will promise anything to get the business. Therefore, you need to beware of escrow agents that offer no limit of liability or an excessive limit of liability.
Perform due diligence to ensure the agent has financial resources to pay future claims and carries both professional and crime liability coverage as well. Some deals are too good to be true. Don't put yourself into the position of promising your management that your company is "protected" by contract language that is not worth the paper upon which it is written.
Verification and Deposit Updates
A technology escrow arrangement is an excellent vehicle to protect all parties involved in licensing technology, but the value of the escrow arrangement is heavily dependent on the quality of the deposit materials. You may have created the most comprehensive escrow agreement with all the right terms and conditions for your company. However, if a release occurs and there are missing components--such as compilation and execution procedures, third-party utilities, or encryption keys and passwords--then the technology cannot be quickly recreated or perhaps even recreated at all. A thorough verification of the materials provides assurance that, in the event of a deposit release, a licensee would be able to more quickly and effectively read, recreate, and maintain the licensor's technology in-house.
Just as lenders examine collateral when they sign a loan, the best practice in technology escrow is to verify and test the deposit materials. This should happen soon after an escrow agreement is executed to ensure that all of the components necessary to rebuild the executable program are part of the deposit and are in working order. Since software vendors are most familiar with the escrow materials at the time they prepare the deposit, the verification process tends to move more quickly if conducted shortly after the escrow agent has received the materials. Aligning verification services alongside your arrangement will help to assuage any potential risk by providing complete intellectual property protection and management.
In addition, to ensure that the most current version of the technology is deposited, the escrow agreement should require that the developer regularly update the account. Licensees should specify the frequency of the updates, such as quarterly, rather than rely on vague conditions such as "whenever appropriate." A full-service escrow agent will notify the parties of all updates and can notify the licensee if an update has not been deposited at the agreed upon intervals.
As technology escrow is becoming a routine part of risk management strategies, contract managers need to be familiar with the terms and conditions of these agreements and know when they should be modified to afford their organization the best protection.
Although an escrow release is meant to be the solution of last resort, there are cases when it will be the best option for all, and indeed, can save a company from disastrous consequences. While all parties hope such problems never arise, experience demands preparation for the possibility.
Reason for Release % of Total Release 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% Based on proprietary research performed by Iron Mountain. Table 1. Breakdown of Requests for Release
1. Survey of 20,000 Iron Mountain customers conducted in June 2004.
RELATED ARTICLE: Tips for Escrow Arrangements
A properly crafted escrow arrangement will:
* Allow timely access to the source code and maintenance materials when specific release conditions have been met;
* Enable recreation of the application development environment;
* Provide leverage after the license has been signed;
* Provide an option to control future software upgrade time-tables;
* Satisfy legal compliance;
* Enable corporations to avoid litigation and court systems; and
* Minimize risk of loss with the right language written into the agreement.
About the Author
FRANK BRUNO is a senior business strategist for Iron Mountain's Intellectual Property Management business unit, and consults with developers, corporations, and intellectual property law professionals throughout the United States on IP management best practices. He has spoken at many professional and industry events, including the NCMA World Congress and NCMA Commercial Contract Management Conference 2004. Send comments on this article to email@example.com.
|Printer friendly Cite/link Email Feedback|
|Author:||St. Bruno, Albert Francis|
|Date:||Jul 1, 2005|
|Previous Article:||From piracy to profitability: re-thinking IP rights protection in China; Experience suggests that the traditional focus on legal remedies employed in...|
|Next Article:||Corporate trade secrets: protecting company assets; Effective trade secret policies, employee agreements, and ethics training for all employees and...|