Are you selling trust or software? As a SaaS company, well, it is a little of both. Let me explain.

I learned something recently about the Salesforce.com agreement that has completely changed my thinking about SaaS Law and service level agreements (SLAs). What I learned was there is no SLA in the Salesforce.com agreement.

Yep, you read it right — there is no SLA in their agreement. What Salesforce.com has realized — and you need to remember — is that you are first and foremost selling trust. So Salesforce decided to spend less time negotiating the complexities of an embedded SLA in their SaaS agreement and instead publicized their SLA under a Trust Site.

Here is what every SaaS or PaaS business needs to know about Trust Sites.

What is a Trust Site?

A Trust Site is a public-facing website on which you post your SLA (current and historical uptime performance, or whatever metrics your customers need to know to trust you), Security Policy, and Privacy Policy. This is a pretty simple concept, but if you think about it, you are actually taking it to another level by making this information public.

Why Salesforce.com Moved Their SLA to a Trust Site

I don’t really know, but what I heard is that Salesforce.com was spending way too much time negotiating their SLA (how to measure it, how to determine and how to apply the credits, yada yada). This was unnecessarily extending the sales process, so they did some deeper thinking about the issue.

They realized what customers really just want to be assured that:

1. The vendor knows when a site has performance issues
2. The vendor is working to resolve the issue
3. They will be notified when the performance issue is resolved.

All of this can be addressed through a Trust Site (instead of the SaaS or PaaS agreement) dedicated to explaining why customers should trust you with their important data. If that is the way your customers are looking at it, you better start thinking about it that way, too.

What You Can Do Now

Take a look at the sample Trust Sites below, as I have provided several examples. As you can see, your Trust Site does not have to look like the Salesforce.com site, and in fact you should figure out what key metrics your customers specifically want to see.

This is really not hard stuff, but if you get it right you could actually spend less time negotiating your agreement and build more trust with your customers. Now that is a really cool idea and great for SaaS Law.

Trust Site Examples:

• Marketo
• Dell Boomi
• AtTask
  
• CentralDesktop
• Ariba
• Clio
• Act On

Do you have any questions about developing your own Trust Site? Let me know in the comments below.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

photo: Robert Scoble

Trying to keep up with customer contracting best practices is not easy, but Microsoft may be able to help you out here. Microsoft drafted their new Windows 8 end-user license agreement in plain English and in a way that has never been done before (at least based on what I have read — and I read lots of EULAs).

Microsoft’s New EULA Structure

It has three sections:

1. FAQ
2. Additional Terms
3. Limited Warranty

Now you may say that isn’t a big deal. Well, actually, it is. The FAQ is part of the contract.Did you get that? The FAQ is part of the contract!

Here are some examples of the questions and answers within the EULA:

What is really unique is that there is no license grant, but simply the question regarding how a user can use the software and the answer.

This may usher in a new form of contract drafting. If you think about it, the reader of the EULA does not care about a license grant (or the legal formalities of license grants), but they do want to know how they can use the software.

While I have never heard of a court interpreting a contract with an embedded FAQ, I don’t see any reason why a court would not enforce it as written. Also, courts really like it when software vendors make their agreements more readable and understandable for consumers, so I think (hope) that the court will give Microsoft credit for drafting it in this manner if there were a dispute.

So take a look, and consider drafting your own customer-facing agreement in this manner. It will really help in keeping up with customer contracting best practices, as this may represent the future of contracting with consumers!

Resources

Link to the Agreement

ZDNET Article

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

Some companies don’t think they need a non-disclosure agreement (NDA) with their customers. Well, here is a great reason why you need one.

Background: An expansion stage SaaS company (Techforward) 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 three takeaways for every expansion stage company. After all, 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 what your customer needs (at that stage of the buying process).
• If your customer wants your super secretive stuff (aka trade secret information) then think hard about it before disclosing it.

Note to self….

• Does the customer really need this level of secretive information?
• Have I shared this type of information with other customers?
• If I plan to disclose it, mark it as ‘Confidential Information/Trade Secret of [Fill in Your Name Here].’
• Do we have a strong NDA in place?

3) Protect Your Trade Secrets (aka Crown Jewels)

• Identify your trade secrets.
  • Take steps to protect them (secure them, mark them, limit access to them, only disclose them with an NDA in place, etc).
  • Don’t share them with third parties (unless you have to).

In this case, Techforward actually disclosed their crown jewels, but at least that was a conscious decision made by the Board of Directors of Techforward (and they did have an NDA in place).

Remember that some potential customers are not good (or the right) customers. You should also take steps to identify and protect your confidential information, and make sure to get a good NDA signed. While none of this will guaranty that a customer will not misuse your information, it will help (a lot) in trying to avoid the Best Buy problem. Trust me.

Additional Resources:

• One of My Blog Posts on Trade Secret Protection. 
• Blog Post from TechCrunch on this Topic. 
• Blog post from the VC that funded this case (yep a VC had to fund it). 
• All the Factual Details: Plaintiff’s Memorandum. 

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

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, 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 three 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).

Model 3: Advanced model, which is the same as Model 2 but direct damages are limited to 1X and certain claims are limited to 3X.

So, the takeaway here is for each expansion stage company to get a better understanding of what its SaaS agreement liability model looks like. So grab your agreement and go find this language. It may not look exactly like one of these but I bet it is close to one of them. If you now have a better understanding of these embedded risk models, then you are closer to deciding what language is right for your company (and what you may ‘consider‘ agreeing to in a larger/enterprise SaaS deal) — which is really the goal here. Go ahead and give it a try, and let us know what you figure out.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

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 as part of your business growth strategy. 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). I have even seen them have separate negotiating teams for negotiating price (usually the IT business owner) and for 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. Since 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 a 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 say it costs more $, then the customer will either decide to pay for it or pass on the request. Either way, the incentives are in place to get the deal closed, as the terms that matter will be addressed early and the ones that don’t will be skipped.

• For example: If the customer wants you to place your source code in escrow, then maybe you can provide source code escrow if the customer is willing to pay for it.  Now the parties are having a real discussion around the issues rather than a made up set of terms the customer wants simply in order to get an advantage in the SaaS agreement (i.e. one-sided customer favorable agreement).

Do customers really think this way? Look at the quote below (this is a quote from a company that hired International Computer Negotiations (ICN) to help educate them on how to negotiate with companies like yours).

Yep, your customers are trained and prepared before negotiating with you.

So as you can hopefully see, whether you link price and terms really does matter. When developing your business growth strategy, you have to think about these kind of practical negotiation tips.

Here are some more real world examples:

1. “If you want x term, we can do it, but it will cost y $.“
2. “If you want that discount, we can provide it, but we need a two year commitment to our SaaS service to give you that kind of price.”

It is not that hard, so go for it. And let me know if it works.

Okay, let me explain this (from the expansion-stage company’s POV).

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 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 of a risk (in this case to backup its data) courts are going to give you credit for that effort. 

So whether you are training your support department or writing your user guide, telling a customer to backup its data can really make a difference. While issues like this are not fun for an expansion-stage company to think about, these things do happen in the real world and (as you know) no software is perfect. I am happy to report though, that the Utah Supreme Court got it right in this case.

Resources:

Copy of the Utah Case

Another Data Loss Case from 1991

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

2) Transparency: Remember that you don’t want to communicate only the easy issues. If there are important difficult issues you need to address, then address them. You should strike to be as transparent as possible, because when you are providing a service remotely over the Internet trust is a huge issue, and transparency will help to build that trust.

3) Avoid Breach of Contract: You need to be careful about what obligations you take on, because you don’t want to be 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? Because, with the exception of indemnities, you don’t have liability under an agreement unless you are in breach. So, in general, you don’t want to over commit and under deliver.  However, if there are certain obligations you are comfortable committing to, then consider adding them to the agreement, especially if it is something that you customer wants to see included. For example, obligating yourself in the agreement to return the customer data is usually an easy obligation/commitment to take on.

These are three relatively easy things every venture capital & startup company should consider when creating their cloud services agreement.

Do you want a recent example of a clear and transparent agreement? Take a look at the Photobucket Terms of Use. 

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, and it should only be provided after review of all relevant facts and applicable law.

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 afterthought…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 thinking about it). Times are a changin’ (or arguably have changed), so think about designing privacy into your SaaS or software solution. (BTW, if you don’t think about it now, you probably will be in the near future)

3) It is All About “Default Settings.” ​Part of the 7 Foundation Principles of Privacy by Design is that the default setting should be set to protect privacy (i.e. the user has to do nothing, and their privacy is protected). I totally agree with this principle, and I think the FTC confirmed this in the Google Buzz consent order (in 2011).

Look, I know this can and will get super complicated, but every company raising venture capital should think about the fact that (a) some form of Privacy By Design will make it into US law pretty soon, (b) you can build privacy into your software development process, and (c) you should configure your software by default to protect privacy, I think you are going to be ahead of the pack.  So if I were you, I would learn from what IBM, Microsoft, Oracle, and the FTC are already doing in terms of Privacy by Design, as this sure looks like the future of privacy to me for SaaS and software companies.

Resources: 

​7 Foundational Principles

Why Privacy By Design Is The New Corporate Hotness (Forbes Article)

Microsoft is Doing it  and The Microsoft Privacy Process

IBM’s Implementation of Privacy By Design. 

​Privacy By Design YouTube Channel

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

image provided by: nuttakit / FreeDigitalPhotos.net

The taxation of international SaaS transactions is complicated (an interesting intersection of technology and law) 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 mains factors are:

• Is there a fixed place of business in the country? [BTW, owning hardware technology 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.

A 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 law regimes were originally set up to tax tangible goods (i.e. not software or software services), so trying to fit SaaS in does not work that well (at least not right now). OK, this is messy and complex, so don’t be surprised if you are a little confused by all of this (technology and law don’t always play well). Even though it helps to learn the basics, I highly recommend you talk to your tax accountant or attorney about these issues, as this is beyond my pay grade.

Resources: 

A Link to the Grant Thornton Article

Great Tax Article on SaaS Taxation Issues (even though it is from 2008)

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

1) Who is really at fault here: Carrier IQ or the carriers?

