2012

There are some great  lessons here regarding SaaS confidentiality agreements (aka NDAs).

Background: A startup SaaS company disclosed its confidential consumer electronic buyback program information when trying to win the business from a ‘prospective customer’ = Best Buy. Best Buy gave all the right buying signals and Techforward went even further and disclosed its trade secrets (internal workings of its proprietary analytical model) to Best Buy. However, at the last minute it appears that Best Buy decided not to buy the SaaS service from Techforward, and instead took Techforward’s information and created a nearly identical internal solution (in violation of the NDA). Techforward sued, and a few years later a court awarded Techforward  $27 million as compensation for their loss (including $5 million for Best Buy doing it intentionally).

Here are 3 takeaways, as something good has got to come from this case.

1) Always Use an NDA When Disclosing Confidential Information to Third Parties.

• This helps to prevent a misuse of the information, as most customers will abide by the NDA. 
• However, if your customer wrongfully uses your confidential information, then the NDA will really help when you try to get them to stop using it or to seek compensation for your loss.

Sorry to tell you, but sometimes customers don’t want to pay for your SaaS service, and they may take your information and create their own solution (that is pretty much what happened in this case).

2) Disclose Confidential/Trade Secret Information in ‘Layers.’ 

• Disclose only

Don’t be surprised if you don’t totally understand this SaaS agreement question, even though you want to know the answer. Ok, let me explain, and this will (hopefully) become clearer.

In every SaaS transaction, the law imposes a liability model that is limited only by what your customer can prove as its damages under contract law.  Therefore, each SaaS agreement has an embedded contractual risk/liability model (i.e. limitation of liability clause) that modifies the liability model with the purpose of lowering your risk (…stick with me, as this is not that hard). You can recognize these models by their language, which looks something like: “X is not liable for indirect, special or consequential damage . .  X liability for direct damages is limited to . . . “ These clauses are actually super important, so don’t ignore these as simply legal “boilerplate” language.  In fact, most SaaS lawyers would say that these clauses are the most important clauses in any SaaS agreement.

Let’s take a conceptual look at 3 different contractual risk/liability models to get a sense of how they work.

Model 1: Standard model, where vendor is liable only for direct damages up to 1X (e.g. amount paid in the last 12 months).

 …

Ok, let me explain what I mean.

Enterprise customers too often want to make up their own terms (i.e rules) regarding how they use your software service. As a result, you really need to think about linking price with terms (in your SaaS agreement). How does this work, well let’s go through it.

1). De-Linking Price and Terms. Most enterprise customers try to de-link price and terms (negotiate price first and later hit you up for a bunch of custom terms), and I have even seen them have separate negotiating teams when negotiating price (usually the IT business owner) and when negotiating terms (usually the purchasing and legal departments ). So if a customer tries to separate price and terms, your job is to keep them linked!

2) What Happens When They Are De-Linked. ​When price and terms are de-linked the customer has no incentive to end the negotiation, as you are just giving and giving terms and getting nothing in return. As the price has been agreed to, your customer is actually incentivized to keep asking for more (and better) terms.  This is what I call ‘going through the grinder,’ as that is what it will probably feel like.

3) What Happens When They Are Linked. When price and terms are linked, the customer is more likely to have the real discussion of what its needs are. Why would this be the case? Well, if a customer wants a specific term in a SaaS agreement and …

Tell Your Customer to Backup Their Data (so Says the Utah Supreme Court)

The Utah Supreme Court ruled in June 2012, that when a software vendor is sued for its software’s destruction of customer data, it really matters whether the software vendor told the customer to backup its data or not. Ok, let me explain this (from the software or SaaS company POV for its EULA or cloud services agreement).

Background. A Dentist was upgrading its practice management software, and during the process all of its data was lost (i.e. the Dentist had to manually re-enter all the data…not very fun). So of course, like any good Dentist it sued the software vendor to compensate it for its losses. Early in the case, the court threw out the case, and the Dentist appealed all the way to the Utah Supreme Court. The good news is the Utah Supreme Court got it right. Let’s go through what the Utah Supreme Court said.

1) Telling Your Customer to Backup its Data Helps…A Lot  (especially when the Dentist said it had backed up its data, but in fact it had not…yep that is what happened in this case). 

​2) Disclaimers of Indirect Damages also Work (in other words, the software vendor stated in its EULA that it is not liable for indirect damages, and the court agreed). 

