Customer question:

“My original thinking was that we could just put our source code in,  because the customer (Beneficiary) already had the object code versions of the 3^rd party software the customer was licensed to use.  We were going to provide EscrowTech with a copy of the 3^rd Party software for technical verification on an as needed basis.  It seemed so simple, until I was told that the customer would not be able to compile the software with just our source code and the object code for the third party software with which it was integrated.  I am sure that we are not the first of your customers who have had this problem.  Can you give us some guidance as to what others do, and what is allowed?”

Answer:

The issue of what should be deposited into the escrow can be somewhat complex and will definitely vary depending on the software and other factors.  The simple question is “what would the Beneficiary need in a worst case scenario to be able to maintain the software if the vendor is no longer available?”  Generally, Deposit Materials should not only include the current version of the source code for the application, but also build instructions, programming documentation, and a detailed list of the development/build environment (or even a virtual copy of the build environment.)  Deposit Materials may further include any software development tools, compilers, linkers, libraries, and any other resources used by the vendor which may be needed to maintain or enhance the software.

Anything that is commercially available may not necessarily be included, although a detailed list of such items would greatly assist the Beneficiary to know what to use.

Lastly, if the Beneficiary requires a third-party verification of the Deposit Materials, a Technical Verification may be performed.  See the following page for more details https://escrowtech.com/technical_verification.php.

One example – The SaaS user no longer obtains “ownership” or access to their unique customer data.  In traditional software this customer database resides on the user’s computer not in the cloud on the SaaS vendor’s servers.  Recently I received a call from a SaaS user who had been using a CRM SaaS solution for the past five years.  The SaaS user decided it was time to move to a more robust software solution from a different software vendor.  According to the SaaS user the current SaaS vendor held their customer data “hostage.”  Because the SaaS user no longer agreed to pay the SaaS vendor, the SaaS vendor was unwilling to release their customer data to them.  The SaaS user was forced to either stick with an unsuitable SaaS solution or move to a new solution and lose access to their customer data.  The SaaS user ended up suffering the loss of losing customer data and migrated to a new SaaS solution.  We set up a SaaS escrow with the new SaaS vendor to protect the SaaS user from experiencing this same situation again.  https://escrowtech.com/saas_escrow.php

I took this to Jon Christiansen, Senior Partner of TechLaw Ventures and General Counsel of EscrowTech International, Inc.  Below is his response:

