First, it is worth outlining from a technology perspective what software as a service (“SaaS”) is. SaaS is a method of software delivery whereby the software is hosted in one place (on the “server”) and use is permitted by the customer during the payment period and with certain restrictions. You will often read references made to a “software license” for a SaaS product — this is a misnomer. As SaaS contemplates the provision of a service, there is no software being licensed but only a service being rendered.

Next, we need to outline (to the extent we can) what SaaS is from a legal and sales tax perspective. Unfortunately, this is where things get murky. While a SaaS product is indeed a service, and not a piece of tangible software, many states tax authorities have not woken up to that fact — some treat SaaS products as software products like any other. In those states, generally speaking, a SaaS product is considered a tangible good and is therefore subject to state taxation the same way it would be if the software was delivered on a physical disk (Washington state is an example of this treatment).

For those states that do not treat SaaS as a tangible good, the question is whether a service is subject to state taxation. If services are taxable, software as a service is taxable; if services are not, generally software as a service is not.

It can be a difficult task to navigate state tax law. If you have specific questions, I’m here to help. Otherwise, make sure you seek the guidance of an attorney before choosing to not charge sales tax, and don’t leave it up to a Google search.

If you’re interested in matters at the intersection of tax, law, and technology consider signing up for our mailing list at TaxMailingList.com. No spam, we promise.

Drafting a service level agreement or reviewing an existing one?
Let me do it for you for a flat $200 fee - get in touch.

A service level agreement (“SLA”) is a contract between a service provider or vendor and a client or customer. It outlines what the customer can expect in terms of quality of service from the vendor, and outlines what remedies the customer will be entitled to if that service level is not maintained. SLAs are a crucial aspect of a Software as a Service (“SaaS”) contract as, as the name implies, in SaaS the software is the service. In a traditional software licensing scheme a customer would not need promises from the vendor that the software would be available and accessible — Microsoft sells you a copy of Windows 10, you install it, and it will always be available as long as your hardware is functioning (maybe using Windows as an example for uptime was a mistake). However, for software that requires a continuing provision of service from the original vendor, customers typically want a guarantee that the service will remain available as long as they continue to make payments to the vendor.

An SLA is not intended to be a whitepaper outlining how the service is provided, nor is it a user manual for the customer to reference if they have a question. It is merely a contractual representation of what the vendor promises to provide to the customer.

Typically an SLA will include:

• Introduction. A section outlining what the SLA is, who it is by and between (defining the vendor and, sometimes, the customer), where the terms of service might be accessed, etc.

• Scope. The scope section of the SLA will define the parties involved, the time period the SLA will run for, the services that are covered, the services that are not covered and any other exclusions. Typically this section will read as outlining what is covered and broadly disclaiming any ancillary services not outlined.

• Responsibilities. The vendor has responsibilities, the customer has responsibilities, both need to be outlined. Vendor responsibilities include the provision of the service that the SLA contemplates, responding to support requests, resolving issues, etc. The customer may be tasked with ensuring their hardware remains functional and up to date, and notifying the vendor of any issues.

• Uptime Guarantees. This is the crux of the SLA. The vendor will guarantee some level of uptime (99.99%, 99.999%, etc.) and outline how that will be measured. This section may also outline what remedies the customer has if these levels are not maintained.

• Response Times. Just as the SLA outlines uptime guarantees, it may outline response times for service requests. Customer service has always been an important aspect of software sales, but in a SaaS situation doubly so. You want Microsoft to respond to your support requests quickly when your printer isn’t working, imagine how important their response would be if the answer to the printer problem might be on their end.

• Resolution Times. A resolution time section is optional, but can help put customers mind’s at ease. To the extent that a vendor can, they may want to make guarantees or set goalposts for the total amount of time it might take to resolve a support issue. This is obviously not always possible, but where possible it is an extra level of guarantee.

• Signatures.

The exact combination or permutation of the above sections may differ between SLAs, but the overarching structure will remain the same. An SLA will outline how consistently the service will remain available, what will happen if it is not made available, how quickly support requests will be responded to, and what will happen if those requests are not responded to. They will all outline what the vendor can guarantee, what they can’t guarantee, and what they disclaim.

The level of detail and precision necessary in an SLA will vary based on the type of service being made available and how much of the service is in the vendor’s hands.

Service Level Agreement Template

Download my boilerplate SaaS Service Level Agreement Template

I have provided a SaaS Service Level Agreement Template as an example, and a a jumping off point. Please note, this is a boilerplate — that means it is not tailored at all to your specific needs. It should not be taken and used without thought, nor should sections be lifted from it and used unless you know their meaning and utility. I charge a nominal fee for the form.

Please get in touch if you want to discuss any of the ramifications for your business.

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.

As we have discussed previously, drafting software as a service ("SaaS") contracts brings with it numerous contractual complexities that in many ways mirror the complexity of the underlying technology. Providers give customers access to software and cloud services, allowing remote access and off-site data storage and shifting the risk of downtime and data corruption or loss to the provider. Of course, the amount of risk the provider wishes to assume in the arrangement is entirely up to the parties to the contract -- but both parties must take care to avoid assuming risk through ambiguous drafting and ensure what is in the contract truly reflects the bargain struck.

