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.

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

What You Should Not Do To Your Competitor (after SAP tried it and got caught).

I have been reading the pleadings in the Oracle vs. SAP case (you know the 2010 $1.3 Billion judgment case), and trying to come up with a few takeaways for every growing SAAS or software company (i.e. what you can learn from this case and how to use a software EULA). I think I have come up with the list, but before we get started here is the background (the 'really' short version).

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

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

1) Don't Download More of Their Software Than You Have License Rights To. Oracle alleged with great specificity and detail how SAP downloaded more software through its TN subsidiary than it had license rights to.  This may seem very basic, but you don't want to be in possession of more of your competitor's software than you are validly licensed for.

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

 

3) Don't Assume Your Actions are Anonymous. Oracle tracked all the TN downloads, and was able to show that before certain customers moved their support to TN they downloaded lots of software from the Oracle customer support site (much, much more than the Oracle customer was licensed for).  This made it really easy for Oracle to prove that what SAP did was wrong and in violation of their copyrights. 

BTW: The opposite is true too, so to help prevent competitors from taking your stuff:

(a) make sure your license grant and restrictions are super clear (so your competitors know what they can and cannot do with your software);

(b) have 'Terms of Use' on your support site; and

(c) track your customer's downloads of your software under support.

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

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

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

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

3 Lessons You Can Learn From SAP Being Sued Under a Software OEM Agreement

Here are 3 things every software company can learn from SAP being sued under a software OEM agreement. Without going into the nitty gritty of the details of the case, here is a summary of the facts:

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

Ok, here is what you can get out of this case.

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

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

SAP tried to argue that the customer had a perpetual license to the software and that this restriction did not apply to them. The court correctly disregarded this argument, and said the agreement is clear on this point… "the then current version of the SAP Software."   Remember, try to be clear on post termination rights in your software OEM agreements, as judges will read the agreement closely to figure out what you meant.

3) Take Ownership of Your Agreements. When you are negotiating a software OEM agreement (no matter which side you are on), dig in and don't simply outsource it to your attorneys. The details really matter, and things like what rights are being granted during term of the agreement and what rights remain after termination should be clearly described in the agreement (just like this one).   Remember to take ownership of the negotiations, as the terms of the agreement will matter . . . especially upon termination.

So next time you are on the receiving end of an software OEM agreement or the granting end, remember this blog post and don't forget to use common sense, as even in the intangible world of software you can't give someone something that you don't have!

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

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

How to Get Sued Over Your Software EULA/SAAS Contract, and Lose!

Ok as a EULA Attorney I thought that would grab your attention. Well, there is a recent court case you should be aware of where the software company lost big time (over its Software EULA (applies to SAAS Contracts too)), and now owes the customer around $240 million for a software/services deal gone bad (here is the actual response from the jury).

How does this happen? Well, let's take a look as there are some tidbits for every software or SAAS company.

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

1) Don't Overcommit and Underperform. You probably knew this already, but if you do it in a big way a court could find that you committed fraud (yes the F word), which is what they found in the Dillards vs. i2 case. What did not help–and I think swayed the jury–was the fact that i2 had agreed to a consent decree with the SEC stating that it had exaggerated the functionality of its products to its customers. But it gets worse! i2 even hired a MIT professor of Management (not quite sure why they had to do this) to perform an assessment of their business practices, as apparently something was not working right. This professor wrote a scathing report stating–in part–that i2 was over-commiting and under-performing…see excerpts below.

2) If You Have a Problem, Solve It Through Negotiation. Look software is not perfect and free of flaws (and customers know this), but if you have a product problem (e.g. the software is not working as it should or your sales team has oversold the technology), then fix it/make it right (free software, credit, extension, refund etc.). Every software company I have come into contact with knows how to solve these type of problems, and doesn't forget the importance of the relationship with the customer. I bet if i2 had given Dillards its money back early on in the process, seen the case for what it is, and handled the disagreement in some fair way, they would not be facing a $240 million dollar judgment. I realize it may seem like I am second guessing i2 with the benefit of hindsight, but come on if you have a consent decree and a report from a MIT professor about your problems, then maybe you should not be going to trial.

So without going on forever on this, my goal is not to scare you, but rather to inspire you make sure you control your sales teams, and make sure people at your company don't think that you can/should commit to things that you cannot do . . . even in the intangible world of software. Oh yea, those limitation of liabilities usually work to protect you, but not necessarily against a finding of fraud as in this case (which you may not realize, is an extremely high burden for the plaintiff to prove). Just a few thoughts from a software attorney, as this is something you should be aware of, even though it is really (actually extremely) rare.

