Mailing List

Popular Articles

Recent Articles

Follow Us

Archive for 'Software Agreement Drafting'

Service Level Agreements: What is a Service-Level Agreement or “SLA” and When Do You Need One?

Written by on Thursday, March 16th, 2017

If you are in the software industry, you may have heard of a “service level agreement” or “SLA,” but do you really understand what a “service level agreement” actually is or when you might need one?

A “service level agreement” or “SLA” is a technical agreement that defines that parties’ expectations of the level of service that will be provided in a particular service provider relationship and establishes how a customer will be compensated if the service at any given time does not meet the expectations as defined in the agreement.  It is usually drafted as a schedule to another agreement such as a master service agreement (“MSA”), software services agreement (“SaaS agreement”) or hosting services agreement rather than standing alone as the sole agreement defining a relationship between two parties.  As a tech transactions and software attorney, I would expect to see a service level agreement present in any agreement involving a software as a service (“SaaS”) or hosting relationship; however, a service level agreement could be appropriate in other tech-related service relationships as well, in which metrics or standards for the delivery of the service mattered to the customer and not just the accomplishment of a particular service milestone.  For example, a “service level agreement” might be appropriate in a business relationship with a provider of IT services, in a back-up or disaster recovery relationship, or in a data service relationship–these are all scenarios where a customer might have expectations beyond merely whether a particular task was performed or not that one or both parties might want to address in a separate service level agreement.

If you are questioning why it is customary to have a “service level agreement” and not just rely on a standard warranty or material breach clause, consider this:  if an interruption in service occurs with a particular relationship and then resumes for any reason, does either the consumer or the provider really want to treat that interruption as a material breach and terminate the relationship?  In many cases, the answer is “no.”  From the provider’s perspective, the interruption may very well have affected its entire customer base, so of course, the provider doesn’t want to go out of business over a single incident.  At the same time, it is frequently not in the consumer’s best interest to treat an interruption as a material breach either.  The consumer may believe the service provider is the best provider in its industry to deliver a particular service, either because of the pricepoint, the technology or service offered, or the reputation of the particular provider.  Also, the cost in terms of time and resources of finding an alternative provider might be higher than the consumer is willing to take on at that time.  There might be no other alternative to the particular provider, or the financial costs of changing providers could be too high.  Obviously, there may be legal consequences as well in terms of the cost and expense of enforcing a warranty clause and terminating a contract for material breach that could easily dissuade a particular consumer against exercising such rights.

Thus, for all of these reasons, a “service level agreement” or “SLA” is frequently relied upon by knowledgeable service providers and customers to define the parties’ expectations about the delivery of a particular technical service and to provide an alternative mechanism for compensating service failures outside of the standard warranty/breach framework.  Where no such agreement exists, the parties often have no real expectations defined for the service, which more often than not will eventually bring a premature end to the relationship.

What types of terms should you expect to find in a “service level agreement” or “SLA”?  As with most technical agreements, it is my view that the terms in a particular service level agreement need to be tailored to the particular relationship between two parties and not just copied from a third party’s agreement, so no single set of terms will be appropriate in all cases.  For example, if you are a SaaS company and you rely on a third party to host your software, then the service level agreement you adopt needs to contemplate the service level agreement terms of the third party hosting your software and not be written independently of the hosting relationship.  If you are procuring another technical service, you should make sure that the service level agreement reflects the expectations of your business or your customer base.  If you don’t have expectations for what you are buying, then you need to do your homework and talk to an attorney, competing service providers, other businesses, etc. to understand the problems you might run into with the particular service and understand what expectations are reasonable for the particular service being procured.  The worst drafting mistake you can make in adopting a particular set of terms for a service level agreement is to simply use a third party’s terms rather than customize the terms to the particular relationship, since the third party’s terms will likely have no relevance to your relationship.  Having said this, there are some terms that are commonly found in service level agreements.  These include such concepts as as “service availability,” “exclusions,” “scheduled downtime,” “uptime,” “service level guarantee,” “service credit,” “business hours,” “priority response times,”  and “service level reporting.”

