Dealing with Application Service Providers
APPLICATION SERVICE PROVIDERS; THEIR MARKET NICHE
by David Smith, Corrs Chambers Westgarth
In his article, David Smith provides an overview of the relatively new business
of Application Service Providers' "renting" applications to customers. David
provides a checklist of some key legal issues to consider when establishing
an agreement with an Application Service Provider.
An Application Service Provider (“ASP”)
provides software-based services in real time, from a remote data centre. The
ASP can be crudely described as “renting” an application to the
customer.
ASP services are growing rapidly in popularity
and are being offered by numerous organisations ranging from the very large
(for example IBM Global Services and Qwest Cyber.Solutions) to the relatively
small. The packages offered by ASPs likewise include major applications (SAP,
Oracle and the like) through to small, industry-specific applications.
According to a story published in Computerworld
on-line magazine on 18 January 2000, a study conducted by Evans Marketing Services
in December 1999 indicated that, “Over one-third of information technology
and development managers at large [US] corporations expect to rent applications
from application service providers this year”.
Over 400 development or IT managers, responsible
for more than 2,000 employees, were polled (story available through www.computerworld.com).
A perceived benefit of ASP arrangements
is the evening out of cash flow resulting from the pricing arrangements which
usually revolve around a monthly, per user fee – although some ASPs also
charge a one-off set-up fee.
The ASP provides a scaleable solution (i.e. the customer
can add more users readily, subject to paying increased fees), which reduces
the investment required by the customer in software licensing, hardware, infrastructure,
labour and training. At the higher end of the market, ASPs provide services
integrating several software applications along with comprehensive support and
maintenance services (and associated training and help desk services) and other
specialist services.
From the ASPs’ point of view the
intention is to derive economies of scale from providing a single solution to
numerous clients, although at the higher end of the market ASPs are prepared
to offer significant degrees of customization for particular customers.
Frequently ASP services are provided over
the Internet through a World Wide Web interface. Drawbacks of ASP services
compared to the customer licensing software and installing the software on its
own servers include:
• business reliance on
a third party (i.e. the ASP), who cannot be controlled except to the extent
that the legal and commercial relationship with the ASP can be managed;
• reliance on external
telecommunications links; and
• reliance on the Internet
with its inherent speed and security issues.
The performance of software provided through ASPs can
also be inferior to software d directly by the customer if the web-enabled versions
provided by ASPs are adaptations of pre-existing software rather than software
which has been designed specifically to be accessed over the Web.
CHECKLIST – MAKING AN AGREEMENT WITH AN APPLICATION
SERVICE PROVIDER
Set out below is a brief checklist which may be used
by customers or their advisers as a guide in considering what needs to be included
in an agreement with an ASP.
Term
• What is the period of the agreement?
• Does the customer have a right to
extend the term?
Licence
• There should be a clause licensing
(or to be precise, in many cases, sub-licensing) the customer to use the software
hosted by the ASP.
Warranties
At the least, the customer will want the ASP to warrant
that:
• the software being made available
by the ASP complies with the agreed specifications;
• the ASP has the right to grant the
licence; and
• the software and its use by the
customer will not infringe any third party intellectual property rights.
Liability and exclusion clauses
• The ASP should not be allowed to
limit its liability for breach of contract or negligence unreasonably. If a
liability cap is agreed upon it should reflect the risk to the customer if something
goes wrong. Liability caps should not bear some arbitrary relationship to the
value of the ASP contract or to the amount paid to date under the ASP contract.
Preferably the ASP’s liability for intellectual property infringement,
confidentiality breach, personal injury or damage to property should not be
capped and the ASP’s liability for consequential losses should not be
entirely excluded.
Price
• Be sure to check how long the price
will remain fixed and what adjustment mechanisms apply.
Acceptance testing
• The customer should reserve the
right to acceptance test the software provided by the ASP and if acceptance
testing consistently fails, to terminate the agreement and obtain a refund of
any fees paid.
Confidentiality and security
• These are particularly important
clauses in the context of an ASP contract, because the ASP will probably be
hosting at least some data which is confidential to the customer.
Termination
Consider:
• the customer’s rights to terminate
(at least the usual rights to terminate for persistent breach and upon the ASP’s
insolvency should be included);
• the ASP should not be able to terminate
arbitrarily (i.e. without cause); and
• the assistance the ASP is required
to provide on termination, while the customer makes the transition to having
its applications reside elsewhere. This is very important.
Support
It is important to conclude support and maintenance
terms at the same time that the other aspects of the
ASP “deal” are negotiated, so that the customer
preserves its bargaining power. The numerous support-related issues to consider
include:
• the ASP’s willingness to commit
to an uptime percentage;
• the ASP’s willingness to commit
to response times to address and resolve problems (i.e. any deviation from the
agreed specifications);
• whether the customer can decide
the severity level of a problem in the event of doubt or dispute;
• whether the ASP will provide on-site,
or only remote, resolution of problems;
• making part of the fee for the next
month depend on achievement of uptime and response time targets;
• whether the customer is entitled
to terminate if support targets are not met;
• what help desk and similar resources
are provided;
• whether the ASP is required to consult
with the customer concerning any planned downtime;
• whether the customer has a choice
about taking a software upgrade offered by the ASP (ASPs may well resist allowing
their different customers to be using different versions of software, as this
obviously reduces the economies of scale achievable by the ASP);
• what disaster recovery measures
the ASP has in place;
• whether the ASP commits to providing
the customer with regular reports of software usage, uptime and any problems
and their resolution (including resolution times); and
• what training the ASP provides.
How hard a customer chooses to negotiate with an ASP regarding the above points
depends of course on a pragmatic weighing up of the need to “get the deal
done” against
the benefits of comprehensively negotiating the legal
issues outlined above so as to minimise the customer’s exposure to risk.
September 2000 contents
|
