This article was first published on CloudPro.
Many organisations use software escrow for peace of mind but this
doesn't work with cloud - what options are available?
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.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.