• While this is a complex question (and as of today all of the facts are not known) what we do know is Carrier IQ is the software provider and the carriers have licensed their software for use on mobile devices for sale to consumers.
• Two key issues are what type of monitoring the carriers were performing on the phones, and was it disclosed.
• Seems to me that what was being monitored and whether there is an issue of ‘not disclosing’ something, really falls on the carrier’s shoulders. The carriers are the ones that determine what information to collect, transmit, etc., and also are the ones with the obligation to disclose these type of activities to their customers.
• Oh, I am not simply making this up, as Tech Crunch (“Don’t Blame the Carrier IQ”) and CBS News (“Carrier IQ wrongly accused of keylogging”) seem to be taking this view too.

2) What does the indemnity say between Carrier IQ and the carriers?

• OK, I know indemnities are something that makes most people’s eyes glaze over, but this is important, so stay with me. Just as background, most software or SaaS providers should only be providing infringement indemnities, and not a typical general indemnity (here is some background on this issue from my blog).
• Why, you say?  Well, this CarrierIQ situation should make you think about indemnities, as if Carrier IQ signed an indemnity (which is in essence an insurance policy) in which they indemnified the carrier regarding “their use of the software,” “arising from Carrier IQ’s performance,” or something like that, then Carrier IQ has a huge problem. Carrier IQ could be on the hook for millions of dollars in legal fees and fines/judgments/settlement amounts, when (based on what we know now) they may not be the ones that really caused this messy situation.
• What I am trying to say here, is if you are a tech company think really hard about indemnities, as in situations like this they can really become a big/huge/ bet the company legal issue for you.

If you think this is not serious business, read the top of a complaint filed in court on Dec 2nd, 2011:

We’ll see how this plays out, but at the very least, every company seeking growth capital ought to be able to learn a thing or two from this mess.

Resources: 

Carrier IQ Press Release December 1, 2011

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

Saying no.

This is a pretty fundamental concept in your organizational management, and therefore something you have to master. One of the big guns (William Ury) from the Program on Negotiations at Harvard (which is in my opinion the best negotiation program out there), wrote a book on how to say no. If you did not realize it, “no” is actually the most used word in the English language (which kinda makes sense) so how to use it your organizational management is worth learning about.

Here goes,

1. In saying “No” to something, in essence means you are saying “Yes” to something (I know that seems weird at first, but there is always a reason for saying “No,” which is what you are actually saying “Yes” to).
2. Express your “Yes”  and then deploy your “No.”
3. Propose a “Yes.”

OK, that was probably confusing, so let’s go through an example using the three steps (in the software or SaaS negotiations world).

1. “Your company is not making a real long-term commitment to our technology.“ (that was your internal “Yes,” ie. the reason you have to say “No”)
2. “So, we cannot give you the discount you asked for.” (that was your “No”)
3. “However, if we can work on a long term commitment then I definitely think we can get there on the discount you are looking for. What is more important to your company?” (This is the proposed “Yes”)

Think about using this when you negotiate, as Accommodating (saying “Yes” when you should be saying “No”), Attacking (saying “No” in an ineffective way), and Avoiding (not saying anything), are not good ways of dealing with issues. Oh yeah, don’t forget to actually read the book, because to fully make the change in your negotiation style, you need to read this book.

IBM Training Material presentation on this topic (yep, IBM is into how to say “No” and trains their employees on it).

Buy Power of Positive No on Amazon for $16.50

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

So here are some takeaways from the perspective of a software attorney.

1) Read the book. OK, I get that this is circular logic, but you will learn things that I think you cannot learn other than by reading the book. What I am trying to say here is that the way he describes how he moved effortlessly in and out of a tech company’s systems, stole source code, and gained direct access to developers is nothing short of amazing. Without getting a real gut feel for this by reading the book, the importance will be missed.

2) The weakest link in your security.  Kevin Mitnick coined the phrase ‘social engineering‘ and you need to know about it (there is even a wiki page dedicated to it). Essentially it is all about how a hacker uses trickery and deception to get information to gain access to a computer system. In other words, it is all about the human element. No matter how great your company’s technical and physical security is, the human element is the weakest link (at least I think so after reading the book).

3) Next steps. I think that if an IT security program is not equally focused on how to prevent social engineering, it is missing the boat. So how do you prevent it? Well there is no guaranty, but I highly recommend some basic training of certain departments within your organization regarding identifying social engineering. I would train these groups, and in this order:

(a) receptionist (definitely first)

(b) tech support

(c) developers

If you train these groups, you will hopefully see an attack coming, and have a great chance of preventing it. Oh yeah, there are some great training materials for this on the Web.

Even if your focus right now is in seeking corporate venture capital, remember that the most notorious hacker is sharing some of his greatest insights and real world examples (many of them) of how he hacked (deep) into major tech companies. If you have not read this, or don’t feel like you know much about this topic, then go read this book!! I think he is really providing a valuable service to all of us. As Daniel Tosh of Tosh.O would say, “And for this we thank you.”

Resources:

Symantec’s Social Engineering Fundamentals. 

A Blog from an Expert and Trainer. 

Kevin Mitnick Even Provides Training. 

One Book Review. 

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

• Can you use third party software (for example, Microsoft’s SQL Server) in your partner’s demo lab for testing your software?
• Can you go onsite to a prospect and use/leave SQL Server in a demonstration environment for 3 weeks, so they can test your software?

While you may not run into this issue every day, this is becoming a much more common licensing issue. The Lady Licensing Blog does a great job of addressing it, so I thought I would give her some recognition for the post and, of course, add some of my own thoughts on the subject.

So, here goes:

1) Check your License Agreement.  While I am sure you had thought of this, I wanted to remind you, as this is where the rubber meets the road. It is ok to look at an FAQ or other online guide, but you should make sure that the actual license agreement specifically allows you to perform the specific demo and test activities (especially offsite). The Lady Licensing post  addresses these issues (with a useful chart AND the license wording).

2)  An Internal Use License is Not Enough. The key here is you need the explicit right to use the third party software offsite, specifically for “End User Testing,” “End User Demonstration,” etc. This specific wording is addressed in her blog, but I thought I would reproduce it here as it is super important.

3) Follow the Rules and You Should Be In the Clear. 

So using the language/example above, you can use the software for:

(a) Internal Testing and Demonstration. Really not a big give by the vendor, but nice to have it clearly described.

(b) Demonstration Purposes where you Retain “Control and Possession.”  This is great, as it means you can take the software offsite, but you have to retain control and possession.

(c) Trial for End Users.  If these 3 conditions are met (i) 120 day limit, (ii) removal after 120 days, and (iii) have an agreement with the end user.

So long story short, these are the kinds of best practices you should think about when you need to utilize third party software for demonstration or testing purposes (especially offsite). Read your vendor’s agreement and dissect it as outlined above, as the keys to your rights should be in langauge like this. Oh yea, talking to a software attorney is probably a good idea, too (but you knew that already).

Resource:

Lady Licensing Blog Post 

Microsft (Partner) Licensing Benefits FAQ

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law. 

Image provided by: ytwgrowthcapital.com

1) Great Resources. This site looks like a great place to keep track of best practices for developing secure applications, etc. Their resource page is pretty good. Take a look. Resources Page.   

2) Useful Privacy Self Assessment Tools. They even provided some online self assessment tools to help you determine where you are in the privacy maturity model. While the assessment tool is based on a Canadian model, it looks really useful to me. Self Assessment Page.  I wish someone in the US would build an assessment tool like this for each privacy regulation (but you know on second thought, maybe a one size fits all privacy assessment is better, since it could ‘theoretically’ cover all privacy regs).  Here is a link to the actual assessment (print version).  Wouldn’t it be great if there was one assessment and it said in the assessment that this issue is a HiPPA issue, GLB Issue, General Privacy/Security Issue, etc?

3) Privacy Policy Generators. This is worth a look. If you can’t afford to hire an attorney you may get something useful out of the privacy policy generator. Privacy Policy Generator. 

So take a stroll through this site since there is something there for everyone who is thinking about seeking growth capital or a venture capital investment. I did, and I learned something.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

Image provided by: pa-statute-of-limitations.com

It is not often that there is a reported case for expansion stage companies that specifically addresses an exclusive software license, so I thought I would share 3 takeaways from this 2011 exclusive software licensing case (HyperQuest vs N’Site Solutions). This case identifies something all companies looking for expansion capital should know about.

I will definitely not bore you with the long and detailed facts in this case, so let’s get to it.

Key Takeaways:

1) If you want copyright law to protect you, then use copyright wording in your exclusive license grant.

• Ok, that was a mouthful, so let me explain. There are generally 6 exclusive rights a copyright owner has (i.e. reproduce, distribute, create derivative works, publicly display and perform, etc.) and these rights need to be used or referred to in the license grant if you want to seek protection under the copyright act.

2) If too many rights are retained, then you may not receive an exclusive software license.

• This actually happened in this case, as the court decided that too many rights were retained by the grantor for an exclusive license to be granted. This makes a lot of sense. If a party says I grant you an exclusive license but then retains rights that are inconsistent with exclusivity, then the exclusive license should not work.

3) Typically exclusive licenses are granted for certain territories, fields of use, or media.

• Yes, typically exclusive rights are granted for certain territories (i.e. US only), fields of use (i.e. for only the insurance industry), or media (i.e. print) so think of drafting them this way.

So next time you are working on an exclusive software license, you may want to review this case and think about how the drafting of the exclusive license grant really matters. Oh yea, these are the kinds of things I discuss with the OpenView portfolio of expansion stage companies.

Reference:

Full Case on Google Scholar.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

1) If you use AGPL’d code or modified code in your SaaS offering, you need to make the source code available.

• Yep, this license requires that if you provide the AGPL’d code ‘over a network,’ you must make the source code available (unlike the GPL where if you modify the code but do not provide it externally (i.e. do not distribute it), you do not trigger the source code requirement).

2) What does the GPL say again?