The bottom line is that if you are on either side of a technical service relationship, it is important to consider whether a service level agreement might be advisable to define the parties’ expectations for the relationship beyond just whether or not a particular service is performed.  There are no single set of terms that should be adopted in all scenarios, but you need to be knowledgeable enough about what you are buying or selling to develop clear expectations in advance of the commencement of the relationship.  As a SaaS company, you are both a buyer and seller of services, and therefore it would be prudent to define expectations for the service not only with your customers but also with your service providers, so that you obtain the services required to meet your customer’s expectations as well.

Share On Facebook
Share On Twitter
Share On Google Plus
Share On Linkedin

Category: Software Agreement Drafting  |  Comments Off on Service Level Agreements: What is a Service-Level Agreement or “SLA” and When Do You Need One?

Recent Software Class Actions Provide Valuable Lesson on Why SaaS Contracts Should Be Drafted to Fit Company’s Business Model

Written by on Friday, March 10th, 2017

When SaaS companies and start-ups first contact me, they are often doing so with the idea that there are a few really well SaaS template contracts circulating in the SaaS industry and they seeking the” right” attorney to provide that industry-standard template to them.  Alternatively, they contact me telling me that they’ve already put together a draft SaaS contract, and that they just want me to look over and “bless” what they’ve already written based on a particular SaaS company’s contract available for download on the Internet.

In these cases, which are the norm rather than the exception, I often encounter significant push-back when I first suggest to them that they are approaching the SaaS contract drafting process entirely the wrong way.  I always explain that a well-drafted SaaS contract should be tailored to their specific business model, and then I proceed to ask them a number of questions about their business model, which they generally aren’t prepared to answer.  They often then proceed to get frustrated by all the questions about their business, when all they are actually looking for is the “right” contract template.

If you are in the SaaS industry and have created your customer contract in a similar fashion, or committed the other common software contracting “sin” of caving into pressure exerted by a potential customer and just agreed to their standard agreement terms because you wanted to close a deal with them, then you may want to consider the example of recent litigation against an industry leader, which adopted contract language which was then alleged not to match the company’s business practices.

The litigation at issue involves class action suits against the McAfee brand security software: Williamson v. McAfee, Inc.,  No. 5:14cv00158 (N.D. Cal. Aug. 30, 2016) and Kirby v. McAfee, Inc., No. 5:14cv02475 (N.D. Cal. May 29, 2014).  Both cases focus on the company’s business practices surrounding its use of automatic renewal clauses–a standard practice widely adopted throughout the SaaS industry.  The litigation is ongoing: while the court granted final approval of a settlement in both cases, an appeal has been filed.  (See posted notice).

The particular contract clause at issue in the Williamson case is a common clause routinely included in SaaS contracts that stated at autorenewal customers would be charged the “then-current” price for the product.  However, the Williamson complaint alleged that the actual practice of the company was to charge customers upon autorenewal a higher price for the product than the price that the customer could have purchased the product for elsewhere.

The particular contract clauses at issue in the Kirby case stated that customer would be automatically enrolled in the autorenewal program and that a customer’s credit or debit card could be charged at autorenewal even after it had expired.  The Kirby complaint alleged that the actual practice of the company was to import into its billing system updated customer credit or debit card information provided by Visa or MasterCard rather than procuring a new authorization from client when the prior authorization became invalid, and to charge the customer at autorenewal at a higher price than originally paid without the customer’s express consent.

While there are a number of allegations made against McAfee in these class action suits, a fundamental problem alleged was that the terms of service binding the customer did not match the company’s actual business practices, and that the customer did not provide consent to the company’s actual autorenewal practices.

While these particular suits were filed against McAfee, the business practices alleged in these cases are perhaps the current standard of conduct for today’s software industry.  Furthermore, I would argue that more often than not terms of service are adopted by companies without any consideration whatsoever of the actual technology and business model for the software or SaaS product, so it is probably rare for the terms of service to match the company’s actual business practices.  Thus, it is my assertion that these cases provide an excellent primer of the risks of adopting terms of service that do not match the actual practices of the business.  It’s still not clear what the ultimate price tag on this matter will reach on the part of the company, but it’s clear it will be multiple millions of dollars in costs and expenses.

