Integrating Software Escrows into Intellectual Property Strategy

From a licensee's perspective, there are three types of risks that drive creation of a software escrow. The first risk is that the software developer substantially goes out of business or becomes financially unable to perform its development and support obligations. The second risk is that the software developer files for bankruptcy and terminates the license. Under the U.S. Bankruptcy Act, if reorganization occurs in a Chapter 11 bankruptcy, and the software developer elects to continue performing its license obligations, there may be no significant impact of the Chapter 11 on the licensee. If, however, the software developer ceases operations or otherwise fails to provide support at a previously agreed upon level with the licensee, the licensee may lose the licensed software and, absent a triggered source code escrow, may find itself unable to maintain and develop its products.

The third risk is that the software developer is acquired by a competitor of the licensee. In such situations, the software may be altered to the detriment of the licensee, discontinued, or support for it may be dropped altogether. An associated risk is a change in the relationship between the software developer and the acquiring third party. For example, the acquiring third party may fail to provide support at a level agreed upon with the software developer.

From a licensor's perspective, software escrows help minimize two primary risks. The first is minimizing the risk of losing business. The software developer can use the escrow to remove uncertainty in business dealings between it and the licensee so that the licensee feels comfortable in entering into a deal with the software developer.

A software escrow may also minimize the risks associated with releasing the source code from escrow. As a part of this risk assessment, the software developer will need to maintain flexibility on circumstances in which the source code would not be released from escrow due to certain business decisions. For example, if a software product reaches end of life, the escrow agreement should be structured so that it does not trigger a release event, particularly if there is an available migration or upgrade path available to the licensee.

How Does a Software Escrow Work?

Thanks to well-established software escrow practices, it is relatively easy to find a base framework creating a commercial software escrow particular for the needs of a deal between two parties. First, the software developer and the licensee must agree upon a software escrow agent. The parties typically select a software escrow agent that is an independent third party having experience in administering source code escrows. Examples of established software escrow agents include Iron Mountain Intellectual Property Management, Inc., (www.ironmountain.com), SourceHarbor, Inc. (www.sourceharbor.com), and EscrowTech International, Inc. (www.escrowtech.com).

Second, the parties need to negotiate what goes into the software escrow. The licensee should ensure that the complete source code of the licensed software goes into the escrow, along with associated materials such as documentation, software libraries, appropriate third-party items, and the like. The deposited source code should preferably be in electronic format. In addition, the licensee should consider whether the software developer also should include documentation such as development manuals and the like. In any event, the rights to have possession and use of the deposit materials should depend on the agreement to deposit them, and not on actual deposit.

Third, the parties negotiate how often updates go into the software escrow. The licensee should ensure that the software developer is obligated to update its source code deposits with all new versions, updates, and new releases of the licensed software. Moreover, the obligation for these additional deposits should be satisfied within a short time period (typically within 30 days) after the initial distribution of the new version, update, or release.

Fourth, the licensee may seek mechanisms to confirm what went into the software escrow. A key part of the escrow arrangement is ensuring that what goes into the escrow is what the licensee expects. To avoid incomplete or out-of-date source code, the licensee should include provisions in the escrow agreement for deposit of new versions, updates and releases as previously described, in addition to the original deposit of code.

Fifth, the parties must agree upon release conditions from the software escrow. The release conditions define the circumstances upon which the source code and associated materials are released by the escrow agent to the licensee. As a general matter, release provisions should focus on identifiable, indisputable facts. The easier it is to demonstrate the occurrence of a release condition, the more quickly and cheaply the licensee should be able to get access to the deposit materials. In addition, release conditions must also be legally enforceable.

Many software escrows limit the release event to the situation in which the software developer has ceased doing business and, therefore, cannot maintain the software. In this regard, the licensee can also ask for conditions related to harbingers of impending failure for release: the appointment of a receiver for the software developer's business, the making of a general assignment for the benefit of creditors (an alternative to bankruptcy liquidation), and the announcement to the public in general that the software developer is ceasing operations, are examples of such release conditions. Still another release consideration to plan for is a software developer's outright refusal to perform, repudiation of the license, including rejection in bankruptcy.