• It is generally considered that SaaS companies that provide their service over the Internet/network (but do not require the user to download the code) are not ‘distributing‘ the code. As a result, using the GPL’d code in a SaaS offering does not necessarily require disclosure of the source code (this is called the ASP exception).

3) Where does it actually say this in the AGPL?

• There is a new Section 13 of the AGPL:

CLICK TO ENLARGE

OK so this is not that hard to remember: if you use code under the AGPL in your SaaS offering, you need to take seriously the source code disclosure requirements, as the rules are very different from the GPL (just a reminder from an open source law firm).

Resources:

• AGPL V3.0
• Why the Affero GPL
• List of AGPL Web Applications

But two very recent big name court cases demonstrate that even the unique restrictions are usually enforceable. Every company looking for growth capital or growth equity should have a read.

Case #1:

In this case, the Blizzard Entertainment (the folks that make World of Worldcraft) license agreement has a very unique restriction (see below).

Without taking you through the whole boring details of the case, the court essentially said that this restriction was enforceable and MDY (the company that made a ‘bot’ that allowed users to advance without actually playing the game) breached the license agreement. Oh yea, MDY also made around $3.5 million from selling the software that performed this task. So not only did MDY make software that violated this restriction, they also profited from it in a pretty big way. Courts really don’t like this.

Case #2:

NEON Enterprises sued IBM regarding certain restrictions in the IBM license agreement (actually NEON was alleging that these restrictions did not exist). NEON made software that allowed IBM customers to move their workloads around more freely, and was making money this way. IBM disagreed and said that their customers are restricted from doing this. It seems pretty clear to me that IBM stated in its license agreement that the IBM customer can only use certain workloads on certain processors. It appears that this was enforceable, as at the end of the lawsuit NEON agreed to a permanent injunction withdrawing its software from the market and actually giving the source code to IBM.

Here is some wording from the court order in the case.

License Restriction Takeaways

• If you are licensing your software and need unique restrictions to protect it, then think about adding those restrictions to your software license agreement. This is probably part of your competitive positioning.
• Be careful with restrictions or capacity limitations in the software you license, as courts sure seem to be enforcing them.

Q: Are software license restrictions always enforceable?

A: Actually, no. For example, clauses that prohibit customers from publishing benchmark tests may not be enforceable. Here is an article about it: N.Y Case Calls Software License Speech Restrictions into Question

RESOURCES:

• Wiki Post on MDY vs Blizzard
• Summary of the NEON vs IBM Lawsuit

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

 The definition.

Negative Option means – when someone ‘fails to act’ (= silence) which means they accepted a contract.

 Q: Why Does the FTC Care?

A: Well, some companies use this concept to trick consumers into paying for something without knowing the financial and cancelation terms (nothing you would do, of course).

 Here are the FTC’s 5 Principles:

1) Disclose the Material Terms of the Offer in an Understandable Manner.

2) The Appearance of the Disclosure Should be Clear and Conspicuous.

3) Disclose the Material Terms BEFORE the Consumer Pays for or Incurs the Financial Obligation.

4) Obtain the Consumer’s AFFIRMATIVE CONSENT to the Offer.

5) Don’t Impede the Cancelation Procedure.

 
Let’s Look at Some Examples:

•  bundle one service/product, with another service/product which auto-renews each month with a charge.
•  trial, which converts to a paid service.
•  service that auto-renews, without notice (your SaaS service or support renewal?).

 Here is a screenshot from the FTC.

1) This version looks compliant (you have a choice to accept it or not).

 

2) This version does not look compliant (where is that specific consent to it? And it is kinda hidden over there on the right side.)

So think about this issue if you are ever using your customer’s silence to accept a renewal or a bundled offer. Quite frankly, I think this is a good business practice, so you may already be compliant (but re-read those 5 principles above, because they are a great checklist!)

These are the kind of things I discuss with the OpenView portfolio of expansion stage companies, and as part of my strategic consulting services.

Resources:

1) Here is the FTC’s Entire Report on Negative Options. (72 pages) from January of 2009.

2) California has a new law on this too (so you California based companies should take a read.)

 
Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

Background: Where is this whole idea even coming from? Many customers are counseled or taught (BTW, there are lots of companies teaching your customers how to negotiate and buy from you) to send out long RFPs that ask for the world (lots of detailed questions about your solution . . . more information than they probably need), and then when it comes to the contract stage they too often demand that your whole RFP response become part of the final contract. Well, I think this is a really bad idea, and here are 3 reasons why. Just a few thoughts for any company looking for growth capital or a venture capital investment.

1) RFP Responses = Marketing Material. These responses were not written or intended to be inserted into contracts. If you really think about it, when you wrote the response, you had your marketing hat on; you were telling them how great your product was. But were you thinking you were writing the contract? Probably not. Marketing material has a purpose, and that purpose is not contractual (it is more about education and inspiration).

2) Contracts = Rights, Duties, Etc. ≠ Marketing Material. If you said in your RFP response that “…this software is the best software that does x…”, should that become part of the contract? Absolutely not. Have you ever heard of the legal term ‘puffery‘? Well it is a legal term that describes those vague and optimistic terms that should not be legally actionable, and should not be relied on (i.e. they are general marketing terms and not contractual terms). So, if these types of words from your RFP response become part of the contract, then I think you are begging for a lawsuit.

3) Good Luck Trying to Book the Revenue. Most of the accounting rules around revenue recognition look for consistency and predictability, and if you start including all these different and varied RFP responses in your contracts, then I think you are probably killing that consistency and predictability. Are you selling a custom solution or a general solution in which everyone really gets the same thing? If it is the former, then I understand the request to address some of the RFP responses in the contract (re-written in another form), but most SaaS companies (at least most of the ones I have worked with) are providing the latter . . . a general solution in which everyone gets the same thing.

So long story short, try super hard not to include your RFP response into your customer contract, since 1) that was not the purpose behind why you wrote it, and 2) you are probably looking at some revenue recognition problems if you do (i.e. not a good thing). Think about this folks, as this is coming up more and more, and quite frankly I think it is somewhat of an RFP trick (that I don’t want you to fall for). Every SaaS company should think about these issues as part of their business growth strategies (definitely before they determine their company exit strategy).

Resources

Puffery as a Defense to a Lawsuit.

Another Puffery Article.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

A very recent case ruled that the parties’ conversation on only IM changed the contract, even though there was nothing actually signed to reflect the change (as one of the venture capital advisors to the OpenView portfolio, I am always looking for cases like this for companies seeking growth capital or a venture capital investment). Does this sound like a crazy result? Actually not, so let’s run through the actual IM conversation, the legal logic, and what you can learn from this case.

1) Here is the Conversation (that changed the volume commitment under the contract).

 
That is it. ‘Awesome’ was interpreted as yes I agree to ‘No Limi’t on volume.
2) Here is the Legal Logic.

The court essentially said that the parties went through an ‘offer and acceptance process’ and changed the volume commitment. Where is the signed document you say? Well, there is none, but there is an offer (by typing ‘NO LIMIT’) and an acceptance (by typing ‘awesome’).

3) Here is What You Should Remember.

The courts in the US are now starting to get more and more comfortable with contracting via electronic means (email or IM), so don’t assume anymore that you need to have a written signed document to change a contract. How do you avoid entering into contract (offer and acceptance) via email or IM?

1. Don’t commit to things in an email/IM, and use more non-commital language (i.e. “that is interesting,” “let me talk to my boss,” “let me think about it,” or “not sure … let me get back to you” VS. “yes I agree,” or “we have a deal”), and
2. Clarify in any email/IM trail that you still need a written contract to formalize the deal, and that there is no contract/agreement until then. Intent always matters, so if you do not intend to be bound, then say that.

So hopefully you are getting the message that things “are a changin”, so be super careful about how you communicate via email/IM regarding commitments. Courts are starting to look at these electronic communications and have already construed them as a contract (at least if they look like a ‘legal offer’ and ‘legal acceptance”).

Resources.

Offer and Acceptance Basics
The Law School Summary: Offer and Acceptance
The Actual Court Order and Conclusions of Law.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.

As you may have heard, Google settled with the Federal Trade Commission regarding its rollout of Google Buzz and its alleged privacy violations during that rollout. There are a few tips here for every company seeking a venture capital investment or growth capital, so I have tried to outline/simplify them for you.

1) It is All About DEFAULT Privacy Settings. Think about it this way, if you add a new feature to your SAAS service where you connect customers/people/partners, etc. who submitted information subject to your privacy policy, you need to think about whether this feature is by default on or off (open or closed, enabled or disabled . . . you get the idea). I generally think that you should turn these off initially, and then educate your customers why they may want to use that new feature (i.e. it should be their choice). Well, Google got this wrong and opened up Buzz to Gmail’s contacts by default and caused all kind of issues.

2) What Google Learned About its Privacy Policy (and you should know). Most privacy policies state that information subject to the policy will not be used for a purpose other than for the purpose for which the information was disclosed (translated into English, if a customer provides a company registration data then the data should only be used for registration purposes, without that customer’s consent). Read your policy, because it may say something like this. If it does, make sure you know what it means before the FTC comes a calling.

Here is the actual text from the Google Privacy Policy.

3) Appoint Someone in Charge. I bet you this privacy blunder occurred at Google, as the left hand did not know what the right hand was doing (i.e. their in-house privacy attorneys were probably not aware of the details of the Buzz rollout). You really don’t have that excuse and unless you are a super large company, this miscommunication should not happen. For a SAAS or software company, even if you don’t have an in-house attorney (which of course most don’t), you can appoint someone to be in charge of your privacy policy, which can really help to ensure you are complying with it. Maybe someone in the marketing department?

As you can see this is not that hard, but at least learn the basics of what is going on in the privacy regulatory world, as a simple change of default settings (opt in or out) can cause the Federal Trade Commission to take action against you (not a good thing).This is worth remembering, as it could affect your business growth strategies or product and development strategy.

Resources.

FTC Press Release

FTC Complaint

Full Detail of the Settlement with Google from the FTC’s Website (only 9 pages, so you can read it in a few mins).

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. Hire an attorney if you need legal advice.