Moreover, these cases demonstrate the importance of consent to having an effective autorenewal clause.  State laws applicable to these cases did require the procurement of clear and conspicuous consent to autorenewal, which McAfee is alleged not to have had in these particular sets of facts.  Obviously, any deficiency with consent could have easily been addressed through the adoption of better business practices and terms that would demonstrate clear customer consent in compliance with applicable state laws.

The bottom line is that terms of service should not be adopted by a SaaS company without a thorough consideration of the technology, the business model, and the business practices of the company.  Even common business concepts like autorenewal accepted across the board within the industry may lead to costly lawsuits if insufficient consideration of business practices is contemplated in conjunction with the drafting of terms of service.

 

Share On Facebook
Share On Twitter
Share On Google Plus
Share On Linkedin

Category: Litigation, Software Agreement Drafting, Software Litigation  |  Comments Off on Recent Software Class Actions Provide Valuable Lesson on Why SaaS Contracts Should Be Drafted to Fit Company’s Business Model

Insurance Industry Guidance to Consider When Negotiating a SaaS Indemnification Clause

Written by on Tuesday, March 17th, 2015

As a software attorney advising SaaS companies in contract negotiations, I am frequently asked for advice on negotiating indemnification clauses. While clients all have different risk tolerances when it comes to the issue of indemnification, it is always challenging to advise parties on either side of the negotiating table, as it is difficult to provide clients with any concrete guidance of what their actual risk may be.

The San Francisco Business Times recently published an article shedding some light on what the actual risk may be to parties on both sides of a data breach, which as any attorney in the software industry knows, is often the concern that prompts the most contentious indemnification negotiations in any SaaS contract discussion.

According to the San Francisco Business Times, the insurance brokerage Aon estimates that 80% of commercial privacy breaches around the world result in $1 million or less in direct costs and damages.  On the other hand, the San Francisco Business Times reported that Aon estimates that  approximately 15% of privacy breaches cost approximately between $1 million and $20 million, with the average cost of those larger breaches running about $7 million.

So what are the significance of these liability estimates to parties negotiating an indemnification clause in a SaaS contract negotiation?

The significance is that a particular group of industry experts are estimating the liability risk for parties on either side of the transaction to generally be at $1 million or less per transaction, with only a small portion of the cases rising significantly above this, and that where the breaches result in greater than $1 million in damages, the loss averages about $7 million.  Thus, for indemnification negotiation purposes, this information suggests that most customers of SaaS services are not going to incur more than $1 million of damages in a privacy breach, and that on the flip side, most SaaS providers will not suffer more than $1 million of damages on a privacy breach affecting a particular customer.

Of course, insurance companies such as Aon do offer cyberinsurance which will provide some insurance against such risk, which is why Aon is in the business of making predictions about the cyber-liability risk to businesses: to sell cyberinsurance and evaluate its own risks as an insurer.

For my purposes, however, as a software transactions attorney, these numbers provide some helpful guidance as to how parties on either side of a deal should be evaluating their real risks for the purpose of indemnification clause negotiations.  While as a customer, an unlimited liability indemnification for a privacy breach might be nice, these numbers suggest that something far less would likely be sufficient to protect your company.  On the flip side, as a SaaS provider, these numbers suggest that your actual risk in the case of an unlimited liability indemnification on a particular customer contract will probably not exceed $1 million, which is far less than the numbers might be envisioned by the phrase “unlimited liability.”   All in all, this data is useful to consider in the context of any SaaS contract negotiation, regardless of whether you are negotiating on the side of customer or the service provider.

Share On Facebook
Share On Twitter
Share On Google Plus
Share On Linkedin

Category: Software Agreement Drafting  |  Comments Off on Insurance Industry Guidance to Consider When Negotiating a SaaS Indemnification Clause

Careful Drafting of Pricing Terms is Key to all Software Licenses and SaaS Agreement

Written by on Tuesday, February 3rd, 2015

As a software company, do you make a special point of sending all your price schedules, payment terms, and price-related clauses to software counsel for review before you send them out the door to your potential customer?

If your company is like most, my expectation would be that you are probably handling all such issues internally  since those are not purely legal terms and you are probably trying to save money on legal fees.

