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.

2 Reasons Why You Need an API License Agreement

I have been delaying writing a blog post about API licensing, as I could not find a good real world example to go along with the post. Well, Twitter just 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 below,  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 11th:

 

1) Your API Developer Use Case, Could Change. As you know, things change rapidly in the software and SAAS world. You may open up your API and then realize that you opened it up too much, and you want to restrict what your API developers are doing.

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

As most API license agreements are pretty one sided (as you are giving them something for free and it is your technology) you can change the terms at any time.  However, if you don't have an API license agreement and then change your API program, your API developers may not only  get really upset, but if they lose $ as a result of the change then you may be responding to lots of complaints and maybe a lawsuit or two (= not very fun). So think about putting an API license agreement in place, as it can protect you if things change, as it can expressly give you the right to change your API terms without any liability to you.

2) Communicate the Right Expectations to Your API Developers. As with any agreement, the API license agreement helps to communicate your model (setting expectations of what your developers can and cannot do), and most users actually want to know where the boundaries are (having a great API FAQ is a good idea too). I find that most software or SAAS companies don't know what the terms of their API license agreement should be, so they avoid the issue (remember, no decision is still a decision). Well, maybe you get lucky and you don't need to make significant changes, but I would not recommend relying on luck.

• I bet you if Twitter did not have an API license agreement with (a) limitations of liability, (b) disclaimer of warranties, (c) specific language giving them the right to change the agreement at any time, etc., they would have been sued for this recent change. The API users would have probably argued that they relied on this access without restriction and created a business around it (i.e. spend $), and now Twitter cannot make a change without compensating them for the loss.

Well, a good API license agreement can help avoid this whole argument, as it can help communicate your API development model and set the right expectations with your API developers.

Anyhow, I could go on and on with other reasons, but if you can remember that (1) things can and will change in your API model (i.e. remember that you cannot see the future), and (2) you need to set the right expectations with your API developers, then you get the 2 main reasons why you need an API license agreement.

TechCrunch Post on the Twitter API Change.

ZDNet Post on the Twitter API Change.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. Hire an attorney if you need legal advice.



Linking and the GPL (Technical and Legal Analysis)

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

(1) Derivative Work or Compilation (copyleft obligations)

• Static Linking (GPL'd code combined with your code in one executable at build time)
• Macro/Template Expansions (embedding GPL'd code into your code)

(2) Close Call (aka, it depends)

• Plug-ins (to extend functionalities of other programs)
  • depends on external factors (I added a few of my own here):
    • dependency/independency of your code;
    • communication protocols/sharing resources;
    • copying of API host code/no copying of API host code;
    • core functionality not subject to copyright/functionality subject to copyright; and
    • existence of other libraries with the same function.

(3) Independent and Separate Program (no copyleft obligations)

• Dynamic Linking (calling and using library only at run-time; (no GPL code copied, modified, translated or changed . . . I added this part from Larry Rosen's view (see below) on it))
  • remember to look at the above external factors as it could become a derivative work if the facts change
  • oh yea, I moved Dynamic Linking to this section as I think it fits in here more than Close Call
• Interprocess Communications (remote procedure calls)
• System Calls (core operating system resources)
• Interpreted Language 'Scripts' (not compiled, executed by interpreter, no third party code incorporated)

So long story short, this is an evolving issue and I don't think the definitive work has been written, but don't let that stand in your way of learning more about it. As an open source attorney and proprietary software attorney, I thought you should be aware of this, as these folks did a fantastic job with this working paper and law review article (see below).

Resources:

Working Paper on Software Interactions and the GNU Public License (July 2010)

Brian, Malcolm (2010) 'Software Interactions and the GNU Public License,' IFOSS L.Rev, 2(2), pp 165-80

Larry Rosen's view on Dynamic Linking.

Disclaimer: This post is for informational and educational purposes only, and is not legal advice. Hire an attorney if you need legal advice.

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 bound). As  I scratch my head to think about what long term commitments you could/should make, I really can't think of any. In fact, maybe that is the answer:  you should not make any really long-term commitments as that is not the model (if you do make any long term commitments, make sure you think it through as things will change). As I said above, the issue of long-term commitments comes up very frequently when licensing software in perpetuity as the customer is paying you for something (and buying something) they could use forever (they are thinking super long term).

So think short-term commitments in your SAAS contracts, and keep the flexibility in your model (to the extent you can). That is what SAAS is all about!

Resources:

Oracle's Long Term Commitment to Support Siebel Products.

Ubuntu Long Term Support Commitment

* Exception: I have seen and worked with some SAAS companies which provide really long-term solutions to their customers, so they will have to address long-term commitment issues, but the key thing is even those are not perpetual models (aka forever).

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

Q: Who Owns Your Sales Leads – You or Your Sales Rep?

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

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

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

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

2) Solution?

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

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

Resource:

Here is a recent summary of some litigation in this area. Worth a read!

Disclaimer: This is not legal advice, and no attorney client relationship is formed. It is provided for informational or educational purposes only.

Enterprise Software Agreements: How to Design Yours!

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

1) 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). If you think about it, enterprise customers want 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 software license 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.