More:

ZDNet Article

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

What Can You Learn From the Justice Department Suing Oracle?

Quick background: Oracle was sued on July 29, 2010 by the Department of Justice alleging that Oracle overcharged the government when it licensed its software.

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

So what can you learn from this?

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

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

3) Get expert help, as it is worth it. You should work with an experienced government contracting consultant or lawyer, as this type of contracting can get very complex, very fast. Remember, we are talking about government purchasing regulations here. For example, there are ways of writing these commercial practices charts where you explain what type of transactions will receive a better price than the government (yes this can be done, but you need to know how to draft these). As my good friend Robert Im reminded me–who is software government contracting attorney–writing these is more of an art than a science!

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

These 4 tips may be worth remembering as part of your SAAS contract or Software EULA negotiating practices, as it may be too late once you are audited!

Resources:

Here is the Actual Filed Complaint. Worth a read, if you have the time.

Risk and Reward GSA Schedules.

Example below of a commercial practices chart (Press It to enlarge the image)

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

Is Your Software Agreement Airtight?

I find that most clients believe that they have an airtight software agreement and their liability is limited to the contract value. Well, from the perspective of a software copyright attorney, as a general matter they are right, but of course there are exceptions (at least from the perspective of a software licensing attorney). Once of the exceptions is fraud claims.

Fraud Claims: While there are many different flavors of fraud, essentially all of them are based on some type of ‘misrepresentation.’ Under certain strong legal theories no fraud claim/damages should be allowed when there is an underlying contract, but needless to say these claims are made to try to get around the contractual limitation on liability.

SAP is learning a lot more about this issue, as they are facing a fraud claim for over $500 million arising from a $30 million software deal with Waste Management (the contractual price)…yes the claim is more than 10 times the contract value. So even though SAP negotiated their contract well and had it reviewed by their lawyers, they are facing a claim for more than 10 times the contract value. Read more here.

Q: So what can a company do to avoid these claims?

1) Get Involved Early in Customer Problems. What I mean by this, is have someone in senior management work closely with the people on the ground to ensure that this gets worked out.

2) Use your Best People. This is not the time to use junior employees or less experienced sales teams, as by their nature these type of disputes need custom solutions and out of the box thinking.

I bet you that someone high enough at SAP did not get involved early enough in this dispute, as this case could have been avoided and the customer relationship rescued. So remember, your software agreement can’t protect you from every claim, and take care of customer problems early on with your best people.

How Many Law Firms Do I Really Need?

Contrary to common perception, for privately held IT companies, one law firm for the company may not be the right fit; at least from the view of a software licensing attorney. The founders have a relationship with one law firm that usually handles all the legal issues. I have found that too often it is more economical to find specialized lawyers at small firms (they usually provide better service for smaller companies too). These firms will inherently have more reasonable hourly rates/fee structures. On the other hand, it makes a lot of sense to have a corporate lawyer from a larger firm if you are venture backed (as corporate law issues can be quite complex in those situations), but that may not be the case in other areas: for employment, trademark, copyright, patent, litigation or licensing issues. The hourly rates of some of the larger firms have increased dramatically over the last few years (in fact some attorneys bill at $1,000 an hour), but that does not necessarily hold true for smaller firms.   When thinking about rates, I have also talked to many CEOs that would not make the call to a $550 an hour attorney for advice on a potential dispute, but would probably make the call if the attorney were $200 something an hour (I suggest that not making a call to a good, reasonably priced,   lawyer for advice could be a missed opportunity to avoid a dispute).

For example in litigation matters, often the total legal fees incurred (and expected to be incurred in preparation for trial) will have a significant impact on the settlement value of the case; in other words, the lower your legal fees the better you will probably fare in any settlement negotiations (in fact, if the other side has a large law firm representing them, then that may induce productive settlement discussions early on). Also, I think that there are some really good litigators at smaller law firms that can help smaller IT companies through the litigation morass. Keep in mind too that according to a 2009 global litigation survey, companies are generally expecting an increase in litigation– with the most common types being contract and employment   (see page 12).

Remember to:

(1) get referrals, (2) interview the firms, (3) ask them about their rates, (4) search on the Internet, and (4) read what the attorney’s publish; and you don’t necessarily have to hire one law firm for all your matters.