There are many different places to go for negotiations training (in general), but where is a great place for learning about the art of software negotiations with customers, partners, etc. (especially for any company seeking growth capital or a venture capital investment)? I highly recommend the Program on Negotiations at Harvard. I have attended some of their seminars, read some of their books, and have found that there is no better methodology for software customer and partner negotiations (from the perspective of the software vendor for say their software or SAAS contract negotiations). You ask why the PON is great, well let me elaborate.

1) Software Negotiations are Unique. These negotiations are unique as,

• you are selling something that is by definition intangible,
• a general matter software transactions are (i) long-term (i.e. it is not a one shot-deal) and (ii) co-dependent relationship (i.e. you each need each other over time) negotiations, and
• you are generally dealing with super smart people on both sides of the table who are technically savvy too (i.e. BS will not get you very far).

2) Transparency and Honesty are the Key. I have negotiated in many different industries over my nearly 20 year legal career, and I have not found any other industry that requires more honesty and transparency over the long haul than this industry. Every software vendor wants their customer to understand how their technology works, what their revenue model is, and what problem it solves (and doesn’t); so communication and education are super important. Now selling vaporware is not the way to do it (even though it has been done in the past and probably will still be done), and the courts have shown that when this happens you will pay (in a big way).

3) A Collaborative Negotiation Process Works Best. There are hundreds of different negotiation styles, but I think this industry demands a win-win negotiations process. This is where the Program on Negotiation at Harvard comes into play, as this is core to every part of their program.

Take a look at their curriculum of training classes, as I think you will find a few that will resonate with you or address a problem you are having (from ‘Difficult Conversations’ to ‘General Negotiation Training for Senior Managers’). If it is not for you, then consider sending your head of Business Development or Sales, or CFO, as they may need to build their negotiation skills. In my opinion–-for the software and SAAS industry (and any company seeking growth equity)–this is the place to go to get trained on how to negotiate. You never know, this could help your competitive positioning.

Resources:

Advanced Negotiations: Difficult Conversations Training
Negotiation Training for Senior Executives

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. Hire an attorney if you need legal advice.

Q: What is a Trade Secret?

A: Long story short, a trade secret is a business secret that gives you a competitive advantage by remaining secretive.

• The owner must prove that it took ‘reasonable measures’ to keep it a secret (if you do this then the law (by statute) will give you some great protection and legal remedies). Examples of trade secrets: source code, customer lists, business and strategy plans, and employee lists.
Ok, here is what you can learn from this.

1) WHO are the Most Common Misappropriators (i.e. people that take your trade secrets without your permission)?

1. Employees
2. Business Partners
Together, they add up to 93% of the misappropriators [see page 68 for more details]. Yep, people you know and once trusted!! Think about that one. A really recent TechCrunch article shows that now the trend is that un-known parties are looking to steal your trade secrets.

2) What do They Usually TAKE?
1. General business information (e.g., customer lists) [litigated 70% of the time], and
2. Technical business information (e.g., software) [litigated 30% of the time].
3) What are the Best Ways to PROTECT your Trade Secrets?

1. Confidentiality Agreements,
2. Computer and Physical Protections (e.g., passwords or restricted access), and 3. Confidentiality Education and Restrictive Markings (marking things as ‘confidential information of [your company],’ ’internal use,’ ‘trade secret,’ etc.).
Oh yea, I forgot to tell you that the reported litigation is exploding on this front, and the chart is up and to the right (and not the kind of up and to the right you want to see).

So, please think about this, and if you are not taking ‘reasonable measures‘ to protect your trade secrets, then good luck trying to stop an ex-employee or business partner from wrongfully taking or using them (i.e. stealing your competitive positioning). Think about this folks, as these may be the keys to your castle!!

Resources:

Here is the law review article with the survey (assuming you have time to read it) Link

Practical Definition of a Trade Secret from the US Dept of Labor Link

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. Hire an attorney if you need legal advice.

For background purposes, Twitter changed their API licensing terms to further restrict how their API developers use their API (oh yea, there are over 750,000 registered apps). Twitter now wants its API developers to build “tools” . . . not businesses or applications.
Quote from Twitter email re: their new API Rules of the Road on March 11th (2011):

“Developers have told us that they’d like more guidance from us about the best opportunities to build on Twitter. More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. “The answer is no.” (emphasis added) Here is the link to the whole email.

1) Your API Developer Use Case, Could Change. As you know, things change rapidly in the software and SAAS world. You may open up your API and then realize that you opened it up too much, and you want to restrict what your API developers are doing.

• Twitter realized this, as developers were using their API to compete with Twitter or simply duplicate their interface, and caused confusion in the market place (plus trademark issues, changing the tweets, etc).

As most API license agreements are pretty one sided (you are giving them something for free and it is your technology), you can change the terms at any time. However, if you don’t have an API license agreement and then you change your API program, your API developers may not only get really upset, but if they lose $ as a result of the change, you may be responding to lots of complaints and maybe a lawsuit or two (= not very fun). So think about putting an API license agreement in place, as it can expressly give you the right to change your API terms without any liability to you.

2) Communicate the Right Expectations to Your API Developers. As with any agreement, the API license agreement helps to communicate your model (setting expectations of what your developers can and cannot do), and most users actually want to know where the boundaries are (having a great API FAQ is a good idea too). I find that most software or SAAS companies don’t know what the terms of their API license agreement should be, so they avoid the issue (remember, no decision is still a decision). Well, maybe you get lucky and you don’t need to make significant changes, but I would not recommend relying on luck.

• I bet you if Twitter did not have an API license agreement with (a) limitations of liability, (b) disclaimer of warranties, (c) specific language giving them the right to change the agreement at any time, etc., they would have been sued for this recent change. The API users would have probably argued that they relied on this access without restriction and created a business around it (i.e. spent $), and now Twitter cannot make a change without compensating them for the loss.

Well, a good API license agreement can help avoid this whole argument, as it can help communicate your API development model and set the right expectations with your API developers.

Anyhow, I could go on and on with other reasons, but if you can remember that (1) things can and will change in your API model (i.e. remember that you cannot see the future), and (2) you need to set the right expectations with your API developers, then you get the 2 main reasons why you need an API license agreement. Any company seeking growth equity should be aware of this (it may even help with creating your competitive advantage).

TechCrunch Post on the Twitter API Change.

ZDNet Post on the Twitter API Change.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. Hire an attorney if you need legal advice.

(1) Derivative Work or Compilation (copyleft obligations)

• Static Linking (GPL’d code combined with your code in one executable at build time)
• Macro/Template Expansions (embedding GPL’d code into your code)

(2) Close Call (aka, it depends)

• Plug-ins (to extend functionalities of other programs)
  • depends on external factors (I added a few of my own here):
    • dependency/independency of your code;
    • communication protocols/sharing resources;
    • copying of API host code/no copying of API host code;
    • core functionality not subject to copyright/functionality subject to copyright; and
    • existence of other libraries with the same function.

(3) Independent and Separate Program (no copyleft obligations)

• Dynamic Linking (calling and using library only at run-time; (no GPL code copied, modified, translated or changed . . . I added this part from Larry Rosen’s view (see below) on it))
  • remember to look at the above external factors as it could become a derivative work if the facts change
  • oh yea, I moved Dynamic Linking to this section as I think it fits in here more than Close Call
• Interprocess Communications (remote procedure calls)
• System Calls (core operating system resources)
• Interpreted Language ‘Scripts’ (not compiled, executed by interpreter, no third party code incorporated)

So long story short, this is an evolving issue and I don’t think the definitive work has been written, but don’t let that stand in your way of learning more about it. As an open source attorney and proprietary software attorney, I thought you should be aware of this, as these folks did a fantastic job with this working paper and law review article (see below). This is just a thought from someone who often serves as an advisor to the OpenView portfolio of expansion stage companies. 

Resources:

Working Paper on Software Interactions and the GNU Public License (July 2010)

Brian, Malcolm (2010) ‘Software Interactions and the GNU Public License,’ IFOSS L.Rev, 2(2), pp 165-80

Larry Rosen’s view on Dynamic Linking.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. Hire an attorney if you need legal advice.

What Should/Could Be Short Term?
The key with SAAS models is that most* are not perpetual models (aka forever) (like a typical software licensing model where the customer purchases a perpetual license to the software), so things are supposed to change along the way. The functionality you provide may change, along with the feature set. Oh yea, this is pretty typical and actually expected for SAAS companies, so don’t feel bad about it. The takeaway here is to think about keeping short in duration your commitments related to functionality, features and pricing (i.e. maybe not multiple years, but a year or less). Why you say? Well, these could change, so be careful what you commit for long periods of time.

• Examples of Long-Term Commitments Requested by Customers: price caps, support commitments, feature and functionality commitments, etc.

What Should/Could be Long Term? 

Well, in the SAAS model I am not sure many really long-term commitments exist, as the customer is receiving/buying a subscription based offering (something that is time bound). As I scratch my head to think about what long term commitments you could/should make, I really can’t think of any. In fact, maybe that is the answer: you should not make any really long-term commitments as that is not the model (if you do make any long term commitments, make sure you think it through as things will change). As I said above, the issue of long-term commitments comes up very frequently when licensing software in perpetuity because the customer is paying you for something (and buying something) they could use forever (they are thinking super long term).

So think short-term commitments in your SAAS contracts and keep the flexibility in your model (to the extent you can). That is what SAAS is all about! Just some thoughts before you focus on your company exit strategy.

Resources:

Oracle’s Long Term Commitment to Support Siebel Products.

Ubuntu Long Term Support Commitment

* Exception: I have seen and worked with some SAAS companies which provide really long-term solutions to their customers, so they will have to address long-term commitment issues. However, the key point is that even those are not perpetual models (aka forever).

Disclaimer: This post is for educational and informational purposes only, and does not constitute legal advice.

1) Where are Your Sales Leads Stored (aka, who has possession of them)?

Here is a recent summary of some litigation in this area. Worth a read!

Disclaimer: This is not legal advice, and no attorney client relationship is formed. It is provided for informational or educational purposes only.

