So, 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 They Did It.

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 want to know about.

1.     Know that the vendor knows when a site has performance issues,

2.     Know that the vendor is working to resolve the issue, and

3.     Some type of notification 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 why customers should trust you with their important data. Yep, that is the way your customers look at it, so you better start thinking about it that way.

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, as you should figure out what key metrics your customers want to see.

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

So are you selling trust or SaaS? Well as I said, a little of both.

Resources.

Marketo Trust Site                          Dell Boomi Trust Site               AtTask Trust Site                           

CentralDesktop Status Site             Ariba’s Trust Site                      Clio’s Trust Site

Act On’s Trust Site

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 post Are you Selling Trust or SaaS/PaaS? appeared first on SaaS Agreement - Software as a Service Agreement.

Microsoft drafted their new Windows 8 EULA 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).

The New EULA Structure. It has 3 sections: (1) FAQ, (2) Additional Terms and (3) Limited Warranty. Now you may say that is not a big deal, well actually it is a big deal. 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, as 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 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 them 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, 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.

The post Microsoft Finally got it Right. They Created a Plain English EULA! appeared first on SaaS Agreement - Software as a Service Agreement.

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

Background: A startup 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 3 takeaways, as something good has got to come from this case.

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

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

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

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

• Disclose only 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.

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.

The post The $27 million SaaS NDA appeared first on SaaS Agreement - Software as a Service Agreement.

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

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

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

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

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 you to get a better understanding of what your 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 figured out.

Jeremy Aber & Ken Sidelinger

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 post What Does Your SaaS Agreement Liability Model Look Like? appeared first on SaaS Agreement - Software as a Service Agreement.

Ok, let me explain what I mean.

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

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

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

3) What Happens When They Are Linked. When price and terms are linked, the customer is more likely to have the real discussion of what its needs are. Why would this be the case? Well, if a customer wants a specific term in a SaaS agreement and 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 will pay for it. So what is going on here is the parties are having a real discussion of the issues and not a made up set of terms the customer wants simply to get an advantage in the SaaS agreement (i.e. one-sided customer favorable agreement).

Do customers really think this way, well 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 in your SaaS agreement negotiations. If you don’t believe me, give it a try and see what happens.

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 2 year commitment to our SaaS service to give you that kind of price.”

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

Resources:

• ICN – a group that is educating purchasing departments on how to negotiate software deals. 

The post Did You Know That Price and Terms are Linked? appeared first on SaaS Agreement - Software as a Service Agreement.

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

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

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

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

3) General Warnings Work (think about it this way, you may not be able to make the law, but if you warn a customer of a risk (in this case to backup its data) courts are going to give you credit for that effort)). 

So whether you are drafting a EULA or a cloud services agreement—or 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 to think about or discuss, these things do happen in the real world and (as you know) no software is perfect. I am happy to report that the Utah Supreme Court got it right in this case.

Resources: 

Copy of the Utah Case

Another Data Loss Case from 1991

The post Tell Your Customer to Backup Its Data (so Says the Utah Supreme Court) appeared first on SaaS Agreement - Software as a Service Agreement.

Ok, I need to define a term first.

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

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

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

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

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

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

Now this seems reasonable on its face, as if the invoice is incorrect the customer should not have to pay (who could disagree with this). But, what happens if the invoice is correct, and the customer does not pay and disputes it for no legally justifiable reason. So if this occurs, how do you go in front of a court and say I need to terminate the service as the customer has not paid. This sounds to me like the kind of uncertainty and ambiguity you don’t want to deal with in your cloud services agreement.

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 post What You Don’t Want in Your Cloud Services Agreement. appeared first on SaaS Agreement - Software as a Service Agreement.

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

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

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

3) Avoid Breach of Contract. You want to be careful about what obligations you take on, as you don’t want to find yourself in breach of the agreement.  Try to only commit to obligations that are ‘in your control’ or you ‘can influence the outcome of.’  Why does it matter? Well, you generally (except for indemnities) don’t have liability under an agreement unless you are in breach. So in general you don’t want to over commit and under deliver (in fact you want to do the opposite).  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 in there). For example, obligating yourself in your cloud services agreement to return the customer data is usually an easy obligation/commitment to take on.

Do you want a recent example of a clear and transparent cloud services 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, which should be provided only after review of all relevant facts and applicable law.

The post 3 Things to Consider When Drafting Your Cloud Services Agreement appeared first on SaaS Agreement - Software as a Service Agreement.

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

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

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

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

The post I Have Seen the Future, and It Is ‘Privacy by Design’ appeared first on SaaS Agreement - Software as a Service Agreement.

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

Here are a few key things to think about:

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

The main factors are:

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

If there is a PE, then

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

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

Few things.

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

