Category Archives: Negotiations

APIs, Trade Secrets and Law Suits: one of these things is best avoided

June 1, 2012 – 5:03 pm

The Takeaway

If you want your code to be protected by trade secret law, keep it a secret.  There are times when you need to share ideas and design with third parties in order to integrate your systems, look to a strong contract to protect your ideas because the more you give away voluntarily, the weaker your trade secret claim becomes.

The Need

It’s obvious that when my software integrates with your software our customer can get functionality and ease of use that neither package could deliver on it’s own.  So there are good reasons for developers to work with other developers to integrate their software and even go out to market together with powerful, feature-rich packages rather than trying to sell more limited stand-alone systems.  But sometimes arguments flare-up when the integration and subsequent sales pipeline don’t materialize as planned.  In particular, what happens when your partner ends the agreement and goes out to market with someone else or with a product that has some of the functions that you were providing?

This gets very messy even when your integration is handled through an API (Application Programming Interface).  Fundamentally the problem is that in order for two systems to work together, one of them has to know something about the other.   And once you start talking about how your system works, once you open up and let someone take a peek, even if it is at the top-most layer, they begin to learn about how you have done things and how your system works.  If they gain that knowledge properly, if you freely give it up, then your ability to protect that knowledge rights gets weaker and your risk increases.

A case in California that was decided last year points out some of the issues you need to look out for.  In Agency Solutions.com LLC v. TriZetto Group, Inc., Agency Solutions claimed that in the process of integrating the Agency Solutions and TriZetto products, TriZetto had learned trade secrets from Agency Solutions and had incorporated those trade secrets into 8 integrated functions that TriZetto was then going to use with Agency Solutions competitors.  Agency Solutions had voluntarily given TriZetto information about their product in planning sessions, and in responses to email and phone requests.  The court looked at four ways Agency Solutions could have protected this information, confidentiality, contract, trade secret and patent, but didn’t find anything strong enough to warrant an injunction that would stop TriZetto from going to market alone with their enhanced product.

In the end, the court found that background information, features and functions, high-level design specifications, and business requirements that become evident when the software is run are not trade secrets.  In other words, those things that are made obvious when you use the software, like the function that makes these words italic, reveals itself publicly when it is used so “italicizing” can not be a trade secret, though the actual specific method used to create the italics deep down in your code, could be a trade secret.

This becomes important when you provide an API to an integration partner.  You cannot depend on trade secret law to protect yourself against your partner using what he has learned from that API in building his own product.  If you want to protect yourself, you need to work language into your contract that stops your partner from using that knowledge without your permission.

The Issues & A Few Ideas

Trade Secret

  • The best way to protect a trade secret is to keep it secret.  An API is a great way to keep the bulk of your system a “black-box” as far as your integration partner is concerned but in order for it to be useful you need to share it with others.  Don’t be caught by surprise and look for other ways to protect your API.
  •  Understand that your protection under trade secret law is weakest when you share your secret.  It is strongest when someone improperly takes something from you.

 Contract

  • A strong contract is still the best way to ensure you get what you expect in your relationship with an integration partner.  You have a number of tools, like confidentiality, exclusivity, obligations to destroy materials and rights in derivative works to go beyond the default protection the law will give you.  Of course, you may have to negotiate these terms with your partners but, if you watch for the things that are important, its more likely you will be the one benefiting from your hard work.
  • Don’t ignore the confidentiality provisions.   You can change how trade secrets are protected through a confidentiality clause and you can change the definition of trade secret itself to have it cover much more than the standard definition.

Afterword

  • The court in this case was looking only at the question of an injunction.  There were other contractual issues in the case that have not yet been decided and I wouldn’t be surprised if Agency Solutions ultimately wins on the claim that TriZetto breached their promise to work exclusively with Agency Solutions.
By Ken Labach | Also posted in License | Comments (0)

Avoiding Traps with Letters of Intent

April 30, 2012 – 11:12 am

The Takeaway

The title of a document doesn’t matter: an agreement is an agreement.  It isn’t uncommon for a “Letter of Intent” to have binding provisions.  Some of these, like confidentiality or a duty to act in good faith, are normal and within the spirit of a Letter of Intent.  But you will see binding clauses transferring ownership of an idea or setting out a binding payment plan – these are not normal but if you aren’t careful, people will sneak them into an LOI and try to make them enforceable.