2) Factors to Consider in Designing Your Enterprise License. The first thing I want you to think about is what does your enterprise customer need/want with your software (compared to your smaller customers). As I mentioned above most enterprise customers want (a) flexibility (the licenses are easy to manage from a password or security perspective), (b) discount and predictable pricing (if they commit to your solution company wide, they don't want you to arbitrarily increase their price), and (c) ease of administration (the agreement is easy to administer), but try to figure out if there are other or different needs/wants of your enterprise customer, as every software product's value proposition is unique. Once you have figured out what your customer is looking for, you need to figure out how to price the enterprise software license. This is not easy, but I suggest you try to ensure that you are being adequately compensated for doing these deals.

3) Example. Let's say you license your software per computer, and customers typically purchase 1-5 licenses at a time. Let's also assume that your licenses are tied to each computer via a unique password, and the licenses cannot be moved around. If a large customer wants to make a purchase and asks for an enterprise software agreement or license, what should you do? I recommend you look at the 3 factors above (flexibility, discount/predictability and ease of admin) and then make sure you are being adequately compensated for the deal.  So maybe an enterprise agreement could look like this: 50 computer licenses with open passwords (to use within their company), higher discount per copy  and fixed price for 5 years for additional copies, annual usage reporting (i.e. if they exceed their 50 licenses), and in 5 years the deal dies and reverts back to fixed computer licenses. This is simply one example, but as you can see there are several levers to pull to ensure that their needs are met but you are not being taken advantage of. I think the key here is that you don't need 5 different types of enterprise agreements, as once you figure out what it should look like you can lead with that model (of course you should consider making changes at the request of an enterprise customer and don't forget to keep improving the model as you learn more about the needs of your enterprise customer).

4) What Not to Do. I have seen some software companies simply provide a site or unlimited license as their enterprise software agreement and call it a day. Now maybe this is the right answer for your company, but I suggest you are not being adequately compensated for this type license. The problem I have with unlimited or site licenses, is how do you define the company or site? What happens when the customer is  acquired or merges with another company? You can get into some really complex drafting  what are called 'change of control clauses' to avoid this issue, but I don't think you want that level of complexity (unless the deal is really large). By the way, most large software vendors rarely license on a site or unlimited basis, and if they do it is often a term license. Here is an example of one.

So remember that when you are designing your enterprise software license agreement, you should think about the needs/wants of the customer and only then you can ensure you are being compensated for it. These enterprise agreements are really not that complex, but they do take some time to design (if you want to get them right). I really can't do this subject justice in such a short blog post, but hopefully you got the main thoughts behind designing your enterprise software agreement.

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

What You Don’t Know About “Naked Licensing” Can Hurt You!

Ok, ok this is a legal blog, so I am actually talking about naked trademark licensing issues here — a few nuggets for every software or SAAS executive to think about for their software or SAAS partner agreement, SAAS OEM agreement, etc.

"Naked Licensing" is in essence a legal defense to a trademark infringement claim, and you absolutely should be aware of it as the consequences of not knowing can be really grave (aka a big deal).

Ok did you get that part about 'abandonment of the trademark.'

Now that I got your attention, here are 3 things to remember to help avoid this.

1) Don't Let Anyone Use Your Trademarks Without a License Agreement. Hopefully I said that clearly enough, but that is the best way to avoid this bad outcome. The trademark license agreement should (at a minimum) expressly state that any use of your trademarks are subject to your trademark guidelines (i.e. supervise their use of your mark), and make sure you take steps to ensure that your trademarks are used in an appropriate manner with the associated goods or services. You can embed this language in any software or SAAS partner agreement.