If you look at the history, most tax regimes were originally setup to tax tangible goods (i.e. not software or software services) so trying to fit SaaS 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. 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.

The post Tax on International SaaS Transactions: 2 Things to Remember appeared first on SaaS Agreement - Software as a Service Agreement.

1) Who is really at fault here: CarrierIQ 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 if 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 CarrierIQ’) and CBS News (‘Carrier IQ wrongly accused of keylogging?’) seem to be taking this view too.

2) What does the indemnity say between CarrierIQ 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. 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 CarrierIQ signed an indemnity (which is in essence an insurance policy) in which they indemnified the carrier regarding ‘their use of the software,‘ ‘arising out of CarrierIQ’s performance,‘ etc then CarrierIQ has a huge problem. CarrierIQ could be on the hook for millions of dollars in legal fees and fines/judgments/settlement amounts, when (based on what we know as of now) they may not be the ones that really caused this 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.

You think this is not serious business, well read the top of a recent complaint filed in court on Dec 2nd.

So we will see how this plays out, but at least I am looking out for you and thinking about some good things to learn from this mess.

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 post 2 Takeways From the CarrierIQ Situation, from a SaaS Attorney appeared first on SaaS Agreement - Software as a Service Agreement.

This is a pretty fundamental concept in any software negotiation, so this is 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 in software or SaaS negotiation 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 your next software or SaaS agreement, 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 yea, don’t forget to actually read the book, as to 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.

The post Software Negotiations: Do You Know How to Say NO? appeared first on SaaS Agreement - Software as a Service Agreement.

Ok, if you have not heard of Kevin Mitnick and you are in the software industry, then he is someone you need to know about. He is probably the most notorious hacker in US history, and he released his new book Ghost in the Wires (A 5 Star Rated Book on Amazon.com) a few months ago.

So here are some takeaways from the perspective of a software attorney that only represents Software, SaaS and IT services companies.

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 that he describes how he moved effortlessly in and out of a tech company’s systems, steals source code, gains direct access to deverlopers, is nothing short of amazing. Without getting a real gut feel for this by reading the book, the importance of this book will be missed.

2) The Weakest Link in Your Security.  Kevin Mitnick coined a 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 any 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, and

(c) and developers.

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

Look I am a software attorney and not an IT security expert, but what is very clear to me is 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 by writing this book. 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. 

The post A Take on Kevin Mitnick’s New Book (from a Software Attorney) appeared first on SaaS Agreement - Software as a Service Agreement.

Ok, let me see if I can explain this issue a little better.

• 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 did a great job of addressing this, 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  addressed this issues in her post (with a useful chart AND the license wording).

2)  An Internal Use License is Not Enough. The key here is you need the specific right to use the third party software offsite, and 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 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 things you should think about, when you need to use 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. 

The post Third Party Demo and Test Licensing: What You Need to Know! appeared first on SaaS Agreement - Software as a Service Agreement.

Not sure if you missed it, but a site was launched called ApplicationPrivacy.org. What is the big deal? Well, this project/site is devoted to educating app developers on application privacy issues (a worthy goal). So as a SaaS Attorney, I thought I would share my thoughts on this site/project, as there are some great takeaways for every company working on app security and privacy.

1) Great Resources. This site looks like a great place to keep track of best practices in developing secure applications, etc., as 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 see where you are in the privacy maturity model. While the assessment tool is based on a Canadain model, it looks really useful to me. 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, as 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, etc.

3) Privacy Policy Generators. This is worth a look, as 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, as there is something there for everyone that is thinking about application privacy. As a SaaS attorney 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.

The post SaaS Attorney’s Take on ApplicationPrivacy.org appeared first on SaaS Agreement - Software as a Service Agreement.

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

Key Takeways: 

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 (ie. reproduce, distribute, create derivative works, publicly display and perform, etc.) and these rights need to be used or refered to in the license grant, to seek protection under the copright act.

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