However, when a dispute arises over software licenses or SaaS agreements, what is usually at the heart of the dispute?  If you guessed that it is those pricing terms that your company is handling internally to save money on legal fees, then you would be correct.  It is precisely those clauses that will typically be the basis for the customer dispute.

Why is this?  Well, one problem that often arises is that the pricing terms were not considered as part of the overall drafting of the contract.  For example, if you are selling a multi-user license or SaaS Agreement, you have to draft the whole agreement to work with the multi-user model.   If you just take a single-user software license and add a price schedule for 90 users as an attachment, then your contract is not going to work.  It is still going to be a contract for a single user that is charging for 90 users.  Also, if you a charging for a particular add-on service at a flat fee rate, and your contract is not set up to describe the terms and conditions being provided for the services charged, then there is a high likelihood that there is going to be an issue over the fee you are charging at some point in the future.  The attorney needs to understand each and every fee you intend to charge a customer and how the fees will be charged in order to properly draft the contract.  If the attorney is kept in the dark on these issues, there is likely going to be a problem with how the contract is structured and drafted.

Another problem that arises on a recurring basis is over implementation and costs that the software user may have to pay while implementation continues.  When you haven’t considered the timing and amount of payments that may be due while implementation is ongoing, you are setting the scene for a potential dispute to arise. Again, if  software counsel were to review your contract before it goes out the door, this issue would most likely be flagged and addressed before it ever arises and the attorney might raise with you suggestions on how to structure the fees differently to ensure that the issue never arises.

A third problem that comes up frequently is the adding on of terms onto a price schedule that conflict with terms that the attorney carefully drafted in the agreement.  You should not make a practice of adding extra terms into a price schedule, and in particular, you definitely want to refrain from adding conflicting terms into a schedule.  If software counsel had had the opportunity to review the draft contract before it went out the door to the customer, the attorney would have reviewed the contract specifically looking for conflicting terms and this issue would be caught and fixed.

Finally, a fourth problem that often arises is charging fees that just don’t make sense in the context of a particular agreement.  For example, if you are negotiating a SaaS agreement with a customer and charging an annual maintenance fee, when maintenance fees are generally included as part of the recurring subscription fee of the SaaS agreement, or alternatively, charging on a monthly basis for a license that would generally be licensed on a one-time basis, then you are likely to run into an issue with the pricing either in negotiation or as soon as the customer becomes disgruntled.  Software counsel reviewing the contract would be alert to any such issues and would flag the problem before the contract is sent out the door.

The above examples are just a few of the scenarios that can arise over how pricing terms are structured if they are not run by software counsel before they are sent out to a prospective customer for review.

The bottom line is that those pricing terms you may not want to talk to your outside software counsel about are precisely the terms that you should be consulting him or her about, as those are the terms that are most likely to result in a contentious legal dispute.   Fees in software contracts need to be carefully structured in conjunction with the rest of the contract, and where that is not happening, mistakes are most likely being made, any one of which could blow up into dispute with a customer.

 

Share On Facebook
Share On Twitter
Share On Google Plus
Share On Linkedin

Category: Software Agreement Drafting  |  Comments Off on Careful Drafting of Pricing Terms is Key to all Software Licenses and SaaS Agreement

Software Licensing vs. Software-as-a-Service (“Saas”) : The Importance of the Technology Model to Contract Drafting

Written by on Friday, January 30th, 2015

When I am first retained by a software company, I inevitably have a conversation with my contact at the company about their technology model.  Nine times out of ten the client either will be unable to answer the question or will say that they are working under one technology model and send you contracts that reflect the exact opposite.