The Need

Ok, as a lawyer, I rarely see the need for a LOI.  Generally, the purpose of an agreement is to create a binding relationship between two parties.  It spells our the rights and obligations of each party which are governed by the law of contracts and can been enforced by a court.  The entire purpose of a Letter of Intent is to set out the intentions of the parties without creating any enforceable rights.  And intentions change every day.  You can see why lawyers aren’t big fans of these kinds of letters, there isn’t much we can do with them.

So, the big question is, why should I care?  If the LOI is just a list of intentions, if it isn’t binding, if you can’t get it enforced in court, why is there any problem?  It’s a problem because people will put enforceable terms and conditions in an LOI and hope that you will just sign it.  The title “Letter of Intent” on the paper really means nothing to a court deciding whether or not there is an agreement.  The court will enforce those parts of the LOI that look like they were intended to be binding.  So, don’t let your guard down when someone puts an LOI in front of you and asks you to sign, saying there’s no commitment.  Look for the commitment, in most cases there will be something to find.

So, if there’s no legal reason to have a Letter of Intent but there may be downside, then why bother?  There is still moral value to getting something on paper.  There is considerable value if it is used as a sales or purchasing technique.  Just remember, don’t let your guard down and read past the heading on the page, make sure you are expressing your intentions and not committing before you are ready.

The Issues & A Few Ideas

Normal Enforceable Terms

  • Confidentiality:  If you haven’t already signed a Non Disclosure Agreement but you want to keep your discussion private, putting confidentiality provisions into an NDA can be useful and is quite common.  Make sure that both sides have the same responsibilities, confidentiality goes both ways.
  • Limitation of Liability: The purpose of a letter of intent is to express your position on paper without creating a legal obligation.  Limiting liability furthers this intent by making sure that no matter what happens, you are only on the hook for certain, measureable damages.
  • Not a License:  Some provision stating that the LOI is not a license or transfer of ownership and that both parties own and control what they brought into the relationship is consistent with a statement of intention.

Sample Terms That Are Not Normal

  • Transfer of Ownership:  One party drafting an LOI and claiming to own everything that both parties work on together.
  • Exclusivity: A clause stating that one party is obliged to deal exclusively with the other party, not that they intend to sign an exclusive deal but that they are already in an exclusive relationship.
  • Any clause that starts: “The parties agree” or “The parties will”.  This language indicates an obligation, not just intent. You should be looking for language like “The parties intend” or “Subject to the execution of a definitive agreement, the parties will”.
By Ken Labach | Comments (0)

What Do I Need from the Cloud?

November 21, 2011 – 12:29 pm

The Takeaway

Availability, availability, availability.  If you’re going to focus on one issue, AVAILABILITY is key.   The promise of quick, easy, cheap access to software and services in the cloud is coming true.  But if your system isn’t available, it’s useless.  If you have a little time to think about other things, think about security and scalability.

The Need

The Cloud is here and it’s time to figure out if you need it or just want it.  While it’s hard to define the exact boundaries of the Cloud, every network administrator I have spoken to has given me a very practical definition – “the cloud is everything I don’t control.”  They don’t spend a lot of time trying to identify various unique characterstics – in practice the Cloud is technology out-sourcing, pure and simple.  You are acquiring hardware, software and services from a vendor instead of hiring staff and providing them yourself.  How I get access to those services is a technical matter of developing the proper networking which is the vendor’s specialty.  Understood this way, you can treat the Cloud the same as any other out-sourcing relationship.  Make sure that you are getting what you pay for and that the service you get meets your needs.  Here are a few issues that are particularly important in a Cloud environment.

The Issues & A Few Ideas

Availability

  • Availability is all about making sure that the hardware, software and communication systems you are paying for are there when you need them.  You can be simple or complex but the key point is that it doesn’t matter what part of the system goes down, for you it is a binary equation.  Either it works or it doesn’t work.  You’ll have to expect some downtime, that’s just reality, systems fail.
  • Figure out what you need.  Are three 9s sufficient (99.9% uptime – 43 minutes of downtime a month) or do you need five 9s (99.999% uptime – 25 seconds of downtime per month)?  The higher the guarantee the higher the cost, so spend some time figuring out exactly what you need.
  • Keep an eye on response to downtime.  If you thought dealing with internal IT was bad, wait until they are just the middle man managing an outside vendor’s help desk.  Make sure you get regular updates on progress and the right to escalate the problem within the vendor’s organization within a set time.  No manager wants to get an escalation call at 2am because his support group hasn’t solved your problem

