Understanding Software Escrows

smallSourceCodeAll around the globe, companies license custom software that is critical to their business. Developing your own proprietary software can cost millions. For most industries, licensing pre-existing software for daily operations is both less expensive and less of a hassle to maintain. Yet how do you ensure that the company you’re licensing from doesn’t go out of business or otherwise breach a licensing contract? You can’t, and that’s why companies like EscrowTech exist.

Software and its source code can be stored, verified, and updated with us. This protects the vendor as they only have to distribute their source code to one trusted company instead of multiple customers who are demanding a source code license.

Just as important it protects the licensee. In the event a software vendor goes out of business, breaches a contract, or can’t maintain client-side operations, a release event is triggered. This releases the source code to the licensee so that they can continue the daily operations of their business unabated.

Searching for answers. Top view of man holding note pad with question mark on it while standing on the wooden floorEscrowTech maintains its primary offices at the Technology Law Center south of Salt Lake City, Utah. This is also where your deposited materials are stored – inside a dedicated, secure vault. The multiple levels of security that keep this site safe include video monitoring networks, card-key systems, constant surveillance, and a fire suppression system. This maintains security and safety for your escrowed materials, but the purpose of escrow isn’t only to plan for what you expect. It’s also to protect you and your company from the unexpected.

That’s why we maintain off site storage in a second location. We call this our Perpetual Storage Vault, and it’s located in Little Cottonwood Canyon. Literally located inside the Rocky Mountains, the location uses both the natural protection of tons of granite and the technological protection of advanced security to keep additional copies of your materials safe and accessible. It’s built to withstand even the worst natural and man-made disasters.

woman with tablet pc and chart papersDeveloping a software contract is a standard procedure most businesses are intimately familiar with – or so they think.  Even if you are a pro at dealing with Software as a Service contracts, software development or other software implications, you may be stunned to discover some of the basics of software contracts that you were unaware of before now!

A recent data survey of close to 100 critical corporate legal contracts (as it relates to software) revealed many security trends and “pain point” issues that plague the rest of the contract industry.   There were many insights, but some of them were so simple they were shocking.  For example, did you know that a full 75% of contracts were put together through cut-and-paste methods from earlier contract drafting?  Yet only 22% of those businesses realized they were in danger of high risk of error.

Escrow agreements are designed to meet a variety of stakeholders’ needs.  Everyone from the creative mind designing the software to the person who invests in a software company has good need for an escrow agreement.  Here are some considerations for the end users of licensed technology when deciding on an escrow agreement.

First, end users should realize that it is definitely in their best interests to get a software escrow agreement.  There are inherent risks associated with depending on software that is basically “mission critical” and not supplied in-house, but rather by an outside, third party.  Could you survive a service interruption due to a vendor bankruptcy or acquisition?  If not, you need to start your search for the right escrow agreement by considering the kinds of services you actually require.

Is your license locally installed, enterprise software?  If so, then a standard software escrow agreement should suit your needs just fine.  An escrow agreement will verify the source code, procure an important copy of the code and put a plan in place to monitor regular maintenance and other agreements.

What about cloud –based applications?  That should be handled more appropriately with a Software as a Service agreement, which creates a different level of continuation procedures, should the worst happen.  People who use cloud-based apps are particularly vulnerable to a shift in operating procedures should a vendor go bankrupt or quit for another, better opportunity.

Do you have a critical application?  You should consider having a technical inspection and possible penetration test to determine where the weaknesses of this critical program might be (particularly now as it relates to Big Data capabilities).

Have an expert walk you through the details of what escrow plan is right for the needs of your business.

dv2171024Some believe they are saving money by not taking on a software escrow.  But the reasons why many financial partners give for not taking on a software escrow agreement are actually myths that have long needed busting.  So here are a few of the most popular reasons people claim to not need a software escrow agreement – and the realities of the situation.

You can’t be expected to trust an escrow agreement company.  The truth is, a reputable escrow agreement is a third party, neutral vendor who has no bias toward either the licensee or the vendor.   The goal of a professional escrow firm is an agreement that protects and clearly defines the issues for both parties.

