Mailing List

Popular Articles

Recent Articles

Follow Us

Archive for 'Software Agreement Drafting'

Negotiating the Purchase of SaaS Company Assets: Key Problems to Anticipate in any Deal

Written by on Wednesday, May 10th, 2017

In light of the popularity of the SaaS model of doing business, it is not uncommon to come across deals in which one software company is buying a third party company’s SaaS assets.  While there are many reasons to be wary of these types of deals, regardless of what side of the transaction you are on,  it has been my experience that the parties tend to be in a hurry to close the deal and rarely take the time necessary to contemplate the issues that should be considered in connection with the acquisition.

So, what are some of the issues that an acquiring software company should be concerned about in a SaaS company asset acquisition?

First and foremost, if the acquiring software company seeks to acquire the code comprising the SaaS product, then the company needs to verify that the target SaaS company actually owns the code comprising the software product.  It has been my experience that entrepreneurs and companies of all sizes frequently overlook this issue and make significant investments in software development without first obtaining the appropriate rights in the products to be developed.  I receive at least a few calls each month from C-level executives whose companies have developed a software product using outside developers without the appropriate contracts in place and call me after a dispute arises over ownership of the code in the product.  If a problem is identified with the code to be acquired, it should be addressed before the acquisition talks are ever commenced, since once a negotiation begins, it will be much more difficult to procure the necessary rights in the code.

Second of all, if the acquiring software company seeks to acquire the SaaS company’s customers as part of the deal, then the acquiring company needs to verify that the customers are actually bound by subscription agreements that are automatically assignable in the event of an acquisition.  Where the customers to be assigned are enterprise-level relationships, the acquiring software company also needs to verify the quality of the contracts in place.  In general, SaaS company customer contracts are very poorly drafted and do not include the key terms of the business relationship, which will be of particular concern in cases where the transfer of a particular customer relationship or group of relationships is essential to the deal.  Again, if the customer contracts are deemed to be insufficient, then this is a problem that should be resolved in advance of the commencement of acquisition talks.

Third, if the acquiring software company seeks to acquire the hosted software platform as part of the deal and not just the code comprising the software, then the acquiring company needs to verify the terms of the relationship in place with the target company’s host, assuming the target company is relying on a third party host as is typical in the industry.  What kind of contract is in place with the host and is it automatically assignable to an acquiring company?  Are the terms of the service level agreement governing the relationship sufficient to operate the software platform without service failures and without breaches of the customer contracts in effect?  If the host is handling personal health information for the SaaS company, is there an appropriate business associate agreement in place that complies with HIPAA?  It has been my experience that most SaaS companies do rely on a third party host for the software platform, and that a significant portion of those companies do not have an appropriate contract in place with the host to provide the expected hosting services that could be assigned to the acquiring company as part of a deal.  If a the contract with the host is identified as inadequate, then this is a problem that should again be resolved in advance of the commencement of any acquisition talks with the target.

Fourth, since SaaS products are by their very nature “service” offerings rather than simply code, an acquiring software company may very well seek to acquire the SaaS company workers necessary to provide the services.  In any such case, the acquiring company needs to verify that these worker relationships are in fact employment relationships that can be transferred to a successor company as opposed to contractor relationships that may not be transferable to the acquiring company and/or that may pose worker misclassification problems for the acquiring company.  Where a problem exists, the acquiring company may want the SaaS company to address the issues in advance of the commencement of negotiations.  In general, it has been my experience that SaaS companies are relying largely on independent contractors to provide services for their SaaS platforms, so encountering issues with any acquisition of a SaaS company workforce is to be expected.

The bottom line is that many of the SaaS company assets that an acquiring software company will seek to acquire as part of a SaaS company asset purchase will be accompanied by a certain amount of problems–problems that the acquiring software company may prefer to resolve in advance of any deal discussions rather than as part of the usual, time-sensitive, deal discussions.  Anticipating the problems that are likely to be present with a target company’s assets before commencing negotiations can help to ensure a smoother negotiation as well as a smoother transition once the deal is closed.