• This actually happended 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, as 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 (example, US only), fields of use (example, for only the insurance industry), or media (example, 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, as how the exclusive license grant is drafted really matters.

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.

The post 3 Things You Need to Know About Exclusive Software Licensing appeared first on SaaS Agreement - Software as a Service Agreement.

 You may have already heard of this open source license, but if not, here are a few things every SaaS company needs to know about the Afferro GPL or AGPL (at least from the perspective of an open source attorney).

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 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:

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

The post AGPL and what EVERY SaaS Company Should Know About It? appeared first on SaaS Agreement - Software as a Service Agreement.

As you know, software license agreements contain restrictions (= things you cannot do with the software). As a software license attorney, I would say that these are examples of the most common restrictions (e.g. (1)  don’t reverse engineer or decompile the software and (2)  don’t let a third-party use the software). However, I would also say that there are unique restrictions out there too. Two very recent big name court cases demonstrate that even the unique restrictions are usually enforceable; let’s take a quick look.

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 (that is the stuff I do as a software licensing attorney), 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. Court 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 $ 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 Takeway

• If you are licensing your software and you need ‘unique restrictions’  in order to protect your software, then think about adding those restrictions to your software license agreement. 

Q: Are software license restrictions always enforceable?

A: Actually no (for example clauses that prohibit customers from publishing benchmark tests may or may not be enforceable. Here is an article about it.)

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 post Software Licensing Attorney’s View on License Agreement ‘Restrictions.’ appeared first on SaaS Agreement - Software as a Service Agreement.

The Federal Trade Commission (aka FTC) has a rule called the Negative Option Rule, which I really think every SaaS and software company should know about. 

The definition.

Negative Option means – when someone ‘fails to act’ (= silence) 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!)

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.

The post FTC’s Negative Option Rule & Online Offers-Renewals. What You Should Know! appeared first on SaaS Agreement - Software as a Service Agreement.

The simple answer is no, don’t do it. Ok, let me explain.

Background: Where is this whole idea even coming from in the SaaS law or software law regime? 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 should become part of the final contract. Well, I think that is a really bad idea, and here are 3 reasons why.

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 type 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 that 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, as 1) that was not the purpose you wrote it for, 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). This is SaaS Law you need to be aware of.

Resources

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.

The post RFP Responses Included in SaaS Contracts. WHAT? appeared first on SaaS Agreement - Software as a Service Agreement.

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 a software licensing lawyer, I am always looking for cases like this for you). 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 have 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 a 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, and 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.

The post Can an IM Conversation Change a Written Contract? appeared first on SaaS Agreement - Software as a Service Agreement.

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 SAAS privacy or software privacy tips here, 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, as unless you are a super large company this mis-communication 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).

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. 

The post 3 ‘PRIVACY’ Takeaways from the Google Buzz FTC Settlement in March 2011 appeared first on SaaS Agreement - Software as a Service Agreement.

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. 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 is 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 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–this is the place to go to get trained on how to negotiate.

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.

The post Where to Go For Software Negotiation Training? appeared first on SaaS Agreement - Software as a Service Agreement.

A recent survey of over 358 reported trade secret cases (from 1995-2009) has some great nuggets for every software or SAAS company looking to protect its SAAS trade secrets and software trade secrets (something you should be doing, by the way). Without going into the legal nitty gritty (which I know you want me to skip), here are 3 takeways (after I define ‘trade secret’).

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, as 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. 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.

The post 3 Things You Must Learn From a Survey of 358 Trade Secret Cases appeared first on SaaS Agreement - Software as a Service Agreement.

I have been delaying writing a blog post about API license agreements, as I could not find a good real world example to go along with the post. Well, Twitter gave me that real world example, as they recently changed their API license agreement (which caused quite an uproar in the Twitter community). Take a read,  as here are 2 great reasons why software and SAAS companies with an API need an API license agreement (instead of going naked with no agreement).

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 in 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.

Your API Developer Use Case, Could Change.

As you know, things change rapidly in the software and API licensing world. You may open up your AP without an API license agreement, realize that you opened it up too much, and then want to restrict what your API developers are doing.

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

As most API license agreements are pretty one sided (as 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 change your API program, your API developers may not only  get really upset, but if they lose $ as a result of the change then 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 protect you (limit your liability, etc)  if things change.

Communicate the Right Expectations to Your API Developers.

As with any agreement, an API license agreement helps to communicate your model (setting expectations of what your developers can and cannot do). I bet you will also find that most users actually want to know where the boundaries are (publishing great info on your APIs is a good idea too). I find that most software 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. spend $), 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.

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.

The post 2 Reasons Why You Need an API License Agreement appeared first on SaaS Agreement - Software as a Service Agreement.

I finally found a really useful working paper and law review article written by some European open source attorneys and the Free Software Foundation Europe on linking issues and the GPL license. I thought I would share some of the highlights with you as it is really hard to get some good practical guidance on open source legal issues. As a bonus, this perspective tries to marry the legal analysis with the technical analysis. Take a read!

(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).

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.

The post Linking and the GPL (Technical and Legal Analysis) appeared first on SaaS Agreement - Software as a Service Agreement.

Have you thought about which parts of your SAAS customer contract commitments should be a short-term, and which parts should be long-term? Well, if you have not thought about it, then how about we do that now.

What Should/Could Be Short Term?

