2011

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 (

…

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 …

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 …

 

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 …

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).   Wouldn’t it be great if there was one assessment and it said in the assessment that this issue is a HIPAA 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 …

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 …

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

…

Software Licensing Attorney’s View on License Agreement ‘Restrictions.’

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 …

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, …

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 …

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?

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

…

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 …

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 …

3 Things You Must Learn From a Survey of 358 Trade Secret Cases

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 VentureBeat 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%

…

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,

…

 

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

…

Should I Make SHORT-Term or LONG-Term Commitments to My SaaS Customers?

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 …

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.

…

This is an issue near and dear to me, as I have spent a large part of my career drafting and negotiating enterprise license agreement. However, what I have found is that many growing software companies are trying to figure out how to design their enterprise license agreement, so some thoughts on it would/should be helpful.

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

…

Gartner Wrote It (About the Cloud), But Here is a Software Attorney’s Take.

Gartner wrote this interesting piece recently called the “Rights and Responsibilities for Consumers of Cloud Computing Services” and published it in the Cloudbook. It is worth a read, and I also have added some of my insights on how and where to address the issues (what should be in the cloud agreement/cloud contract and what is more of a policy statement/communication issue).

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…