Security

  • Security is more than just making sure your password is a mix of 9 or more mixed-case alpha-numeric characters and symbols.  If you are collecting, processing and storing information it is likely there is someone watching what you do.
  • The big standard that is becoming impossible to avoid is the PCI DSS.  The payment card industry (read here Visa and MasterCard).   Credit card information is valuable and this detailed and expensive standard defines how the card providers want you to handle the data.
  • The secret?  PCI is a system for allocating risk and liability.  The purpose of it is to identify the source of any security breach and make the operator of the source responsible for the costs.  Get a copy of your cloud provider’s security certificate and make sure you keep tabs on their compliance so that they are responsible for security failures.

Scalability

  • Part of what you are paying for in the cloud is the excess capacity that is sitting there, ready for you to use on demand.  If you already know the size of the system you need to service your business then is the cloud really for you?  The reports I have from hosting service providers is that if you are comfortable with the size and power of the system you need, it is likely cheaper to build it out yourself in your own data center or as part of a private cloud.  You can still use the tools developed for the cloud to manage the system.
  • That said, if you haven’t  got the confirmed traffic numbers or the capital to sink money into your own build-out use a cloud provider that can guarantee you additional resources.  Just make sure they guarantee the additional resources.
By Ken Labach | Also posted in Cloud, Services | Comments (0)

SaaS Service Level Agreements – How Much is Enough?

June 25, 2011 – 4:19 pm

The Takeaway

When your customer’s revenue depends on the software as a service (SaaS) you provide, they will want to make sure your service meets minimum standards. These standards are set in a service level agreement. This agreement is not intended to compensate your customer for all their losses but to give you an incentive to provide good service.  Make service credits big enough to be noticeable but not so big that you can’t afford them.  Choose a few simple functions to measure that are core to the user experience in order to simplify your negotiation process.

The Need

We’ve all bought software that for one reason or another failed.  For a consumer a software failure can be disappointing or frustrating but it rarely causes a significant financial loss.  However,  a business buying software is often using that software to generate income.  An outage can result in angry calls to support, bad reviews in blogs or Facebook and losing sales or subscribers.

Nobody wants to lose reputation or sales because their software vendor isn’t performing properly.  So when a business does have a problem there is a natural reaction to blame the vendor.  It’s not unreasonable, the business bought a service expecting it would work and any downtime is the responsibility of the person providing it.  According to this logic, the next logical step is that the vendor should both fix the problem and share the pain resulting from the failure.

Fixing the problem is the subject of a support agreement.  It will cover ins and outs of reporting service problems and getting them fixed.  Feeling the pain is the subject of a service level agreement that sets standards that the services must meet,  measures the service against those standards and says how the vendor will compensate his customer if the service fails to meet the standard.

At worst, your customer will want you to feel all their pain.  I often seen warranties and indemnities in customer-drafted agreements that cover all the costs of any failure of the service.  That seems harsh, but I’m happy to say that while a customer may ask for maximum protection, I’ve always found them willing to negotiate a reasonable alternative that better allocates the risk.

The Issues

  • Full Cost Protection – It’s time for a dose of reality.  There is no such thing as perfect code or uninterrupted service. The losses to your customer from an error in your delivery are based on their use of the software and their revenues not on the price you charged for it.  A small application hosted for $5,000 per month may be powering a mission-critical sales process.  One failure could cost millions.  How can you account for that without distorting your pricing? You can’t be expected to price your service based on the insurance you buy rather than the value to your customer or the hard costs of delivering it.
  • Incentives – Full coverage is unreasonable, but you customers are comforted by knowing that you are on the hook for a service failure.  I look at support level agreements as incentives.  It always hurts to lose a percentage of revenue – but if you control how much is paid it won’t kill you. By providing a service credit based on ongoing payments, I lose money when my service doesn’t work while my customer feels like she has received some compensation and sharpened my focus.
  • Relevant Metrics – You need to look at how your customer uses the service to figure out what to measure.  But there are a few rules of thumb that should help.  Think about the user experience but don’t over-think and create some complex measurement structure.  You should be able to come up with one or two relevant measures that indicate real performance for users.  Trying to agree a precise, complicated measurement and credit scheme adds complexity to your negotiation and is unlikely to be significantly more useful than a few representative measurements.  Typical standards are up-time and response time.