2) Remember What is At Risk Here! Think about it, you develop your trademark (maybe your company name or logo) and people associate your business with that name or logo. However, if you don't take certain protective measures when allowing third-parties to use your trademarks you could abandon the mark ( = you lose it).

3) Don't Scare Me With This. Does it Really Happen? Absolutely. Here is a case from November 2010. Long story short, the owner of the trademark rights to "Freecycle" (see above) let other affiliated groups (are you seeing a connection to your business?) use their trademark without a written trademark license agreement, without exerting control over the mark and associated services, and simply said in an email " . . . just don't use it for commercial purposes." That was it. The court found that there was no written contractual control over the mark and no actual control, so the result was that the Freecycle mark has been abandoned (because of naked licensing). What that means is they could not stop a Freecycle affiliate from using the mark in any way they wanted. It does not get any more real, relevant and recent than this folks!

So every software or SAAS company out there should sit up and take notice of this issue, as I know you have trademarks (you need to review your processes for allowing partners, resellers, etc. to use your trademarks). You can easily avoid this outcome, if you understand naked licensing and take measures to avoid it (even if it is not as sexy as it sounds)!

Here is a copy of the court opinion (if you want to read the nitty gritty details).

Resources: Example of Really Good Trademark Guidelines.

Microsoft Trademark Guidelines.

Symantec Trademark Guidelines.

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

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 Things You Need in Your Open Source Policy!

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, and really hard to re-create if you have to do it years later when someone (an acquiror or the CEO) needs to know what open source code is embedded in your product.

3) Annual Review. While many people overlook this, whoever is in charge of your open source process/policy (and I suggest you have one person in charge who owns this policy), should annually review that your developers (including any developers that are actually contract developers) are aware of and follow your policy.

Look I could make this a lot more complicated, but I find that most small software companies need at least these three basics requirements and not the 25 page open source policy.

Great More Detailed Article on Developing an Open Source Policy.

Some Thoughts from a Microsoft Attorney on Creating an Open Source Policy

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 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 to agree to them); only then can you attempt to influence them.

2) Key to Successful Negotiations. Mr. Noesner suggests that it is important to figure out a person's motivation, goals and emotional needs, and then to make use of this strategically. This is relevant too, as having a deep understanding of your customer's (and the person you are working with) motivation, goals and emotional needs can really help to close the deal.

For example, maybe the company has been burned by a previous technology vendor by not appropriately supporting the product. Even if you are the best negotiator, you may not be able to get past this issue as the customer feels burned and abused by that vendor, and they don't want it to happen again. You may have to carry this burden (in some way at least) in the negotiation, and be forced to address the issue.

3) Paradox of Power. Another interesting point is that the harder you push the more resistance you will get. I totally agree with this, and you should definitely remember this in your negotiations. Negotiations are very much about education, and not simply imposing your will on the other party.

4) People Want to Work with People They Like. You probably already knew this, but take this a reminder as the person negotiating the purchase of your technology has a lot more discretion than you probably realize, and if they like you and want to work with you, your deal is much more likely to close.

5) Active Listening. If you don't know what this is, basically it is repeating back to the speaker what they have said or otherwise acknowledging their statement/concerns. Try this, as it takes practice, but really works. Here is a short article that the author wrote on Active Listening.

While software negotiations are not as emotionally charged as a crisis negotiation, it would be worth your effort to try some of these skills if you are dealing with a difficult or irrational person on the other side of the table/phone (even if they are unarmed!). Practice this beforehand though. I plan to try these skills with my kids when they take my TV remote control hostage, as that becomes a crisis negotiation at my house!

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.

 

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.

When Should a Software or SAAS Company BUY a Patent!

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 patent for any software or SAAS company.

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, talk to a patent broker as maybe you can buy a patent that covers your technology.

It could really help you ward of competitors, especially if your business model and technology are easy to replicate = execution risk. Where do you find a patent broker? Well there are several of them, but the leader in this space in my view is Ron Epstein.

So long story short, think about patents and talk to a patent attorney or broker about them, as they can really help you differentiate yourself from the pack. Just a few thoughts from a software and SAAS attorney.

Here is a copy of the petition, for you detail oriented folks.

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.

Can a Third-Party Access or Use Your Software?