1) What is Enterprise Licensing? Essentially, most software companies have a licensing model wherein they provide their software to their customers based on some licensing metric (user, computer, device, division of a company, revenue, etc.). This often works well for small and medium size customers, but not necessarily for large customers (enterprise customers). If you think about it, enterprise customers want something more: flexibility, discount/predictable pricing, and ease of administration if they are going to commit to a large license purchase of your software. So long story short, an enterprise software license can mean many different things to different software companies and enterprise customers; therefore, you need to define what it means to your company and to your large customers. By the way, some customers call an enterprise agreement an agreement under which they can purchase software at a discount company-wide for a certain period of time. I am not saying they are wrong, but the key here is to figure out what your enterprise customers need or want.

2) Factors to Consider when Designing Your Enterprise License. First, I want you to think about what your enterprise customer needs/wants with your software (compared to your smaller customers). As I mentioned above, most enterprise customers want (a) flexibility (the licenses are easy to manage from a password or security perspective), (b) discount and predictable pricing (if they commit to your solution company-wide, they don’t want you to arbitrarily increase their price), and (c) ease of administration (the agreement is easy to administer). Try to figure out if your enterprise customer has different needs/wants, as every software product’s value proposition is unique. Once you have figured out what your customer is looking for, you need to determine how to price the enterprise software license. This is not easy, but I suggest you try to ensure that you are adequately compensated for doing these deals.

3) Example. Let’s say you license your software per computer, and customers typically purchase 1-5 licenses at a time. Let’s also assume that your licenses are tied to each computer via a unique password, and they cannot be moved around. If a large customer wants to make a purchase and asks for an enterprise software agreement or license, what should you do? I recommend you look at the 3 factors above (flexibility, discount/predictability and ease of admin) and then make sure you are adequately compensated for the deal. So maybe an enterprise agreement could look like this: 50 computer licenses with open passwords (to use within their company), higher discount per copy and fixed price for 5 years for additional copies, annual usage reporting (i.e. if they exceed their 50 licenses), and in 5 years the deal dies and reverts back to fixed computer licenses. This is simply one example, but as you can see there are several levers to pull to ensure you meet their needs and they do not take advantage of you. I think the key here is that you don’t need 5 different types of enterprise agreements. Once you figure out what it should look like you can lead with that model (of course you should consider making changes at the request of an enterprise customer and don’t forget to keep improving the model as you learn more about the needs of your enterprise customer).

4) What Not to Do. I have seen some software companies simply provide a site or unlimited license as their enterprise software agreement and call it a day. Now maybe this is the right answer for your company, but I suggest you may not be adequately compensated for this type of license. The problem I have with unlimited or site licenses is, how do you define the company or site? What happens when the customer is acquired or merges with another company? You can get into some really complex drafting and what are called ‘change of control clauses‘ to avoid this issue, but I don’t think you want that level of complexity (unless the deal is really large). By the way, most large software vendors rarely license on a site or unlimited basis, and if they do it is often a term license. Here is an example of one.

So remember that when you are designing your enterprise software license agreement, you should think about the needs/wants of the customer and only then can you ensure that you are compensated for it. These enterprise agreements are really not that complex, but they do take some time to design (if you want to get them right). I really can’t do this subject justice in such a short blog post, but hopefully you got the main thoughts behind designing your enterprise software agreement (definitely think about this before you determine your company exit strategy).

Legal Disclaimer: This post is not legal advice, and is provided for general informational and educational purposes only.

1) Retain Ownership of One’s Data. This is covered ground and nothing new to most people. I think all cloud agreements should address this issue as clearly as possible so everyone knows who owns what, and how and when data will be returned to the customer. Oh yea, there is already some reported litigation on this issue, so remember this is important! Recent Case (see page 4). (Address in Cloud Agreement) 

2) Service Level Agreement. This one is also nothing new, as service level agreements have been around forever (at least it seems like it). I think the SLA should be in the cloud agreement and not left to a policy statement. (Address in Cloud Agreement) 
3) Notification of Changes to the Service. This is a great idea and cloud vendors really should communicate about any material or significant change to their service (i.e. ones that would impact their customer or a change they would want/should know about). I think the key here is for the vendor to be as transparent as possible so there aren’t any missed expectations (that is what often leads to disputes and litigation). This too is a communication or policy matter so it does not need to be in the cloud agreement. (Address via Communication) 

4) Understand the Technical Limitations.Gartner is suggesting here that vendors educate their customer on architecture and technical issues. This seems like a no brainer and is something every cloud vendor should implement as part of selling and supporting their service. (Address via Communication Before and After the Sale) 

5) Understand the Legal Requirements of Jurisdictions Where the Service Provider Operates. In essence, Gartner is saying that the cloud vendor should tell their customer where their data resides, and handle any legal and privacy issues associated with the transfer of customer data. This seems like a reasonable expectation and also sounds more like a policy statement (not something that necessarily needs to be in the cloud agreement . . . other than some type of vendor warranty that “they will comply with all applicable laws regarding their performance under the agreement”). (Address via Communication Before and After the Sale)

6) Know the Security Process the Provider Follows. While this is usually not a contractual issue for a cloud agreement, I think it should be a policy statement wherein vendors communicate what they are doing to secure the customer data. I actually think the company I use for my legal billing does a great job of this in their security statement (here is their statement on security). (Address via Policy Statement)

7) Understand and Adhere to Software License Requirements. The issue here is that software vendors should communicate to their customers if they allow their customers to move their licenses from an on-premise license to the cloud. I find this is more of a policy statement by a vendor, but it should be documented (if the transfer or use/access is allowed) in an addendum or some type of legal agreement between the customer and the software vendor. (Address via Communication and in an Amendment)

All in all, I think this is a great current and short list of many of the important issues to consider when working with a cloud vendor. However, it seems like these lists keep changing and everyone (including me) is still trying to figure out what the most important issues are and how to address them appropriately. I hope this is interesting or useful, and is the kind of thing you should expect from venture capital advisors. 

Resources (lots of these Bill of Rights things out there!):

CNET Cloud Computing Bill of Rights.
Altimeter’s: SAAS Bill of Rights.
Disclaimer: This is not legal advice, and is for educational and informational purposes only. Contact and hire an attorney if you need legal advice, which advice should be provided only after review of all the facts and the applicable law. 

“Naked Licensing” is, in essence, a legal defense to a trademark infringement claim. You should absolutely become more aware of this concept, for the consequences of not knowing can be really grave (aka a big deal).

What is Naked Licensing?

Ok, did you get that part about ‘abandonment of the trademark‘?

Now that I got your attention, here are 3 things to remember to help avoid this:

1) Don’t Let Anyone Use Your Trademarks Without a License Agreement. Hopefully I made this completely clear, for that is one of the best ways to avoid a negative outcome. The trademark license agreement should expressly state that any use of your trademark is subject to your trademark guidelines, and steps should be taken to ensure your trademarks are used in an appropriate manner. You can embed this language in any reseller, distribution or other channel agreement, so it’s not necessary to add it to a standalone agreement.

2) Remember What is at Risk Here! Think about it, you develop your trademark (maybe your company name or logo) and people associate your product or service with that name or logo. However, if you don’t take certain protective measures when allowing third-parties to use your trademarks, you could abandon the mark (= you lose it). 

3) Don’t Scare Me With This. Does it Really Happen? Absolutely. Here is a case from November 2010. Long story short, the owner of the trademark rights to “Freecycle” (see above) let other groups use their trademark without a written trademark license agreement and without exerting control over the mark and associated services. They simply stated in an email ” . . . just don’t use it for commercial purposes.” That was it. The court found no written contractual control over the mark and no actual control, so the result stated that the Freecycle mark has been abandoned (because of naked licensing). What that means is the original trademark owner could not stop a Freecycle affiliate from using the mark. It does not get any more real, relevant and recent than this folks!
 

So every software or SAAS company working on their business growth strategies should sit up and take notice of this issue, because I know you have trademarks. You need to review your processes for allowing partners, resellers, etc. to use your trademarks. You can easily avoid this outcome if you understand the risks of naked licensing and take measures to prevent it! 

Here is a copy of the court opinion (if you want to read the nitty gritty details).

Disclaimer: This is not legal advice, as it is provided for educational and informational purposes only. Hire an attorney if you need legal advice on these issues.

Background: TomorrowNow, a third-party support company, was bought by SAP in 2005. TN claimed to provide support for certain Oracle products (for less than 50% of what Oracle charged), and SAP tried to use their business model to lure customers away from the Oracle products and to the SAP products (it was called the “Safe Passage” program . . . which, funny enough, wasn’t safe/legal after all). I guess this was a little bit of competitive positioning gone awry. 

3 Takeaways: Here are the 3 things you should not do to your competitor, now that this case has been decided (all based on the last Oracle filed petition in the case).

1) Don’t Download More of Their Software Than the Amount to Which You Have License Rights. Oracle alleged with great specificity and detail how SAP downloaded more software through its TN subsidiary than was allowed from their license rights. This may seem very basic, but you don’t want to be in possession of more of your competitor’s software than the amount to which you are validly licensed.

2) Don’t Ignore Their Terms of Use on Their Support Site. Before logging into the Oracle customer support site, the TN employees had to agree to the Oracle ‘Terms of Use’ (i.e. a contract). This contract prohibited things like downloading more software than your rights permit, and using Oracle software for the benefit of third parties. It appears that TN ignored and disregarded this contract (i.e. clear warnings/instructions from Oracle). 

3) Don’t Assume Your Actions are Anonymous. Oracle tracked all the TN downloads and was able to show that before certain customers moved their support to TN, they downloaded lots of software from the Oracle customer support site (much, much more than the Oracle customer was licensed for). This made it really easy for Oracle to prove that what SAP did was wrong and in violation of their copyrights. 
BTW: The opposite is true too, so to help prevent your competitors from taking your stuff:

(a) make sure your license grants and restrictions are super clear (so your competitors know what they can and cannot do with your software);
(b) have ‘Terms of Use’ on your support site; and
(c) track your customer’s downloads of your software under support.

