SaaS

Check out this great article from the Software Advice team: http://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

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.