2010

I have been tracking this case (Starwood vs. Hilton Hotels), as it has some really practical things to remember for every software or SAAS company regarding protecting their confidential and trade secret information (especially when some of your employees go to a competitor). As it was settled in December 2010, I can now (from the perspective of a software copyright attorney), give you some useful insights and takeaways.

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

Ok, so what do you need to know about protecting your confidential and trade secret information (at least from the perspective of a company that could lose its key employees to a competitor).

1) ‘Identify’ and ‘Mark’ Your Confidential and Trade Secret Information…

If you operate a software based business you are likely using some open source code in your software. There really is nothing wrong with that, as it is really common now (and probably a best practice). But what is your process to review and track this code, and the associated license terms? Well, here are 3 thoughts from a software licensing lawyer that may help.

1) Written Policy. Think through (a) what situations makes sense for your company to use open source code (maybe with functionality that is not core to your offering), and (b) what type of licenses you will allow and won’t (maybe try to avoid GPL licenses if you distribute your code to your customers). For example, you may allow licenses which only require notice (i.e. attribution) that the code is distributed with yours. Oh yea, don’t forget to write this down in a policy and let all your developers know about it.

See below for an example of attribution.

2) Tracking Process. Tracking where you use the open source code and the associated license terms is critical, and I suggest very easy to do (along the way at least). Your process could be as simple as a spreadsheet with the name of the open source code, listing of which of your products (and versions) it is included with, any requirements of that license, and a copy of the license agreement. This tracking process is super simple if you implement it along the way

…

What a FBI Hostage Negotiator Can Teach You About Software Customer Negotiations.

I read a really interesting negotiations book, and thought about a few takeaways for every software or SAAS company in their customer negotiations (maybe even as a software negotiations best practice).

Background: The book by Gary Noesner came out in September 2010 and is called Stalling for Time: My Life as an FBI Hostage Negotiator. It has all the kinds of things you would expect to find in a book written by the retired head of the FBI’s Crisis Negotiations Unit (here is a podcast on the book from NPR): stories about estranged husbands holding their wives hostage, the Branch Davidian shootout in Waco, the DC sniper incident, etc. etc. But what is really interesting, and I think useful, are some pearls of wisdom regarding dealing with irrational people and people under lots of emotional stress. So here are a few things you may be able to use in your next software or SAAS negotiations.

