2014

I have found that FAQs are not used enough by SaaS companies as part of their selling and SaaS contract negotiation process. Here is the frame of reference, at least from my perspective: you are selling something that is intangible (aka cannot touch or feel) and your customer does not exactly know what they are getting. They may know how much it costs, but how it works and what exactly they get are somewhat elusive. This is never good when trying to get a SaaS contract deal closed. So here is what you can and–more importantly–should do.

1. Create

   Create a really great FAQ for your customer (including their purchasing, finance and legal departments) so they can better understand, for example, your ordering, renewal, onboarding, payment process, etc. The FAQ should be short and list the most important issues first. Remember, contracts are poor communication vehicles, but FAQs are great at it.

2. Communicate

   Have your sales team use the FAQ when they are selling and when they are working with the finance, purchase or legal departments of your customer to get the SaaS contract closed. These people want–and more importantly need– to understand these things, and it is your job to educate and explain it to them. Did you get that? This is part of your job.

3.  Examples

Who is doing this well?

•  Kareo’s FAQ is really great. It is simple, short and to the point. Plus the questions are listed in categories, and the answers are hidden (initially),

…

These Words are ‘Dangerous’ in Any SaaS or Software Agreement.

 

 

I have seen wording like this in SaaS or software agreement orders or templates, and it has always bothered me. A case from 2014 addressed this issue head on, so I thought I would share the outcome of the case with you (and some suggestions to avoid this messy legal issue).

Summary of the Facts: The following language was included in a software agreement.

 “To be valid, this agreement must be signed within 30 days of. . . “

Every SaaS or software company has probably seen (or used) language like this when trying to get a deal closed. Usually companies use this kind of language when trying to tell a customer that the offer will expire if the deal is not done by x date (a good sales practice). Well that may be the business objective, but courts look at this issue differently.

What courts often do (and this court actually did), is say that this language is a ‘condition precedent’ to the execution of the contract. What this means is that if the condition is not met, then there is no contact (even if both parties sign the contract after the 30 day period). This is where people get confused. They think that as the contract was signed by the parties, this means the 30 day language does not apply and is irrelevant. Well, as this court said, it that language does apply and therefore …

On May 9, 2014, the appellate court handed down its 69-page decision in the Oracle vs Google API copyright case. The court ruled in favor of Oracle, but did push down to the lower court some remaining issues (which I will not bore you with right now…even though it is super interesting to software attorneys). I know you don’t want to read all of the case, so as a software licensing attorney I thought I should share a few takeaways for software and SaaS based companies. So here goes.

 Thin Slicing.

One overall theme I clearly got from reading the case, is that courts do not think all software is equal or the same. Said another way, courts will look very closely at the actual code (how it was created, how it works, what functions it performs, etc) and the same for the alleged infringing code.  The courts are going to slice things very thin, and it’s hard to come up with many general rules, as it really does depend on the technical details. Translated into plain English, these cases are very fact specific and can become super expensive to litigate.

Functions (and Short Phrases) May be Copyrighted.

The court made it pretty clear that because something performs a function (or is a short phrase), it does not necessarily mean that it is uncopyrightable.  Also, even if an element is functional (like ‘File,’ ‘Print,’ ‘Quit’), the code that implements the function may be copyrightable as it will …

What to Know About the ‘Combination Exception’ to Infringement Indemnities.

As a software licensing attorney I run into the issue of infringement indemnities all the time. These risk shifting contractual clauses can be very confusing for clients, so I thought I would explain (with a real live case and a graphic) what is called the ‘combination claim exception.’

Contractual indemnities are in essence insurance policies, and the customer is asking for insurance if your software infringes (violates someone else’s IP rights). They expect that you will  defend them (sometimes they even want to hire their own attorneys and send you the bill)  in an infringement suit and pay any resulting judgment.  This is a very common request from large customers.

However, there are typical exceptions to a software company’s indemnity obligation (i.e. risks that software companies should not be on the hook for). One of the most important exceptions is known as the ‘combination claim’ exception. The theory behind this exception is that your indemnity should only cover your software, and not your software + some other technology (either customer or third party). Look at it this way: Are you being compensated sufficiently in the transaction to pay for infringement insurance on how your customer uses your software or only on your software?  Let’s take a look at a real world case from 2014.

The Facts:  Intervoice’s software was deployed on premises at AFLAC and then AFLAC was sued for patent infringement. However, supposedly the Intervoice …

 
What to remember about Saas Reseller Agreement and SaaS OEM Agreement Models!
There are essentially 3 different SaaS channel models: referral, reseller and OEM, which are documented in a referral agreement, SaaS reseller agreement and SaaS oem agreement. I discuss these three reseller models a lot with clients, so I thought this topic deserved a brief outline of the differences between the models (here is another post on the types of SaaS reseller agreement models).

 