Just as lines of code cannot be cut and pasted reflexively from one project to another, so too is the case with contract language. Boilerplate should be used a heuristic - a quick way to see a list of provisions and clauses that you may want to consider negotiating for your current transaction. This post can be considered a boilerplate of the heuristic variety: some common SaaS provisions that you may want to consider. It is neither complete nor exhaustive and the entire list will likely be neither necessary nor sufficient for any individual transaction. They are provided merely as a list of provisions to get you thinking. 

Virtual Point of Demarcation

When goods are shipped internationally, parties to a sale agreement need to negotiate when title to the goods transfers from the seller to the purchaser. If Amazon sells you a box of crystal juggling pins and they are dropped on the warehouse floor, we have a pretty good understanding of who will bear the cost of replacement. Perhaps the answer remains clear if the pins are lost in transit. But what if Amazon sees them safely all the way to your doorstep where they are trampled and broken? Intuitively we have an understanding that the title and the risk of loss for those pins has now shifted to you - they were delivered safely to your door and were broken while in your possession. 

In the digital world, as is so often the case, the situation becomes murkier. Take for instance a voice over internet protocol ("VOIP") provider that sells a telephone service to a mid-sized business that has its own existing telephony infrastructure. If the VOIP service goes down on the provider's end, we understand that the outage is their responsibility. What if, however, an outage occurs and it becomes clear that it was owing to a misconfigured piece of equipment owned by the business? Without a virtual point of demarcation, the answer may need to be provided through litigation. 

Virtual points of demarcation make clear where a service provider's obligations end and the customer's begin. They are, conceptually, linked to the service level agreement -- they draw thick lines around the boundaries of the service level warranties. In essence, the service provider promises that X, Y and Z will not happen, but makes no additionally unenumerated assurances. 

Adjustments

Most businesses' needs are in flux. When a customer first signs a service agreement they can only do so based on their requirements (users, devices, licenses, etc.) at the time of signing. While it seems obvious, care should be taken to ensure that there is a transactionally cost effective way for a customer to expand or contract the number of users, devices or licenses that they are licensing. Placing undue transactional costs here, such as requiring them to renegotiate a new license, may cost the provider a customer when it comes time to expand - the cost effectiveness of staying with an existing provider is wiped out if new terms will need to be renegotiated as though they were a new customer. Make the path to expansion or contraction clear and as painless as possible. 

Ownership

A number of years ago, cloud photo hosting service Flickr, now owned by Yahoo, ran in to some issues regarding the ownership of user photos uploaded to their service. Their Terms of Service, ambiguously worded, gave some users pause and caused them to wonder if Flickr was attempting to retain copyright ownership of all photos hosted on their service. Flickr responded, clarified their Terms of Service, reassured their users, and the furor died down. However, it really is impossible to say how much the debacle effected their growth, customer satisfaction, and even valuation. 

Providers: don't be like Flickr, make it clear from the start. For many modern businesses, their most valuable asset is their data. While service uptime and data security and privacy provisions may go over the heads of everyone save for the nerds in the basement in IT, the concept of who "owns" the data that is stored with your service will be crystal clear to techies and Luddites alike. Make clear who owns the data, who can use the data, if the data can be used or sold in the aggregate by the provider. If you were leasing warehouse space and the leasing agreement left who would own the items kept in the warehouse ambiguous, wouldn't you want to make sure it was cleared up before pen met paper? 

Indemnification and Insurance

Consideration should always be given on either side of a SaaS contract as to whether one or both parties should be compelled to carry insurance. Most obviously, a provider should carry insurance to cover data and privacy breaches, data loss, and service downtime. Less obviously, however, is the insurance carriage requirements of the customer. If the customer will be indemnifying the provider for any liability, the provider will want to ensure the customer carries sufficient insurance to cover the cost of liability. 

Downtime Allotments for Updates and Maintenance

99.9%, 99.999%, the minimum acceptable level of uptime is getting more 9s after the period every year. Owing to virtual servers and data redundancy, the need for downtime for updates or maintenance is becoming less and less common. However, there remain some technologies that still may require data or services to be unavailable for a period of time - and there is always the dreaded DNS issue. If required downtime may be a factor that needs to be considered by a provider in a SaaS agreement, care should be taken to also consider whether that downtime needs to be provided for separate and apart from the service level provision. In other words, a provider may want to guarantee 99.999% uptime as pertains to nonscheduled maintenance outages, but provide for a certain amount of downtime for upgrades an maintenance. 

Closing Thoughts

A solid understanding of the underlying technology, if not a technical mastery, is really a prerequisite for properly negotiating a SaaS agreement. As is the case with any contract, the drafter needs to be able to imagine all the potential scenarios that might present in the course of performance and account for them. If you were drafting a service agreement for the provision of transportation services for nuclear waste, you would engage experts to help ensure you were considering all of the potential risks - you wouldn't rely on your own reckoning just because you have seen Atomic Train. The same should be true for SaaS contracts: engage technical personnel and be realistic about your own understanding of the technology. Posting a meme on Facebook may not be sufficient technical savvy to negotiate the terms alone!

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.