Understanding (Your) Technology

Ken Adams recently posted about the destruction of confidential information that would otherwise be found on backup media. Beyond the discussion of suitable contract language is a conversation about a contract professionals’ understanding of the technology about which you’re drafting contracts.

The long and short of it is that you need to have a passing understanding of the technologies involved in any contract you’re reviewing. Why? Well first, it’s a requirement of the Five Fundamental Skills for Effective Negotiation (Information Gathering).  Second, assume for the moment that you are going to replace your network infrastructure from one manufacturer to another (these things happen more frequently than you’d imagine). To replace the existing technologies wouldn’t make sense without some amount of upgrades and network re-architecture (replacing old hubs with switches, etc). So the new vendor is offering a swap – hub for hub, switch for switch. Sounds good, right?

Before I tell you if it’s a good deal, what do you know about hubs and switches? Do you know how they work? Hmmm… that might not matter. It would help, however, to know how the devices are constructed. Hubs and Switches are physical devices that connect pieces of networks together. To do this, they have ports on them that accept ethernet cables… lots and lots of them. In other words, the value of a hub or a switch is not based only on whether it’s a hub or a switch (switches are more expensive), but on how many ports it has. So in this particular situation, you don’t just want a like-for-like swap, but also a port-for-port swap, otherwise, you could be giving up money without even knowing it.

Now, this issue also comes into play when you’re negotiating with smaller software vendors (called mISV’s – micro Independent Software Vendors) who sometimes sell software of a smaller dollar amount.  The mISV is quite sensitive to the costs, time and effort needed to work through their license agreement.  In fact, there’s a discussion going on right now over at Joel Spolsky’s Business of Software discussion boards on this very topic.  The mISV’s see the attempt at negotiation as costly and potentially harmful and their reaction is to tell the negotiator that no changes are allowed (they even use EULAs as a way to say it’s a non-modifiable form).

If you’ve taken the time to understand the product/service, there’s a chance that you won’t have to make a sweeping amount of changes to the document.  So, for example, if the product is a small desktop-based (non-networked) product, that doesn’t use ANY network resources (no internet access, for example).  Then I can relax my standards just a bit because now, if the product breaks, the likelihood of it taking down our network in the process is smaller.  So rather than lots of changes to their EULA, I will work with my legal and business folks to agree to only make two changes to the document:  1) Insert a warranty for exactly what the product does/not do – ie: no network access, doesn’t transmit anything, wholly desktop contained, etc; 2) Make the mISV liable for damages only if they breach this warranty.

In this way, I’ve lowered our risk, and I’ve only really made it risky for a deceitful mISV.

Oh, and while you hopefully have a subject matter expert hanging around to help you… you can’t count on them understanding the language enough to know to even ADVISE you of this issue. Because chances are they will make two fatal errors: 1) They believe what the vendor tells them, and 2) Absent blind faith in the vendor, they will also believe that technical people are all on the same page and that it’s only LOGICAL that the swap would be port-for-port.

Advertisement

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.]