1) Behavioral Change Stairway. I had never heard of this concept before, but it may be useful to you. This is how it works: a) you show interest, b) you respond emphatically (which leads to rapport), and c) only then do you attempt to influence. This makes sense, as during any negotiations with a customer, you need to show interest and listen to them, and then show them you understand their concerns and issues (you don’t have …

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 …

A Software Lawyer’s Take on Forrester’s Software Licensee Bill of Rights.

As a software lawyer that represents software and SAAS companies, I thought my perspective on the Forrester Software Licensee Bill of Rights may be useful to you (this is something that may come up during your customer software negotiations). In case you missed it, this report actual came out in 2009, but you know, I missed it too.

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

(1) Choose Any Implementation Partner. While this sounds good on its face, there may be valid reasons why a software company does not want just anyone implementing their software (you know, training, expertise, know-how, confidentiality, competitive issues, etc.).
(2) Pay for Actual Usage. While this sounds good too, I think software companies should be free to determine their pricing models (plus reporting on actual usage would be really complicated/hard). Remember, that if the license is more restrictive the price for the license should/will be lower.
(3) Licensee Free to Share Modifications. As most software is not provided in source code this is not even an issue, but if it were, I can understand why a software vendor would not want this to happen (e.g. derivative works/extensions to their software could create other software products that the vendor would instead like to capitalize on . . . seems fair to me).
(4) Freely Transfer Software (regardless …

First of all, I am not a patent attorney, but I know when to strategically use them (and I stayed at a Holiday Inn last night). A recent news story got my attention, as I think it is a great example of when to buy a SaaS patent.

You may have heard of Groupon. If you haven’t, then read about it because it is a very interesting business model. But the angle for you is to learn about how (from my perspective) they are using patents to beat new startups trying to compete with them.

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

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

So remember this: if you have a real ‘execution risk’ to your business model, and even if you don’t have a patent or you are not sure you invented anything new, …

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.

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 …

This question may come from time to time as part of your SAAS contact or software EULA review or negotiations, so as a software lawyer I thought I would address it. Here goes.

If you have a software product or a SAAS service you should think about whether third-parties (you know people like in the picture to the left) you don’t have a contract with can use or access your software, or is it only accessible by your customer (and their employees of course).

A recently reported court case addressed this issue, so I thought I would share the result and provide some takeaways. Without going into the details of the case —which I know you really would like to skip–the court held that when the customer granted use to a third-party they violated the license agreement. Oh and by the way, the third-party was even using the software for the benefit of the customer, and the court even said no way.

So what can a software or SAAS company learn from this case?

1) Depends on the Your Value Prop. Some software or SAAS companies really care whether a third-party uses or accesses their technology, and others really don’t.

– For example, if you measure usage on say the # of transactions, maybe you don’t care if a third-party accesses your software (for the benefit of your customer) as they will use more transactions under your customer’s account, but if you are concerned …

While this may not be one of the most exciting topics, if you work with any type of SaaS agreement you will (or have) run into SaaS indemnity issues. I thought I would break this down into 4 basic issues you should know when your customer/partner asks you to indemnify them.

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

They usually have wording similar to:

“…x will indemnity, defend and hold-harmless y from all claims, demands….”

So let’s get started.

1) Indemnity = Insurance. As a general matter, an indemnity is the same as an insurance policy, so that indemnity clause in your agreement is as if you are writing an insurance policy for your customer/partner. You are really providing software or a software service, so why are you writing an insurance policy on top of that? Exactly. That is the way you should think about it, as you are providing technology, not selling insurance.

Here is few words from the ‘Insurance Liability Wiki.’

2) Infringement Indemnity. On the other hand, what is typical in the IT industry is to provide an ‘infringement type indemnity’ (i.e. protects your customer/partner if you don’t have the necessary rights under copyright, patent, or trade secret law) to provide the license or access to your technology (that seems fair). I realize that this may make you queazy, but …

I often get the question of which type of SaaS distribution agreement do I need (i.e.SaaS reseller agreement, SaaS distributer agreement, SaaS referral agreement or SaaS oem agreement). While these agreements could be structured differently, here are some good general rules (i.e. 80% true).

Q1) Who is Paying the Vendor?

A1) End User – Yes for Referral Agreement

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

Q2) Who is Entering into the Agreement with the End User?

A1) Vendor – Yes for Distribution, Reseller and Referral Agreements (i.e. license resale)

A2) Partner – Yes for OEM Agreement (i.e. sublicensing)

Q3) Who is Provisioning/Configuring the Service for the End User?

A1) Vendor – Yes for Distributor, Reseller and Referral Agreements

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

This is just a simple quick checklist when you are deciding which agreement to start from. Give it a try and see what you come up with.

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

Let me frame this right. When you are selling to an end user, they sometimes say/insist/require that you use their form of agreement as part of the Software agreement negotiations or SAAS agreement negotiations. So what do you do?

1) Negotiate, Negotiate.

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

2) Price and Terms are Linked.

If you think about it, your end user agreement contains your model (what rights the end user receives (and doesn’t get), what restrictions they have, warranties, transfer rights, etc.) and your pricing is based on your model. If your customer wants to significantly change the terms of your offering/model, then this could/should affect the price they receive. Remember this, as price and terms are inextricably linked.

3) Time is of the Essence (hopefully).

Is time an issue for them? If time is an issue (i.e. there is an impending event), then make sure you bring this up before you agree to use their form agreement, as I have found that using the customer’s form as a starting place will too often lengthen the sales cycle (not shorten it, even though they may tell you it will). Instead, try to start with your agreement, and make the changes that your customer needs to that agreement (much more efficient).

