Monthly Archives: April 2008

Malware Licensing

Wow. More here.  And here.  And here (from the original Symantec Alert).  (For those who don’t want to click the links, a malware author inserted a EULA into their virus code.)

First, let’s be clear.  Even though the software could be used for malicious purposes, this doesn’t affect the ability to license it.  Copyright protection doesn’t have any exceptions when it comes to things that might be used in a bad way.  So, midway through the article where it says “While not legally binding…”, the author is incorrect.

However, what the software license holder would potentially have trouble with is enforcement. If you don’t want to make it known that you’re the one creating malware, it will be quite difficult to be public enough to obtain license compliance.

But I am impressed with the idea, as well as the creativity involved in coming up with their penalties (they threaten that they will turn a violator over to the antivirus companies and explain how to shut down the effects of the malware).

The best part of this is the statement from Symantec:  “Despite the clear licensing agreement and the associated warnings, this package still ended up being traded freely in underground forums shortly after it was released. It just goes to show you just can’t trust anyone in the underground these days. ;)”

Advertisement

Limitation of Liability

A contract is an allocation of risk and liability limits are a huge bone of contention.

Vendors want to limit their liability to very specific types of damages:  1.  They want to only be responsible for direct damages; and, 2. They only want to be liable up to a capped dollar amount.  Generally speaking, this is acceptable (we’ll talk about the dollar amount in a second), as it’s a question of reasonability.

With respects to the types of damages (direct, indirect, consequentials, specials, etc), direct damages (in a very layperson definition) are those that are connected to the cause of the liability.  So, for example, if Person A steals from Person B, the cost of the stolen goods would be direct damages.  But, in the event that the theft led to Person B being unable to complete another business transaction (and thus negatively impacting Person B), that negative impact would be “consequential.”  You can quickly see that damages other than directs can be hard to quantify or calculate – and someone who would be liable for more than directs would not have a good way to understand their total portfolio of liability.

For dollar amounts, most people used to say that you could reasonably ask for 3x the amount “spent” under the terms of the agreement.  But to be fair to both sides, any amount I might recommend here isn’t a fair assessment of damages.  When discussing software deals gone bad, I typically want every penny I’ve paid over the term of the agreement returned to me – this is less an exact science of knowing the amount of future damage and more of an understanding of what it costs to replace software once integrated into an environment.

With respects to both limitations on liability (type and amount), customers should be able to get three exceptions:  A.  Indemnification Obligations (including both IP and general indemnity), B.  Breach of Confidentiality, and C. Gross Negligence or Willful Misconduct.  These three things, in my (supported) opinion, are eligible for ALL forms of liability and without any financial limit, either.  In almost all cases, vendors do not challenge these exclusions from the limits.  They recognize, as does the customer, that indemnification is only valuable when unlimited, that breaches of confidentiality have far reaching implications, and that willful acts shouldn’t be capped, either.

However, even a generous vendor is only going to allow themselves to be “on the hook” for indemnification for software that they licensed in the form in which it was licensed, or for certain types of damages.  Modifications to the software, for example, usually prevent indemnification to the extent that the infringement is a result of those modifications and not based on the unmodified software received from the provider.  However, in many instances, vendors rely heavily on talking the customer through various issues via phone or via e-mail and they provide a variety of bug fixes in numerous ways.  It is advisable to change any language limiting liability as a result of modifications made by licensee to read “modifications made by customer unless authorized by provider.”  This allows for the ability of the customer to make changes to the software at the vendor’s direction but not remove the vendor’s liability for the changes that are made.

In some cases, vendors are concerned that even this language is not enough protection as the customer might not follow the directions/instructions provided by the vendor.  If that is the case, language such as “modifications made by customer unless authorized in writing by vendor and such modifications explicitly conform to the changes contained in the written authorization” can be used.  The net result is that the customer should not be harmed as a result of following the directions of the provider with respect to their software.

Recently, I’ve seen some significant push-back on the limitations section – a desire to avoid the exclusions and reductions in the financial amount, as well.  I’m pushing back and I continue to use one of my favorite bad-cop/jerk phrases when discussing what will happen if the vendor breaches confidentiality (“I want to own your company.”).  What’s happening in your deals?

Ahhh… and it comes full circle.

