March 2011

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

A recent survey of over Statistical Analysis of Trade Secret Litigation in State Courts (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.  Yep, people you know and once trusted!!  Think about that one. A really recent VentureBeat article shows that now the trend is that un-known parties are looking to steal your trade secrets.

2) What do They Usually TAKE?

1. General business information (e.g., customer lists)[litigated 70% of the time], and

…

I have been delaying writing a blog post about API license agreements, as I could not find a good real world example to go along with the post. Well, Twitter gave me that real world example, as they recently changed their API license agreement (which caused quite an uproar in the Twitter community). Take a read,  as here are 2 great reasons why software and SAAS companies with an API need an API license agreement (instead of going naked with no agreement).

For background purposes, Twitter changed their API licensing terms to further restrict how their API developers use their API (oh yea, there are over 750,000 registered apps). Twitter now wants its API developers to build “tools” . . .  not businesses or applications.

Quote from Twitter email re: their new API Rules of the Road on March in 2011:”Developers have told us that they’d like more guidance from us about the best opportunities to build on Twitter.  More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.” (emphasis added) Here is the link to the whole email.

Your API Developer Use Case, Could Change.

As you know, things change rapidly in the software and API licensing world. You may open up your AP without an API license agreement, realize that you opened it up too much, and then want to restrict what your API developers are doing.

• Twitter realized exactly this,

…

 

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

(1) Derivative Work or Compilation (copyleft obligations)

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

(2) Close Call (aka, it depends)

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

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

• Dynamic Linking (calling and using library only at run-time; (no GPL code copied, modified, translated or changed . . . I added this part from Larry Rosen’s view (see below) on it))
  • remember to look at the above external factors as it could become a derivative work if the facts change
  • oh yea, I moved Dynamic Linking to this section as I think it fits in here more than Close Call
• Interprocess

…

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

Have you thought about which parts of your SAAS customer contract commitments should be a short-term, and which parts should be long-term? Well, if you have not thought about it, then how about we do that now.

What Should/Could Be Short Term?

The key with SAAS models is that most* are not perpetual (aka forever) models (like a typical software licensing model where the customer receives a perpetual license to the software), so things are supposed to change along the way. The functionality you provide may change, along with the feature set. Oh yea, this is pretty typical and actually expected for SAAS companies, so don’t feel bad about it. So the takeaway here is to think about keeping your commitments as to functionality, features, support  and pricing short in duration (i.e. maybe a year or less and not multiple years). Why you say? Well, things could change, so be careful what you commit to for long periods of time. By the way, if you contractually commit and don’t’ perform, then that will likely turn into a ‘breach of the contract’ on your part (aka not a good thing).

• Examples of Long-Term Commitments Requested by Customers: price caps, support commitments, feature and functionality commitments, etc.

What Should/Could be Long Term?

Well in the SAAS model, I am not sure there are many long-term commitments, as the customer is receiving/buying a subscription-based offering (something that is time-bound). As  I …