Tel 800.661.2530

2 Takeways From the CarrierIQ Situation, from a SaaS Attorney

Ok this CarrierIQ situation is really crazy, but there are some things (from a SaaS Attorney’s perspective) that every software or SaaS company should think about.

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.

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.

Software Negotiations: Do You Know How to Say NO?

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,

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).
Express your 'Yes' and then deploy your 'No.'
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).

"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')).
"So we cannot give you the discount you asked for" (that was your 'No').
"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.

A Take on Kevin Mitnick’s New Book (from a Software Attorney)

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

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.

Third Party Demo and Test Licensing: What You Need to Know!

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.

SaaS Attorney’s Take on ApplicationPrivacy.org

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. 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, 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. I did, and I learned something.

3 Things You Need to Know About Exclusive Software Licensing

It is not often that there is a reported case specifically addressing exclusive software licensing, so I thought I would share 3 takeaways from this 2011 case (HyperQuest vs N'Site Solutions).

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.

AGPL and what EVERY SaaS Company Should Know About It?

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

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

There is a new Section 13 of the AGPL:

section 13 e1309814706365 AGPL and what EVERY SaaS Company Should Know About It?

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:

Restrictions in License Agreements: Do They Really Work?

As you know, software license agreements contain restrictions (i.e. things you cannot do with the software). Some of them are pretty common (e.g. don't reverse engineer or decompile the software or don't let a third-party use the software) but others are pretty unique. 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 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. 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 Takeways

If you are licensing your software and there are unique restrictions you need to protect your software, then think about adding those restrictions to your software license agreement.
Be careful with restrictions or capacity limitations in software you license, as courts sure seem to be enforcing them.

FTC’s Negative Option Rule & Online Offers-Renewals. What You Should Know!

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

RFP Responses Included in SaaS Contracts. WHAT?

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

Puffery as a Defense to a Lawsuit.

Another Puffery Article.

Can an IM Conversation Change a Written Contract?

The answer is, yes.

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?

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

Interview with a SAAS/Software Finance Co. (Not VC or Angel)

I had a call the other day with Tim Johnson of Sand Hill Finance, and thought you should know about these folks. Their offering is quite unique in the SAAS and software world. Here is an excerpt from our conversation:

Me: "What do you guys do, because I am not sure I get it?"

Tim: "Sand Hill Finance provides revenue-stage software companies with NON-DILUTIVE growth capital for SAAS, traditional license models or cloud companies."

Me: "What is a typical driver for a SAAS or software company using your services?"

Tim: "Software firms that require capital to meet milestones or increase valuation PRIOR to an equity round."

Me: "What is the profile of a company that could use your service?"

Tim: "A company that has a strong sales pipeline, but insufficient cash to execute. Typically, these companies are 'not quite bank fundable'."

Me: Why did you start this business?

Tim: "As a former turnaround CEO and VC, I saw the need for a NON-DILUTIVE, simple capital solution for growing software firms. Sand Hill Finance provides a unique solution, with funding within 1-2 weeks."

Note to Self: Maybe these folks can finance that 6 figure contract I just received, where the customer is paying over 3 years for my SAAS solution!

So there you have it. This company has a super unique service, and this is something that you should be aware in the SAAS and software world, as you or your friends in the industry may need it.

Resources:

Site: www.sandhillfinance.com

FAQ: http://www.sandhillfinance.com/faq.htm

Contact: Tim Johnson – email: tim@sandhillfinance.com

3 ‘PRIVACY’ Takeaways from the Google Buzz FTC Settlement in March 2011

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 Releas e

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.

Where to Go For Software Negotiation Training?

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.