4) Set the Right

…

Have You Had Your Software EULA/SaaS Contract TUNEUP for 2010?

You know, adjust your contracts to improve their performance…just like your car. Ok, let me explain. Every software or SAAS based business should take a look at their Software EULA or SAAS Contract each year to see if they are 100% consistent with their current model, pricing, go-to-market strategy, etc., as too often this is forgotten or last on the list. Look I know legal issues and contracts are not top-of-the-mind for most executives, but don’t over look it.

My TuneUp ideas are:

1) At least once a year, whenever you make a change to your model, or come out with a new offering etc., think about whether you need to change/tweak your Software EULA or SAAS contract.

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

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

Just a few thoughts from a software attorney.

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

I was presenting at the OpenView CFO Forum in Boston (on SAAS contracts) last week to their portfolio companies, and at the conference I learned quite a lot from the Grant Thornton tax presenters about the current state of confusion of the applicability of SAAS sales tax. GT wrote a short article on it, so I thought it was worth sharing on my blog, as their article was on point and timely (plus I thought I would provide my 2 cents worth).

My takeaways from the article are:

1) Current State: Most states have not specifically addressed taxation of software-as-a-service transactions, and so you have to shoehorn it into their existing rules (i.e. it is messy and a grey area).  You understand, as your hosting company is in x state, you are in y state and your customer is in z state.

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

3) Proposed Federal Legislation: There is no answer yet, but there is a bill going through Congress which could help provide some clarity and predictability on taxation of SAAS. Here is the latest on the bill (at least on one website).

Take a read of the short Grant Thornton article, as I think they nailed the current state of things–even if there is no clear …

So what is up with signing contracts online? Well, what is up is that it is becoming mainstream really fast, and is a great way to speed up the process of having written contracts signed (e.g. your SaaC contract template). You can now skip the faxes going back and forth, mailing of SaaS contract template for signature in duplicate, etc.

So here are some thoughts:

1) Give it a Try. Maybe try it first for NDAs/Confidentiality Agreements, Reseller Agreements, EULA, Employment Agreements, and other more routine contracts (probably not the right thing for your signature when you sell your company).

2) Different from Clickwrap Agreements. These type of electronic or online signatures are fundamentally different from the online or electronic clickwrap type agreements (you know, the click to agree agreements we all agree to). These online signatures are supposed to take the place of your written signature on a written contract.

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

So give it a try, as it could help your employees become more productive while ensuring you get your contracts signed. Just a thought from a software attorney on how to become more efficient in getting your SaaS contract templates signed. .

Disclaimer: This is provided for …

While there are many different issues to include in a software or software services referral agreement (SAAS referral agreement), here are a few practical things to consider:

1) What is In and Out. What types of referrals will  you pay on, and what types won’t you? Don’t forget excluding transactions that are already in flight or that don’t close within x amount of time. What about extensions of the transaction? Be super clear on all these issues, as this is the key part of the agreement (quite frankly most of the disputes I see are related to these issue).

2) Payment/Reporting.  Do you want to pay after each transaction, or on a monthly/quarterly basis under a report? Also, don’t forget to address credits and returns, and that you have to be paid first (before you pay them).

3) Simplicity/Plain English. Keep this agreement simple, and short, as you want to make sure (a) your partner understands the agreement, and (b) your internal sales/channel teams understand it too. Any confusion between these two groups on referrals could create a lot of disagreements.

Just a few thoughts from a software attorney.

 

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

Why aren’t your policies written so they can be easily consumed by your customers and employees?  Look, if Google, one of the largest and most sophisticated technology companies in the world can simplify their policies (in this case their Privacy Policy) then why can’t you (see this post by their Associate General Counsel regarding updating their Privacy Policy and Making it Simpler).  Yes you read it right, Google’s lawyers are trying to make their Privacy Policy easy to read, transparent and simple.

So let’s brainstorm.