If you do this and you think a competitor is violating your license rights, you may have a good case to go after them for big $ (just like Oracle did with SAP).

So long story short, you should not use a person’s property without permission (something you probably learned in kindergarten) . . . especially when they are your competitor (something you probably learned once you entered the business world). If you do, the consequences can be quite grave, as this is the largest software copyright judgment ever.

Resources: Here is the 4th Amended Complaint if you want to read the details. 

Disclaimer: This is for educational and informational purposes only, and does not constitute legal advice.

Background: Without laboring through the long details, two top level employees of Starwood who worked on developing the W brand of hotels went to work for Starwood’s competitor (Hilton Hotels) and apparently took with them 100,000 documents. Hilton was planning to create a similar boutique hotel brand to the Starwood W Hotels, and probably thought that getting these Starwood employees would really help them get a leg up. Well, long story short, Hilton cannot (by court order) develop a competitive boutique hotel chain for 2 years, and they must have (for 2 years) federal monitors supervise their strategic activities, and (according to the NY Times) pay Starwood $75 million (all of this before they even got started in competing with Starwood). All I can say is WOW. This is unprecedented and this all started from hiring 2 Starwood employees.

Ok, so what do you need to know about this before you even think about your company exit strategy?

1) ‘Identify’ and ‘Mark’ Your Confidential and Trade Secret Information. This case would not have gone as well for Starwood if they had not marked their confidential and proprietary information and restricted access to it. Think about it, once your documents leave your site, how does the person in possession of them know that it is your confidential or trade secret information? In a way–at least for argument’s sake–it may seem like documents lose their character once they leave your site if they are not properly marked (in terms of ownership and their confidential nature)!
2) Think About Your Business and Marketing Plans (not only Source Code). What is really unique about this case is Starwood had developed a ‘Brand in A Box’ (brand handbooks, marketing plans, and immersion plans), and properly marked and protected this material. Most software based businesses have lots of confidential and trade secret information besides source code, and this case demonstrates that marketing material can be very valuable.

3) Conduct Exit Interviews With Your Departing Employees. The goal here is to make your departing employee conscious about what the company owns, and inform them to return or destroy all company information (you don’t want them to think that they own or possess rights to their material just because they created it). 

4) Confidentiality Agreements. Use confidentiality agreements where appropriate, for this helps to prove you took steps to protect your important information. 

Now you be saying–and I have heard this argument hundreds of times from software executives–if the information was still taken by a competitor, what do all of these legal steps to protect IP really achieve? Well, if Starwood had not identified and marked its information, held exit interviews with its departing employees, and consistently used confidentiality agreements, they would probably not have come out so well in this case.

If you think about it, imagine if your significant competitor:

(a) cannot (for 2 years) compete with you in a very important growing market segment,
(b) must have (for 2 years) federal monitors on-site reviewing their strategic planning, and
(c) must pay you $75 million (even before they start to compete with you).
If you could put your competitor in this type of straight jacket by taking the above precautionary measures, then maybe you should consider them! Let me know if you got the message, because sometimes departing employees go wild!

These are a few thoughts from a venture capital adviser who works with OpenView’s portfolio of expansion stage companies.  
Here is the 135 page petition if you want to read the detailed allegations.

Do departing employees go wild in the tech industry too?
CA vs. Quest Software – departing employee is hired by Quest. 
SiRF Technologies – employee departs to allegedly start a competitor
Intel vs. AMD – departing employee is hired by AMD
Ex-Employee of Goldman Sachs – employee departs to allegedly start a competitor

1) Written Policy. Think through (a) when it makes sense for your company to use open source code (maybe with functionality that is not core to your offering), and (b) what types of licenses you will allow and won’t (maybe try to avoid GPL licenses if you distribute your code to your customers). For example, you may allow licenses which only require attribution/notice. Oh yeah, don’t forget to write this up and communicate it to all your developers (and contractor developers). See below for an example of attribution wording:

2) Tracking Process. It’s critical to track where you use the open source code and the associated license terms and thankfully it’s very easy to do. Your process could look as simple as a spreadsheet with the name of the open source code, a listing of your products (and version) with which it is included, any requirements of that license, and a copy of the license agreement. This tracking process is super simple if you implement it along the way, and really hard to re-create if you need to do it years later when someone (an acquirer or your CEO) wants to know what open source code is embedded in your product. 
3) Annual Audit. While many people overlook this, whoever is in charge of your open source process (and I suggest you have one person in charge who owns this policy) should annually review what your developers (including any developers who are actually contract developers) know and follow your policy. 
I could make this a lot more complicated, but I find that a software company looking at its company exit strategy needs at least these three basics steps and not necessarily the 25 page open source policy. 
Great, Detailed Article on Developing an Open Source Policy. 
Some Thoughts from a Microsoft Attorney on Creating an Open Source Policy

Disclaimer: This is not intended to serve as legal advice. It is provided for educational and informational purposes only.

Background: The book by Gary Noesner came out in September 2010 and is called Stalling for Time: My Life as an FBI Hostage Negotiator. It has all of the things you would expect to find in a book written by the retired head of the FBI’s Crisis Negotiations Unit (here is a podcast on the book from NPR): stories about estranged husbands locking up their wives, the Branch Davidian shootout in Waco, the DC sniper incident, etc. But what is really interesting and also useful are the pearls of wisdom from the author regarding how to deal with irrational people or those individuals facing a lot of stress. So here are a few things you can use during your next software or SAAS negotiations.

1) Behavioral Change Stairway. I never heard of this concept before, but it can be useful.

This is how it works:

• you show interest
• you respond emphatically (which leads to rapport), and
• only then do you attempt to influence.

This makes a lot of sense. During any negotiations with customers, you need to show interest and listen to them (actively listen), and then show them you understand their concerns and issues (you don’t have to agree to them). Only then can you attempt to influence them.

2) Key to Successful Negotiations.  Mr. Noesner suggested it is important to figure out a person’s motivation, goals and emotional needs, and then to make use of this strategically. This is relevant too, for having a deep understanding of your customer’s (and the person with whom you are working) motivation, goals and emotional needs can really help to close the deal.

For example, maybe the company was burned by a previous vendor for not appropriately supporting the product. Even if you are the best negotiator, you may not be able to get past this issue because the customer feels burned and abused by the vendor, and they don’t want it to happen again. You may have to carry this burden (in some way at least) and address it in your contract.3) Paradox of Power. Another interesting point is that the harder you push the more resistance you will probably get. I agree with this, and you should remember this in your negotiations. Negotiations are very much about education, and not simply about imposing your will on the other party. 
 4) People Want to Work with People They Like. You probably already knew this, but the person negotiating the purchase of your technology has a lot more discretion than you probably realize, and if they like you and want to work with you, your deal is much more likely to close. 

5) Active Listening. If you don’t know what this is, basically it is repeating back to the speaker what they said or acknowledging their statements/concerns (in an empathetic way of course). Try this…it takes practice, but it really works. Here is Gary Noesner’s view on it.

While software negotiations are not as emotionally charged as crisis negotiations, it would be good to try out some of these skills if you are dealing with a difficult or irrational person on the other side of the table/phone (even if they are unarmed!). This takes some work so practice it prior to your engagements. I plan to use these skills with my kids when they take my TV remote control hostage, as that becomes a crisis around my house really fast!

I hope you found this information useful. This will give you an idea of the types of topics I discuss with the OpenView portfolio of expansion stage companies as part of my strategic consulting services. 

Legal Disclaimer: This is for informational and educational purposes only, and does not constitute legal advice. Contact your attorney for legal advice, which should be provided after review of the facts and applicable law.

• SAP distributed and sublicensed certain AMC Technology software embedded with an SAP product.
• When the software OEM agreement expired, SAP tried to provide specific instructions to its customers on how to use the AMC software with a new version of the SAP product, yet the customers actually could not do this (the OEM agreement specifically stated that post termination SAP could only sublicense the AMC software with the ‘then current version of the SAP software’).
• SAP tried to argue that its customers could use the AMC software with the new version of the SAP software, but the court correctly said no way.

Ok, here are the takeaways:

1) You Can’t Grant More Rights Than You Have. This is a fundamental aspect of property law, and dates back hundreds of years to when people tried to grant more rights to buyers of real estate than what they (the seller) had; (it is kind of common sense too). This is the first example I saw where this legal doctrine was applied in the software OEM world. It is good to see that it is still true (at least in this context). So remember that you cannot grant more rights than you possess, and as the recipient you can’t acquire more rights than the grantor has. 

2) Plain English Matters. This agreement was clear as can be, but SAP missed it. . . thankfully the judge didn’t. 

SAP tried to argue that the customer had a perpetual license to the software and this restriction did not apply to them. The court correctly disregarded this argument, and said the agreement is clear on this point… “the then current version of the SAP Software.” Remember; try to be clear on post termination rights in your software OEM agreements, as judges will read the agreement closely to figure out what you meant. 
3) Take Ownership of Your Agreements. When you are working on a software OEM deal, dig in and don’t simply outsource it to your attorneys (too many companies do this). The details really matter, and specifics such as the rights you are granting and what rights you have after termination should be clearly outlined in the agreement. 

So next time you are on the receiving end of a software OEM agreement or the granting end, remember this blog post and use common sense, for even in the intangible world of software you can’t give someone something you don’t have! Just some thoughts from a person who serves as a venture capital advisor to the OpenView portfolio of expansion stage companies. 

Here is the actual court order, for you detailed oriented people. 

I am ok with most of it (see all the yellow highlights), but what I highlighted in red I don’t (or don’t understand). 

