Business customers are familiar with software escrow. It can be an effective remedy where a business pays for a software licence but the vendor goes bust. But it’s not really an effective answer for cloud customers.
The traditional model of proprietary software licensing has been for software supplier to license the object code to customers and hold back the source code. Without the source code and with complicated practical and legal restrictions on decompiling the object code back to source code the customer can’t adapt the software to do what the customer wants. For this, the customer must rely upon the software supplier.
This works fine until the customer and supplier fall out or the supplier goes bust. The answer is escrow where, for a fee, the customer can get the source code if certain events occur. Under this arrangement, the customer will install the object code on its equipment and run it locally. The software supplier will deposit the source code of its proprietary software and relevant documents with a trusted third party – the escrow agent. The escrow agreement between the customer, supplier and escrow agent will specify that if certain "release" or "trigger" events occur, the agent will release the source code and documents to the customer.
Typically, a trigger event is where the supplier fails to maintain the software or becomes insolvent. Once it has the source code, the customer can hire a new supplier to adjust the code to do what the customer needs. That’s the theory anyway. It’s not a simple task to take someone else’s source code and make sense of it, but at least it’s an option.
Cloud is different and escrow is not the cure-all that many think. If a customer has opted for a public cloud SaaS offering, that software will likely be a standardised version offered to all customers. The supplier won’t want to enter into escrow arrangements with all its customers who are paying rock-bottom prices. Even if it’s a bespoke software solution, by the very nature of cloud, there is likely to be very little installed on the client’s equipment. Perhaps it will be accessible by via a web browser. Therefore, the customer won’t even have the object code but will have access to software run on the supplier’s infrastructure.
If there is an escrow arrangement in place and the supplier goes bust, then in theory the customer can now get access to the code and can hand it over to a new supplier. At a practical level, with a traditional software licensing model the customer can still use the software while it finds a new supplier, but with SaaS that might not even be an interim option. In the meantime, with the bust supplier not paying its data centre or electricity bills, the service may have stopped. Relying upon escrow is probably not a viable business continuity strategy.
If a customer still believes escrow can be of value, then it needs to ensure it has access to its data. If the supplier is hosting the data too, then the customer needs to identify how to get this back or, at least, for a new supplier to get hold of it. Perhaps the customer should consider keeping the master or backup copies on its own site through a hybrid cloud model.
Even then, all too often upon release the source code might be out-of-date, incomplete or even defective and of no use.
So the customer will have to keep on top of this by ensuring the escrow agent verifies each deposit of code will do what it is supposed to – and a verification service is usually not cheap. Also, the customer may need to insist upon regular deposits of code as the supplier updates and maintains it. The customer should identify a third party supplier upfront who can step in at short notice. Finally, if the supplier has not gone bust but the relationship has deteriorated, the outgoing supplier might contest that there has been a release event. The escrow agent won’t want to get drawn into a dispute between the customer and supplier so both sides may need to engage lawyers.
There might be another way but it will cost more and is not generally available. This would be where one supplier runs the primary service and a secondary supplier runs a back-up or failover service. If the software is proprietary then the primary supplier is unlikely to agree to this. But if the secondary supplier offers a similar service the other way round, it might be an option.
So what can a customer realistically do? There are other options which don’t involve escrow:
- Prevention is better than cure. The customer should evaluate its proposed cloud provider. Does it have a good track record and good finances? Does the provider have any standards accreditations such as ISO or with the Cloud Industry Forum? Does its cloud contract adopt the Cloud Industry Forum’s best practice recommendations?
- The customer should draw up a sensible business continuity plan. For example, pay for the additional backup and failover solutions from the supplier. Often, the customers who complain their business is affected by their supplier’s outage are the ones who didn’t pay for failover.
- If the supplier is renting space from a data centre, can the customer bypass the supplier and deal direct with the data centre, even if just to get its data back? This is easier where the supplier is bust, but the customer should be thinking about this upfront and addressing it in its contracts.
- Are there competing products which could provide a similar service? If so how long would it take to switch to a new supplier if the current one goes bust? Getting access to the data may be key here, so the customer should think about having a local copy or one directly accessible from the data centre.
- The customer should evaluate whether to have a private or hybrid cloud and keep a list of other suppliers who could step in and continue if something happens to their main supplier.
Frank Jennings is chair of the code governance board of the Cloud Industry Forum, co-founder of Cloud Industry Legal Forum and partner in law firm DMH Stallard LLP. frank.jennings@dmhstallard.com