The questions are good, and often not even asked when going into a transaction like this (or most any kind of SaaS or IT outsourcing arrangement.  Here are my brief answers as a long time practicing computer law attorney and as General Counsel for EscrowTech.

Your Question #1 “What if X suddenly increases the prices of the services?”

Y should insist on long term price protection in the contract with X – e.g., Fixed pricing, capped pricing, price increased tied to a CPI or PPI index, and MFN pricing.  Also, be constantly aware of alternatives to X (i.e., competitors of X) to whom Y can go, but Y should be careful not to be locked in to X for a long contract term.

Your Question #2 “What if X goes out of business?”

This question could be asked even more broadly.  What if the service is not available from X for any of a variety of reasons.  I will ignore physical disasters because that was excluded from the question.  A small company can simply go out of business and for all practical purposes disappear.  There may be a bankruptcy petition filed by or against the company.  In a bankruptcy, the trustee will likely reject the contract between X and Y as an executory contract and deny service (and access) to Y.  There may be a contract dispute between X and Y, leading X to claim breach and suddenly terminate the contract.  The termination may be rightful or wrongful, but in either case Y will be hurt.  Even if the termination is wrongful (e.g., Y didn’t breach), X may be substantially shielded by limitations of liability that give Y little or no monetary relief for damages suffered (e.g., loss of business or profits) because of the wrongful termination by X.  X may simply decide to end service to Y for any of a variety of business reasons (e.g., the business is not profitable, there is a relationship problem, or X wants to go with a different API or business model that is not acceptable to Y) and the contract may allow termination or a decision not to renew.  I call these financial and legal disasters (as opposed to physical disasters usually addressed through a disaster recovery plan of X).  For these legal disasters, the disaster recovery plan does not good.  The best solution is a SaaS or cloud escrow that has a third party (e.g., a company like EscrowTech – obviously I am biased) implement and maintain a mirrored solution (servers, software, continuously updated data, etc.) in place in a hot, warm or cold state that can be turned on in the event of one these legal disasters.  X should grant a license to use the software and any needed materials, development environment, intellectual property, etc.  The grant should occur upfront, and not later.  A license that is granted prior to the filing of a bankruptcy petition can be retained if the contract is rejected by a trustee in bankruptcy under Section 365(n) of the Bankruptcy Code (a post-petition license cannot be retained).  Even though the service by X stops, the service can be continued by the third party for Y (and other customers of X if they are also beneficiaries under the escrow).  Any of the legal disasters (not just bankruptcy) or an excessive price increase (you mentioned 5X) could be a trigger that allows the third party (escrow company) to make the mirrored solution available to Y.

Y could itself act as the escrow company for itself and have the mirrored solution on its own servers.  But Y may not have the capability or resources to do so.  Also, X may object to having customers hold X’s valuable software, intellectual property, etc.  X may not want multiple clients to have its proprietary solution.  Consolidating the solution with one SaaS escrow company would be better from X’s perspective than distributing the solution to multiple customers who might not take the same precautions as a SaaS escrow company.

A “storage” escrow may be sufficient in some cases in lieu of a full SaaS escrow.  In other words software (including source code), development environment, configuration files, build instructions, etc. could be held in escrow, but this is far less protective of Y than the SaaS escrow described above that has a mirrored solution ready (or nearly ready) to go in the even of a trigger.

None of this is “standard” because usually companies like X ignore the risk.  But increasingly more companies like Y and their investors are giving attention to this issue and protecting themselves.

For more information on SaaS escrows go to https://www.escrowtech.com/saas_escrow.php or see the video at https://www.escrowtech.com/video_saas.php.

Question #3 “What is some VC wants to invest in Y, but is worried about the risk….?”

The VC should be worried and refuse to invest unless Y takes the precautions described above.

Click here for original question from Quora

When a SaaS customer adopts a SaaS solution over a traditional software license the customer may no longer have possession and control over its data residing on the servers and storage devices of the SaaS vendor. The customer, as a subscriber to the SaaS solution service, is vulnerable to inherent risks of the cloud and a SaaS business relationship.

SaaS customers are faced with the reality of these risks:

• Sudden temporary or long term loss of access to SaaS services, applications and data due to legal and financial disasters such as SaaS vendor bankruptcy, insolvency, business discontinuation, contract termination, legal disputes, litigation, and deteriorating business relationships.
• Their own SaaS data being corrupted or lost by the SaaS vendor.
• The need to comply with internal policies and external regulations that are not met by the current SaaS vendor’s practices and capabilities.

A traditional SaaS storage escrow can provide assurance to the SaaS customer that it will have access to the SaaS application (source code and object code) and SaaS data if a release condition should ever arise. In this type of escrow, the SaaS application, build environment, implementation instructions, and any other desired materials are stored in escrow along with timely deposits of the customer’s SaaS data. Upon the occurrence of a contractually-agreed-upon release condition, the deposits materials (e.g., the SaaS application and SaaS data) will be released to the SaaS customer. The SaaS customer is then able to install and use the SaaS application to assist it in continuing operations that were dependent on the vendor’s SaaS solution. The SaaS customer will also be able to recover and use its data from the escrow.

In instances where immediate or prompt access to the SaaS solution is required, only a complete SaaS data center escrow is sufficient. In a SaaS data center escrow, the SaaS application and data are hosted on servers and storage devices at an Escrow Data Center. The SaaS application is continually populated with the customer’s SaaS data. In effect, a mirror of the SaaS solution is held at the Escrow Data Center. If a release condition occurs, the mirrored SaaS solution can be brought online for access and use by the customer. The SaaS customer is then able to continue operations without losing access to a functioning SaaS solution and its SaaS data.

There are significant motivators for software users to transition from traditional software licenses to SaaS solutions accessed over the Internet. In many instances the risks described above have inhibited some customers from adopting a SaaS solution. SaaS escrows can eliminate or substantially mitigate those risks for customers. SaaS vendors can also benefit from the adoption of SaaS escrows because these escrows proactively alleviate the concerns of prospective customers. By proactively protect the interests of customers when a SaaS vendor escrows its SaaS solution, the SaaS vendor provides a more reliable solution and addresses what may be the unspoken reservations of a prospective customer.

To learn more about EscrowTech’s various levels of SaaS Escrow solutions watch https://escrowtech.com/video_saas.php.

Several recent articles have covered the software escrow issue, including the following from PC World http://www.pcworld.com/businesscenter/article/151850/the_it_workers_wall_street_meltdown_worry_list.html, saying that “The bottom line is that you need to make sure that you can get a hold of the source code if that company goes under and ensure that it is the correct version and is valid.” 

EscrowTech is the leading Software Escrow agent in the country, with offices in India as well.  Please see the related blogs and visit www.escrowtech.com for more information about Software Escrows and Technology Escrows.

Phone: 801-852-8202    email: mail@escrowtech.com    website: www.escrowtech.com

This blog is dedicated to the explanation and exploration of Software Escrows and Source Code Escrows.  Much of this is taken from the article “Doing Software Escrows Right” published in the Computer and Internet Lawyer.  The author, Jon Christiansen, is not only a recognized computer law expert, but is also one of the founders of our company, EscrowTech International, Inc.  A full copy of the article can be found here http://escrowtech.com/article.php

Are software escrows useful?  How do you do a software escrow right?

Although software escrows have been used since the 1970′s, they are an increasingly common practice. Today, most software lawyers deal with them occasionally, if not frequently. 

A software escrow protects a software licensee by ensuring that the licensee will have access to the source code in the event that the licensor goes out of business, discontinues support of the licensed software, breaches maintenance obligation, or some other release condition occurs.  Typically, the parties use a software escrow when the license is for the object code (binary form) of the software, but the licensee does not receive the source code and therefore is unable to maintain, update, or enhance it.  The licensee is dependent on the licensor for maintenance, updates, and enhancements to the software.  Simplistically, a software escrow can be described as the following:

1. The licensor delivers a copy of the source code to a software escrow agent.

2. The software escrow agent holds the source code.

3. The software escrow agent releases the source code to the licensee only if a release condition occurs.

4. The software escrow agent returns the source code to the licensor if the escrow terminates without the occurrence of a release condition.

Sometimes software escrows are referred to as technology escrows.  For clarification, software escrow are a subset of technology escrow.  Some technology escrows do not involve software or source code.  For example, technical documents, chemical formulas, prototypes, drawings, and other embodiments of intellectual property can be held in a technology escrow.

1. Request the appropriate Agreement and forms from an EscrowTech representative by calling 801-852-8202 or email us at mail@escrowtech.com.

The following processes can be expedited by sending PDF copies via email or fax.

A. Single Beneficiary Software Escrow Agreement

a. Once you have reviewed and filled out the Agreement, print off at least one copy, sign it, and fax/email PDF a copy to the other party. Ideally, three original copies should be mailed through the loop for signatures so that all three parties can have an original.

b. The other party will then sign the originals and mail them to EscrowTech at the following address:

EscrowTech International, New Accounts, 3290 W. Mayflower Way, Lehi, UT 84043

c. Once EscrowTech receives a copy signed by both parties, an account manager will process the Agreement immediately and set up the Software Escrow to receive a Deposit. At that point, you will receive instructions and froms to make a Deposit.

B. Multiple Beneficiary Software Escrow Agreement

a. Review the Agreement and fill out the front page and Exhibit A. Also, verify that Exhibit B regarding Release Conditions is acceptable to both parties. Once you have reviewed and filled out the Agreement, print off at least one copy, sign it, and fax/email PDF a copy to EscrowTech to be fully executed and set up. Ideally, two original copies should be mailed to EscrowTech so that both parties can have an original.

b. An EscrowTech account manager will process the Agreement and contact you same day.

c. The next step is to fill out the Beneficiary Registration form. Input the Escrow No. given to you, your company information and contact person, reference your license with the client, input the product name next to its number (in a separated products Agreement), and choose the release conditions that you want to use from the sample language at the end of the form. You may need to have them approve the form before signing, but once you sign it go ahead and have your client sign it and send to EscrowTech. The other party should receive a copy of the master Agreement for their reference.

d. Once EscrowTech receives a copy signed by both parties, and account manager will process the Agreement immediately and set up the Software Escrow to receive a Deposit. At that point, you will receive instructions and forms to make a Deposit.