Category Archives: License

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 Negotiations | Comments (0)

Developer Tips: Code Smart to Protect Your Copyright

May 21, 2012 – 5:52 pm

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)

By Ken Labach | Also posted in Copyright | Comments (0)

Open Source Licensing – what’s the danger?

May 18, 2012 – 3:05 pm

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.
By Ken Labach | Also posted in Liability | Comments (0)

The One Thing You Really Need to Know About Selling Software

July 6, 2011 – 2:59 pm

The Takeaway

Software licensing is flexible. So flexible that even if there is no current software model that supports your business model, you can develop your own. This gives you another opportunity to differentiate yourself, make a new market or maximize the value of your software.

The Need

Over twelve years of practicing software licensing, the one question that pops up all the time is: “Can we do this?” Honestly, I’ve yet to come across an idea that wasn’t doable in a software license. My response is “Do you understand how you want to sell your product?” Your product, your sales model, your revenue model need to be the star of the licensing process. You need to apply the same creativity that you used to define your product to develop a licensing model that fits your business and your customer’s needs.

Once you have worked out your business model, you can find a document that fits that model. A sure sign that someone isn’t thinking about their customer is a software contract that doesn’t match the sales pitch. Sometimes I think people just grab a form that says “Software License” and use it without ever reading it. This isn’t rocket science, but if you are selling software as a service (SaaS), use a contract that talks about things that are important to a SaaS deal. Expect to get push-back from a customer who has been sold a one-time fee license but is presented a pay-per-user license document. It happens.

The Issues & A Few Ideas

How often are you going to get paid?

  • The One-Time Fee: Perhaps the oldest model, probably because it feels like walking into a store and buying something off the shelf. It’s still commonly used for things such as Windows and smartphone apps. It will often come with some recurring annual support and maintenance priced at 15% to 20% of the purchase price.
  • The Subscription Fee: Weekly, monthly, annually, the subscription fee is a favourite for licenses that are bundled with some hardware or service commitment such as security software, dating sites or on-line gaming. This model matches revenues to your ongoing expenses so that you have the funds to keep your operation running. You can offer free upgrades and new features to help justify recurring payments.
  • The Use Fee: The use fee is the typical SaaS model. If you need to access a database or complete some transaction – here is the fee each time you use the software and hardware bundle. It’s very similar to a subscription in that you have a periodic fee, it’s just a variable fee tied to an easily counted metric.

What is your unit of sale?

  • Per instance installed: This is the classic model, be it licensed by processor, computer or site. Just remember that if you are selling to someone running a virtualized environment for end users, one instance of the software may be shared across many installed end users. Take this into account when setting your pricing and your definition of an installed instance.
  • Per User: The per user model is typical for subscription-based cloud applications that provide a communication platform for a business that scales as the business grows. Some are restricted to named users, some to a total number of concurrent users. The user could be a person or another process.
  • Per Use: That use can be whatever you can count. A search, a sale, a look, a click, MB of storage or data processed or number of users. You may need to set some minimum use requirements to guarantee a minimum income.
By Ken Labach | Also posted in Marketing | 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, Negotiations | Comments (0)
Follow

Get every new post delivered to your Inbox.