Category: Software Agreement Drafting  |  Comments Off on Negotiating the Purchase of SaaS Company Assets: Key Problems to Anticipate in any Deal

Common Software Agreement Fee Drafting Problems and How to Fix Them

Written by on Wednesday, May 3rd, 2017

When a client sends me a software license agreement or SaaS agreement to review or update, I always make a priority of reviewing any terms in the contract involving fees and then carefully reviewing the website and any marketing materials or fee schedules to confirm that the fee terms in the contract clearly match the fees listed outside the contract.  Then, I will also confirm that the contract terms clearly articulate how the fees listed on the website and in other marketing materials or a fee schedule are to be calculated.  I have generally found it to be rare for the contract terms and website, marketing materials, or fee schedule to match.  More often than not, it is clear upon review of all of the supplemental materials that the fee terms of the contract are poorly drafted and make no sense.

So, what are some of the usual discrepancies that I will find?

One common issue I often see is that the marketing materials or the fee schedule suggest that the license or subscription fees are being calculated according to the number of authorized users, but there are no terms in the contract to explain what constitutes an authorized user, what rights the authorized users obtain through the license or subscription, whether authorized users are made available in blocks of users or individually and for what fees, or how you would add or drop authorized users.  Whether your software contract is a license or a SaaS subscription, just listing the total fees and total users and not drafting contract terms describing the relationship between the licensee and users or subscriber and users and how that relationship works is completely inadequate.  Those terms need to be clearly defined in the contract and not just in marketing materials.

A second issue that I frequently come across upon review is that the marketing materials or fee schedule suggest that there are multiple types of software licenses or SaaS subscriptions being offered to the customer, each of which provides different levels of functionality or services for a different fee, but the terms of the contract only reflect a single level of functionality or services and provide no clarification as to what functionality or services are comprised by that single offering.  Whether the software contract is a software license or a SaaS subscription, the contract always needs to define the scope of the license or subscription being offered for a particular fee, and if multiple options are being made available for different fees, the contract needs to carefully describe the base option extended and the add-on option extended and how the various options and the applicable fees work.

A third issue I frequently come across upon review is that a fixed fee amount for “professional services” is listed in the fee schedule or marketing materials.   However, often the terms of the contract are completely silent on what professional services are being provided under the software license or SaaS subscription, what the hourly or project rate is for the services and how many hours are being provided, or any other clarification about what constitutes the “professional services” to be provided under the agreement. Moreover, it’s generally unclear as to how fees would be billed for additional professional services.

In general, the problem with many software contracts is that companies are relying on marketing materials and fee schedules to justify fees that are never explained in the contract terms.  However, the contract terms are what is binding on the customer–not the marketing materials, vague fee schedule, or other supplemental documents.  So, clearly, software companies need to exercise the same sort of drafting caution that I exercise in my reviews, and go through each and every marketing material and fee schedule to confirm that any fee described is carefully explained in the terms of the contract.  Where disparities exist, software companies need to identify those disparities and revise their contract terms to address the issues.  When they fail to exercise such care in their drafting, they significantly increase the risk of future customer disputes.

Category: Software Agreement Drafting  |  Comments Off on Common Software Agreement Fee Drafting Problems and How to Fix Them

Does Your Customer Software License or SaaS Agreement Leave Your Software Company Vulnerable to a Legal Dispute Over Implementation?

Written by on Monday, May 1st, 2017

If your software company is like most software companies these days, you likely set up a software interface and train your customers on how to use the product at the very beginning of the relationship.  You probably even charge some sort of fee for these initial services that you provide.  And the set-up process may run anywhere from days to weeks to complete.

Moreover, if you are like most companies, you are probably relying on a software license or SaaS Agreement which is either completely silent or almost completely silent on the specifics on how this “implementation” phase of the relationship will work, except for all of the fees you will be charging for the services. And you probably are charging your customer other fees on top of the implementation fees while the implementation process is ongoing.

If this sounds familiar, you are likely committing one of the most common contracting mistakes I see: leaving your company extremely vulnerable to a dispute over the implementation phase of your company’s software services.

