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. 

The Telephone Consumer Protection Act 47 U.S.C. 227 (TCPA) has, for some time, been steadily increasing in inscrutability. In 2017 it appears set to continue this trend with new case law, even as FCC chairman and expansive-TCPA-interpreter Tom Wheeler cedes the agency's reins on January 20th, leaving the future of the act in new hands.

On the case law front, wasting no time in the new year, the Northern District of Ohio rendered a decision on January 3rd that, in effect, ensures manufacturers of products are not held liable for unsolicited (in this case, faxes) sent by third party entities, merely because the advertisement, if heeded by a consumer, would benefit the manufacturer's bottom line. To hold otherwise, the court was concerned, would give rise to "sabotage liability."

"By way of illustration, it would allow a rabid Tampa Bay Buccaneers fan – with a rhino helmet, red face paint, and an undying devotion to the organization – to trigger per se liability for the organization under the TCPA by gratuitously, and without directive from or notice to the organization, promoting season ticket sales via fax.  The same could be true of a random individual in Boston, mind brewing with scienter, who works to implicate the New York Yankees by advertising their season tickets.  Universal liability for complete inaction was not contemplated by Congress in passing the TCPA and does not appear to have been contemplated by the FCC in crafting and interpreting its regulations."

Thus, the pendulum that is the TCPA swings back, the definition of "sender" contracts -- if only in Ohio, if only for now. 

Traditionally privacy policies have answered three general questions: (1) what user data is collected, (2) how that data is collected and (3) how that data is stored or used; generally, how that data is treated.  A privacy policy is a simple enough thing to draft when the entity directing the drafting is the sole party acting to collect and store data. In the case of the modern web, however, that is never the case. For the most part even the most basic of websites will utilize some content delivery network (CDN) to serve images and other larger files and embed code to track usage data. CDNs and analytics companies will, then, have access to non-personally identifiable information: internet protocol (IP) addresses, browser, operating system information, and display information, and in the latter case, referrer universal resource locators (URLs). More and more ecommerce sites are taking advantage of third party payment processors, rather than taking payments on-site and taking on the burden of security maintenance and all of the accompanying risk. In short, as more and more services are outsourced, the number of entities gaining access to some form of user information is directly correlated to the complexity of the website. Indeed, with the advent of third-party authentication services such as Facebook Authentication, Google OAuth and LinkedIn OAuth, user data is only becoming more removed from the control of the entity owning and operating even a relatively simple website.[1] This raises questions as to how one can best disclose the answers to the above three questions. 

What User Data is Collected

There are known-knowns, known-unknowns, and unknown-unknowns[2]. The data that is collected by the website owner is a known-known – you either do or do not offer a "Contact Us" form that collects and stores a user's name, email address and their comment. Without further investigation, the information obtained from a user choosing to use Facebook Authentication is a known-unknown – you are aware that user registration and login information is collected by a third party, but you don't know how that information is being stored. Unknown-unknown information is all of that information[3], potentially collected by a third party, that it is difficult or impossible to ascertain the storage and use of. For example, an analytics company that offers free user analytics services may be using the aggregated information in order to improve their other offerings. Their own privacy policies may only obliquely reference what aggregated information is used for and, as such, a privacy policy cannot in good conscience be drafted in a way that makes representations or warranties as to what information is collected by that third party.

How Data is Collected

Methods of collecting data is another area by which the complexity of a website significantly impacts the scope of the privacy concerns. The obvious first level collection schemes are all of those user-driven and user-chosen methods: contact forms, user registration, payment processing, email listserv subscriptions, etc. Second level collection schemes are those that can be ascertained by examining the website and its source – analytics and tracking scripts, calls to offsite-hosted images, cookies, etc. Third level collection schemes, which are the most difficult to know and thus disclose in a policy, are all those methods that are not either user driven or evident in the source of a website. For instance, an examination of the source of a website may indicate that a call is being made to a third party for a tracking script, but the source cannot and will not give guidance as to whether that third party is using data analytics on their own server logs to form a more complete picture of a user, or tracking the user across multiple websites.[4] How information is collected is more difficult to disclose, then, as the owner of the website can realistically only indicate how they think information is collected, what information is collected that they are privy to, and the identities of some of the entities that they have chosen to collect information.   

How Data is Stored or Used  

So-called "Right to be Forgotten" European Union laws aside, if there is one immutable fact about the internet, it is that anything that is on it, remains on it. In the early days of the web, a privacy policy could give users an accurate picture of how long information that is collected about them will remain – a quick call down to IT would be all that was required. In the modern web, a visit to a website is more akin to tossing a stone in to a pond. A rudimentary privacy policy can describe the splash, a well-drafted policy can predict some of the ripples, but no policy will be able to describe the effect on the shoreline. To abandon the metaphor, a privacy policy can be drafted to outline how long the website owner intends to hold on to user information and how long third-party services tied to the website claim to retain user information, but it can never tell a user with an accuracy how long it will be before their visit or use of the site is "forgotten." 

Solutions

1. To the extent that you can, disclose.

The above may serve to discourage an individual from bothering to draft a policy at all, but this is not the intent. Information privacy was hardly in the public discourse twenty years ago. The first discussions of privacy mostly centered around personal healthy information, later turning to contact information, with the advent of do not call registries, and financial information, as identity theft has become more common. Moving forward, the trend line would appear to point squarely in the direction of privacy becoming more important and more relevant -- the European Union and the State of California have already adopted laws mandating as much.

As such, not surprisingly, the solution to privacy policies lagging behind the increasing complexity of the web is … increased disclosure. To the extent that you know what information is collected, stored and used, disclose it. To the extent that you know what information MIGHT be collected, store and used, disclose it. Where you aren't certain of anything, disclose the entities that you have contracted with to provide services that might be collecting information and link to their privacy policies. Don't work with entities that do not provide privacy policies that at least give some modicum of explanation as to how information is collected, stored and used. 

2. Offer an up to date list.

In your privacy policy, elect a Data Controller and allow users to reach out to them to obtain an updated list of all the companies (third party service providers, mail carriers, hosting services, IT companies, communications companies, analytics companies, advertisers, etc.) that may be processing user data. Maintain the list and, where possible, post it and link to it in your privacy policy.

3. Update your policy frequently.

The privacy policy of a website cannot be thought of as a set-it and forget-it static page -- just as the rest of your website is evolving, so too must your policy. At regular intervals have your policy reviewed and updated to reflect features added or removed from your site, third parties contracted with or released, and changes to third party's policies.

4. Demand more.

Think of yourself as a steward of your user's information. When you choose a new product, contract with a new party, or implement a new feature, call on the entity you are working with to provide you with answers to the aforementioned three questions: what information is collected, how that information is collected, and how that information is used. It is more than just a nice thing to do for your users, it helps ensure that, as privacy becomes more and more of a hot button issue, you remain ahead of the curve and needn't fear having to fix a problem that could have been prevented through good management.

[1] Indeed, to want to make use of a third-party authentication service the website owner need only wish to save user preferences with slightly more granularity and permanence than a traditional "cookie" can provide. The availability of free authentication services through Facebook, Google and LinkedIn, among others, creates a situation where the entities that are seeking the most cost effective and simple method to permit users to have an account on their website are the ones that need to draft the more sophisticated privacy policy.

[2] https://en.wikipedia.org/wiki/There_are_known_knowns

[3] Generally speaking this will be non-personally identifiable information – IP addresses, regional location data and the like.

[4] The concern being, at some point, a certain order of magnitude of non-personally identifiable information is personally identifiable information – enough individual data points and the number of individuals that fit all of those points eventually drops to one.