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

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.
June 1, 2012 – 5:03 pm Categories: License, Negotiations | Post a comment

Developer Tips: Code Smart to Protect Your Copyright

tl;dr

Make sure diagnostic tools are written as stand-alone modules so that they can be protected by copyright.  Trade secrets need to be kept secret, maintenance passwords can do this if your application is at your customer’s site.

The Details

There are two main ways for a software developer to stop his customer from using software he hasn’t patented.  The developer will argue that his software is a trade secret, or that its use is protected by copyright, or both.  While these rights will give him a lot of protection they are not absolute.  Some times the way code is written has an effect on how the courts protect it.

A case recently decided in California drives home this lesson.  A manufacturer built a software diagnostic system into their check scanning equipment.  One of their customers used a competitor to service the equipment. The competitor circumvented the password protection (we’re not sure how) and used the internal diagnostic system provided by the manufacturer to service the machines.

One of the questions answered is does the manufacturer have copyright protection over his diagnostic tools?  The answer here depends on how he wrote and implemented that code.  Copyright has a specific exclusion for use of code in the maintenance and repair of machines.  If your diagnostic code is built into the code that operates the machine, if it is necessary for the machine to run properly in the first place, the copyright act specifically allows an owner or lessee of the machine to use that code for maintenance or repair.   If your code is a stand-alone module, if it is not activated by turning the machine on but by some separate process, it doesn’t fit inside the exception.

The question of the password and how it was circumvented was the key point in the related trade secret claim.  By taking the precaution of password protecting the diagnostic system, the manufacturer was able to say that the system as a whole was a trade secret and that the service provider was not allowed to access it.  While there are other considerations, mainly how well did the manufacturer keep his secret, the password gave him a leg-up in the proceeding.

Here’s the case if you are interested: Burroughs Payment Sys., Inc. v. Symco Group, Inc., Case No. C-11-06268 JCS., [Docket No. 33]., 2012 BL 119409 (N.D. Cal. May 14, 2012)

May 21, 2012 – 5:52 pm Categories: Copyright, License | Post a comment

Open Source Licensing – what’s the danger?

The Takeaway

As it is with every other aspect of your business, using a third-party to supply anything is a risk.  Open source software is no different, you need to know what you are getting into before you start using it.  Be aware of licenses that require you to open source anything you produce that is based on the open source code you use, these are known as copyleft provisions and are a features of the GPL and LPGL licenses.

The Need

There is a lot of open source software available freely for download that solves problems you need solving.   Using existing code can save you money by eliminating days of development, reducing test cycles and bringing creative solutions into your development shop.  There are good reasons to use open source and it has to be a consideration in any project you undertake.

But it seems that for every snippet of open source code you find, there is a unique open source license that governs how you use, modify and distribute the open source.  The Open Source Initiative, an organization that promotes open source software and approves licenses as Open Source Definition compliant, recognizes roughly seventy different open source licenses.

Fortunately, the open source world is dominated by just a few of these licenses and due to the restrictions imposed by the OSD definition, the variation between the licenses isn’t as great as you might think.  The key to staying safe is to understand how the open source code you want to use is licensed before you incorporate it into your product.  Its far easier to just not use a piece of code than to rip it out later.

The Issues

Copyleft

  • By far the biggest issue you need to watch for is a “Copyleft” provision.  If you use open source that is subject to a copyleft license, all modifications of that open source, and any other code that is integrated with the open source must be licensed under the same terms as the original open source code.  In other words, by using the open source code, you may be giving up rights to profit from the code you develop yourself.
  • Copyleft has two main variations, strong and weak copyleft.  Strong copyleft, which is found in one of the most popular open source licenses, the GNU Public License (GPL), forces you to open source all works derived from or using the open source code.  Weak copyleft, used, for example, in the Lesser GNU Public License, allows a application that to links to an open source software library to stay outside the open source requirements, but requires any changes to the open source library to become open source.
May 18, 2012 – 3:05 pm Categories: Liability, License | Post a comment

Avoiding Traps with Letters of Intent

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”.
April 30, 2012 – 11:12 am Categories: Negotiations | Post a comment

What Do I Need from the Cloud?

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.
November 21, 2011 – 12:29 pm Categories: Cloud, Negotiations, Services | Post a comment

Follow

Get every new post delivered to your Inbox.