3) General Warnings Work (think about it this way, you may not be able to make the law, but if you warn a customer …

Ok, I need to define a term first.

‘Strategic uncertainty’ =  when a party to say a cloud services agreement intentionally tries to create an ambiguity in a clause, so they can later use it for their benefit (in a dispute of course).

Look agreements are all about certainty and rules, so any type of uncertainty is generally not a good thing. However, it is near to impossible to be clear on everything (even if you try to), but if I were you I would make sure you are clear about at least these three issues.

1) It is All About the Money. You should be clear about how much, when and for how long your customer is committing to your     service.

2) Restrictions of the Service. You should be clear about any restrictions of your cloud service (for example, maybe your customer should not access your service other than through a documented interface…if that is the case).

3) Disclaim Unique Risks. You should be clear about any unique risks of your cloud service that your customers should be aware of  (for example,​ you do not guaranty compliance with say a certain law, even though your service helps them to comply with the law).

Oh yea, do you want an example of what a strategic uncertainty looks like. Well, here is one: “The customer must pay all undisputed invoices within 30 days.”   

Now this seems reasonable on its face, as if the invoice …

3 Things to Consider When Drafting Your Cloud Services Agreement

While there are a lot of things you should think about when drafting your cloud services agreement, here are 3 things you should definitely think through.

1) Clarity.  While not all lawyers agree, I think cloud services agreement in particular should be drafted as clear as possible. Why you ask? Well, your customers want to understand your model and what they are committing to, and so the quicker you can communicate it the better (oh yea, your cloud services agreement is really part of that communication process). Remember, that as you are providing something that is intangible, so communication, consistency and clarity are really important. 

2) Transparency. Keep in mind that you want to communicate not only the easy issues, but if there are important (difficult) issues you need to address, then you have to address them. Being totally transparent helps, because when you are providing a service remotely over the Internet ‘trust is a huge issue’ (and transparency helps to build that trust).

3) Avoid Breach of Contract. You want to be careful about what obligations you take on, as you don’t want to find yourself in breach of the agreement.  Try to only commit to obligations that are ‘in your control’ or you ‘can influence the outcome of.’  Why does it matter? Well, you generally (except for indemnities) don’t have liability under an agreement unless you are in breach. So in general you don’t …

Ok that may be a little bit of an overstatement, but I do think that this new concept of ‘Privacy By Design’ is the future of privacy in terms of SaaS privacy and software privacy.

Here are 3 simple things you should know about Privacy By Design:

1) ‘Being Adopted’ in the US (Invented in Canada). This methodology (if you can call it that) was actually conceived by the Information and Privacy Commissioner of Canada (Ann Cavoukian), but  the US Federal Trade Commission is joining in. While this is not the law (yet) in the US, the FTC is trying to get companies to think about adopting Privacy by Design when they are sued by the FTC for privacy violations, and it is being addressed/referenced in draft privacy legislation in the US…..not too hard to connect the dots. Also, it is already global (and has been translated into multiple languages), which is really a great thing.

2) Build Privacy Into Software Development. As soon as I read this, I thought ok this is how privacy should be addressed in SaaS and software (it should be thought about during design of the software and not an after thought….which it too often is). To me this is merely part of the evolution of privacy as part of the software development process, as at first privacy was not that big of an issue for software companies (therefore, developers did not spend a lot of time …

 The taxation of international SaaS transactions is complicated and not all worked out, but I thought I would summarize a few key points from a recent Grant Thornton article on the subject.

Here are a few key things to think about:

Permanent Establishment – this is accounting speak for do you have enough of a presence in a country for the country’s tax authorities to tax your SaaS offering.

The main factors are:

• Is there a fixed place of business in the country? [BTW, owning hardware in country = fixed place of business]
• Is there a dependent agent in the country (‘dependent agent’ is not the same as ‘independent agent/contractors’)?

If there is a PE, then

• You will be taxed by the local authorities on the income generated from that location.
• The transfer pricing rules apply (we can figure this one out another day, but here is some info on it from Wikipedia).

Sales and VAT Taxes  – these taxes often apply, even if you don’t have a PE in a country.

Few things.

• SaaS is considered taxable for VAT purposes in the European Union (in the country where your customer is located).
• Your customer should pay this, so make sure in your contract that your clarify that you customer is responsible for any sales, use, VAT and other similar taxes.

If you look at the history, most tax regimes were originally setup to tax tangible goods (i.e. not software or software services) so trying to fit SaaS …