Why do I ask the question?  Drafting an appropriate software contract (or even reviewing and providing feedback on a particular software contract is going to be dependent on whether or not the terms reflect the model.  If either the client or the drafter are unclear on the model, then the contract is not going to be a high quality contract.

In software contracts, perhaps the single most common issue that gets confused is the difference between a software license and a software-as-a-service agreement.  But the concepts are very different.  In a software licensing model, the software company offers a physical piece of software via cd-rom or electronic download from a website to be downloaded, installed, run, and operated on a piece of hardware that is typically physically on site at a particular company or residential location.   There may be one user or multiple users of the software.  The software may be installed on a single piece of hardware or multiple pieces of hardware.   There may be services associated with the software that are offered to the licensee such as implementation, customization, training, maintenance, and technical support.  In some cases, the company may even offer separate hosting services.  However, the software itself is made available to the licensee as a tangible product.

What is different about the software-as-a-service model?  In the SaaS model, the software company generally makes no tangible software product available to its users, and the product itself is only available “on the cloud” as a hosted platform.  As in the licensing model, there may be one user or multiple users of the platform.  But the platform itself is only accessible through the cloud.  Thus, the quality of the various services provided is critical because the ability to access and use the hosted platform is entirely dependent on the quality of the experience delivered.  In the SaaS model, there is no separate maintenance service provided because that is all expected to be included as part of the hosted platform service package, along with the hosting and technical support.  You may still have separate implementation, customization, and training services, however, that are made available separately from the hosted platform.   The key feature of this model, though, is the very fact that you are offering a “service” model rather than a “tangible product” model.

What is the primary issue I see contractually?  More often than not, companies say they are offering a “SaaS” model but their contract is in fact based on the software licensing model.  What alerts me to this fact?  Usually it’s the presence of a license grant to the software and the lack of any clauses explaining all the various services provided pursuant to the platform.  It’s also not uncommon to see a maintenance agreement attached to the agreement, which is not what I typically expect to see in the hosted platform model.  Also, there is often a lack of attention to any of the issues or concerns that you would have in a model where you never receive a physical product, and where you have absolutely no control over data security, your ability to save or download the data on the platform, or how well you can access the platform in the first place.  Another problem that you may see is a lack of concern over how you are charged for accessing the model when some sort of set up process is involved.  Obviously, if you are being charged on a monthly basis for accessing a platform and a set of related services, you don’t want to be charged until set-up is complete and you can access the platform and immediately use it.  This is less of an issue in a licensing model  where the fee is usually billed once and not charged again during the life of the product.

The bottom line is that these two models are very distinct business and technology models and the contract will absolutely not be correctly set up if the appropriate technology model is not determined and/or understood in advance of drafting.  The same is true in contract reviews: it is impossible to provide accurate feedback in reviewing a contract if the technology model is not thoroughly understood before the review is started.  Everything starts with the technology model.

So, if you retain an attorney like me to work with your software company on contracts and you are asked about your technology model, be prepared to answer the question.  Thoroughly sorting out the terms as they relate to the model is critical to the proper drafting or proper revision of your contracts, and spending billable time on this issue is time very well spent, as the job cannot be done properly otherwise.

Share On Facebook
Share On Twitter
Share On Google Plus
Share On Linkedin

Category: Software Agreement Drafting  |  Comments Off on Software Licensing vs. Software-as-a-Service (“Saas”) : The Importance of the Technology Model to Contract Drafting

Drafting SaaS and Software Licenses Effectively Requires High Level Knowledge about the Technology

Written by on Tuesday, January 27th, 2015

There seems to be a common universal belief among many companies that there is a single form agreement circulating among software lawyers with the perfect terms that can just be cut and pasted into their agreements if they can just find the right attorney who can furnish that ‘perfect’ form agreement.  I have lost count of the number of times I have been told by clients that they don’t need anything from me other to provide said ‘perfect’ template.  A few have even equated my or another attorney’s ability to provide them with the ‘perfect’ form template to the level of expertise of the attorney.

The reality, of course, is that merely cutting and pasting from a form agreement–even a very well-written form agreement–is precisely the wrong way to draft this type of agreement.   In fact, I would take this one step further and take the position that it is precisely the wrong way to draft all technology agreements.   Furthermore, it is my opinion that an attorney’s willingness to provide any document purported to be a ‘perfect’ software template is likely to be inversely correlated to his or her level of drafting experience in the space.  I certainly was far more comfortable with the idea of furnishing a template in response to a client request of that nature as a very junior and inexperienced  attorney than I am today, when I know better.   I’ve seen all too well how companies may take the ‘perfect’ template provided and rely on it for years and years without understanding that the form required many long hours of attorney customizations and revisions before it was ever put into use for their business.

While there absolutely are standard terms that you will find in all software agreements–whether SaaS or software licenses–which may form the basis of high quality software template for either the software license or SaaS model, a well-drafted contract is more than just an assortment of the “right” terms, it reflects the actual product offering to customers.  Thus, the drafter needs to not only know and understand how to draft these contracts but also have a very high level understanding of what the product offering to customers is.  Otherwise, the contract will be of a very poor quality, regardless of how good the lawyer was that put the original form agreement together that the contract may be based upon.

For example, in the enterprise license model, a company may purchase a license allowing a set number of user rights.  In such a model, a well-drafted license would at least explain what constitutes a user, how users can be added and deleted, what rights the users have to the various license grants made (which should go beyond the simple ‘use of the software’), the cost of purchasing new users, and the cost of purchasing the initial set of users.  But the decisions on how to structure each of these terms would be entirely dependent on the business model and product offering made available by the specific software company.  Thus, if the terms selected  are being cut and pasted from an unrelated form agreement, it is almost certain that the terms chosen will be wrong and make no sense.

The same problem occurs with the cutting and pasting of SaaS agreements.  In the enterprise model, again, you may similarly have users with different access rights, which are the SaaS equivalent to a license.  Your enterprise customer may want to start with 100 users and anticipate needing to add 100 more in a period of months.  Your enterprise customer may also anticipate losing some users and want to get some sort of credit for the users lost.  You may have different pricing based on when the timing of the purchase of new users.  Given all these different drafting and business model choices that can be made, if the terms selected are simply being cut and pasted from an unrelated form agreement, again, it is almost certain that the resulting agreement simply will make no sense.

The structural choices in how you draft these kinds of agreements do not end with the user rights.  For example, there are choices that the drafter has to make based on what type of data is being collected by the product, where the data is being stored, the level of risk to the company if the data is accessed by a third party, and what needs to happen to the data at the end of the relationship.  Also, there are choices that need to be made based on whether use of the product depends on importing pre-existing data into the software and effectively reading such data.  It is not uncommon for enterprise customers to have much higher requirements with respect to data than a small business client would generally have.  Fees, technical support, and training are other common areas of significant variation from product to product.

The bottom line is that a well-crafted software license or SaaS agreement will be structured around the technology, features, functionality, and business model of the applicable product and will not be based merely on a set of “perfect” terms from any template.  As a software company, that means that if you retain an attorney to advise you on your contracts, your attorney should absolutely be pushing you to provide significant details about how the technology, features, functionality, and business model of your product work, among other issues.  If you are not getting those kinds of questions from your lawyer, then it is highly likely that the terms of any contracts that your attorney reviews or drafts for you will reflect a similarly low level of understanding about those same concepts.

Share On Facebook
Share On Twitter
Share On Google Plus
Share On Linkedin

Category: Development Tips, Software Agreement Drafting, Software Start-up Tips  |  Comments Off on Drafting SaaS and Software Licenses Effectively Requires High Level Knowledge about the Technology

Copyright 2008-2017 The Prinz Law Office.

The Prinz Law Office | Silicon Valley, CA | Los Angeles, CA | Orange County, CA | San Diego, CA | Atlanta, GA | Tel: 1.800.884.2124

Mailing Address: 117 Bernal Rd., Suite 70-110, San Jose, CA 95119. Silicon Valley Office: 2033 Gateway Place, 5th Floor, San Jose, CA 95110 (408) 884-2854. Los Angeles Office: 3110 Main St., Building C, Santa Monica, CA 90405. (310) 907-9218. Orange County Office: 100 Spectrum Center Drive, 9th Floor, Irvine, CA 92618. (949)236-6777. San Diego Office: 4455 Murphy Canyon Road, Suite 100, San Diego, CA 92123. (619)354-2727. Atlanta Office: 1000 Parkwood Circle, Suite 900 Atlanta, Georgia 30339. (404)479-2470

Serving Silicon Valley, San Jose, San Francisco, Santa Cruz, Los Angeles, Irvine, Anaheim, Orange County, Santa Monica, Silicon Beach, Santa Barbara, San Diego, Sacramento, Atlanta. Licensed in California & Georgia.