{php}echo $_SESSION['the_Crumb'];{/php}

short lines

Software business models and contracts on the cusp:
Legal Implications of Software as a Service

August 2009

Introduction

The software industry has entered its period of greatest change since its inception as a distinct business forty years ago when IBM first unbundled software from hardware. This change has been driven by the Internet and the constant need to innovate to gain competitive advantage, and subsequently accelerated, in the last year or so, by the onset of adverse economic conditions and a consequent business imperative to achieve efficiencies and reduce costs.

As the second of five software focussed Short Lines that we will be publishing in the second half of 2009, this article considers one of two areas currently of greatest development in the software world: the rise of service-based computing. In particular, we will review what it is, where it has come from and where it is going, before briefly looking at the legal issues affecting these types of services. We consider the other significant development are, Free/Open Source software, in the next article in this series.

The four stages of service-based computing: ASP, SaaS, cloud and utility

Easy to use; faster; and more secure, reliable and scalable broadband Internet communications connections lie at the heart of the rise of service-based computing, with ASP (application service provision), SaaS (software as a service), cloud computing and utility computing representing stages one to four of this development[i]. All of these stages share the essential features of delivery of software as a service over the Internet: remote processors (as distinct from “software as a licence” installed on the customers’ servers); a “one to many” (rather than a “one to one”) hardware centre; and periodical payments on a subscription basis (in contrast to up front licence, development and integration fees payable for software traditionally provided under licence).

ASP