Referral Agreements.

SaaS referral agreements are essentially models where the referring company ‘refers’ or introduces new leads to the SaaS vendor.

If a SaaS vendor closes a deal with the new lead, then the SaaS vendor pays the referring party a % of the deal for a certain period of time (usually 1-2 years; the duration really depends on the vendor’s business model and the sales contribution of the referring party). The SaaS vendor sets the price and the referring party does not.  In these deals you have to think about issues like tail payments (if you terminate the referral agreement early, often the referring party would like some kind of continuing payment) and exceptions to the referral fee obligation (like active or known deals, etc). Some people also call this agreement an ‘affiliate agreement’ which is fine, but I think a referral agreement is a more accurate description.

Reseller Agreements.

SaaS reseller agreements are for situations when the reseller will resell the SaaS vendor’s service AND …

3 Things to Consider When Creating your Enterprise SaaS Agreement

Lots of clients ask me to help them with their enterprise SaaS agreement models. The discussion always starts with; well tell me about your ‘enterprise’ SaaS offering. Too often the clients don’t have it all mapped out, so we then talk about the following 3 issues.

 Its About Price and When Your Customer Pays.

 I have found that most enterprise SaaS customers are looking for a discount and are usually willing (but not always) to make some kind of long term commitment to your service (or some kind of other commitment that you can sink your teeth into). So remember that you are looking for a commitment here, and if you don’t get one then all you have given them is a big discount. Also, try to structure the agreement in a manner which requires them to pay upfront for at least 1 year (which is pretty typical for enterprise SaaS deals).

 Is your Capacity Locked?

In other words, does your service prohibit them from exceeding the capacity they purchased (however that is measured) without coming back to you to make an additional purchase? If your service does have this restriction (which by the way I think it should), then providing the customer the ability to exceed the purchased capacity and pay later is usually part of the enterprise SaaS deal.

Price and Terms are Linked.

The main underlying theme of all enterprise SaaS agreements is price and terms are …

Every software app developer needs to know about the latest software app privacy issues, so I thought I would provide a brief summary of some of the best published privacy guidelines for app developers. You may have missed it, but the Federal Trade Commission (aka FTC), the Attorney General for the State of California, and the Future of Privacy Forum and Center for Democracy & Technology (aka FPF and CDT), have each created a great privacy guideline document for app developers. This is something app developers should have on their radar screen, as if you have forgotten, messing this up can be very costly/painful, etc. (Remember the Path.com app privacy fiasco Link).

Ok, so here goes.

The FTC and the California suggestions are similar so I combined them below:

 App Developers

• • Review the collection and use of personally identifiable data
  • Create a clear Privacy Policy
  • Use Enhanced Measures (e.g. in app notices)
  • Use Just-In-Time Disclosures

App Platforms

• • Make app privacy policies accessible from the app platform
  • Use the platform to educate users on mobile privacy
  • Use Just-In-Time Disclosures
  • Use privacy icons

Mobile Ad Networks

• • Avoid out-of-app ads
  • Create a Privacy Policy
  • Move away from device identifies to temporary identifies (see Carrier IQ Situation Link)

Mobile Carriers

• • Educate mobile customers on privacy issues

 The FPF and CDT created a checklist:

 1)   Practice ‘Privacy By Design’ (this is a Canadian invention, but it has been adopted by the FTC Link)

2)   Communicate Openly & Effectively

3)   Make your Privacy …

SaaS Indemnity – What Types of Insurance should a SaaS Company Purchase?

Every SaaS company should have insurance , as any typical business should and would. However, there are a few significant differences that every SaaS company should be aware of (by the way, insurance is a form of indemnity = way to shift/move liability by contract).

1)   Commercial General Insurance. This type of insurance generally protects business owners against claims of liability for bodily injury, property damage, and personal and advertising injury. But what is important, is that this type of insurance only covers ‘tangible property damage.’  Said another way, it does not cover intangible property loss or damage (e.g data and information). So you should get this insurance, but don’t expect that it will cover much for your SaaS company.

2)   Workers Compensation, Auto Liability and Umbrella Policies. I am not going to spend a lot of time on these policies, other than to say get them.

• Workers Compensation: covers employee injuries caused on the job. This type of insurance is required by state law, and is usually not a big issue for SaaS companies (cuz people don’t usually get hurt around software).
• Auto Policies: you know what this covers; nuff said.
• Umbrella Policies: fills in gaps & increases limits of the other policies.

3)   Technology Insurance.  Ok this is where this insurance stuff gets more interesting! Every SaaS company should pay attention to–and get educated about–the variety of technology related insurance products in …