If you have specific questions regarding the hosted services provision, or any aspect of a Software as a Service Contract, please don’t hesitate to get in touch.
In the old days of software, deployment for a software company to a client entailed mailing a stack of floppy disks with a end user license agreement ("EULA") seal; the client broke the seal and the license agreement was agreed to. Maybe there was a prompt during the installation process for good measure. Internet connectivity was anything but ubiquitous and the idea of shipping software that heavily leaned on an internet connection, much less relied on connectivity, was anathema. The physical product being shipped was the software, true, but digital rights management ("DRM") was in its infancy, and making copies of the software was trivial. What was really being granted to the end user was a license to use that particular piece of intellectual property.
Most work at the intersection of software and law revolved around the issuance of licenses and the formation of license agreements. Now, as internet connectivity has become all but a prerequisite for business (and, perhaps even more so, personal) life, there has been a rise in the use of software as a service at the enterprise level. Software as a service is an umbrella term for the concept of remotely hosted software, maintained and hosted by the software provider, licensed to users on a subscription basis.
Software as a service ("SaaS") brings unique challenges to the legal sphere. Chiefly, there is a shift from mostly license-driven agreements to what are in essence technology service agreements. (There are tax implications, as well -- but a topic for another day). Notwithstanding this shift of primacy, there are still elements in a SaaS agreement that call for relatively standard software license agreement language -- the license to use the hosted services, the permission to or restriction on sub-licensing, etc. In a series of posts, I am going to explore some of the main provisions and standard language in a SaaS contract, and outline some of the things to look out for and issues to consider.
Hosted Services
The hosted services provision of a SaaS contract is, at its core, a grant of the right of the user to access the hosted software, a license to use the hosted software and all of the limitations therein, a service level agreement or promise of security and availability on the part of the software provider, and an agreement to an acceptable use policy on the part of the user.
Grant of Access
"Software Co. shall create an Account for the End User and shall furnish the End User with the login username and password for that account on the Effective Date."
A license to use the hosted software platform without the actual technical instructions and ability to access the same would not be of much use to the end user -- leaving this provision out would be like shipping the EULA without an disks. In drafting, consideration must be given to the software platform: does the platform require someone to manually register a username and password for the new account? Is it done automatically as a process of the end user's agreeing to the contract? Being specific about the method by which the Account will be created lends more clarity to the contract and ensures all parties are aware of what to expect and what is expected of them.
Grant of License
"Software Co. grants to the End User a personal, limited, nontransferable, non-exclusive license to use the Services, through the use of their own Internet Access, for the Purposes outlined herein, for the duration of the Term. Software Co. retains all others rights to the Services, including those provided by copyright, trade secret and other intellectual property laws. You are only granted the right to use the Services for the Purposes for the duration of the Term."
A grant of a license to the hosted services is the flip side to the grant of access -- the grant of access provides the end user with the physical ability to access the software, and the grant of license outlines their permission to do so.
An argument can be made that certain SaaS suites do not require a grant of a license to the software. A license grant to software is really only necessary when there is a copying or duplicating of the software. Thus, if a SaaS suite has some offline components (in other words it installs anything on the end user machine) it might still be wise to include a license grant. If, however, the software is entirely cloud-based, with no installation or "copying" for copyright purposes on the end user machine, then the omission of a license provision may be warranted. In such cases, it might be said that the software, housed and running on "Software Co." machines, is merely providing a service to the end user. In which case, just as an inventor of a special kind of wood splitter wouldn't need to grant a license to the customers he uses the chipper to split wood for, the SaaS company wouldn't need to grant a license to the software to the end user. Instead, the frame that the license should be viewed from is that it is a license to the service that the software provides.
Scope of the Grant of License
"The license granted by Software Co. to End User in this section is subject to the following limitations: ..."
If a license is to be granted for the software, care will need to be taken to outline the scope of the license. Some things that need to be considered include: 1) is the license granted just to an individual user, or the employees of the user? 2) how many concurrent connections to the SaaS are permissible? are there technical reasons why one may want to limit the total number of users online at a given time? 3) will there be a schedule of permitted users, as in cases where there may be confidentiality concerns?
Service Level Agreement
Service level agreements ("SLAs") outline the minimum service standards that are being guaranteed to the end user. Generally speaking, these include uptime guarantees (99.9%?), latency guarantees, and remedies available to end users should these standards not be met, or what sorts of force majeure events excuse all parties from performance. In addition, they may contain information regarding security and privacy, and time frames for service requests.
Specific uptimes can be difficult to guarantee, and present their own challenges in drafting. For instance, will a third party service be used to monitor uptimes and report outages? What will constitute a loss of uptime? Complete software outage? Substantial? If 100% uptime and software availability is not something that can be guaranteed, it should be disclaimed.
Latency is an even thornier subject, as the latency between any two servers on the internet can vary greatly based on regional issues and outages, network congestion, and other factors. Thus, having latency monitored by a third party may not be acceptable for an end user that isn't concerned with whether or not some neutral third party can reach the service.
Perhaps most importantly, an SLA will typically contain a provision outlining the mean time to repair and the mean time to respond. In other words, how quickly Software Co. will respond to an issue, and how quickly they can guarantee and issue causing an outage will be remedied. Often time to repair and time to respond will be further sliced and distinguished according to issue severity -- so, for instance, a mean time to respond and repair to a complete outage might be substantially less than the time to respond to minor bugs and defects. Further still, enterprise SaaS SLAs will often contain another set of response times for certain specific users. The VP of Operations having an issue reading her email, then, may take precedence over the Associate Counsel whose calendar won't sync.
Finally, Saas SLAs will generally contain an outline of how service issues will be escalated. In other words, the name, number, and email address of someone on Software Co.'s side that will answer the phone when an issue presents itself that warrants more action than an ordinary support ticket system can muster.
End User Policies
Finally, a Hosted Services provision will frequently contain an outline of what is and is not acceptable use for the end user. This often includes using reasonable methods and taking reasonable precautions to protect account details, not permit unauthorized access, and the like. This is a provision that will vary widely in length, complexity, and importance, based on the sort of software service being contemplated. The level of restriction can run the gamut from end users agreeing to only use the SaaS for the specific uses outlined in the agreement, to a simple "reasonable methods" boilerplate clause that holds the end user responsible for things done on the software using their access credentials.
Conclusion
In sum, the Hosted Services provision is among the most recognizable provisions in a SaaS agreement -- a holdover from days of yore. In future posts, I will go over provisions outlining support service, maintenance and updating, the licensing of the data put in to the SaaS by the end user to Software Co., and other considerations for data privacy and security.
Note this post is for informational purposes only and nothing contained within should be construed or relied upon as legal advice.