WARNING LAW CONTENT: In the US structure the service credits as liquidated damages, not as penalties because contract penalties aren’t enforceable in the US.  See The Free Legal Encyclopedia and UCC Art. 2 Sec. 2-718(1) and speak to a lawyer for more detail.

By Ken Labach | Also posted in Cloud, Liability, Services | Comments (0)

IP Indemnity – It Doesn’t Need to Bankrupt You

June 19, 2011 – 8:36 am

The Takeaway

There is only so much business risk that a software vendor can take and patent risk can be overwhelming.  The US patent system is not friendly to small companies so try to limit your liability when you can.  Limited indemnities help you manage your risk.  It may take some effort to get your customer to agree but he will understand what you are doing and is unlikely to walk away on this point without some negotiation.

The Need

You can’t argue that business customers deserve a commitment from you about the software you produce.  You make the product; you control your employees and vendors; you are in the best position to know what the risks are and protect yourself and your customer from them.

One of the biggest risks in developing software in the US today is the patent system itself.  The news is full of Nokia vs Apple, Oracle vs Google, Microsoft v. Barnes and Noble and Paul Allen vs the World.  Even software developed in-house, without reference to any documents, former employees or patent filings, can infringe on a patent buried among the 20,000 patents granted each month.

And honestly, who can afford to defend these suits?  Often it’s cheaper to pay out a hundred thousand dollars to a patent troll rather than defend your technology in a legal system that just burns cash.

The answer for a company acquiring software is to get indemnification from the supplier.  When a vendor indemnifies her customer, she promises to defend the customer from any lawsuit brought by someone else based on the customer’s use of her software or services.  In other words, if the client gets sued because the vendor’s software infringes a patent, the vendor is liable under the indemnity to pay all the costs, litigation, settlement or damages.

So now you know the starting point.  All customers want a full indemnity for any software you provide.  It’s the most they can ask for and it doesn’t seem unreasonable so there is no harm to ask.  The question now becomes, how do you respond?

The Issues

  • Your Customer Wants Full Indemnity - I’ve recently spoken with the chief patent counsels at a number of major US corporations about indemnities and they all agreed that their standard negotiating position is to request an unlimited IP indemnity.  But they also admitted that full indemnity is a negotiating position.  They understand that a small company can’t necessarily take all the risk and they don’t see a limited indemnity as an unreasonable position.  So, try to negotiate your customer off their position, it won’t look like a crazy demand and isn’t likely to scare them off.
  • I Can’t Protect You – Sometimes in a negotiation you just have to admit that your customer is bigger than you are.  While there is always a danger in saying it out loud, they may prefer dealing with larger companies, it is sometimes a fact of life.  And if your customer’s revenues dwarf yours, if they could use your software in a way that produces a huge infringement liability, you might not have the cash and resources to live up to an indemnity.  This frames the argument and can get your customer to back away from a hard negotiating position.
  • An Incentive is Fair – You’re not going to get away without IP liability.  Your customer is going to want to see that you have an incentive to be careful when developing your code.  Offer a capped indemnity.  You can base it on your own insurance cover or on the revenue you expect from the customer or on an amount that will hurt but not break you.  It’s an act of good faith and is much easier to agree on than no indemnity at all.
  • Lawyers Can Be Unreasonably Rigid on this Issue – There comes a time in a contract negotiation when the business has to decide whether or not to take the risk.  The arguments I’m suggesting here are business arguments and unlikely to sway a lawyer who isn’t willing to take the time to understand the underlying business opportunities.  There is no legal magic about indemnity, it is an allocation of risk and reward, just like pricing or an SLA. Sometimes getting it out of the hands of the lawyers is the best way to get your deal done right.
By Ken Labach | Also posted in Liability, License | Comments (0)
Follow

Get every new post delivered to your Inbox.