1) Choose Any Implementation Partner. While this sounds good, there may be valid reasons why a software company does not want just anyone implementing their software (you know, training, expertise, know-how, confidentiality, competitive issues, etc.). 
2) Pay for Actual Usage. While this also sounds good, I think software companies should be free to determine their pricing models (plus reporting on actual usage would be really complicated/hard). Remember that more flexibility may equate to a higher price for the software (yes, price and terms are linked).
3) Licensee Free to Share Modifications. Because most software is not provided in source code, this is not even an issue, but if it were, I can understand why a software vendor would not want this to happen (e.g. they probably want to capitalize on the market for extensions to their software). 
4) Freely Transfer Software (regardless of site/hardware). Again, this should be up to the vendor to determine as part of their pricing model/strategy. Remember, it is all about price (more flexibility may cost more than a customer wants to pay for that license).
5) Speak Freely About It. The argument here is that software is treated as the confidential information of the software company, and so why should the customer be free to discuss these kinds of things. 
6) Ensure License Equivalency. I am not sure what this is (and nothing came up in a Google search), so I am at a loss on this one. Sorry. 
7) Unbundling of Support and Maintenance. Nice idea, but I think that should be up to the software company to decide, as they can/should determine their revenue model/strategy. 
8) Support from a Third Party. Sounds great on first blush, but here’s the practical reality: How can a third-party support someone else’s code (bug fixes, upgrades, new versions, etc. . . no source code access)? It just does not work (quite frankly I am amazed anyone tried it); I am open to someone proving me wrong though. Ask SAP about it, as a court just ordered them to pay $1.3 Billion in damages for trying to do just that through a company they bought for $10 million. 
9) Define Functionality Replacement. I am not sure I understand this, but if the vendor is retiring a product it would be nice/good to tell your customer what key functionality they would need in a replacement (if that is what they mean by this. . . not sure?).
10) Resell Software. This I don’t get, because most commercial software is not transferable. Vendors don’t want to create a secondary market for their products (consumer software vendors usually allow it, though). I think they should be free to restrict this. 
Just some thoughts (biased, no doubt) from a software lawyer who also works as a venture capital advisor to the OpenView portfolio of expansion stage companies. 
Related Articles. 

Deal Architect’s POV. 

Intro to these BOR by Forrester in 2007.

You may have heard of Groupon. If you haven’t, then read about it because it is a very interesting business model. The angle for any software or SAAS company is to learn about how (from my perspective) they are using patents to beat their competitors. 

Think of it this way, their business model and site is easy to replicate because they essentially have a great idea of how to bring coupon buying to local markets. The problem is they are widely successful, and so copycats are coming into their market really fast (maybe faster than Groupon can setup local market sites). So Groupon, in essence, has a real ‘execution risk’ to their business model…this is where buying patents comes in! 

It looks like Groupon really thought ahead and bought a patent issued in 2001 that covers some of what they do today (i.e. they did not file for it, nor discover the invention). They are now using it to fight off copycat sites. Pretty smart!

So remember this: even if you don’t have a patent or you think you invented something new, talk to some patent brokers so you can possibly buy a patent that covers your technology.

It could really help you ward of competitors, especially if your business model and technology is easy to replicate = execution risk. Where do you find a patent broker? Well there are several of them, but the leader in this space in my view is Ron Epstein’s IPotential. 

So long story short, think about patents and talk to a patent attorney or broker about them because they can really help you differentiate yourself from the pack. Just a few thoughts from a venture capital advisor who works with the OpenView portfolio of expansion stage companies.

Here is a copy of the petition for you detail oriented folks. 

Ron Epstein’s Bio at IPotential

Disclaimer: This post is for informational and educational purposes only, and does not constitute legal advice. Contact your attorney for legal advice. 

How does this happen?

Well, let’s take a look at some helpful tidbits for any company looking for growth equity or a venture capital investment. 

First things first…the case: Dillards (the customer) sued i2 (later acquired by JDA Software) over a failed software and services implementation (even though Dillards still uses the software; go figure that one out). Without going into a detailed factual analysis, Dillards believed the i2 software was not working as promised and took it up with i2. Obviously, the parties could not work it out and the case went to trial in Dallas, Texas in 2010. Long story short, i2 lost and Dillards won an approximately $246 million judgment on a $10 million software and services order (yep, 24 times the amount of the sale). So how did this happen when a contract with a limitation of liability existed, and i2 had attorneys representing them on the contract? Let’s dig a little deeper and see what we can learn from a case like this. 

1) Don’t Over commit and Underperform. You probably knew this already, but if you over commit and underperform in a big way, a court could find that you committed fraud (yes the F word), which is what they found in the Dillards vs. i2 case. What did not help (and I think made all the difference), was the fact that i2 had agreed to a consent decree with the SEC stating that it had exaggerated the functionality of its products to its customers and was overstating its revenue. But it gets worse! The company i2 even hired an MIT professor of Management (not quite sure why they had to do this) to perform an assessment of their business practices. This professor wrote a scathing report stating in part that i2 was over committing and underperforming…see excerpt below.

2) If You Have a Problem, Solve It. Software is not perfect and free of flaws, but if you have a product problem (e.g. the software is not working or your sales team has oversold the technology), fix it and make it right. Every software company I make contact with knows how to solve these types of problems, so don’t forget the importance of relationships with your customers. I bet if i2 had given Dillards its money back early on in the process, seen the case for what it was or in general handled the disagreement in a fair way, they would not be facing a $240 million dollar judgment. I am not trying to second guess this case with the benefit of hindsight, but I would not have recommended going to trial on this set of facts. 

So without going on forever about this subject, my goal is not to scare you, but rather to inspire you to make sure you control your sales teams, and people at your company don’t think you can/should commit to things that don’t exist (even in the intangible world of software). Oh yea, those limitation of liabilities usually work to protect you, but not necessarily against a finding of fraud as in this case (which you may not realize is a really high bar). Just a few thoughts from an attorney who helps companies seeking growth capital prior to looking for their company exit strategy.

www.zdnet.com/blog/btl/dillards-wins-246-million-in-damages-vs-jda-i2/35888

If you have a software product or an SAAS service, you should think about whether third-parties can use or access your software, rather than granting access to only your customers (and their employees of course). A recently reported court case addressed this issue, so I thought I would share the result and some takeaways.

Without diving into the details (which I know you really would like to skip), the court held that when the customer granted access to a third-party to use the software they violated the license agreement. Oh and by the way, the third-party was even using the software for the benefit of the customer, and the court said no anyways.

So what can you learn from this case?

1) Depends on the Your Value Proposition. Some companies care whether a third-party will use or access their technology, and others really don’t.

- For example, if you measure usage on say the number of transactions, maybe you don’t care if a third-party can access it, for they will use more transactions under your customer’s account. But if you are concerned with the possibility of a customer (or the third-party) receiving significant value that you did not take into account when pricing your technology, maybe you do care. So figure it out and tell your customers if they can or can’t allow third parties to access your technology.

2) How You Do It. If you plan to allow third-parties to access or use your technology, state this specifically in your agreement. Because these third-parties by nature do not have a contract with you regarding the software. You should either (a) make your customer responsible for their actions (and omissions) or (b) require that the third-party sign some kind of use and access agreement with you and your customer (yes, a three party agreement). If you plan to disallow this access or use…most agreements do not address the issue of allowing this access or use, and state that the software or SAAS company reserves all rights not expressly granted. This should be one of the reserved rights. You could even go further and specifically prohibit it (maybe in the confidentiality section).

- By the way, you can even split ‘Access’ and ‘Use’ rights, so you may allow a third-party to ‘Access’ (i.e. view only) your software but not ‘Use’ it. In fact, in this particular case, (the one mentioned above) ‘Access’ was ok, but ‘Use’ was not.

Take a look at what your agreement states on this topic, at least before your customer does. Just a few thoughts from a software attorney who also works as a venture capital adviser to the OpenView portfolio of expansion stage companies.

Legal Disclaimer: This is for informational and educational purposes only, and does not constitute legal advice. Contact an attorney for legal advice, which should be provided after review of the facts and applicable law.

Before we get started, as you probably know, indemnities are those pesky paragraphs (near the end of the contract) lawyers seem to get caught up with.

They usually have wording similar to:

“…x will indemnity, defend and hold-harmless y from all claims, demands….”
 So let’s get started…
1) Indemnity = Insurance. As a general matter, an indemnity is the same as an insurance policy. That indemnity clause in your agreement is the same as if you were providing insurance to your customer or partner. You are providing software or a software service, so why are you writing an insurance policy too? Exactly. That is the correct way to view the situation; you are providing technology, not selling insurance.

Here are a few words from the ‘Insurance Liability Wiki.’ They also refer to insurance as an indemnity. 

2) Infringement Indemnity.  On the other hand, what is common (in this industry at least) is to provide an ‘infringement type indemnity’ (i.e. protects your customer/partner if you don’t have the necessary rights under copyright, patent, trade secret or other proprietary rights) to provide the license or access to your technology (that seems fair). I realize this may make you queasy, but it is a best practice. The technology vendor should make sure they have the necessary rights to the technology before they provide it to their customers/partners. For all other types of indemnities, you need to really think about whether you want to provide that insurance (I mean indemnity). 

3) One Size Fits All Does Not Exist. Read each indemnity closely, as it could be very broad (e.g. you see words like ‘arising out or related to’) or very narrow. Remember to talk to your attorney. Most indemnities are specifically tailored/drafted, and there are very few standard ways to draft them. 

4) 2 Ways to Pay. An indemnity generally includes two types of payment obligations (I am trying to simplify this):

(a) An indemnity where the Indemnitor (company taking the risk) hires the attorney to defend the claim, and
(b) an indemnity where the Indemnitee (company being protected) hires the attorney to defend them against the claim. The first one is a little fairer because the party footing the bill will hire the attorney after they are informed of the claim. 

The second one is a lot tougher, for the other party thinks they have a claim covered by the indemnity. They could hire their own attorney and send you the bill.
 Long story short, each indemnity is really unique and you need to read them closely, and at least understand the basics. This is one of the most complex (maybe the most complex) legal contracting issues so it is always better/advisable to have your lawyer read them. This is just a few thoughts from someone who serves as a venture capital advisor to OpenView’s portfolio of expansion stage companies. 

Disclaimer: This is provided for educational and informational purposes only, and is not legal advice. Talk to your attorney for legal advice, as they should consider the pertinent facts and applicable law before providing any advice.

Q) Who is Paying the Software Vendor? 
A1) End User – Yes for Referral Agreement