ASP, properly characterised as “hosted application management”, was an early beneficiary of the convergence of computing and communications that the first stage of the `Internet revolution’ enabled in the mid to late 1990s. Whilst still popular today, is viewed as rather cumbersome outside the enterprise (large system/requirement) market. This is primarily due to the fact that it relies (at the start of the relationship) on significant configuration/installation services and (throughout) on support services typically supplied separately.

SaaS

There is a step change between ASP and SaaS, in turn characterised by:

‘built for the web’ software applications which improve usability and manageability;
the supply of ‘web ready’ services for the customer[ii];
the supply of software to multiple customers, concurrently, through a ‘one to many’ secure delivery model[iii];
addressing consumer as well as professional markets; and
payment on an incremental ‘pay per use’ basis.

Cloud

The evolution from SaaS to cloud computing is marked by the ‘massive scalability’ (in the words of a Gartner report from 2008) of computing services provided through the cloud, the traditional metaphor for the Internet as the communications network between the customer and the computer resources it is accessing. In practical terms, the ‘massive scalability’ of cloud computing means moving to bigger and bigger data centres – think of TV images of futuristic, low, windowless warehouses the size of five football fields on the banks of the Columbia River in Oregon, USA. The CRM service of Salesforce.com is classic market leading SaaS and cloud computing service[iv].

In addition to CRM, the line of business based services likely to prove fertile ground for the uptake of cloud computing include HR and accounts, web-conferencing and collaboration; supply chain; budget/expenses management; web content management; e-commerce; and email and email marketing. Given the current growth in demand for Internet based software delivery techniques and the hugely popular services offered from them such as social networking sites like MySpace and flight searching services, Merrill Lynch has predicted that the cloud computing market could reach $160bn by 2011.

Utility

Utility computing will perhaps at some point in the next decade represent the ultimate stage of service-based computing, where all the computing resources needed for performing particular business and consumer tasks – data input, processing, programming, storage, output and communications - will be able to be assembled and packaged into the required customer service for supply on a metered basis like electricity.

Service-based computing (particularly in the stages after ASP) means that the customer does not need to make significant investments in its own infrastructure and resources – servers, space, security, staff, etc – as it does in order effectively to use a particular software developer’s licensed-in solution. Supplier dependence is reduced, and switching to an alternative service provider becomes a practical possibility. Avoiding the need for high sunk costs and the ability to switch suppliers are direct consequences of the rise of service-based computing and represent far-reaching changes to the software business model. They will lead to more choice, greater competition, faster innovation and lower prices. These trends will develop more quickly in the straitened economic climate likely to prevail over the next few years where the accent will be very much on using technology to reduce business cost and risk.

Service-based computing: legal issues checklist

Just as software customers have got used to the ins and outs of software licensing and all the contractual points arising, along comes a new service-based computing technique. Although they come in a software or computing wrapper, most of the contractual points customers and suppliers will need to think about will be familiar from other ‘grown up’ services contracts. By way of checklist, they can conveniently be grouped under four heads –

supplier stability issues (what if the supplier goes bust?);
customer service/dependence issues (what’s the worst that can happen?);
lifetime contract issues (redressing the balance); and
regulatory issues (data protection, data security, audit, sector-specific and generally applicable regulation)[iv].

Supplier stability – what if the supplier goes bust? From the customer perspective, things that the customer will need to think about in current economic conditions include:

supplier financial stability: do your credit searches (bearing in mind that information more than 3 months old is likely to be too out of date to be of much help) and customer and supplier references;
supplier dependence: check whether the supplier itself depends on particular resources and the financial stability of the providers of those resources to the Supplier; and
what are the supplier’s own disaster recovery/business continuity arrangements?

Customer service/dependence – what’s the worst that can happen? Review, assess and, if necessary, remediate:

customer’s dependence on the supplier: what will be the impact on the customer’s business in each case of a small, moderate or severe service outage; and what happens if the services are not performed at all or up to scratch?
customer’s ability, time required, etc to switch to an alternative source of supply;
ensure the customer can effectively monitor and operate any supplier contract requirements on security, passwords, etc: it is embarrassing if staff are swapping passwords to access the service where this is not permitted under the contract;
as ever, think through the exit/disengagement strategy before contracting, and make sure the customer puts in place an effective, workable exit plan particularly to promptly recover data and to do so in a useable form; and
make sure the customer has full, unrestricted right and title to intellectual property in the customer data and that the supplier is appropriately bound by confidentiality and non-disclosure obligations.

Lifecycle contract issues - redressing the balance in negotiations

SaaS and cloud computing providers' standard-form contracts are generally long on supplier rights and customer obligation and short on supplier obligations and customer rights. That is because they have many contracts in the field, so the agreements become a sort of probability theory with the accent on generics. The customer of course wants a deal that meets its requirements, with the accent on specifics. Against this background consider to what extent the customer can realistically negotiate a better deal (which in the service-based computing world is likely to involve higher fees) on:

service levels and service credits for performance below the contracted standard;
pricing, price benchmarking and so on, during the agreement;
changes the customer may want to make at any time or times during contract lifecycle;
business continuity/disaster recovery − the customer may get an enhanced back-up service if it is prepared to pay higher fees. Don't forget to test at least annually (and more frequently in appropriate cases) the resilience of the back-up and data return arrangements put in place under the agreement; and
as customer, check that you're happy with the position on:
- Supplier use of sub-contractors to provide the service; and
- Communications requirements − are you buying VPN or other internet access services from the supplier or is the supplier saying this is down to the customer? If the supplier is providing them, check they're adequate (and try and get the benefit of market pricing pressures, especially in long term deals, as bandwidth prices decline). If not, make sure your communications requirements are adequate for, and ideally back-to-back with, the services supply arrangements.

Regulatory issues to be addressed in contract negotiations. Regulatory issues are taking up more paper in service-based computing deals. Consider:

treatment of personal data and compliance with applicable data protection laws. Does the agreement cover personal data? If so, will it be processed outside the EEA − in the USA or India for example? If so, who is the data controller and who the data processor and how are the transborder data issues dealt with?
in what circumstances can third parties obtain contract data?
if the customer is operating in a particular sector (for example, financial, professional or healthcare services) make sure the supplier is required contractually to comply with the regulations that apply by operation of law to the customer and endeavour to ensure back-to-back compliance.
ensure adequate audit rights, and that these enable the customer to comply with any audit carried out by the customer's regulator.

Rebecca Anderson

[i]For a description of each of these stages, please see the Glossary attached to our first Short Lines in this series.

[ii]Such services include support services. SaaS providers can benefit from only having to support one version of their software and delivering their service on a single platform. In addition, vendors can make enhancements to the software on a regular basis, fairly simply: as the software is located at the SaaS provider’s data centre and not at the customer’s premises, the vendor is able to implement enhancements and upgrades at its data centre and then make those changes available to its entire customer base. Each of its customers can then, depending on their configuration settings, either accept or reject them, as required.

[iii]This multi-tenant architecture allows vendors to offer customers major cost savings as a result of economies of scale achieved by managing multiple customer solutions in a single instance. Vendors are further able to reduce costs by using open source software in their software applications.

[iv]It is common for SaaS providers to host their service and store all of their customers’ data in the cloud. All of the data belonging to each customer is stored, or “stacked” on shared computer platforms operated by the SaaS provider in the cloud, but each customer’s data is capable of being kept separate from that belonging to others.

[v]The later two heads will be discussed in more detail in our final two Short Lines articles in this series.