Well… while I do love to be right, I like it more when I can fit things into nice neat little boxes.  The Microsoft/Yahoo skirmish is playing out well for me in this way as we circle back around to a failure on the part of Microsoft to perform proper Information Gathering from the Five Fundamental Skills.  Scott Mortiz posits that Jerry Yang simply wants to know that he’s going to have a position of power within a combined organization, and that this is what is keeping Jerry from accepting Microsoft’s offer.  If that’s really the case, and Microsoft would’ve learned through a complete information gathering process that this is what Jerry really wanted, it’s amazing what might have been avoided in the last month.

The truth is that we all tend to forget that information gathering is a two-step process.  First, you have to identify your own needs and wants.  You have to figure out what you can live with and what you can give up.  Second, and perhaps more importantly, you have to go through the same identification of needs/wants for your opponent.  This is never as simple as asking.   It’s rare that a lot of folks go through the full information gathering process themselves and even if they did, they probably won’t tell you what they discovered.

This is where your abilities as a negotiator can really shine – plying the information out of the other side takes persistence, time and skill (and a little luck, too).  You have to ask questions, sometimes multiple times.  You have to listen to the answers given and the answers avoided.  And through it all, you have to be able to push aside your preconceptions of what you believe they want so that you’re receptive to what they really want.

Have you ever asked yourself what I want by writing this blog?  Have you figured out that I keep asking questions of you because I want to try to figure out what you want?  What’s the problem we both have?  Well, the most significant barrier we have is the lack of communication connectivity.  I write, you read.  It’s one-sided whereas successful communication requires a two-way street.  So what’s been my response so far?  I take guesses.  I try to write about things I think you’ll find interesting (and those that I find interesting to write about, too).  Sometimes I get a hit, sometimes not.  But I have noticed that when I responded to skribit, for example, interest in the issue was evident.  In other words, bi-directional communication worked when I listened to what you wanted and gave it to you.

The same could work for Microsoft… and what’s so interesting is how easy the “fix” can be once you know what the desires are. All you have to do is apply the Five Fundamental Skills.

Lines in the sand

I can’t remember the comedian who was discussing a war-torn area in the world and talking about the dictator who scratched a line in the sand and said “cross this line, and you’re dead.” When the opposition advanced forward over the line, the dictator repeated their behavior after taking a few steps backward. Three… four… five times. Ludicrous deadlines are meaningless. Repeating them over and over again in a failed attempt to create validity simply makes you sound foolish.

Which is exactly what Microsoft is doing to themselves. Since their line in the sand a week or two ago, Yahoo!’s stock has gone up, Microsoft’s has gone down. Microsoft is now saying that “Unless we make progress with Yahoo! towards an agreement by this weekend, we will reconsider our alternatives.  These alternatives clearly include taking an offer to Yahoo shareholders or to withdraw our proposal and focus on other opportunities.” (Microsoft Chief Financial Officer Chris Liddell).

So they’re not only continuing to threaten to go to Yahoo!’s board,  they’re now trying to give themselves a backdoor to get off stage and save face by withdrawing the proposal.

Ya know… I happen to know that Microsoft has several good contract negotiators both in their procurement and sales teams.   Apparently the C-level execs aren’t talking with them before they go and make these silly statements to the public.

Folks, if you’re going to use Power and Time, (or any other negotiation skill), use it properly and with an understanding of the consequences.  Don’t be Microsoft.  Please.

More on Letters of Intent

A few months ago, I discussed the reasons why I wasn’t in favor of letters of intent.  They’re simply poorly written contracts – and in most cases, they’re going to not cover the issue that causes a dispute over the relationship.

Consider the case of Alfred West vs IDT.  I trust that you can read the details, but the high-level on this is that West and IDT signed a two-page, handwritten contract (which, much to my amusement, contained the phrase “this is binding”) to the tune of several million dollars.

You know what’s going to happen – and sho’ nuff.  IDT terminated the relationship with West, West sued to enforce the contract.  As of today, the latest verdict gives him $10.5 million.

Folks:  Please do NOT sign letters of intent, term sheets or anything else that is NOT a full-blown agreement.  If you feel the need to do something like one of these documents (or you’re forced to by your business folks), please take these additional steps:

1.  State on the document that it’s NOT binding until a full agreement is later executed by both parties.

2.  Include “time-bomb” language that terminates the agreement in a very short window (so that even if it’s later determined to be a contract by a court of law, it will have expired).