My source code is in jeopardy!  Nothing could be further from the truth.  In fact, an escrow agreement protects your interest in the source code because it specifies when and how source code can be released.  Just because the customer is “entitled to” the source code in some way doesn’t mean that the customer gets the source code whenever and however they want it.  There are rules governing intellectual property, and they protect the creator just as much as they protect your customers.

An escrow agreement will prevent your sale of the company.  On the contrary, any good investor who has any real knowledge of the volatility of software firms will insist on an escrow agreement before purchase or investment in a Software as a Service company or software firm.  An escrow agreement is protection for everyone.  It ensures a customer or investor that the maintenance is going to be in place and technical support is always available.

Knowing the whys and hows of your technology and how it works isn’t enough.  You need more communication about how escrow agreements really work.  Instead of relying on myths or rumors, why not find out yourself just how a software agreement can benefit your company?

ThinkstockPhotos-492151733It might seem like putting together an intellectual property or software escrow is about guarding against wrongdoing, but in reality, it is a great representation of trust for both sides.  It is just an extension of the trust that has already been going on for some time, and it enables everyone to breathe a little easier knowing the that the unexpected is accounted for.

Getting into business in the first place is an exercise in trust, if you think about it.  Customers have to trust your brand, you have to trust that the choices you are making in terms of product line, website design, software package and others are the right choices to make.  If you have ever had customized software, then you should know that what you are getting is the “object code” – the front piece that makes the software run.  The heart of the software is the “source code,” its guts, its essence, so to speak.  This code is a developer’s intellectual property, the bread and butter, as it were, of a developer’s profits.  They don’t want to share it, and understandably, they want to protect their investment.

ThinkstockPhotos-466732957When setting up a software escrow one of the most critical areas to review should be the Trigger events also known as Release Conditions.  Here are a few common events that trigger the release of the code you put into escrow.

  • The software provider files for bankruptcy. This is, of course, a dreaded event, but it’s surprisingly more common than you might think.  When your software provider or the designer of your source code files for bankruptcy, you are within your rights to ask for the release of the source code.
  • Breach of agreement. Let’s say your software provider is required to provide certain maintenance or upgrades to the source code.  If you discover this isn’t the case (say, through an audit as part of your escrow agreement), then you may want to ask for an escrow release of the source code.

Check out this great article from the Software Advice teamhttp://blog.softwareadvice.com/articles/enterprise/the-cloud-and-why-installed-software-isnt-going-away-1013112/ .  It is a good summary of the forces keeping installed software around as cloud computing continues to emerge.  I too believe installed software will stick around.  In many instances it is a better fit for enterprises.  I have worked with EscrowTech over 13 years and witnessed the emergence of cloud computing.  In the cloud environment the vendor is exposed to additional inherent financial and business risks than with traditional “installed” Software.

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

Recently this question was posted on Quora:

What kind of legal assurances (IP related) do SaaS startups have to give (early) enterprise customers?

Suppose there is Startup X that provides some software as a service in the cloud. And there’s an API which other service providers can use to build services on top of X’s services. Now suppose there is Startup Y which is providing some solution to end customers while using X’s services under the covers. What is the norm for the kinds of assurances that Y can expect from X in terms of IP.

Specifically, Y is worried about being locked into using X’s services without much of an alternative (because this service is not yet a commodity). So Y’s concerns are:
1. What if X suddenly increases the prices of the service?
2. What if X goes out of business?
3. What if some VC wants to invest in Y, but is worried about the risk associated with the use of X’s service – and insists that he cannot fund Y unless Y is able to acquire the IP of X (or something to that effect)?

What kinds of protections is it reasonable for Y to demand? What kind of assurances does it make sense for X to provide? I’m assuming this is not an uncommon situation – is there an industry “standard” in this area?

(Note: I am not talking about SLAs (service level agreements), or outages, and support and things like that. I am talking about the entire service being withdrawn, or prices being increased by 5X, or other such issues.

Also, I have a rough idea of how these issues are handled when either X or Y or both are big, established companies. My question has to do with the specific case where both X and Y are small, early-stage startups.)

If you were Y, what kind of assurances would you ask for? If you were X, how would you deal with a Y?

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.