A licensee may also consider attempting to procure additional release events tied to the software developer's failure to perform its maintenance obligations in a timely or effective manner, eg, a consistent failure to respond to, or correct, documented errors within a specified number of days of their report by the licensee to the software developer.

The licensee should also consider other release events tied to the practicality of using the software developer for continuing maintenance services. For example, the licensee may use this release when the software developer seeks to increase maintenance costs beyond a specified limit set in the maintenance contract.

In addition, the parties should avoid relying on “insolvency” as a release condition because its occurrence is difficult to determine with accuracy and it is usually determined only in hindsight through expensive litigation with delay. Although an insolvency release condition may exist in an agreement, it often is not an enforceable release condition.

Finally, the parties must determine who pays for the software escrow. Typically, the software developer will pay for the software escrow, although this point is often negotiable between the parties.

What Are Key Issues Faced By the Licensee with Respect to a Software Escrow?

Despite a well-architected agreement between parties to a software escrow, problems do sometimes arise, particularly for licensees. One common problem is that the material (ie, the source code itself) is never deposited, or only partially deposited, into the escrow. To manage this issue, the licensee should watch for and monitor the escrow account activity, including a description of what was deposited and when. To assist with this process, the parties may agree to allow an independent technical verification service that verifies the integrity of the deposited materials.

Another problem faced by licensees is unclear or disputed release conditions. Most escrow agreements allow the software developer to oppose the licensee's release request when a release event allegedly occurs. To address such conflicts, the licensee may consider incorporating provisions into the source code escrow that provides a quick, low-cost, decisive alternative to litigation. For example, the parties may agree to an arbitration provision. Alternatively, decision-making executives for each party may be required to meet and resolve their differences through dialog and a threat of a release. Still another approach to resolve disputes is to write into the escrow agreement the requirement that disputes be “expedited,” including setting forth timetables to complete each step.

Still another problem encountered by licensees is having a complete source code deposit, but no guidance on how to work with it. To address this issue, the licensee should consider including a provision requesting supporting documentation and a list of technical maintenance personnel from the software developer. If the software developer goes out of business, these employees may be available as consultants after the release has occurred, helping to ensure that the licensee has access to support personnel familiar with the software.

A more complex problem facing many licensees today is bankruptcy of a software developer. Bankruptcy is often the most complicated issue in structuring and enforcing an escrow agreement. It is important to understand the underlying principles because the Bankruptcy Code interferes with the parties' ability to strike any bargain they want. Section 365 of the U.S. Bankruptcy Code gives debtor parties to “executory contracts” a choice of assuming and finishing the contract or “rejecting” it, generally leaving the other party to a damages claim. If the debtor is a software developer that rejects the license, it allows the licensee to retain certain rights to use the technology as it existed on the date of filing in exchange for paying royalties due under the agreement, and to have rights under “ancillary agreements,” which include the escrow agreement.

Section 365(e) generally disables certain contract clauses and provisions in some non-bankruptcy laws that permit the non-debtor's termination of an agreement because of a debtor's bankruptcy filing or its financial condition upon filing. These so-called ipso facto clauses are not enforceable in licenses where the debtor is a software developer. Hence, special crafting is required for the escrow release triggers to ensure that if the license occurs, and the licensee makes the Section 365(n) election, the escrow release will occur and be effective. Specifically, Section 365(n) grants the licensee absolute entitlement to retain rights to intellectual property (despite the debtor-software developer rejection of the license agreement) with some conditions. The licensee cannot also enforce exclusivity against the debtor or its assignee if the license is exclusive, and cannot compel further performance (such as development or maintenance) otherwise provided under the license.

