In an increasingly digitized business world, any software application can be mission-critical. A company can only survive and thrive when it gets adequate support for the applications that drive it. Yet, more than half the IT decisionmakers who responded to a recent IDG Research survey reported they entered into a relationship for use of critical applications with a vendor who failed to meet their expectations.
The most common reason for that failure was a breach of service level agreements (SLAs), which is fairly easy to correct. However, 35 percent cited causes that are harder to bounce back from: failure to support the application, a merger or acquisition that deprioritized the application, or the vendor’s bankruptcy or insolvency. The negative consequences ranged from cost overruns, project setbacks, and poor internal IT performance to customer dissatisfaction and brand damage, legal involvement, and loss of revenue.
John Boruvka: Vice president for Iron Mountain’s Intellectual Property Management group, John is a widely recognized expert in technology escrow and issues related to intellectual property (IP) protection.
Frank McGinn: An award-winning attorney specializing in business litigation and insolvency, Frank works with Iron Mountain on the legal aspects of technology escrow.
Boruvka: Enterprise companies face lack of support issues from their vendors all the time. Here are a couple of examples of how real customers handled problems through the release of source code from escrow:
Boruvka: With technology escrow, a developer agrees to store all the source code, build instructions, third-party tools, databases, and other proprietary information with a neutral third party, such as Iron Mountain. That way, a licensee can recreate the environment necessary to support the product in case something happens to the developer. The escrow agreement defines the specific conditions under which the neutral third party can release the source code to the licensee. Once you’ve signed your licensing agreement and the vendor has moved on to focus on its next customer, your escrow agreement allows you to escalate the conversation about any unmet SLAs with the leverage of releasing the source code. It also protects you in the worstcase scenario, when you need to access the source code to keep your critical application operational.
McGinn: Escrow engenders trust between the parties and levels the playing field between small developers and large companies. Outside the U.S., it avoids the bottomless pit of intellectual property issues that would otherwise occur if the code were directly turned over to buyers.
McGinn: The most common example is if the developer is insolvent, goes out of business, files for bankruptcy, or has a restructuring instituted against it. Another is if the developer fails to support the software or meet the maintenance commitments specified in the main licensing agreement. We’ve also seen escrow agreements that call for code release if a developer chooses to stop supporting a specific product, if one of the founders or lead technologists dies or leaves the company, or if the developer starts competing in the licensee’s market.
Boruvka: Licensees should negotiate use rights for source code and other information as part of their main agreement with the developer, or alternatively, reflect them in the escrow. The publishing industry company we mentioned earlier actually hired engineers from the failed startup to continue developing their product in-house. The healthcare organization is free to maintain, retire, and even generate a new product from its source code.
McGinn: The main benefit is the ability to avoid the cost and delays of litigating in bankruptcy court against a trustee, other creditors, or anyone who claims the licensee doesn’t have a right to the source code.
Boruvka: If a developer goes out of business, an escrow release lets you continue with development in-house or keep a suddenly unsupported product running long enough to find and implement a replacement.
Boruvka: It’s very important for companies to keep their designated contact information up to date. If a release is initiated, and the designated contact is no longer with the company, it stalls the process. The developer also has to have a current address on file so we can request contrary instructions. Otherwise, the code gets released to the licensee by default.
McGinn: Escrow parties sometimes assume mistakenly that Iron Mountain will assess whether the allegations in a release request or contrary instructions are true. However, Iron Mountain’s role is generally to await joint instructions or an order from an arbitrator or judge, once there is a dispute over the occurrence of a release condition.
Boruvka: Escrow deposits are extremely useful if they’re complete. We verify about half our technology escrow deposits, but recommend that every escrow agreement should include at least basic verification. In the release process, we’ve discovered that developers often inadvertently omit critical build instructions and third-party tools. If you ever need to rely on a technology escrow release, you’ll be glad you completed verification.
NCC Group Software Resilience has acquired Iron Mountain’s Intellectual Property Management (IPM) business. For more information on the acquisition, please visit our dedicated information hub, or contact Iron Mountain IPM.