A2) Partner – Yes for OEM, Distribution and Reseller Agreements

Q) Who is Entering into the License Agreement with the End User?
A1) Software Vendor – Yes for Distribution, Reseller and Referral Agreements (i.e. license resale)

A2) Partner – Yes for OEM Agreement (i.e. sublicensing the software)
Q) Who is Distributing the Software to the End User?
A1) Software Vendor – Yes for Distributor, Reseller and Referral Agreements

A2) Partner – Yes for OEM Agreement (some Distributors do this)

Q) Who is Providing the License Keys to the End User?
A1) Software Vendor – Yes for Distributor, Reseller and Referral Agreements

A2) Partner – Yes for OEM Agreement (some Distributors do this)

This is just a simple quick checklist you can utilize to help you decide which agreement to use. I often discuss issues similar to these with the OpenView portfolio of expansion stage companies or with other companies looking for growth venture capital. 

1) Negotiate, Negotiate. Don’t forget about the dynamic of negotiation. This is not the time to simply say yes and hope this reply will somehow make it easier to close the deal (it won’t). Trust me. What to negotiate? See 2-6 below. 

2) Your Model is in Your Agreement (and not theirs). If you think about it, your end user agreement contains your model (what rights the end user receives or does not receive), what restrictions they have, warranties, transfer rights, etc.) Your pricing is based on your model. If your customer wants to significantly change the terms of your offering/model, it could/should affect the price they receive. Remember these points, for price and terms are inextricably linked. 

3) Time is of the Essence (hopefully). Is time an issue for your customer? If time is an issue (i.e. an impending event ensues), make sure you vocalize this before you agree to use their form agreement. Using the customer’s form as a starting place will too often lengthen the sales cycle, not shorten it, even though they may tell you otherwise. Instead, start with your agreement and make the changes your customer needs to it (much more efficient). 

4) Set the Right Expectations. Make sure the customer understands they can expect extensive changes to their form agreement (every customer form agreement I witnessed looks very little like the vendor’s model), as you will need to build your model into their agreement and remove the terms that affect your pricing/model. If you don’t mention this early and get their buy in to help you work through the open issues along the way, the process of using their form will likely be very long and delay the deal unnecessarily. Oh yea, try to get a business owner/decision maker separate from their legal/purchasing department to help make decisions. You don’t necessarily want the legal or purchasing departments making the important business decisions.  

5) It is All About $. It really is all about the money. If the transaction size is too small, it may lead to a waste of your time and resources to start with the customer’s form agreement (suggest that if the transaction was $x, then it would be worth using their form agreement but as it is $x-y, it is not). However, if the transaction is large, continue to read the other tips in this post, as you may be forced to start with their form agreement. Where do you draw the line as to $? This is company specific (= your decision).

6) What are Your Goals? If you use the customer’s form agreement your goal should be to culminate with an agreement that:

• does not pose any significant risk to your company (i.e. a risk you normally would not take)
• is administratively efficient (i.e. you don’t need to spend a lot of time maintaining the agreement, tracking it for compliance, looking over your shoulder, etc.)
• is consistent with your model (i.e. you can still book the revenue as you would other deals)

Keep these goals in mind or add to/change this list to fit your business model.
 
Just a few thoughts from an attorney who has negotiated hundreds of deals using the customer’s form agreement. I often discuss this topic (as one of the venture capital advisors) and others with the OpenView portfolio as part of their business growth strategies.

My tune-up ideas are: 
1) At least once a year, whenever you make a change to your model or come out with a new offering etc., think about whether you need to change/tweak your software EULA or SAAS contract. 

2) When you do take a look, think about whether you can simplify, shorten and make your agreement more transparent. That is the trend in contracting for software and SAAS, so don’t forget it. 

3) As with cars, there is no one size-fits-all tune-up (I hope you knew that), so there is no one size fits all tune-up for your agreements either. Figure out what is new or different, and fix it/improve on it. 

Just a few thoughts from a software attorney. 

My takeaways (aka my 2 cents) are:

1) Current State: Most states have not specifically addressed taxing software-as-a-service, and so you have to shoehorn it into their existing rules (i.e. it is messy and a grey area). 

2) Form of Agreement Matters: The form of agreement you use matters (is it a license agreement, subscription agreement or professional services agreement), but of course so does the substance of the services you are providing. 

3) New Federal Proposed Legislation: There is no answer yet, but there is a bill going through Congress which could help define these rules and provide specific guidance. Here is the latest on the bill (at least on one website). 

Take a read of this short Grant Thornton article, as I think they nailed the current state of confusion, and it is a must read for any SAAS company seeking growth capital (or at least by your finance leader). 

So here are some thoughts: 

1) Give it a Try. Maybe try it first for NDAs/Confidentiality Agreements, Channel Agreements, End User Agreements, Employment Agreements, and other more routine contracts (probably not the right thing for your signature when you sell your company as part of your company exit strategy).

2) Different from Clickwrap Agreements. These types of electronic or online signatures are fundamentally different from the clickwrap type agreements (press or click to Agree or Reject type contracts). These are supposed to take the place of your written signature on a written contract. 

3) Vendors Seem the Same. It looks like there are 3 main vendors, EchoSign, DocuSign and RightSignature. They all look fine/the same to me, so maybe pick the one with the (a) right workflow, (b) price point, (c) features, and (d) easiest interface. 

So give it a try, as it could help your employees become more productive while ensuring you get your contracts signed. Just a thought for any company seeking growth capital. 

So here are some thoughts: 

1) Give it a Try. Maybe try it first for NDAs/Confidentiality Agreements, Channel Agreements, End User Agreements, Employment Agreements, and other more routine contracts (probably not the right thing for your signature when you sell your company as part of your company exit strategy).

2) Different from Clickwrap Agreements. These types of electronic or online signatures are fundamentally different from the clickwrap type agreements (press or click to Agree or Reject type contracts). These are supposed to take the place of your written signature on a written contract. 

3) Vendors Seem the Same. It looks like there are 3 main vendors, EchoSign, DocuSign and RightSignature. They all look fine/the same to me, so maybe pick the one with the (a) right workflow, (b) price point, (c) features, and (d) easiest interface. 

So give it a try, as it could help your employees become more productive while ensuring you get your contracts signed. Just a thought for any company seeking growth capital. 

1) In/Out. What types of referrals will be paid, and what types won’t? Don’t forget excluding transactions that are already in flight or that don’t close within x amount of time. What about extensions to the original transaction? In my experience, most of the disputes relating to referral agreements are around this issue, so be super clear about this. 
2) Payment/Reporting. Do you want to pay on each transaction, or on a monthly/quarterly basis under a report? Also, don’t forget to address credits or returns. 
3) Simplicity/Plain English. Keep this agreement simple, and short, as you want to make sure (a) your partner understands the agreement, and (b) your internal sales/channel teams understand it too. Tell your lawyer this, as they may not be thinking about a short and simple agreement written in plain English. 

Just a few thoughts from a venture capital advisor for any software based company working on its business growth strategies. 

How to do it: bullet points, highlighting, bold, FAQs, summary headings, short sentences, plain English, colored icons….etc. 

Which policies: Privacy Policy, Customer Support Policy, HR Policies, Sales Compensation Policies…think about it, as you probably have others.
 
Just a few thoughts from a venture capital advisor to companies seeking growth capital or growth equity. This can make a difference! Just ask your customers. Who knows, maybe this can help in creating competitive advantage.

How to do it: bullet points, highlighting, bold, FAQs, summary headings, short sentences, plain English, colored icons….etc. 

Which policies: Privacy Policy, Customer Support Policy, HR Policies, Sales Compensation Policies…think about it, as you probably have others.
 
Just a few thoughts from a venture capital advisor to companies seeking growth capital or growth equity. This can make a difference! Just ask your customers. Who knows, maybe this can help in creating competitive advantage.

• How does this work? Well, when a company wants to sell a significant volume of software to the federal government, they file what is called a CSP-1 (Commercial Sales Practices Format chart). On this form the vendor describes their pricing, products, services, etc., by tier of buyers (direct, channel, etc.) and, most importantly, their discount practices. The government wants to know that no one is receiving better pricing for a similar transaction.
• The Case. What happened in the Oracle case (at least as alleged in the complaint) is that the Oracle overcharged the government by selling software to various agencies at higher prices than it was to commercial customers. A whistleblower (i.e. insider) brought the initial case under seal and the government investigated (which took a few years). By the way, the whistleblower can receive up to 30 or so percent of the award, so there is a very strong incentive to bring these type of cases.
• What could the award be? Let’s look at some similar cases. Oracle paid $98.5 million in 2006 on behalf of PeopleSoft, EMC reached a settlement to pay $87.5 million, and Net App reached a $128 million settlement in 2009. 

So what can you learn from this?
1) Commercial Practices Sales Charts are really important, and someone needs to take ownership of them (cradle to grave). I suggest 1 person should be responsible for (a) helping draft the CSP-1, (b) updating it, and (c) ensuring compliance with it. If you read the Oracle complaint, it really looks like people were confused as to what the Oracle CSP-1 covered and what was excluded.

2) You can be audited, and they will look retroactively at your transactions and discounts. Not fun.

3) Get expert help. You should work with an experienced government contracting consultant or lawyer, as this type of contracting can get very complex, very fast. Remember, we are talking about government purchasing regulations here. 

4) The federal government is getting quite acquainted with software transactions and discounting practices, so they will get better at finding violations and bringing these type of cases. 

Any company looking for growth capital or a venture capital investment should take a read, especially if you have a GSA Schedule or will have one soon. This type of compliance issue will also come up when you want to sell your company or as part of your company exit strategy, as buyers are now well aware of this risk and compliance issue (this applies whether or not you are looking for growth equity).

Resources
Here is a copy of the actual complaint filed with the court (if you have a few mins, it is worth reading)

Blog Post on the Risk and Rewards of Government Contracts 
Here is an example of a Commercial Practices Chart

Disclaimer: This post is for educational and informational purposes only, and does not constitute legal advice. Contact your attorney for specific legal advice.