There are a number of things a licensee can do to increase the probability of having the agreement fall under the scope of 365(n), including using executory contracts (which include software licensing agreements) that call for continuous performance over time by both sides. Because the rights that can be retained upon rejection are those that existed at the time of the bankruptcy petition, license grants must be present grants, not those that spring into existence upon bankruptcy. Specifically, an escrow agreement should be drafted as a present grant to use the escrowed materials and not just a license right becoming effective upon bankruptcy. If the license makes the escrow agreement effective upon bankruptcy, then that does not fall under the section of the code that says the license must be in effect in order to be valid, eg, reciting “software developer hereby grants” instead of “software developer grants.”

The right to the deposit materials should also be without regard to whether the software developer actually made the deposit required under the license. That way, if the software developer did not do so and the escrow is triggered, the licensee will have a legal right to demand that the debtor or its trustee hand over the materials. At the very least, this provides a licensee with the legal rights to the materials, and it can work with the debtor (or trustee) to find the materials.

Finally, the parties need to be careful in their license to differentiate which payments are for use of the licensed software and related intellectual property and which are for maintenance. Licensees making the Section 365(n) election must pay royalties required under the license to continue using the intellectual property. If the license is not clear, the licensee will end up litigating how much “royalty” must be paid to continue its use rights under Section 365(n) without the support and maintenance of the software developer.

Conclusion

Software escrows can be a vital part of a software purchaser's intellectual property plan and strategy. Further, software escrows can ensure that a licensee will have unfettered access to critical source code in the event the software developer becomes unable to maintain the same.

Software developers invest a great deal of time and effort developing complex code that performs unique functionality for which there is a viable market. These software developers typically offer software licenses that only license object code, ie, the code that can be read by a machine, rather than the source code, ie, code that can be deciphered and read by a person.

Companies often invest in software developed by these developers. To protect this investment, a company may seek to acquire all rights to the developed software. Where they cannot acquire the software, they typically license the software from the software developer. In some instances, this causes tension between the software developer's desire to keep source code confidential and out of the hands of the licensee and others who may gain possession of, or knowledge about, the source code, and the licensee's desire to have access to the source code in the event that the software is no longer available at agreed upon levels of service.

To help ease the tension, parties often agree to a software escrow. A software escrow is a deposit of source code of software and other materials with a third-party escrow agent. Generally, the licensee (ie, the buyer) requests the software escrow from the licensor (ie, the “software developer”) to ensure maintenance of the software and possibly performance of development obligations under a license.

From a licensee's perspective, there are three types of risks that drive creation of a software escrow. The first risk is that the software developer substantially goes out of business or becomes financially unable to perform its development and support obligations. The second risk is that the software developer files for bankruptcy and terminates the license. Under the U.S. Bankruptcy Act, if reorganization occurs in a Chapter 11 bankruptcy, and the software developer elects to continue performing its license obligations, there may be no significant impact of the Chapter 11 on the licensee. If, however, the software developer ceases operations or otherwise fails to provide support at a previously agreed upon level with the licensee, the licensee may lose the licensed software and, absent a triggered source code escrow, may find itself unable to maintain and develop its products.

The third risk is that the software developer is acquired by a competitor of the licensee. In such situations, the software may be altered to the detriment of the licensee, discontinued, or support for it may be dropped altogether. An associated risk is a change in the relationship between the software developer and the acquiring third party. For example, the acquiring third party may fail to provide support at a level agreed upon with the software developer.

From a licensor's perspective, software escrows help minimize two primary risks. The first is minimizing the risk of losing business. The software developer can use the escrow to remove uncertainty in business dealings between it and the licensee so that the licensee feels comfortable in entering into a deal with the software developer.

A software escrow may also minimize the risks associated with releasing the source code from escrow. As a part of this risk assessment, the software developer will need to maintain flexibility on circumstances in which the source code would not be released from escrow due to certain business decisions. For example, if a software product reaches end of life, the escrow agreement should be structured so that it does not trigger a release event, particularly if there is an available migration or upgrade path available to the licensee.