The key with SAAS models is that most* are not perpetual (aka forever) models (like a typical software licensing model where the customer receives 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. So the takeaway here is to think about keeping your commitments as to functionality, features, support  and pricing short in duration (i.e. maybe a year or less and not multiple years). Why you say? Well, things could change, so be careful what you commit to for long periods of time. By the way, if you contractually commit and don't' perform, then that will likely turn into a 'breach of the contract' on your part (aka not a good thing).

• 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 there are many really long-term commitments, 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 as 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!

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, but the key thing is even those are not perpetual models (aka forever).

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

The post Should I Make SHORT-Term or LONG-Term Commitments to My SaaS Customers? appeared first on SaaS Agreement - Software as a Service Agreement.

Hey this used to be an easy answer (you owned them and you had possession of them), but these days of LinkedIn, Twitter, Facebook, etc., it is not so simple. Here are some thoughts on this software sales compensation issue.

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

Old days = CRM (internal) software and a Rolodex (internal, but portable) (yep business cards are not dead)

Now = CRM (internal), Rolodex (internal, but portable) and LinkedIn, Twitter, Facebook, etc. (external)

2) Solution?

• Create  a Policy To Address It
  • Clarify that sales contacts whether stored internally or externally are the property of the company
  • Clarify that this applies to social media accounts (such as LinkedIn, Twitter and Facebook)
  • Add other clauses to address this issue the way you want to address it (your company may want to deal with this differently)
    • FYI: some companies even prohibit employees from connecting with sales leads and sales contacts (i.e. they cannot accept the invitations) via social media. In other words, the sales reps have to reply that they cannot connect. Sounds tough, but it is true.
• Address it in Your Employment Agreements
  • Same as above
  • Also prohibit sales reps from soliciting the leads after they leave (it may be hard to police though)
  • Non-competes in employment agreements may be more important now, as the worst case scenario is if a sales rep goes to a competitor with all the leads and sales contacts.

At the end of the day, technology and the law don't work so well in this situation. I think the problem now is that getting leads and staying in contact has become an external social process.  This post is not the definitive dissertation on this issue (as this is an evolving issue), but I suggest you think about this in advance, as after the fact you may be dealing with a situation where a sales rep takes or things he/she can take all their leads with them (as they are stored externally).

Resource:

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.

The post Q: Who Owns Your Sales Leads – You or Your Sales Rep? appeared first on SaaS Agreement - Software as a Service Agreement.

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 looking for an enterprise license agreement). If you think about it, enterprise customers want an agreement with 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 license agreement can mean many different things to different software companies and enterprise customers, but 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 (I think that is simply a pricing agreement though), but the key here is to figure out what your enterprise customers need or want.

Factors to Consider in Designing Your Enterprise License Agreement.

The first thing I want you to think about is what does your enterprise customer need/want 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),

but try to figure out if there are other or different needs/wants of your enterprise customer, as every software product’s value proposition is unique. Once you have figured out what your customer is looking for, you need to figure out how to price the enterprise license. This is not easy, but I suggest you try to ensure that you are being adequately compensated for doing these deals.

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 the licenses cannot be moved around. If a large customer wants to make a purchase and asks for an enterprise license agreement, 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 being adequately compensated for the deal.  So maybe an enterprise license 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 a fixed computer license. This is simply one example, but as you can see there are several levers to pull to ensure that their needs are met but you are not being taken advantage of. I think the key here is that you don’t need 5 different types of enterprise license agreements, as 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).

What NOT to Do.

I have seen some software companies simply provide a site or unlimited licenseas their enterprise license agreement and call it a day. Now maybe this is the right answer for your company, but I suggest you are not being adequately compensated for this type 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  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 license agreement, you should think about the needs/wants of the customer and only then you can ensure you are being 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 license agreement.

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

The post Enterprise License Agreements: How to Design Yours! appeared first on SaaS Agreement - Software as a Service Agreement.

1) Retain Ownership of 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 can be returned to the customer.  Oh yea, there is already litigation on this issue, so this is an important issue! Recent Case (see page 4). (Address in Cloud Agreement)

2) Service Level Agreement. This one too is nothing new, as service level agreements have been around forever. 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 (but let’s add material or significant) change to their service (i.e. ones that would impact their customer or that 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 thing, so it does not need to be in the cloud agreement. (Address via Communication)

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

5) Understand the Legal Requirements of Jurisdictions Where 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. (Address via Policy Statement)

7) Understand and Adhere to Software License Requirements. The issue here is that software vendors should communicate if they allow their customer’s to move their licenses from an on-premise license to the cloud. I find that 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. (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.

Resources (lot’s of these Bill of Rights things out there!):

CNET Cloud Computing Bill of Rights.

Altimeter’s: SAAS Bill of Rights.

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

The post Gartner Wrote It (About the Cloud), But Here is a Software Attorney’s Take. appeared first on SaaS Agreement - Software as a Service Agreement.