3.  Try one more time to NOT do the letter of intent and push harder for completion of a full contract.  Show your business folks this post and explain the pitfalls of half-baked agreements.

Microsoft trying to convert you from perpetual to SaaS

Well, as I predicted years before I started writing this blog, Microsoft is now trying to convert the average home user from a perpetual software license model to “software as a service” (Saas).

My knee-jerk reaction is that this isn’t going to be good for the average (any) user – business or consumer.  But let’s play it out and see what happens:

In the current, perpetual model, the average cost of Microsoft Office 2007 is $119 (per Amazon.com).  This is a one-time expense and allows you to install Office on two machines (desktop and laptop) so long as you only use it on one machine at any given moment in time.  The average person never buys any kind of support for this product unless it’s a pay-per-incident issue that is SO complex that they can’t get help with it from friends or strangers via the internet.  But you do get all of the updates to the current version of the product (ie: if you’re on version 2004, you’d get all updates to 2004, but not get version 2007).

Because it’s a perpetual license, you can use this product FOR EVER, without ever having to pay another fee to Microsoft unless you want to upgrade to their latest version (which, at the time I’m writing this, happens about every 3 years per platform, alternating between PC and Macintosh).  From a depreciation perspective, if you were going to buy the latest and greatest version of the product every three years, you would divide the purchase price by 3 to find out your annual cost of ownership:  $39.67, which works out to $0.108/day.  Not too bad for the product that supports all of your e-mail, writing, spreadsheet and presentation tasks.

We don’t yet have pricing available for Microsoft’s new online offering, called Albany, but we do know that they’re going to bundle in a few already-available-for-free services.

We also know that Google already offers something quite similar (GoogleDocs) for free.  If you’re already a GoogleDocs user versus a Microsoft Office user, you have made a choice to go with one or the other for a reason (most would say that they choose Microsoft for “guaranteed compatibility” and “support if needed” … and Google users say that they want “openness”, “freedom” and “collaboration ability”).  I highly doubt that Microsoft is going to offer their product/service for free… but I’ve been wrong before.

However, this really isn’t about Microsoft versus Google – it’s about a bigger issue of whether a conversion from Perpetual Licensing to SaaS is really a benefit to either the vendor or the consumer.  Perpetual software users like not having to upgrade every time the vendor releases a “fix.”  They like knowing that they don’t have to keep paying for maintenance when the product hasn’t really changed much over time.  They like having a one-time depreciable expense (if they’re business users).  Oh, and they like knowing that if the vendor ever goes out of business, it doesn’t matter too much, since the software is installed locally.

SaaS offers a level of convenience not found with perpetual products.  You are always on the latest version, always covered by support and you have less of an administrative headache since the product isn’t installed locally.  Sure, you have to have greater bandwidth (I’m guessing Microsoft will actually have you download a full version of the product which will simply “phone home” every time you double-click on the product to use it).  But you give up the ability to sever your ties with the vendor yet continue using the product.

I like the SaaS model for some situations – I use one for my contract management system, for example.  But for everyday, standard use products?  Especially those in millions of homes world-wide?  I’m not sure we’re there yet.  I’m REALLY concerned about the quality of service – and the constant communication connection (from a privacy perspective) of all of these phone-home events.

What do you think?

CIOForum – the best IT conference I’ve been to in a long time!

This past week, I was aboard the Norwegian Dawn for the CIOForum.  I admit that I was a bit skeptical about getting to go on a four-day cruise for free (even if I was presenting… but the attendees get to go for free, too)!  The “catch” is that IT vendors have to pay a significant amount of money to go, thus they are guaranteed meetings with the attendees to explain their products and services.

From a marketing perspective, this is absolutely brilliant!  They sail from New York to the East Hampton end of Long Island, drop anchor, and sit in the ocean for four days.  You are on the boat the entire time… and you have a personalized schedule keeping you in meeting after meeting for the entire time with limited breaks.  It sounds like an endurance test, and it is, but the truth is that the best part of any conference is the ability to network with your peers … which just doesn’t happen in cities like Las Vegas where the attendees scatter to the wind after the opening session to do “fun” things in the host city.