How Does a Software Escrow Work?

Thanks to well-established software escrow practices, it is relatively easy to find a base framework creating a commercial software escrow particular for the needs of a deal between two parties. First, the software developer and the licensee must agree upon a software escrow agent. The parties typically select a software escrow agent that is an independent third party having experience in administering source code escrows. Examples of established software escrow agents include Iron Mountain Intellectual Property Management, Inc., (www.ironmountain.com), SourceHarbor, Inc. (www.sourceharbor.com), and EscrowTech International, Inc. (www.escrowtech.com).

Second, the parties need to negotiate what goes into the software escrow. The licensee should ensure that the complete source code of the licensed software goes into the escrow, along with associated materials such as documentation, software libraries, appropriate third-party items, and the like. The deposited source code should preferably be in electronic format. In addition, the licensee should consider whether the software developer also should include documentation such as development manuals and the like. In any event, the rights to have possession and use of the deposit materials should depend on the agreement to deposit them, and not on actual deposit.

Third, the parties negotiate how often updates go into the software escrow. The licensee should ensure that the software developer is obligated to update its source code deposits with all new versions, updates, and new releases of the licensed software. Moreover, the obligation for these additional deposits should be satisfied within a short time period (typically within 30 days) after the initial distribution of the new version, update, or release.

Fourth, the licensee may seek mechanisms to confirm what went into the software escrow. A key part of the escrow arrangement is ensuring that what goes into the escrow is what the licensee expects. To avoid incomplete or out-of-date source code, the licensee should include provisions in the escrow agreement for deposit of new versions, updates and releases as previously described, in addition to the original deposit of code.

Fifth, the parties must agree upon release conditions from the software escrow. The release conditions define the circumstances upon which the source code and associated materials are released by the escrow agent to the licensee. As a general matter, release provisions should focus on identifiable, indisputable facts. The easier it is to demonstrate the occurrence of a release condition, the more quickly and cheaply the licensee should be able to get access to the deposit materials. In addition, release conditions must also be legally enforceable.

Many software escrows limit the release event to the situation in which the software developer has ceased doing business and, therefore, cannot maintain the software. In this regard, the licensee can also ask for conditions related to harbingers of impending failure for release: the appointment of a receiver for the software developer's business, the making of a general assignment for the benefit of creditors (an alternative to bankruptcy liquidation), and the announcement to the public in general that the software developer is ceasing operations, are examples of such release conditions. Still another release consideration to plan for is a software developer's outright refusal to perform, repudiation of the license, including rejection in bankruptcy.

A licensee may also consider attempting to procure additional release events tied to the software developer's failure to perform its maintenance obligations in a timely or effective manner, eg, a consistent failure to respond to, or correct, documented errors within a specified number of days of their report by the licensee to the software developer.

The licensee should also consider other release events tied to the practicality of using the software developer for continuing maintenance services. For example, the licensee may use this release when the software developer seeks to increase maintenance costs beyond a specified limit set in the maintenance contract.

In addition, the parties should avoid relying on “insolvency” as a release condition because its occurrence is difficult to determine with accuracy and it is usually determined only in hindsight through expensive litigation with delay. Although an insolvency release condition may exist in an agreement, it often is not an enforceable release condition.

Finally, the parties must determine who pays for the software escrow. Typically, the software developer will pay for the software escrow, although this point is often negotiable between the parties.

What Are Key Issues Faced By the Licensee with Respect to a Software Escrow?

Despite a well-architected agreement between parties to a software escrow, problems do sometimes arise, particularly for licensees. One common problem is that the material (ie, the source code itself) is never deposited, or only partially deposited, into the escrow. To manage this issue, the licensee should watch for and monitor the escrow account activity, including a description of what was deposited and when. To assist with this process, the parties may agree to allow an independent technical verification service that verifies the integrity of the deposited materials.