What policies can you simplify today? Privacy Policy, Customer Support Policy, Licensing Policies, HR Policies, Sales Policies……keep thinking of more as you probably have others.

The key thing to remember is it can be done, but you have to ask for it (maybe demand it) from your attorneys (it does not come naturally to most attorneys) or whoever is drafting these polices.

Think…. bullet points, highlighting, short sentences, bold, plain English, Icons, FAQ,  etc. (Google did).

The big guys are doing this and maybe you should too!

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

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 …

Why EDUCATION is So Important to Software Negotiations or SaaS Negotiations

Think about it. One of the most important things to remember — maybe the most important thing — is that it is really important to educate your customer, partner, etc. about your Software or SAAS model when negotiating the software eula or SAAS contract (i.e. Software negotiations or SAAS negotiations).  This is important as with all IT based contracts the buyer needs to know what they are buying, as they are purchasing an ‘intangible’ item. As they can’t touch or feel it, it is incumbent on the seller to educate the buyer about  what they are selling, what the customer can expect, how it is paid for, how additional usage will be measured and paid for, etc.) as part of the contract negotiations.

So how do you do this?

• Put together a ‘simple’ document explaining your pricing and its methodology (or maybe a FAQ page), and put it up on the web (don’t forget to send this link to the person that is reviewing the Software EULA or SAAS contract).  This summary must me simple, and does not necessarily need to be very long or detailed (think bullet points, and short sentences).
• Be transparent and clear (this is not the time to hide anything).
• Educate not only the user of the technology, but also the person that is reviewing the contract (sometimes it is the same person, but not always).
• Make sure your Software EULA or

…

What Does a Software/SaaS Company Need to Know About the Creative Commons License Program?

Any software or SAAS executive should learn about this, even if this does not affect their software EULA or SAAS contract. This is just one of those things to be aware of, because it is a big deal in the licensing of copyrighted material. So what do you need to know about this?

• What is the Creative Commons License Program. It is a new way to license copyrighted material, as essentially there is so much confusion out there regarding what people can and cannot do with content, images, music, etc (especially on the Internet). The fundamental idea is to try to find a more efficient way (trying to take out the intermediaries) to allow people to use copyrighted material through the use of icons/badges, a legal license and embedded code, and to move away from the concept of ‘All Rights Reserved’ to ‘Some Rights Reserved.’ More info here.

• How Does it Work? The creative commons is a non-profit organization that promotes the use of their free tools to allow people to license their copyrighted material in a much easier way (but it does not work for everything and every scenario).

• What Do I Need to Know About This?
  • First, the Creative Commons License Program should NOT be used to license software (they actually say this, so don’t take my word for it (see about 1/3 down this page)).
  • Second, I also

…

A Software Lawyer’s Take on the Linux Foundation’s ‘NEW’ Open Compliance Program

On August 10, 2010 the Linux Foundation announced the Open Compliance Plan. So what is this all about and is this bad or good?

Essentially, the Linux Foundation created this program to address a lot of the FUD relating to using open source software with proprietary software. I think this is a noble objective, as there definitely is quite a lot of that FUD out there. So what are the components of the program (from the perspective of a of proprietary Software or SAAS company).

1) TOOLS

[Note to Self: need to check what OS these run on, as it may not be that useful for us]

• Dependency Checker – checks for dynamic and static links.
• Code Janitor – scans for certain keyword before the code is released.
• Bill of Material Difference Checker – provides the ability to more accurately track components of the software.

2) SELF-ASSESSMENT CHECKER 

• Here is the checklist. 

3) SOFTWARE PACKAGE DATA EXCHANGE (SPDX).

[Note to Self: While this sounds good on its face, it sounds like they are trying to lead the industry into disclosing all embedded open source software to (a) customers and (b) partners, etc. in the form of the Bill of Material  (not sure this is a good thing or even necessary; sounds like it will mainly add complexity and delay (at least in certain situations))]

• Black Duck Software is deeply involved in this Working

…