Onboard, however, you are constantly networking.  You are talking about problems you really face in the workplace and you get great insights into what others are doing to solve the problems.  For example, I had meetings on IT governance, cybercrime, leadership and my own on negotiation.  Oh, this isn’t just for CIOs, either.  They ran 5 concurrent conferences on the ship:  CIO, HR, Marketing, SupplyChain/Logistics and Legal.  So if you’re actually in a high-level leadership role one of those areas, there’s an event for you, too.  Of course, there are great keynotes (we had Dan Rather as our opening speaker, for example), plenty of activities (the spa and fitness area is open 24/7) and entertainment, too (comedians, dancing and more networking).

Maybe I’ll see you onboard in 2009!

CIO Forum this week

This Tuesday through Friday, I’ll be onboard the Norwegian Dawn for the 2008 CIO Forum. I’m participating on a 2-person panel talking about strategies for receiving more value from your IT-related purchases. We’re going to cover the Five Fundamental Skills for Effective Negotiation and you’ll even get a free copy of the Software License Risk Matrix!

If you’re one of the attendees, please look me up… Deck 11, second room from the bow, starboard side – we don’t have to talk about software licensing… I swear.

Additionally, for those people interested in either purchasing a copy of the Software License Risk Matrix or in redeeming my special offer for a FREE copy for those people who own the Software Licensing Handbook… I’m sorry to say that I’ll be slightly delayed in getting your Matrix out to you as I will not have internet access on the ship.  But I will fulfill all orders/redemptions by Saturday at noon (ET)!

MicroISVs, Contracts and Negotiation

Our first Skribit request asks to explore MicroISVs and how they maneuver through the unique challenges specific to being a MicroISV. Let’s start with a definition of MicroISV. The “term was coined by Eric Sink in late 2004 to mean software “companies made up of exactly one person”. Revenue is not a factor – as pointed out in the link above, some MicroISVs have made at least $1 Million.” (Poached from The Business of Software Wiki.)

As a result of their size, MicroISV’s don’t typically have in-house people that are focused on contracts, licensing and negotiation. This role and related tasks fall to the owner, who is typically a developer. They’re concerned with getting their products into the hands of their potential customers, which creates a potential negotiation issue, too. Let’s start with the big issues facing a MicroISV: 1. They can have less leverage because of their size or their “age.”; 2. They can have fewer financial resources able to devote to any legal/contract-related questions.; 3. They usually have fewer people resources to attend to these things.

When you combine a lack of resources and a need to close the deal, the typical MicroISV may feel that they have no choice in contract discussions. Thus, the challenge is to setup your individual situation in a way that gives you some leverage and allows you to not have to spend too much time distracted from your strengths in developing amazing software.

So, here are 3 things you can do RIGHT NOW to regain some control and leverage.

  1. Remember from our discussions on power in negotiation that simply being at the table gives you negotiation strength. The customer wants your product. If I’m across the table from you, I’ve been directed to acquire it… the only way we won’t is if you’re completely unreasonable. Thus, you’re not at an initial disadvantage as you might believe. In fact, you start with equal footing. So if you are open with me and tell me that you’re small, that you have no staff to do contract negotiation and as a result need to start from your document (see #2 below) but are negotiable, I will probably work with you quite well.
  2. Be prepared. Pay someone to create a license agreement for you. Do NOT call it an “End User License Agreement” or EULA (this screams “non-negotiable” and “inexperience”). Rather, call it a “Software License Agreement” or “License Agreement.” (Sounds stupid and silly, but it’s amazing what a name change does for the validation of your document.) While I would suggest that you keep it short (10-15 pages in 11-12pt font), make sure that you cover all of the key sections found in any large license document as discussed in the Software License Risk Matrix – otherwise, you’re going to get suggested changes. This is especially true with regards to maintenance and support. If you offer it, make sure it’s all detailed in the agreement. If you don’t, say that you don’t.
  3. Study the Software License Risk Matrix again if/when you have to negotiate. Go through the Software License Risk Matrix once with your lawyer (or contract professional) and discuss each section, why each section is important to you, what flexibilities you might have and alternate ideas. What you’ll end up with is an enhanced version of the Risk Matrix designed specifically for you and your business. When you talk with someone like me, you’ll be able to articulate your side – and if I ask for something you don’t like, you’ll have pre-considered alternatives to make as suggestions. This will cost you about 5 hours of time and expense. But you’ll be able to recycle the knowledge gained over and over. Then, if the deal is really large enough, and the request unique enough, you’d only have to go back to that professional on a case-by-case basis for just those single things rather than the entire document.

[Shameless plug (this is, after all, my blog): If you need someone to help you with #2 or #3, you know who to call.]