Another problem faced by licensees is unclear or disputed release conditions. Most escrow agreements allow the software developer to oppose the licensee's release request when a release event allegedly occurs. To address such conflicts, the licensee may consider incorporating provisions into the source code escrow that provides a quick, low-cost, decisive alternative to litigation. For example, the parties may agree to an arbitration provision. Alternatively, decision-making executives for each party may be required to meet and resolve their differences through dialog and a threat of a release. Still another approach to resolve disputes is to write into the escrow agreement the requirement that disputes be “expedited,” including setting forth timetables to complete each step.

Still another problem encountered by licensees is having a complete source code deposit, but no guidance on how to work with it. To address this issue, the licensee should consider including a provision requesting supporting documentation and a list of technical maintenance personnel from the software developer. If the software developer goes out of business, these employees may be available as consultants after the release has occurred, helping to ensure that the licensee has access to support personnel familiar with the software.

A more complex problem facing many licensees today is bankruptcy of a software developer. Bankruptcy is often the most complicated issue in structuring and enforcing an escrow agreement. It is important to understand the underlying principles because the Bankruptcy Code interferes with the parties' ability to strike any bargain they want. Section 365 of the U.S. Bankruptcy Code gives debtor parties to “executory contracts” a choice of assuming and finishing the contract or “rejecting” it, generally leaving the other party to a damages claim. If the debtor is a software developer that rejects the license, it allows the licensee to retain certain rights to use the technology as it existed on the date of filing in exchange for paying royalties due under the agreement, and to have rights under “ancillary agreements,” which include the escrow agreement.

Section 365(e) generally disables certain contract clauses and provisions in some non-bankruptcy laws that permit the non-debtor's termination of an agreement because of a debtor's bankruptcy filing or its financial condition upon filing. These so-called ipso facto clauses are not enforceable in licenses where the debtor is a software developer. Hence, special crafting is required for the escrow release triggers to ensure that if the license occurs, and the licensee makes the Section 365(n) election, the escrow release will occur and be effective. Specifically, Section 365(n) grants the licensee absolute entitlement to retain rights to intellectual property (despite the debtor-software developer rejection of the license agreement) with some conditions. The licensee cannot also enforce exclusivity against the debtor or its assignee if the license is exclusive, and cannot compel further performance (such as development or maintenance) otherwise provided under the license.

There are a number of things a licensee can do to increase the probability of having the agreement fall under the scope of 365(n), including using executory contracts (which include software licensing agreements) that call for continuous performance over time by both sides. Because the rights that can be retained upon rejection are those that existed at the time of the bankruptcy petition, license grants must be present grants, not those that spring into existence upon bankruptcy. Specifically, an escrow agreement should be drafted as a present grant to use the escrowed materials and not just a license right becoming effective upon bankruptcy. If the license makes the escrow agreement effective upon bankruptcy, then that does not fall under the section of the code that says the license must be in effect in order to be valid, eg, reciting “software developer hereby grants” instead of “software developer grants.”

The right to the deposit materials should also be without regard to whether the software developer actually made the deposit required under the license. That way, if the software developer did not do so and the escrow is triggered, the licensee will have a legal right to demand that the debtor or its trustee hand over the materials. At the very least, this provides a licensee with the legal rights to the materials, and it can work with the debtor (or trustee) to find the materials.

Finally, the parties need to be careful in their license to differentiate which payments are for use of the licensed software and related intellectual property and which are for maintenance. Licensees making the Section 365(n) election must pay royalties required under the license to continue using the intellectual property. If the license is not clear, the licensee will end up litigating how much “royalty” must be paid to continue its use rights under Section 365(n) without the support and maintenance of the software developer.

Conclusion

Software escrows can be a vital part of a software purchaser's intellectual property plan and strategy. Further, software escrows can ensure that a licensee will have unfettered access to critical source code in the event the software developer becomes unable to maintain the same.