Now, I know it is easy to say “I’ve always done things this way and I’ve never had a dispute.”  I hear this from clients frequently as well as the argument “This is the real world.  We don’t have the time to spend on such issues.  You are just overlawyering.”  However, from my side of the desk, whenever there is a customer dispute involving a software license or SaaS Agreement, it virtually always involves a dispute over an implementation process and the financial obligations tied to that implementation process.

Why is this?  Well, software companies are largely using software licenses or SaaS agreements copied from other companies to contract with their clients.  When they actually hire an attorney to draft a correctly drafted license or “SaaS agreement,” they retain the services of an attorney who lacks industry-specific knowledge about drafting these contracts and who fails to ask the right questions about the software company’s business model or set-up practices.  And, in the rare cases where the software company actually does retain a knowledgeable attorney, the company may discount the importance of addressing the implementation process in the contract and not provide to the attorney the necessary information regarding the implementation process in order to enable the attorney to draft the appropriate terms required in the contract.

If you wonder what the “real-world” consequences are of this approach, they are as follows:  if something changes at your customer’s company while implementation is continuing, your customer will likely call up an attorney like me to find a way to terminate your contract for material breach, and the attorney will point to the fact that the customer cannot use the software as intended to argue that a material breach has occurred.  And then the customer or its attorney will demand a refund of all previously paid fees in conjunction with the breach.  Alternatively, if the customer is a bit more aggressive, the customer may just terminate the contract for material breach and hire a litigator to pursue a breach of contract case against your company.

What can your software company do to avoid falling into the “implementation” trap with your software license or SaaS contract?

First of all, if you sell a software product that your customer cannot immediately utilize upon the execution of the software contract, you need to make certain there are well-drafted, company-specific terms regarding your implementation process in your contract.   Those company-specific terms should address such issues as the specific milestones for your implementation process, what will constitute the successful performance of each milestone by the software company, what date each milestone will be completed, and what steps are required from the customer during the process and whether failure to perform any step constitutes a material breach or changes the software company’s implementation obligations in any way.

Second of all, if your software company will charge the customer fees for the implementation process or during the implementation process, your contract needs to contemplate how the fees are deemed “earned” in relation to the implementation services performed.  It is not uncommon today to see contracts where hundreds of thousands of dollars are being exchanged during the implementation period, but if the contract does not actually articulate how those fees are earned by the software company, it could be argued that the fees were not actually incurred until the implementation process is complete and the customer provides final approval to the successful implementation.  Also, if the contract is drafted in such a way that fees are being charged for services and functionality that are unavailable until a future date, this could be used against your company in a dispute to allege the occurrence of a material breach.

Third, if the customer is promised “training” as part of the implementation process, the specific terms of the exact training extended to the customer should be carefully defined.  Does the “training” constitute pre-recorded webinars made available over the Internet, or does it constitute live, on-site, seminars taught by instructors on a particular date?  Who can attend the “training”? When can they attend? How long will the training sessions last? What will be taught in the training sessions?  Who absorbs the fees to provide the training sessions?  What happens if the training sessions do not happen as scheduled?  It is not uncommon for disgruntled customers to argue that they did not receive the training promised to them and that they were therefore unable to use the software as promised, and argue that this failure constituted a material breach.

The bottom line is that if your software license or SaaS agreement fails to provide detailed, company-specific terms on implementation and your software company does in fact have an implementation process that is necessary before a customer will “go live” with your software product, then you are leaving your software company very vulnerable to potential customer disputes.  Taking the time to draft the appropriate customer contract terms before you retain a new software customer can significantly reduce your software company’s risk of a very costly customer dispute down the road.


Category: Software Agreement Drafting  |  Comments Off on Does Your Customer Software License or SaaS Agreement Leave Your Software Company Vulnerable to a Legal Dispute Over Implementation?

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.

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.


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.

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.


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.

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.

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 | Los Angeles | Orange County | San Diego | Atlanta | Tel: 1.800.884.2124

Silicon Valley Office: 2033 Gateway Place, Suite 500, 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, Los Angeles, Santa Monica, Silicon Beach, Irvine, Anaheim, Orange County, San Diego, Atlanta. Licensed in California & Georgia.