Software Licensing Handbook

Conversion Complete

2007-11-09T21:32:00.001-05:00

The switch to WordPress is complete. You can find me here: http://www.licensinghandbook.com

Thanks for visiting!

~Jeff

Switching to WordPress

2007-11-08T19:09:00.000-05:00

Sorry for the lack of a post this week. I'm trying to swtich to WordPress... more work than I imagined.

Five Fundamental Skills for Effective Negotiation

2007-11-06T09:54:00.000-05:00

About a year ago, I was honored to participate in research that revealed the five fundamental skills for effective negotiation. These five skills, none of which are really negotiation skills, but rather foundational building blocks upon which negotiation abilities are built, are not rocket science. In fact, the five fundamentals are really no-brainers - concepts that when you hear about them you slap yourself in the forehead and go, "of course. Duh."

But these five fundamentals are also clearly lacking in many negotiator's repertoires, as I've been thinking more about the question of the difference between good negotiators and not-so-good negotiators. So, the next five weeks are going to be devoted to the five fundamental skills - and if you'd like to get a jump on me, you can read the results of our research and purchase a manual on teaching the five skills (with a negotiation exercise included). I'd suggest the PDF version.

Next week: Fundamental Skill #1: Information Gathering

Wisconsin Lawyer Magazine Review

2007-11-02T09:54:00.000-04:00

Hello Wisconsin!

(Sorry, I couldn't resist... I'm a fan of >That 70's Show... please forgive my indulgence.)

After publication delays and the normal ups and downs of the average legal community, Wisconsin Lawyer Magazine released its review of the Software Licensing Handbook. Check it out... not bad, in my humble opinion.

The print version of the magazine, however, does have a type with regards to the price of the book. My apologies for any confusion.

Thanks to Craig Wilson who took the time to review it - he read the whole thing cover to cover. For that alone he deserves praise, as the book was never intended for that kind of read.

PDFs [Halloween Special Guest Blog by Stephen Guth]

2007-10-31T21:54:00.000-04:00

I have a lot of "pet peeves" when it comes to negotiating a supplier's contract-like when they don't want to make indemnification mutual or they give me a hard time about carving out infringement from the limitation of liability. What that says to me is that I'm not a valued customer and I'm dealing with someone that has either just graduated from law school or is on a low rung of the supplier's corporate ladder. But what really ticks me off, what really sends me into orbit, what really makes me want to go ballistic on a supplier is when a supplier sends me their contract in PDF format. Mind you, I absolutely love Adobe. I think they make some of the best nearly-bug-free software products out there. So, it's not that I don't like Adobe-it's the fact that I've gotten a contract in an unchangeable format.

I mean, aren't contracts intended to be negotiated? Sure, I clench my jaw when I have to click-through online license agreements, and I smile and suck it up when it comes to shrink-wrap agreements. But that's OK, because that's what I've bargained for. When it comes to a semi-COTS software package, especially one that is pricey, I want to negotiate the *(&^%@# contract. Otherwise, if I can't negotiate it, it's just another adhesion contract and I have enough of those in my personal life, like when I park my car and "assume all risk." I'm still OK with that, but I'm not parking a car here, I'm buying an expensive piece of software (or whatever)!

When a supplier sends me that PDF contract, they're impliedly saying a number of things I really find offensive. "We don't want you to redline the contract." "We don't trust you to redline our contract." "We want to make redlining so painful for you, that we want you to write the redlines in the form of an amendment to our PDF contract." At the same time, the supplier wants to be my newest best bud and take me out for lunch. Stand in line, supplier, there are other suppliers out there that want to take me to lunch AND use MY contract template.

So what do I do when I get a supplier contract in PDF format? Well, the first thing I do is send them my contract template-again, because I probably already sent it and the supplier is now engaging me in a dizzying battle of the forms. If I have no leverage because the supplier has hypnotized my customer and I'm forced to use their contract template, I give them an earful about how unprofessional it is to send a PDF contract and I scream bloody murder for them to send me their template in a Word format. Or better yet, use my contract template. If they still give me a hard time, and sometimes they do, I whip out one of my trusty PDF crackers and bust their PDF into a Word document so I can hack at it. If you don't have one of those crackers, they're worth every penny.

So suppliers, wake up and get real, save the PDF format for the final version of the contract and treat your customers like we keep you in business. You might even be able to reduce your own costs (and mine, right?) by not having to buy so many Adobe Acrobat licenses.

Here's the irony that makes everything all better for me: I just love sending my comments back to a supplier in a PDF format.

[Stephen R. Guth, Esq., CCCM, C.P.M., CTPE is the executive director of NRECA's Vendor Management Office. He can be reached via e-mail at
stephen.guth@nreca.coop.]

Negotiation skill

2007-10-30T09:54:00.000-04:00

Yesterday was the Business of Software 2007 Software Idol competition in San Jose. The topic of my 11 minute talk was the Five Fundamental Skills for Effective Negotiation - a result of research done last year. I didn't win the prize (a Nintendo Wii), but I did end up having some great conversations with many of the world's leading thinkers with respects to technology. Bill Buxton, head of Microsoft Research, asked me two very simple, yet often ignored questions about negotiation and negotiators.

First, he wanted to know whether a skilled negotiator (or sales person) could identify someone not so skilled simply on the basis of an initial conversation. The easy answer is "yes, they can." If you are party to a negotiation and are not a skilled negotiator when the other side is, they will know it.

The logical followup second question then is whether two skilled negotiators create better deals. The answer, generally speaking, is also yes. I know that if I'm talking with another trained negotiator, we're going to complete the deal much faster and more efficiently. Part of it is the negotiation skills and part of it is the contract/license experience to know where there are real issues versus red herrings.

For example, governing law is not a real issue. The parties either agree on their respective home states or New York. Once in awhile it's Delaware. It's a non-issue and can derail an unskilled negotiator/contract professional who is unable to move to the more important contract components.

So... the moral of the story is that if you're a less-experienced negotiator, please go educate yourself. Books, training classes (and of course, real experience) will all help you to become better. Then add in the licensing component to understand what is really important as opposed to what only appears important.

At Caucus IT Summit 2008

2007-10-23T09:54:00.000-04:00

Sorry for the lack of a post this week. I'm at the Caucus IT Summit 2008 in Orlando. If you're there, too, come find me to talk shop.

Term and Termination

2007-10-16T09:54:00.000-04:00

I told you the other day that I was implementing a contract management system. Part of this task is the Herculean effort required to go through all of the existing contract files and cull them down to the contracts and their related paperwork. This wouldn't be so bad if we didn't have active agreements dating back to the 70s - or if thirty people didn't mark the same document "to be filed" and the filer never look to see if another copy was already filed.

The second task, however, and one that is more important, is entering the metadata about the contract into the system. One obvious piece of information is the date of termination... and while you wouldn't possibly believe this, almost 50% of the agreements I've seen so far have no termination date.

I don't mean that they were intended to be perpetual - I mean that they're usually a services agreement and they have an effective date, but no contemplation of an end. Sure, I suppose it's possible that after they spent time negotiating the contract, they didn't want to have to revisit the agreement... but "forever" is a long time. Besides, I'm sure your organization has change at least one contractual phrase in the intervening years that you'd like to integrate into your old agreements.

So, short and sweet today, let's just all remember to put termination dates on our agreements. Even if you set it up so that there is some sort of a renewal term, make sure you have a way to get OUT of the agreement that lists what happens in the event of termination (and not just for breach). I might thank you for it some day.

[As a complete side note, don't forget that the Caucus IT Procurement Summit is next week! If you're in Orlando, or have time to burn, we'd love to see you. And if you're going to be there, come find me and say hello!]

Audit

2007-10-09T09:54:00.000-04:00

Provider’s typically require the ability to come to a customer’s facilities at any time and with almost no notice for the purpose of conducting an onsite audit of the use of provider’s product. While an audit, in and of itself, might not be a problem for a customer (in some cases, third-party associations argue that they have this right to audit as well), the convenience of any audit is of concern. For example, if a party had a sales cycle that was quarterly in nature, an audit at the end of the quarter could significantly disrupt the cycle and that quarter’s earnings.

The customer might also like the ability to audit the provider to review their accounting and bookkeeping practices. As such, audits are not a contractual problem so long as they are done upon several days’ prior written notice and at a mutually convenient time, usually during business hours.

Most audit provisions also detail that the expense of the audit is to be borne by the party conducting the audit unless, as a result of the audit, it is discovered that the audited party is somehow breaching the terms of the agreement. Watch out for situations where the audited party has to pay the costs of audit regardless, as this could merely encourage random and inconvenient audits designed more to harass rather than to find true issues. This also means that audits should only be performed a “reasonable” number of times. In other words, audits should be done on a consistent (i.e.: annual) basis and with some form of reason behind the audit.

With the advent of remote monitoring systems, many providers are now attempting to include the ability to audit remotely. This usually involves connecting through a secure system to enable the provider to gain access to the customer’s internal network and to view certain log files or other data that indicates software usage. From an ethical perspective, a customer should never have a problem with allowing their providers to review their usage. From an IT security perspective, however, the concept of remote monitoring may raise some concerns. Before agreeing to such a provision, a customer should make sure to check with their IT security group and include language regarding IT security into the license.

What audit language have you agreed to? Are you happy with it? Have you been burned?

Caucus Annual IT Procurement Summit 2008

2007-10-02T09:54:00.001-04:00

I can't believe it's already October! But one of my favorite events of the whole year happens at the end of this month, the Caucus IT Procurement Summit. Held this year at Walt Disney World (yes, I'm a Disney fan, too), this annual conference provides one of the best opportunities for IT procurement professionals to gather and discuss contract, negotiation, legal and other related issues that face our industry.

I have the honor of serving on the planning committee this year, so of course, some of the best speakers are going to present the best sessions! (No, I'm not speaking this year, so I'm not being arrogant.) In all honesty, though, the presenters really are hand selected and represent the highest quality practitioners in the field.

If you would like to join us (or perhaps you are just looking for a reason to come to Disney in the fall with the nicest weather all year) - don't fret, there's still time to register!

See you in Orlando!

TechnoLawyer BlawgWorld

2007-10-02T09:54:00.000-04:00

Software licensing is just one of a host of legal issues now covered online by a variety of bloggers. Some of the folks I mention in my blogroll to the right discuss many other important topics on a daily basis.

BlawgWorld 2007 is an eBook published by TechnoLawyer, an aggregator for legal blogs. The 2007 Problem/Solution Guide enables you to find solutions to 185 common problems - by providing you the "best of the best" posts from a lot of these blogs throughout the year. These solutions are organized by topic, including case management, depositions, discovery, document management, legal research, time-billing, etc.

No registration is required to download the book - it's a free PDF. If you're one of my lawyer-readers... or just enjoy legal topics, you'll enjoy the book - and probably find a few new blogs to add to your feedreaders - just like I did! My only disappointment was that I didn't find out about them soon enough to get one of my posts listed in the 2007 guide, but look for me in 2008!

Enjoy the free eBook!

To my non-US readers...

2007-09-29T21:17:00.000-04:00

In the course of my career, I've only really done a handfull of deals where the vendor was based outside the US. In those situations, the vendor was generally willing to use language that I was offering. But I know that this isn't always the case.

I have been watching my analytics pretty closely over the last few months and have noticed a significant increase in my non-US readership. So, this off-Tuesday post is a request to anyone and everyone who lives anywhere other than the US to let me know about licensing and contract issues that are happening in your corner of the world that may be unique to your area.

I would really like to start an international conversation on these topics, as I'm not sure anyone is covering these issues from that perspective (whether you have specific intra-country issues or if you have trouble when doing licensing between companies in different countries). All you have to do is talk to me (each other) and we'll all be better off! It's as easy as clicking the comment button below.

Two-Top Tuesday

2007-09-25T09:55:00.000-04:00

Thanks to Apple's press release yesterday regarding iPhone unlocking tools and the iPhone's warranty and license agreements, you get a special second-post (I'm also still feeling guilty about last week).

"CUPERTINO, Calif., Sept. 24 /PRNewswire-FirstCall/ -- Apple has discovered that many of the unauthorized iPhone unlocking programs available on the Internet cause irreparable damage to the iPhone's software, which will likely result in the modified iPhone becoming permanently inoperable when a future Apple-supplied iPhone software update is installed. Apple plans to release the next iPhone software update, containing many new features including the iTunes Wi-Fi Music Store (www.itunes.com), later this week. Apple strongly discourages users from installing unauthorized unlocking programs on their iPhones. Users who make unauthorized modifications to the software on their iPhone violate their iPhone software license agreement and void their warranty. The permanent inability to use an iPhone due to installing unlocking software is not covered under the iPhone's warranty."

This was the perfect opportunity to go read Apple's iPhone license. At seven pages in 7-point font, it was a treat. Apple has taken the license to a state of one-sided nirvana (though I must admit that Apple isn't the only vendor to have found Valhalla on this).

First the good news. There is no specific license prohibition on unlocking software. If a third-party application can unlock the iPhone without violating the terms of what most competent folks would consider a standard one-sided agreement, you're still in the clear.

Now the bad news. As with almost any license, there are specific restrictions about reverse engineering, decompiling or otherwise taking things apart to figure out how they work. Based on the various announcements from places like Gizmodo and Engadget, it appears that the people developing these cracks are having to do at least SOME deconstruction. They, then, are violating the terms of the agreement. But if the unlocking software itself doesn't decompile the iPhone software (and the end-user doesn't have reason to suspect that the creator of the unlocking tool violated the terms of the license - which, unfortunately, most of them do as a result of the heavy-duty detailed articles in Giz and Engadget, among others), use of the tool by an unknowing end-user would not necessarily be a violation of the agreement.

There is also nothing in the agreement that will prevent Apple from releasing a product update that will "brick" (kill) an iPhone with unlock software on it.

But, if there is an unlocking tool that is 100% software, was created and runs like any other third-party application, Apple's iPhone updates could still brick the iPhone, but use of the software wouldn't be a violation of the agreement... and restoring the iPhone to its original state would be a simple fix - one which Apple should do under warranty.

As usual, though, there is another wrinkle. The DMCA (Digital Millennium Copyright Act) prevents circumvention of any copy-protection devices implemented (for an extreme situation, consider the Zune - which, even for music that you created from scratch still wraps with a copy restrictive time-bomb that you can't disable, and is thus illegal to remove for your own self-created music). If the iPhone uses such device(s), avoiding them is a violation of the DMCA in addition to any pure copyright issues that would already exist. And each USE of the tool to do so would be another violation.

Overall, I make no recommendation here, but merely suggest, as with all licenses, that you understand the licenses you're under so that you know what you can and cannot do.

May the Force be with you

2007-09-25T09:54:00.000-04:00

While sometimes found in a license agreement, force majeure language is usually only appropriate for the provision of services or maintenance, as a force majeure event is considered to be delay caused as a result of something outside the control of either party. This would not usually impact a license itself, as delay of use of the license cannot normally be the fault of the provider, except where there is a problem with delivery or installation services.

Force majeure events should be listed items that are also known as “Acts of God” but should not include delay as a result of preventable problems or events that have no true impact on the provision of the Services. For example, many force majeure clauses contain “earthquakes” (and now in 2007, "wars, riots and terrorism") as listed events. This is only appropriate if the event is happening in the same geographic location as either the provider or the licensee and is where services are being performed or received. Otherwise, a war in a far-off country could be used to claim force majeure.

Some providers are also now attempting to list events that fall cleanly outside of the traditional view of force majeure. My favorite, perhaps, is "labor disputes and strikes." Again, remember that force majeure is an event outside the control of the provider. While a provider doesn't usually go on strike themselves, their ability to manage their workforce is within their control.

Additionally, the delay should only exist as long as the force majeure event predicating the delay. Some providers like to remain vague on when work will resume after a force majeure event. A general rule of thumb is that normal activity should resume when the event is over, as further delay will only be a detriment to the customer.

Lastly, some providers prefer to exclude customer’s payment obligations from receiving the benefit of force majure events. Customers should generally push back to keep the benefit of these events mutual, so long as the event is actually causing an impact upon both parties.

Are there items in a force majeure clause that strike you as interesting, funny or odd? Let us know in the comments!

About last night

2007-09-19T07:16:00.000-04:00

Oops. A week slipped by and I hardly noticed. I've been totally engrossed with installing a new contract management system. I forgot the billions of decisions that have to be made... and forgot how hard it was to make changes after you started entering data.

But the benefits significantly outweigh the negatives. I simply can hardly wait for the first "event" to get e-mailed to one of my business owners telling them that a contract is up for renewal. They'll ignore it, of course, but my first line of defense was at least present.

In the event that you're in the market for a system, though, make sure you find one that's appropriate for your size... and budget... and contract load. There are dozens of them out there - ranging in price from a few thousand to a few hundred thousand dollars. It's easy, especially if you're a contracts geek like me to get all googly about the various choices available. And Ken Adams has even gone so far as to start interviewing contract management system vendor employees to get a feel for the differences.

As the Knight Templar said to Indiana Jones "Choose wisely." Granted, it won't save your father, but it might save your sanity.

Copyright, the iPhone and You

2007-09-11T09:54:00.000-04:00

The new iPods were released on Wednesday, along with a drop in the price of the iPhone - and Steve Jobs then announced a little tweak to allow an individual to "buy" a song solely for the creation of a custom ringtone. He was excited that you'd pay $.99 for the song and then $.99 to allow it to become a ringtone - still less expensive than most "premium ringtone" services. But during his presentation, he let loose a little slip that I haven't heard mentioned on anyone else's blog or on any news outlet. He said that the extra $.99 was for the rights to make the song into a ringtone.

Woah. Wait a minute. Don't you already HAVE the rights to turn your music that you've purchased into ringtones? Let's break down copyright just a little bit and find out.

There are six exclusive rights granted to the creator of a work. These six (reproduction, creation of derivative works, distribution, public performance, public display and the right to perform via digital audio transmission) can be granted to a "buyer" independently of any other rights and in fact, can be parceled even within one specific right.

This is why, when you "buy" a CD, you can listen to the song anywhere you can take the CD - and you can rip the songs from the CD to your computer/MP3 player. But it's also the reason why you have to remove the songs from you computer/MP3 player if you ever sell the CD. You have a license to the songs - you didn't actually buy the songs themselves (hence why this is important to us in the software realm).

But the deeper meaning of what Jobs said, without elaborating, is that the license you get from a downloaded song on iTunes is actually a more limited license than was originally considered by most consumers. Namely, that there is NOT included in the license the ability to make a ringtone. I disagree.

The only way this would be possible is if one of two things were happening. First, if you actually received notice when you were downloading the song that there was a more restrictive license in place; or second, if the ringtone is somehow going to be considered as a derivative work. As I've downloaded a few songs from iTunes, and actually read all of the license language that came with iTunes, I haven't yet seen anything that would restrict my usage of a downloaded song. In fact, iTunes itself has a restrictor built right in - knowing full well that people won't remember differences in licenses for each song - so it limits your ability to create a CD with a certain playlist more than a specific number of times.

That leaves derivative works. And I'm just not sure that a 30 second clip from a song - which hasn't otherwise been altered, really constitutes a derivative work. I've never heard of someone playing a ringtone (mine happens to be a-ha's "Take on Me") that's anything other than a clip from the song. If the 30-second clip WAS a derivative work (ie: was altered by the consumer in a way that made it a derivative), it would be problematic regardless of whether it was a ringtone or not. But taking a chunk of a song and playing it on your phone isn't a derivative work - you are not required to play an entire song every time you hit the play button, and you can play your existing CD, for example, in your house, car, boat or portable player. Thus, Steve's comments the other day don't reflect the derivative work option.

In all, that means that you CAN create a ringtone from any song that you've already lawfully purchased/licensed. Apple and iTunes are making the recoding industry happy to charge extra for something that isn't required to pay extra for (at the moment). This also lead to two possible ends to this story, both of which affect us in the software world:

1. Apple is just getting away with what the consumer population will let them charge. The average consumer doesn't know the law - nor do they realize that they don't actually have to pay to make a ringtone. They're paying for the feature in iTunes to make one more easily. In the software world, this happens all the time, with vendors selling products based on "value" to the customer. Fuzzy math at best.

2. Apple is introducing a new licensing model for music - more restrictive than anything you've been exposed to in the past - licensed per consumer's use (as opposed to commercial use, which is already restricted in this way). As consumers, we will either have to manually manage these different licenses, or technology will come up to "help" - but "help" is a misnomer, as I don't want help with losing rights I already had.

As before, the software world feels this already and it's just getting worse. License metrics are getting more and more restrictive - it's now quite common to find double, triple and sometimes even quadruple license metric restrictions. Be careful what you agree to - as you're setting precedent for what the industry will do to everyone else.

Source Code Escrow Demystified

2007-09-04T09:54:00.000-04:00

When purchasing a million dollar software product with a quarter-million dollar implementation and 18% annual maintenance fee, it's probably reasonable to guess that the buyer expects to keep the product around for a little while. The fear is that the vendor, however well intentioned, won't be able to survive in this interesting world of mergers, acquisitions and bankruptcies. So the buyer asks for a little insurance policy known as "source code escrow."

For those of you who don't already know, software is developed in a 2-step method. What you install on your computer (the executable) is actually the result of the second step, the object code. It's machine readable only. The developers code in a human-readable version known as "source code" and go through a process called "compiling" to convert the source into object.

In the event that a future developer would want to modify an application, then, they need the source code to do so. There are some specialized tools (known as decompiliers) to help in the event that you don't have the source code, but generally speaking, having access to all of the original source files is the easier way to go. And in fact, most license agreements expressly prohibit reverse engineering or decompiling.

But the source code is really the crown jewel of the software company. Giving it to everyone and anyone who asks isn't a good idea. Recognizing the fear discussed earlier, though, the vendors are sometimes willing to place their code into escrow. Source Code Escrow is a service offered by a variety of organizations (such as GuardIT, Iron Mountain and others), called escrow agents. The vendor can "deposit" copies of the source code and then have an agreement with the Escrow Agent to only release the Source Code to specific recipients in the event of a "Release Condition."

In theory, if the vendor were to suffer a Release Condition (usually something catastrophic to the vendor's health, such as bankruptcy), the buyer could send a notice to the Escrow Agent that such a Release Condition has happened. The Escrow Agent, through a contractually-detailed process, confirms the condition and then would release the source code to the buyer.

Through contractual restrictions between the buyer and the vendor, the buyer is normally then allowed to use the source code to maintain their copy of the software. This doesn't allow the buyer to sell or otherwise divest themselves of the source code - it merely offers the buyer a way to continue to help themselves in the event of a problem with the executable. In some rare cases, the buyer might also have the ability to create derivatives of the source code - new versions of the product, so to speak, but again, this is almost always limited to the buyer's own use and not for resale to others.

Practically, though, source code escrow is a bit more tricky. First is the source code escrow agreement and the various things that have to be properly defined, such as the Release Conditions and the process by which the Escrow Agent would release the code in the event of one of these conditions. Buyers always want to play a bit more fast and loose than the vendor (for obvious reasons). But for the most part, these issues are resolved in favor of the vendor.

Second, the Escrow Agent doesn't provide escrow services for free. Some vendors will offer to pay for the service, but most require the buyer to pay the annual costs involved. These are usually relatively nominal - $1500/year or so. But some Escrow Agents charge a small fortune. This cost may be easily forgotten when budgeting - or may be overlooked in later years and the service then lapses.

Third, the quality of the code placed into escrow is important. Most good escrow agreements have stated periods upon which the vendor is supposed to update the code or re-deposit new code. This could be on an annual basis (which is usually fine for software that's not updated frequently or is less expensive) - but the buyer's perspective says that they always want the source code equivalent of the most recent released commercially-available product. So there are times where the vendor will have to pay for multiple deposits and will want the buyer to share in that cost. Remember, though, that HUNDREDS (or thousands) of buyers may be beneficiaries of an Escrow Agreement - so buyers generally shouldn't have to pay for deposits (as one deposit can satisfy all buyers).

Perhaps most important in the escrow discussion, however, is the ability of the buyer to actually make use of what they've received in the event of a release. Unless you, as a buyer, have an IT staff that's educated on the programming language used to write the code in the first place - and have the tools to debug and then compile any changes you were to make, source code access might not do you any good.

In the age of ASPs and SaaS vendors, having source code escrow is seen as a remedy for the problem of not having the executable running at your physical location. But, consider whether you have all of the other back-office requirements needed to effect a product's use. Having the source code to their product might get you that product - but if that product also requires, for example, a SQL or Oracle backend database, do you also get THOSE products as well? Probably not. So source code won't help you as much as you would hope.

Overall, then, when considering source code escrow, make sure that:

it will actually provide you what you need to stay operational;
cost a reasonable sum in relation to the value (just like any other purchase);
that the terms of an Escrow Agreement are reasonable and that Release Conditions are clearly defined and not unduly burdensome to prove or meet;
your in-house IT staff has the ability to make use of the code.

If the answer to any of those questions is NO, look for other solutions to the possible problem of the vendor shuttering its doors. By way of example, one creative idea I've seen is to have the vendor (in an SaaS model), actually host the physical server within the buyer's IT facilities. The vendor would remotely access the box for maintenance and service, just like they probably would if the box sat in a hosted data center. The only difference is that in the event of trouble with the vendor, the box was sitting in the buyer's IT shop - readily accessible by the buyer without having to negotiate with an Escrow Agent that a release condition was met.

Anyone have other creative solutions to this problem?

Thanks for your Votes!

2007-09-02T13:58:00.000-04:00

I just received notice that I've been selected to be one of five finalists in the "Software Idol" competition at the Business of Software Conference next month in San Jose!

I didn't realize that the competition was anything more than getting to speak at the conference, but thanks to your votes, I'm among the five finalists. We'll each have 11 minutes to speak on our specific topic - then instantaneously, we'll find out the results.

So, if you're in the San Jose area and have some time October 29th/30th, I would highly recommend coming down... if for no other reason than to hear Guy Kawasaki, Joel Spolsky, Eric Sink, Bill Buxton and Rick Chapman (among others). These folks are all at the forefront of the software business - and are shaping its future form. Oh, and yeah, you can hear my 11 minute talk on the Five Fundamental Skills for Effective Negotiation, too.

Thank you all again!

Risk

2007-08-28T09:54:00.000-04:00

I'm currently looking at buying a new software application. It's not going to be a large purchase, but it's relatively important (at least to me). The vendor, of course, tells me that because this isn't a large deal for them, the contract template they've provided is non-negotiable.

Sound familiar?

What instantly becomes obvious, then, is the question of risk. Which, of course, is what most contract negotiations are really about anyways. In other words, are the terms of the agreement bad enough that it would make me not accept the contract and walk away from the application.

To make this assessment, I have to review the agreement in detail. I pass it along to counsel for their thoughts - especially since I was a bit biased as it's a tool for me. Then I forward the redline to the vendor and tell them that while I understand their position, we're unable to accept their template as written - that there are just some issues on our side that are too important to ignore.

The vendor, as expected, hemmed and hawed a bit... but eventually came back with a list of sections where they would not accept our changes. Some required a little internal discussion regarding risk - and after reminding everyone that the deal was pretty small... and limiting our total exposure from other perspectives, we felt the overall risk assessment was acceptable.

I called the vendor to let them know that we'd reached agreement. In the end we went from non-negotiable to partially-negotiated, just by doing a little work. The moral of the story is to never just give in. Assess your risk points, decide what is most important (your true needs), what's nice to have (your wants)... and ask the other side to do the same.

The worst thing that happens is that you have a good risk assessment. The best thing is that you know your risk AND get your product, too!

A Fair(y) Use Tale

2007-08-24T07:31:00.000-04:00

In this special TGIF edition of the Licensinghandbook Blog, take 10 minutes out of your busy day to watch the following "Fair(y) Use Tale" by Eric Faden. If you've ever wondered about copyright law and the fair use exception, there aren't many better ways to learn:

Death and Taxes

2007-08-21T09:54:00.000-04:00

Just as in your normal life, contracts deal with some consistent yet unwelcome issues - such as taxes.

Let's see, there exist: sales tax, use tax, value added tax, ad valorem tax, excise tax, income tax, transfer tax, and my personal favorite, tariffs.

In most licensing situations in the US, you should ONLY be worried about paying sales and use taxes. Language that lists any other taxes should be cut down to only address sales and use tax if for no other reason that within the US, those are the taxes that really apply to the sale itself - and they're the only taxes that the seller is required to collect from you. The other taxes, even if they apply, are really the responsibility of the seller... but if they can get you to pay, so much the better for them. [I'll save discussion of telecom tariffs for another day, but these are NOT taxes - they're fees that are passed along to the buyer.]

Even within sales and use taxes, though, there are some exceptions (depending on your specific state's laws) which might allow you to avoid paying taxes on the purchase of software in the event that the software is delivered electronically. My state (North Carolina) is one of those states.

We have an additional requirement - maintenance can't be mandatory. I didn't think this requirement really merited any extra attention until the other day. All I'll say at this point is that I would recommend that anyone who has this requirement in their sales tax law quietly (and quickly) insert language into your template agreements that clearly states that maintenance is OPTIONAL and not mandatory, and that the buyer is free to purchase maintenance from anyone they wish (or refrain from buying maintenance entirely).

Oh... and if you happen to be a NC-based person like me and you work on the procurement side of the house, please get in touch. We need to talk.

Letters of Intent

2007-08-14T09:54:00.000-04:00

When was the last time that someone referred to you as the Order Prevention Department? Business folks tend to think that a contracts staff is only there to stop them from getting their next purchase. We know better, of course, but it doesn't change the fact that we are constantly having to show value and purpose to our existence in the fact of adversity.

Recently, I was engaged in the beginning of a deal that would end with the purchase of a large technology system. The evaluation was done via an almost picture-perfect RFx process, spearheaded by a business owner who knows the value of a corporate contracts group and for whom I hold great respect. As the selection process neared conclusion, the business got anxious. They "needed" to start work immediately to meet their internal deadlines and thus wanted to do a...

... wait for it ...

... bu, bum, baaaah...

Letter of Intent!

I wanted to cry. Here we were, humming along beautifully, and they wanted to derail it with a Letter of Intent (LoI).

Now, if you've never heard of a LoI, it is to a contract what a golf cart is to a car. In other words, it might eventually get you to your destination, but without the protection afforded by an enclosed vehicle. LoI's are one of the banes of a contract negotiator's existence - a poor excuse for a contract and they are sometimes seen as the easy way out to get a deal done quickly.

In the particular example above, the business wanted to use it as a bridge to get work started while we negotiated the full agreement. Since LoIs take at least some time, there's a choice to devote some effort to the LoI rather than review the full agreement. Granted, the full contract will require MORE time, but I don't think it outweighs the risks of the average LoI.

When confronted with a request to review a LoI (and when you can't negotiate with the business to just forge ahead with the full agreement), then remember to at least lock down the following things:

1. Term. Place a limit on how long this interim agreement is going to last. The shorter the term, the less the risk.

2. Fee/Rate. Clearly state the rate/fees and how they will be calculated. A fixed fee is always best (and even better if that fee is $0.00). If you really want to protect yourself, include a cap on the total amount of money that can be expensed under the LoI. Remember always that a one-week engagement isn't equal to only 40 hours - 2 resources = 80 hours, 3 resources = 120 hours. Multiply against your listed hourly rate and you can see "small" agreement add up quickly. Oh, and don't forget about capping expenses, too.

3. License. If you're getting access to software without a full license - WATCH OUT. All of the standard license issues still apply (IP indemnification and virii for example). Also remember that if for any reason the full agreement doesn't get signed, it's most likely that your license will terminate.

4. Services. Clarify ownership for anything created as a result of services performed. What happens if the full agreement isn't completed? Do you lose ownership? How about work that includes your confidential information?

5. Warranty. Depending on how long the LoI lasts, or how any deliverables are created and delivered, you may need/desire a warranty for those deliverables.

6. Indemnification. As mentioned above, and for deliverables/services, too, you will want to be indemnified in the event that the vendor uses something they don't have the right to use in performing the work. You will also want a general indemnification if the vendor is going to be onsite at your facilities in the interim term.

7. Confidentiality. Hopefully you've already completed a Non-Disclosure or Confidentiality Agreement with any vendor that you're willing to use a LoI with - but if not, include your standard confidentiality language.

8. Termination. As with any other license or services agreement, include standard termination for breach language. Make sure you also retain the ability to terminate the LoI at any time, for any reason. It's probably reasonable that you will have to pay for services performed up to the moment of termination, but don't forget to tie it to ownership over work completed and paid for.

9. Governing Law. Fairly self-explanatory, but don't forget to cover governing law. And remove jurisdictional statements, just like always.

Oh, and to make matters even worse, each of the terms you negotiate in the LoI may change in the full agreement, as the risk you (or the vendor) are willing to tolerate in a short-term agreement may be drastically different than the risk you (or they) are willing to take in the long run. The usual saving grace in all of this is that the vendor probably doesn't want the LoI either - work together to make it palatable.

In Memoriam

2007-08-07T03:52:00.000-04:00

http://www.jeffreygordon.net/2007/08/in-memoriam.html

We'll return next week with a new article. In the meantime, please do me a favor. Go hug your mom, dad, brothers, sisters, sons, daughters, cousins and any other relative you have. You never know how much time you have until you don't have any at all.

Your contract will be there when you get back. I promise.

The perils of using someone else's work

2007-07-31T09:54:00.001-04:00

On Saturday in another forum, I noticed a post about boilerplate terms being used in website Terms of Use. The original poster commented that they thought it was quite funny that about 200 websites had all used the same boilerplate language which required any lawsuits to be brought in King County, Washington (where Microsoft is based).

This wouldn't be nearly as funny if the websites weren't all based in Australia or New Zealand.

Try this GoogleSearch

Interesting, eh?

Moral of the story? DO NOT USE SOMEONE ELSE'S LANGUAGE UNLESS YOU KNOW THE MEANING AND IMPACT OF EVERY SINGLE WORD!

I understand that we all want to not reinvent the wheel - it doesn't make sense to redraft an indemnification clause if someone else has already worked up something good. But you'd best understand what you're including in your contracts.

Now, as for the folks in Australia? Well, I tried sending an e-mail to all of them. I wonder how many will never be read as a result of a spam filter or be dismissed as a joke. [Yep, at least one was taken as a joke and required additional commentary to get them to believe me - and to not think I was soliciting them for something.]

Let's Make a Deal!

2007-07-24T09:47:00.000-04:00

When was the last time you bought something? Today? A few days ago? Do you have the item in your possession now, or did you order it online? At what point in the transaction did you pay for it? I keep twisting these questions over in my head each time I read payment language that wants payment for software at the time of signature.

Of course I can see the vendor's point. They are granting immediate license to use the product, thus I should pay now as I can have immediate benefit of the license. But for the vast majority of products, some kind of implementation or installation must occur first... and almost always, the vendor is the installer.

In such a case, when should I have to pay? My gut feeling is that I don't pay until I receive value from that which I have purchased (or will be immediately able to receive value - for those items that are being shipped to me). Which means, in the case of most software - that I shouldn't pay until installation/implementation is completed.

Again, on the vendor's side, this is a huge problem. Some implementations can take months. Cash flow is a serious concern for everyone, especially for smaller software vendors. So how do I address the vendor's concerns of getting paid promptly, while still making sure that I get what I'm paying for?

Know first that this is all a matter of personal preference and corporate choice. Your organization may have no qualms about paying 100% upfront vs 100% at acceptance. But if you do HAVE the choice, I recommend considering the following things:

1. Software which requires installation should not be more than 50% paid for prior to acceptance. If you can't use it in its un-installed form, it's not worth anything to you yet.

2. Installations or implementations that take an extended period of time protract the risk for both parties. Decide upon a payment schedule that makes sense given the apportionment of the risk. This means understanding thoroughly the complete deal and where responsibility lies for each task.

3. ALWAYS, ALWAYS, ALWAYS have an acceptance testing procedure and tie the bulk of the fees/payment obligations to successful completion of the LAST acceptance test. My favorite analogy for this is the one about building a house. If everything else is done on the house but the roof isn't put on properly, do you still want the house? Of course not. Make sure you end up with a completed project.

4. Payment breakdowns can be whatever you wish them to be. Milestone based is my preference.

5. Added to #3 above, make sure you also have the ability to get a full refund in the event that the project is never finished due to the vendor's behavior. My vendor audience will cry bloody murder about this, but let's be honest and depersonalize it for a moment. If I was selling you a car, but was doing so in pieces that could only come from me, would you want the body if I didn't give you the wheels? I doubt it. The same is true with software. Those products which require vendor assistance to install need to be fully installed or the product isn't worth anything to the buyer.

At the end of the day, however, and like everything else in the contract world, these points are all negotiable. Giving up payment terms for lowered cost - or the inability to get a full refund for a fixed price installation, for example, might be worth the risk.

What odd payment agreements have you made to close your deals? Comment below and lets learn from each other!

Quick Note of Thanks!

2007-07-22T12:50:00.000-04:00

Hi.

As this is an off-day for the blog, I thought I would take a few moments to thank all of you who are reading my little notes, tips, tricks and missives. I hope that you're getting something valuable out of the time you give me - and with each post, I remember those who have come before me and have offered suggestion, comment, praise and criticism, as it is only with the help of those around us do we achieve more than we would on our own.

To that end, I also wanted to take a brief moment to (as personally as I could) thank those of you who have thought highly enough of what I had to say to buy my book. I can't believe it's done as well as it has - Lulu tells me that it's the 492nd most popular item out of 250,000+ works available. Simply incredible. And it's thanks to you.

So - I'll look forward to seeing you on Tuesday. Enjoy the rest of your Sunday!

Sign Here ->

2007-07-17T09:54:00.000-04:00

One of the greatest inventions of the 20th Century was the Post-It. Created completely by mistake by the awesome folks at 3M, I'm sure all of you use them on a daily basis. In the last few years, 3M has continued to innovate with the Post-It, tape flags being an excellent post-Post-It product. The tape flag style I use most is the "Sign Here ->" flag.

You've seen them, right? They have a yellow tab with red writing and a red arrow that you align with the place you're looking to have someone sign.

I love these little pieces of cellophane for the sole reason that they help get my documents signed. Yes, really.

One would think that contract signatures would be a no-brainer. That somehow folks would understand that without a signed contract, there is potentially no contract at all. But alas, such is not the case. In almost every organization I've ever worked, there are almost always a slew of documents that are sitting in the contract files, but aren't signed.

When I ask about these documents, I get a variety of answers.

"I dunno."

or

"Oh, we only need THEIR signature..."

or my personal favorite:

"Well, the work was already done, so what did the document matter? Who cares if it was signed?"

I care. I care because I know what can happen when there's a dispute and no fully executed agreement. I care because I understand that people forget things with time. I care because details matter... and the final steps of closing a deal are just as (and perhaps more) important than those at the beginning.

Get your contracts signed.
Use tape flags, smoke signals, bribes. My most successful method is to hold up payment until I have the fully-executed document. This technique even works from both sides, as the vendor wants to get paid and the customer wants to not be late with payment. So, whomever is "slow" with signature will be prodded by the other for you.

Simple.

Oh, and as long as you're doing that - get originals, not faxed or e-mailed/scanned copies. Nothing is better in your hands to know that you have your ducks in a row. And if you've got your ducks lined up and quacking in unison already, start asking for signatures in blue ink so you can always distinguish originals from copies. Then scan your originals after full execution into a searchable contract management system.

Business of Software

2007-07-10T09:54:00.001-04:00

The world is getting smaller by the minute, significantly made possible by the internet. People connect in more ways than ever and it's interesting to dissect the connections themselves.

Joel Spolsky is a software developer, author, renaissance man. His company, Fog Creek Software, not only produces cool tools, but the company itself is a model for others in how to treat your employees with respect and admiration. He also runs a few websites, among them www.joelonsoftware.com and, as part of that, a discussion board on the Business of Software. Conversations happen on a daily basis between developers and business folks alike - all working on the problems that smaller, usually independent software developers face when creating products.

One of the participants on the the board (and a co-founder of Red Gate Software), Neil Davidson, is helping assemble the 2007 Business of Software Conference. This event is essentially a live version of some of the discussions that happen frequently (plus a lot of bonus material). Additionally, one of my favorite speakers (besides Joel) is going to present this year, Guy Kawasaki.

Feeling a little overconfident, I contacted the organizers and asked if they wanted someone to talk about licensing or negotiation. Come to find out, they have a few slots available - and were going to try something a bit novel to fill them: Software Idol. Each hopeful has 3 minutes to pitch an idea, posted on YouTube. Business of Software newsletter subscribers get to vote. The top three get to come to the conference to present their idea.

It took a few days to arrange, but here's my submission. Shameless plug: If you're a Business of Software newsletter member, please vote!

And if you want to attend the conference, I would highly suggest it for almost anyone reading this blog - you'll learn a lot about the fundamentals of this interesting business.

Service Levels Redux

2007-07-03T09:54:00.000-04:00

Back in March, I discussed the creation of service levels for the first time. I talked generically about how to create a service level and what key components were part of the process. At this past weeks' IT Financial Management Conference, one of my sessions focused on performance guarantees (which is just a broader description that includes service levels). What I realized is that, along with maintenance percentages and other negotiable items, buyers have long been reducing their demands - which has increased the "boldness" quotient for our vendors.

So first, as with these other contract sections, please let me remind you that your actions DO impact others. The less you ask for now, the less I'm going to be able to get without a struggle later.

More importantly, however, is that you should remember that there are two primary classifications of performance guarantees.

First, Service Levels (and Service Level Agreements). SLAs, in my view, are to describe guarantees related to the performance of contractually-agreed upon services. This means that SLAs are usually used to measure performance against response and repair times in your maintenance agreement. In other words, SLAs measure quality. How well did the vendor do with respects to performance?

Obviously, you have to have stated response and repair times to make these work - and such times will also usually be based on a "severity" level determination, too. Thus, outages for Severity 1 (high) will require a much faster response than those for a Severity 4 (low) problem. But with proper definition, you can cover your bases adequately.

Second is the use of Standard Performance Obligations (SPOs). These are the types of things I was really talking about in the last post on SLAs. The distinction here is that an SPO is measuring output/availability/quantity as opposed to quality. So a SPO would cover uptime/downtime or the number of widgets your software is supposed to process in a given time frame, etc.

See the difference between SLAs and SPOs?

Your contract might need both for you to be sufficiently covered for any particular issue. Both require good definitions, measurability, reporting and "incentives" to meet the guarantee. But each one measures something a bit different than the other and it's important to cover both.

How do you measure performance in your agreements? Comment below!

Speaking Engagements

2007-06-26T09:54:00.000-04:00

Happy Sunday!

This special Sunday edition of the Licensing Handbook Blog is being sent out in lieu of the regular Tuesday post. I'm going to speak at the IT Asset Management Conference in Las Vegas on Wednesday... so I'll be in the air much of Tuesday.

If you find yourself in Vegas - and get bored of the usual things to do there - come on down to the Mirage and hear me talk about the licensing decision making process and performance guarantees. And, if you had a hankering to buy the book, I made the mistake of offering it at a significantly discounted for conference attendees.

Yes, I realize this is short notice. So: here's your next chance:

Technology Procurement Conference in Chicago on July 9-11, 2007. I'll be talking on the topics of "Drafting better Software Licenses" and "Open Source Software Considerations". I'd love to see ya' there!

But in both cases, I'll be sure to have some carry-over topics to discuss here in the weeks that follow. So check back soon to see what you missed!

Revenue Recognition

2007-06-19T09:54:00.000-04:00

One of the most confounding negotiation topics is Revenue Recognition (RevRec). This is partially due to ill-informed people and partially due to a lack of understanding on BOTH sides of the negotiation table. For the purposes of this post, I'm talking about the "RevRec Excuse" - when a vendor uses RevRec as a way to block a request for some contractual provision.

The American Institute for Certified Public Accountants (AICPA) releases published guidelines for accountants, auditors and other financial management folks on how to account for a variety of transactions. In 1997, they released the latest version of their RevRec guidelines for software transactions, SOP 97-2 (with a small amendment in 1999). This book is available for purchase via the AICPA. I highly recommend that negotiators who do software transactions buy a copy. It's $17.50 well spent.

These guidelines lay out the framework for how an organization should account for software transactions, including maintenance/support, custom development, refunds, future purchases, etc. So, when a party makes reference to revenue recognition, they should be able to support the statement with a reference to a section of SOP 97-2.

Of course, this rarely happens. The buyer wants something like future versions of the current product and the seller's response is that "no, we can't do this because of RevRec issues." From a negotiation perspective, this is using the "authority" tactic. (If you've never heard of this tactic, check out Herb Cohen's books.) Essentially, they're telling you that there's a written authority/guideline/policy that prevents them from doing what you are asking... but oh, they would help you out if they could.

"OK," I respond. "Can I please talk with your accounting director who is enforcing this guideline?"

This request is usually met with resistance, but if they want to use the RevRec excuse, we'll need to explore it with the policy maker (which is almost never the negotiator). Once you have the accounting director on the phone, simply ask them if they follow the AICPA RevRec guidelines (you can even call it out by name: SOP 97-2, they'll know what you're talking about).

If the answer is yes, lead them through the guidelines to show them how your request doesn't violate the guidelines. Or, if your a bit more bold, ask them to show you the guidelines that are preventing your request. Either way, you need to have read the guidelines to know what you're talking about. But they're pretty straight forward, so don't worry too much.

In the event that the buyer does not want to read SOP 97-2, or if they simply don't care about the vendor's RevRec issues, the buyer always has the ability to use an alternative response to the RevRec Excuse.

"Your RevRec issues are not my problem."

I give this response to you so you know that it might come (a gift to my vendor-readers). It truly isn't the buyer's problem to worry about how the vendor is going to book the revenue. Just like it's not the vendor's problem to figure out how the buyer makes their payments on time, so long as they do.

This doesn't prevent the buyer from using this statement, and it doesn't help the vendor respond, though. To respond appropriately, the vendor should have a firm grasp of the real issue. If it's really a RevRec problem, be prepared to support it with the SOP. If it's really a RevRec Excuse, be prepared to concede the point.

At a higher level, however, the vendor should not use RevRec as an excuse. Like our discussion of Maintenance from last week, there is a snowball effect. The more it's used as an excuse, the less impact it will have overall. Most vendors I've worked with have made every effort to give me what I'm asking for - especially when they know that I'm educated about their issues (another reason to read the SOP).

Maintenance Percentages

2007-06-12T09:54:00.000-04:00

How much are you paying for software maintenance?

In the last 10 years, it seems that the average price for maintenance has increased from 8-10% for basic maintenance to nearly 20%. The underlying service hasn't changed. Software really isn't THAT much more stable than it was a decade ago (twice as stable? I doubt it). So what's up with the increase?

Personally, I think it's laziness. No, not on the part of software vendors. They're doing what the oil companies are doing... which, in essence, is what basic economic theory demands they do. They're increasing their price to the point that the market will bear. And, for whatever reason, buyers have been paying higher and higher maintenance costs. In fact, I received an invoice the other day for 30% maintenance for 8-5, M-F, no frills service!

I've been saying this for years, so now I'm going to repeat it while I know a few folks are really listening:

Stop paying outrageous prices for maintenance and support!!!

Please. Really. Because if you accept that higher maintenance price, the vendor is going to expect me to do it, too. And I'm not willing to pay high maintenance prices for the same service I was getting 10 years ago. Oh, and I definitely don't want to be paying that price against the "then-current list price" of the product.

So, buyers, do the rest of your fellow buyers a favor. Don't accept high maintenance prices without a comparably high level of service. 12-15% is about right for basic maintenance these days. Which includes bug fixes, updates, upgrades, new releases, etcetera. Pay up to 20% if you're getting 24x7 service. Anything higher should be "white glove", on your doorstep the next day, kind of service (which, btw, nobody seems to want to provide).

Vendors, charge a reasonable amount for maintenance and support or be prepared for some buyers to cancel their maintenance contracts (or not buy any more at all). M&S used to be a fairly steady stream of continued revenue. But unlike car owners, I don't need my maintenance plan to use my product indefinitely. This isn't a threat... it's just the ranting of a guy who recently finished his MBA Economics course and is feeling a little bold today.

Take this EULA... and shove it!

2007-06-05T09:54:00.000-04:00

[Note: The following is an article written for Soft*Letter early this year. I got a few calls about EULAs the other day, and like NDA's, I felt they deserved a shout out. The article is a bit long and does cover some topics already discussed - the advice given herein is specifically for EULAs and is from the customer's perspective.]

Have you (or your sales team) ever gotten this call?

“Hi! I’m Jeff from the contract management group at yournextcustomer. I’m calling about the End User License Agreement (EULA) that your distributor would like us to agree to before purchasing your product. I just have a few issues with it and want to know where to send a redline.”

Do you know what is happening or about to happen? The call above is not fabricated, as it is a conversation I have personally started hundreds of times with a variety of software vendors over the last several years. The companies I’ve worked for believe they are large enough to not have to agree to a one-sided contract and I was hired for the express purpose of negotiating a more favorable license agreement with each of our vendors. Invariably, I start with the sales contact, get passed to management, and I usually end up with a contract more favorable to my company than it is to yours.

When I initiate the call, I am usually confident about two key things. The first is that you want our business. As a large buyer in a particular industry, you may want to leverage experience in that industry into more lucrative deals. I count on the fact that you realize that an initial purchase is almost never the final purchase, and that getting your foot in the door with a negotiated agreement is better than no deal at all. Secondly, and perhaps more importantly, I know that I can use that “want” of business to leverage you into using my template license agreement. Truthfully, neither of these two facts will probably change. You will still want your customer’s business and will still be willing to make concessions in order to reach that goal. The important next detail, then, is an awareness of the various options available when a customer refuses to agree to your EULA.

Initially, you have three possible options, depending on your comfort level and pre-planning: a) Offer the customer a negotiable Software License Agreement, b) Negotiate the terms of the EULA itself, or c) Use the customer’s template Software License Agreement. Obviously, if possible, you would want to use option (a) first. It’s probably longer than your EULA, but it also has probably been written in a way that would allow for some concessions to various terms and conditions.

Options (b) and (c), however, pose more difficult challenges. EULA’s are now distributed to the customer by one of two main conduits, either as a click-through agreement or as a PDF, sent prior to the sale or attached to the ordering document. As a negotiator, I prefer to use an electronic form of the agreement, so having a word-processing document format would be advisable. Using e-mail to send the document to your customer subtly tells the customer that you have a document from which you want to start and it opens the door for negotiation without agreeing to use the customer’s template.

Regardless of which document you end up negotiating, there are key license and other terms that you need to consider with respects to margin, liability and feasibility issues. In essence, you need to evaluate the language with an eye to profitability, exposure and whether you can actually live up to the agreement. Your answers to these issues, of course, are unique to your business, but the following sections are usually considered the most crucial to any software license and should be paid special attention.

License Grant
While the nature of software licensing versus sales is beyond the scope of this article, suffice it to say that you will be granting your customer a set of rights to your software. These rights can be as simple as the ability to use the product, and as complex as the ability to create and/or own derivative works from your product. Additional considerations such as backup copies, location-based restrictions and other options results in your need to clearly understand what you want to allow your customers to do with your product and what rights they will need to accomplish their purpose for licensing.

Warranty
In days of yore it was once common to see a one-year warranty. More common now, however, is a short-term warranty of anywhere from 30 to 90 days. The reduction in length is a function of the real purpose of a warranty, namely, to show to the customer that your product works as advertised. The complex nature of customer environments discourages software vendors from offering a longer term warranty, as the risk of issues increases the longer the product is installed. On the other hand, most customers believe a warranty to act in the form of an insurance plan – a way to guaranty that the product continues to work over a longer period.

Customers also have a tendency to believe that warranties are the free version of maintenance or support services. To their credit, this was a functionally accurate description until the late 1980s, when many software vendors started offering maintenance programs designed to provide long-term support and product updates. Once the two types of help (at the time of installation versus in the future) were delineated, customers were often confused by the software vendor’s attempt to separate these concepts in the contract.

Today it is imperative that a warranty describe those things that you guaranty will never happen, and those things that will be fixed at no charge (for some limited period of time). Amongst this list would be warranties that protect the customer against problems resulting from ownership issues, conformance to documentation, processing four-digit years and a warranty protecting the customer from the introduction of malicious code.

Indemnification
When a customer licenses software, one of the last things they want to have to worry about is a situation where the software vendor does not have the right to license or is not the owner of the product licensed. This scenario creates substantial financial liability that the customer believes they are paying the vendor to assume. As a result, the concept of indemnification is used by vendors to promise to customers that they will be receiving an unencumbered license (based on the license grant as discussed above). Indemnification obligations are most often a) limited to only cover the most recent version of a particular product, but b) offer unlimited financial protection to the customer (the cost of the product, attorney’s fees and any damages awarded to a true owner). An EULA may offer little or no indemnification, but the desire by a customer to include an indemnification section should not come as a surprise to a software vendor.

Confidentiality
Another common, but often overlooked provision is one detailing the confidential information of each party and the obligations the recipient of confidential information will have to the discloser. Confidentiality terms should almost always be mutual. Each side should have an identical obligation to the other side with respects to how they are going to treat information they receive. Software would be included within the definition of confidential information for the vendor, whereas specifications, drawings and other work product might be information special to the customer.

There are five standard exclusions from protection: 1) information already known by the recipient, 2) information later received from someone not under a confidentiality agreement, 3) information put into the public domain, 4) information you’re later told by the discloser is no longer confidential, and 5) information required to be disclosed by a court of law (so long as recipient gives the discloser reasonable notice that they’re being compelled to provide confidential information).

Term and Termination
Software license agreements are usually found to be either perpetual (license the software once and there are no additional license fees) or term-based (license the software for a set period of time and renew the license afterwards if still needed). A third variety, the so-called “subscription model”, is essentially a term-based license for a set number of years and the license includes maintenance, support and upgrades. There is a faction of attorneys and negotiators that are concerned about the perpetual model, and thus resort to a 99-year term license. This is not a subscription, but a way to license the software well beyond its useful life. When negotiating, watch for the conversion of a term-based license to a perpetual license and for the inclusion of maintenance, support and upgrades.

Termination is also a consideration, as most EULAs will have broad termination rights for the vendor. It is not uncommon to have almost identical termination capabilities for both parties and to limit termination for cause to the breach of a party’s obligations. Customers sometimes desire the ability to unilaterally terminate the agreement without cause (you can’t force a customer to use the product). Vendors can usually accept this provision with the caveat that the licensee and/or maintenance fees for the current term still be paid as due under the agreement.

Maintenance
Perpetual and term-based licenses are designed to allow continued use of a product over a long period of time. In the meantime, the software vendor continues to develop their product line as well as provide support for the current products. Customers are usually offered the ability to purchase maintenance as a way to obtain those newly-developed products without paying the entire licensing fee all over again, as well as to enable the vendor to offer help in the event of a problem. Confusion sometimes happens when maintenance and/or support are separated into their component parts or when service capabilities are redefined to mesh with the customer’s needs. Care must be taken to be sure that what is sold is actually able to be provided and that what is provided is going to satisfy the needs of the customer.

Converting an EULA into a fully-negotiated contract is not usually advised, as the level of risk involved in the transaction can increase proportionately to the changes in language. If you do not have a full Software License Agreement and you are selling a product for more than $15,000-$20,000 (either a single product or an average sale), it is advisable that you have one developed, as buyers of that quantity of product expect the ability to negotiate. As starting the negotiation process from your preferred language is one goal of the EULA, maintain that advantage by developing a negotiable license as well.

How Much for that Maintenance in the Window?

2007-05-29T08:18:00.000-04:00

[The following is an excerpt from the Software Licensing Handbook. If Google never gets around to allowing you to "view inside" the book, I guess I'll have to do it here over time.]

Maintenance and support comes at a price, usually expressed as a percentage of the license fees paid in the license agreement. This should encourage two things from the customer’s side:

Negotiate the initial license fees down to the greatest possible discount. If this is a perpetual license, these fees will not recur.

Negotiate the maintenance and support fee percentage down to the greatest possible discount. Industry average is between 8 and 12 percent for 8-5 M-F support (allowing for a 3-5% increase for 24x7 support), while most providers initially request 20 to 25 percent.

Additionally, maintenance and support fees act in a similar manner to other fees in that they can increase over time simply due to provider choice. Therefore, negotiating a cap on the increase in any fees is always advisable and almost always accepted by the provider, even if not included in their initial language. As with future orders in a license agreement, an increase of 3% per year is almost always acceptable, with the possibility of tying the increase percentage to the Consumer Price Index.

Providers will sometimes have difficulty in accepting a perpetual cap on the maintenance fee. This is usually either based on a future income concern or as a result of revenue recognition. With respects to maintenance fees, revenue recognition is not applicable. However, it is not unreasonable for the customer to need to realize that a provider who locks in maintenance perpetually might not be able to afford to provide services in the future as a result of lowered income. Compromise can sometimes be found in setting a time limit for the cap, but then stating that the parties will return to the negotiation table to discuss the next year’s fees.

Strategic Sourcing

2007-05-22T08:08:00.000-04:00

You read a contract because you are either buying or selling something. On the purchasing side of the transaction, many organizations have a procurement group (called "Purchasing" or "Procurement", sometimes "Sourcing") and many also have a contracting group (almost always just "Contracts"). And, within larger organizations, most believe that the combination of the two groups automatically bestows upon the organization the coveted concept of "Strategic Sourcing".

The mere existence of Purchasing and Contracting teams, even if they're working together (which isn't always the case), doesn't mean that an organization is doing any sourcing, nor does it mean that they're doing it strategically. The plain truth is that it takes a dedicated effort, above and beyond having the groups working together.

The creation of a strategic sourcing team for your organization (and a strategic sourcing plan) starts with a recognition of the end goal: making purchase decisions based on significant data analysis and always with the best interests of the entire organization in mind. Sounds simple, of course.

Let's talk about strategy first.

Information alone isn't helpful. Most organizations' contracts files are filled with millions of words in thousands of contracts. The information itself is already there - the key is to be able to sift through the data to get exactly (and only) what you need when you need it. This is the primary argument for a good contract management tool (Procuri, Emptoris, Nextance, etc). Once such a system is in place, much of the ground work has been laid - the trick then, of course, is being able to keep the information updated and to be able to mine it.

Your digging and mining is to discover not only where you're spending your money - but what vendors are doing which types of work, where there are overlaps in skills, even where you have multiple pieces of software doing similar tasks. Again, this isn't difficult. From the point where you decide to start looking at this information to the point where you have good research results can take as little as six months for an average sized organization. And unfortunately, this is where most organizations stop. They have "a system" - people are even using it faithfully. They know who is doing what, when, and for how much.

Which is why, to get to true Strategic Sourcing, you have to worry about the sourcing side of the phrase.

What's lacking in most places is this next step: where decisions on purchases change as a result of the data in the system and where some vendors are even eliminated as a result of consolidation and house cleaning (ie: "sourcing" a solution rather than just buying one). This is admittedly a difficult task. Culling through your records (and staying on top of them at all times) to diligently maintain the discipline needed is a full-time task beyond the scope of most contracts and procurement people (who are usually just trying to keep up with demand). Thus, taking a strategic sourcing direction requires additional staff.

And remember when I said "vendor are eliminated"? As you might imagine, this isn't always a popular decision. Selecting the downsized vendor(s) involves a painstaking process and requires political savvy within the organization. In fact, it might even add additional expense (contract termination fees, replacement systems on other vendor's platforms, etcetera). No two organizations are identical, each one has to decide what is the right option - but at the end of the day, if strategic sourcing is the goal, the price to get there for an organization that hasn't been doing it from the start is going to be significant.

On the reverse side of the coin, cost savings from moving to a strategic sourcing model are high. Volume discounts alone, via one or two vendors who do "x" task rather than 30 vendors each doing 1/30th of "x", can net substantially-reduced expenses. Ask any organization that has done this exercise with their HR staffing contracts - the consolidation consultants themselves promise millions.

But it's not just cost savings that makes strategic sourcing valuable. The real benefit is in reduced time to contract, fewer agreements/relationships to manage, and the overall reduction in risk from having so many different relationships.

Regardless of where your organization sits on the path, however, the ultimate goal should be Strategic Sourcing. It will take time, effort and cooperation - well worth it for the end result.

NDAs

2007-05-15T07:07:00.000-04:00

I don't know why, but I've had a spate of NDAs cross my desk in the last week. Seemingly innocuous little documents, Non-Disclosure Agreements (sometimes also known as Confidentiality Agreements) are usually the starting point for all new contract negotiators.

Perhaps it's because they're generally short in length (usually no more than a page or two)... or perhaps it's because they're usually not very contentious (both parties desire to keep some set of secrets). But whatever the reason, all of the ones that I've done in the last week have had some sort of difficulty factor that just seemed out of the ordinary. So, let's see if we can address common NDA concerns.

Starting with the basics, NDAs should clearly state the purpose for which the NDA is going to apply. You usually don't want a generic NDA - it simply becomes difficult to manage the obligation over time... and since they're usually easy to negotiate, doing another one for a future obligation isn't seen as too problematic. Additionally, once you create a contract based on the purpose (ie: the NDA was the precursor agreement to a bigger, more involved relationship), you also usually have confidentiality language in the bigger "master" agreement anyways.

A NDA should also clearly define what is being kept confidential. This would seem to be a simple task - what you bring to the table is yours, what the other party brings to the table is theirs. This, of course, is too generic (too simple, I suppose). So get more specific... "documents, templates, source code, plans, drawings" etc. And if your business involves the capturing or use of information from your customers (such as via a financial institution, an insurance organization, a health-care company or any other business, too), you will want to detail that your customer information is confidential.

But then you have to carve away those bits of knowledge that are generally known in the world/industry. And you need to remove from obligations of confidentiality those bits that you learned from somewhere else (who provided it to you "lawfully" and not while they were under an obligation to keep it secret). Getting confused yet? What you end up with is a list of things that are confidential... and a list of exclusions for ways in which you obtained information and don't have to keep it confidential.

Then you need to add a list of reasons why, even for information that is confidential, you can disclose it anyways. This would include a valid court order, for example. (But wait! You usually first have to tell the other party that you're being compelled to disclose the information so that they have the time to try to fight the order.)

Of course, you also need to list who can see the Confidential Information and for what purpose they may use the information. You don't want your new business partner to take your information and develop something based on it without your permission, for example.

Next, don't forget remedies in the event that your Confidential Information is disclosed in a way not allowed under the agreement. The usual analogy here is to Pandora's Box and the inability to put the secrets back in the box once released. It's simply impossible. Legally, you'll want to file an injunction to prevent further disclosure... but you also may have monetary damages as a result of the disclosure (for example, if another company steals your great idea for a new product, you can attempt to sue for lost profits). So I generally like to use a conversational phrase with my counterparts when discussing this section... just in case there's any confusion.

"If you disclose my Confidential Information, I am going to own your company."

In other words, the penalty for disclosing my information is going to cost you so much, that you're going to go bankrupt in the process of trying to put the lid back on the box. This is especially true if you're in one of the aforementioned Customer Information industries... and REALLY REALLY true if you're dealing with Protected Health Information or Financial Information - which are both protected by various federal and state laws as well. Which, by the way, means that if you're the recipient of this kind of information - of any Confidential Information for that matter - you need to take the obligations very seriously.

Lastly with respects to NDA basics, you need to know what to do with Confidential Information once the NDA terminates. Usually it's "return or destroy". Some organizations want one over the other. And some also want "certification from an officer" of the other party that destruction, if the chosen option, has been completed in a timely manner.

OK. So let's review:

Definition of Purpose
Description of Confidential Information
Exclusions from stuff that's otherwise Confidential Information
Reasons why you could disclose Confidential Information
Who can use the Confidential Information (and for what reason)
Remedies in the event of disclosure.
Return or Destruction of Confidential Information after NDA ends

"Are we there yet?"

"No."

What's left, of course, is the boilerplate contract language that you find in many other agreements. Sections on assignment, governing law, severability, term (again, how long should this thing go on?), party relationship and even a section on signature counterparts all get included, too.

Phew, maybe NDA's aren't that simple, eh?

Demo/Eval Agreements

2007-05-08T11:18:00.000-04:00

Almost every large software purchase is predicated on the ability of the end user to review the product. When you're buying something of that magnitude, it's not unreasonable to have that testing time.

But vendors don't just deposit software at even their most favorite customer's facility without assurance that the software is going to have some sort of contractual fence protecting it from release, abuse or misuse. So the typical pattern for a customer to test software is a one-two contractual punch of a non-disclosure agreement (NDA) in addition to, or part of, an evaluation agreement.

We'll talk NDA's in the near future - today is about the eval.

Evaluation agreements (also called Demo Agreements) are used for GA software, not just software still in development or otherwise limited or restricted in some way. So invariably, the contract presented is a repurposed software license... which does, actually, have the right type of terms and conditions necessary to effect the temporary relationship desired.

The problem, however, is that temporary relationships have a tendency to become permanent simply by inattentiveness. And a contract that's designed to be temporary has probably been given less review attention at the outset of the relationship. Which means that a long-term eval/demo agreement is essentially a possible perpetual license agreement. Combining the lesser review attention with the possibility of perpetuality, and you get a bad deal from the customer perspective.

The fix, of course, is diligence. Remember that each interaction between vendor and customer has the chance to last much longer than originally intended... the chance to apply to things never initially considered. And it is for this reason that many contract professionals have a negative visceral reaction to eval or demo agreements. The business people believe that it's "just a demo", and the contracts folks know that it can become so much more.

When reviewing an eval agreement, the most effective solution is to place a termination date in the agreement itself. This will cut short the demo/evaluation process (which the business folks must be aware of), but it will at least prevent the eval from becoming the more permanent software license for the purchased product. Of course, this doesn't stop someone from amending the agreement to make it last longer, but at least there's the chance that the someone will also at least ask the question of why there was termination for the eval in the first place.

If you have the time or wherewithal, evals should be reviewed in as much depth as any other normal software license agreement. This allows you the flexibility to slip into a longer term relationship without worry about the terms and conditions of the underlying agreement (and without additional review/negotiation time/expense). But it does require a more extensive up-front investment of time, which is often problematic for organizations that don't have a lot of contract reviewing staff or are paying outside counsel for time to review agreements that might never lead to a purchase.

Oh, and by the way, NEVER accept any type of eval agreement without the same IP Indemnification clause you would get in any other software license. If you're going to install the software at your organization, you need the same protections that you'd need from purchased software. Arguments from the vendor that the customer is not paying for the software and is thus not eligible for protection should not be paid any attention.

Whatever the solution that is right for you, just remember that the eval is just as binding as any other agreement... the term "eval" isn't meant to describe the agreement.

Copyright reform

2007-05-01T19:52:00.000-04:00

Jonathan Lethem would like to see a world where each artist can decide, at the time of their creation's release, the rights their customers/fans/etc will have with respects to using, copying, recycling, etc that creation. As part of this, he's going to release certain film rights and other derivative work rights to his next creation, You Don't Love Me Yet.

He claims "The point is, it ought to be up to the artists." And as the article on Wired states: "Listening to Lethem, one imagines a world where every artist crafts an idiosyncratic copyright notice, with its own strange rules, to adorn the front page or liner notes or gallery notice fronting her creations."

What I find troubling about this push for copyright reform is that the "reform" that Jonathan (and others) are asking for already exists. The truth is that even since the beginning of copyright protection, the artist has ALWAYS had the ability to dispense of their given rights in any way in which they feel comfortable.

So, if you write a poem, craft a sculpture, paint a painting or make a movie, you can give away your rights in any form or fashion you choose. You want to allow people unlimited copying ability? You can. You want to restrict copying so that they have to BUY your work, but then they can create something new based on your work? You can. You want 100% restriction? You can do that, too. There's nothing in the current copyright laws that would prevent anything that Jonathan is talking about wanting to do now.

In all, copyright doesn't need reforming. Consumers (and artists) need education. Artists need to understand that if they use certain distribution organizations (publishers, printers, distributors, etc), they're going to give up some of their rights to those organizations in exchange for the services those organizations provide. There are alternatives, of course. For publishing, there's your own personal PC + Lulu (my favorite); for movies, again there's your PC + YouTube.

But don't claim that the current laws need to be changed. Know your rights. Use them.

Open Wha?

2007-04-25T00:01:00.000-04:00

[OK... my bad... things got a bit busy yesterday.]

I live in Raleigh, NC - home to RedHat Software. Most of you have heard of RedHat as a result of their linux offering. But more than that, almost everyone has heard of RedHat because they sell free software. Initially, this was absolutely dumbfounding, confusing even seasoned contract negotiators with the world's first broad introduction to the concept of free software, also known as open source software.

[Let's clear something up just in case there are still any misunderstandings. "Free" software, is not actually free. The term "free" is meant to refer to access to the source code, not to financial costs. As a result, it's better to use the term "open source" when talking about this access.]

Open source software, then, is based on the idea that the source code would be provided along with the object code at no additional charge. In other words, you still end up BUYING the object code, but you get the source for free and a license to make changes (and distribute the source code per the constraints of the license if you make said changes).

But all of this open distribution leads to an absence of definitive liability. The result is that if you have licensed open source products for use in an enterprise environment, you can have problems with indemnification, warranty, and other "missing" traditional contract terms. So the trick is to understand the scope of the open source usage in your environment in conjunction with the license provided. This obviously can become a large issue.

Additionally, there are currently more then 50 "accepted" open source standard agreements. Each one is unique in some form or fashion - and thus each one provides at least a small difference in terms of the rights and obligations apportioned. The net effect is that each of these licenses has to be read very carefully. Any vendor looking to use open source software (and any customer looking to use a vendor who uses open source software) needs to read, re-read, and triple-re-read the license to understand the specifics of what is provided, what has to remain "open" in the future and what kinds of protections you have in the event of a problem. At the end of the day, then, what you have is a completely custom software license that has to be read with a fine-tooth comb. DO NOT TAKE THE USE OF OPEN SOURCE SOFTWARE IN VENDOR PRODUCTS LIGHTLY!!!

ICN offers a slew of conferences and presentations on a variety of contracting and negotiation topics. In June, the Technology Procurement Conference in Chicago will offer attendees the chance to deep-dive into technology contracting-related topics in a series of 3-hour sessions. It sounds like one of the topics for this conference is going to be on Open Source procurement. Check it out (especially since I'm going to be there as a presenter)!

Contract Management

2007-04-17T06:18:00.000-04:00

In a recent Ken Adam's posting, he discusses some of the tension that exists in organizations between the business folks and the legal folks and asks some good questions about how the two can work together to better serve the organization itself.

These questions stem from long-standing assumption the neither party really respects the value provided by the other. Business folks assume that the lawyers are simply there to be the "Order Prevention Department" (Ken called it the "Business Prevention Department") and Legal folks assume that the business people will buy anything shiny (or with a power cord) put in front of them without considering anything other than "do we have enough money to pay for it?". But the truth is that neither side is actually as bad as the other sometimes believes. The trick is getting people to work together for the common goal of helping the company move forward efficiently.

So, if it's really that simple, then, how do we make it happen? Well... yes, saying the words is simple. Walking the talk, well, not so much. The problem is that each side has a competing interest with the other. Like any good negotiation between disparate parties, then, the key is to find the common ground and to build off of those shared goals to craft a relationship whereby both sides feel that they are getting what they need, but are allowing the other side to "win", too.

It's complicated at times, of course. Even if you have a business unit that recognizes the importance of legal, a particular deal (usually a result of some sort of end-of-year fire sale) that has to get done now will derail even the most stable legal-business relationship. Likewise, for smaller in-house legal teams, larger business distractions such as lawsuits, high-level corporate governance issues and other items seen as more pressing than contracting, sometimes takes away legal's ability to be responsive to the needs of the business units.

Although I'm obviously biased as a contract negotiator myself, I feel it only proper that such organizations should have an internal contract management group. This is a dedicated team of specialists who understand the contractual terms and conditions (and know how to get support from legal when they need help or see something new or particularly difficult)... but they also understand the shifting and sometimes hurried needs of the business, too.

A contract management team is NOT an administrative group of paper-pushers, though. The team members must be highly-skilled professionals (sometimes even lawyers themselves). They have to receive continued and intensive education on contract review, drafting and negotiation. They must be able to spot potential risks and know how to mitigate those risks without sinking the deal. Additionally, most also need to have a solid grasp on many facets of the business units to which they provide support, so much so that in some medium-to-large organizations, contract professionals are even sub-specialized to these units. The end result is perhaps a contract management department that has an IT contracts person, a facilities contracts person, a services contracts person and sometimes even a dedicated HR contracts person (just to name a few).

This team then works diligently to assist the business units in closing their deals (by the way, this specialization works in sales-organizations, too, with sales contracts people) as efficiently as possible. In companies that really understand the value of how this group can work, they allow the contract management team the ability to function autonomously - managed by the organization, of course, but not controlled by the groups they work to serve. They have priority access to Legal - as the lawyers learn to trust the contracts professionals to come with key, important and already-reviewed issues... allowing the lawyers the ability to only have to provide tactical contract assistance and review, rather than read/negotiate the entire document from top to bottom.

At the end of the day, I've never seen an organization that creates a contract management group ever disband it. Centralizing this function offers a high level of benefit to the entire company, and in my personal experience, these groups are usually well-respected in their organizations for providing prompt, sound business and contractual judgment and advice. I would be interested in hearing your experience with these groups (though I suspect that many of you are in these groups).

Software Licensing Handbook Wiki

2007-04-10T00:01:00.000-04:00

A few weeks ago, I was asked by a reader if I had thought about creating a digital version of the Software Licensing Handbook. He suggested the creation of a database based on the book, using the sections as the key articles. I really liked the idea, but struggled with a way to make it interesting and useful not only to those of you who don't have the book, but also valuable to those that do. In essence, I wanted to add additional value to the book, not replace it.

Continuing to think about it, I came to realize that a semi-static wiki was perhaps the best way to electronically "publish" access to the bulk of the content of the book (some sections are harder to translate to a database/digital form). I've created the wiki with pages for each term, categorized the terms and I've limited the reader to a read-only view (with the ability to add comments, but not edit the main article itself).

My goal here would ultimately be to license access to the wiki - the main article would remain as it is/was in the book... but readers could add information/suggestions that are perhaps industry-specific, or country/region specific (as I would love to hear what other countries laws do to US-style software licenses).

I want to do this efficiently and effectively. So I'm looking for some folks who would be willing to serve as beta testers. I'll provide you access for a beta period where you can play and explore, and even add comments. In sum, you'd have "full" reader access during the beta period. If you don't already own a copy of the Software Licensing Handbook, this would also provide you with a serious review opportunity of the content of that guide.

I'm thinking that 10 people (and I would prefer them to be scattered throughout the world, as I see I have readers in just about every country) would give me some good feedback. I make no promises on duration or future accessibility... this is merely an indeterminate beta trial period.

Any takers? Please e-mail your name and e-mail address to me (the wiki is password protected and I will need to give you the URL, too). I would like to know where you're from geographically and what you can contribute in terms of feedback, beyond just the ability to look at the wiki. For example: are you a lawyer in Germany? a contract negotiator in Spain? a paralegal in Australia? are you an author? a student? an internet god?

I look forward to hearing from you!

NCMA Book of the Month

2007-04-07T06:12:00.000-04:00

Don't worry, there will still be a regular Tuesday posting... but I just saw that the Software Licensing Handbook was selected by the National Contract Management Association as the April, 2007 Book of the Month!

I've never received this kind of recognition before, so it's exciting to me. Thanks for letting me share. I'll now return you to your regularly scheduled programming, but stay tuned for an exciting announcement next week!

Service Levels

2007-04-03T22:37:00.000-04:00

The last thing most people want to consider while starting a relationship is what happens if the deal goes south. As a result, areas of the contract having to do with breach, termination and service levels or performance guaranties tend to lack the same depth as others.

Specifically with respects to service levels, the goal is to create a measurable set of steady-state obligations that are able to be met by the product. The first two steps are then to list the obligations themselves and their associated performance level. This could be as simple as saying that the product will operate uninterrupted to a certain percentage of the day, or as complex as 30 or 40 individual operational features that have to perform to a certain degree or quality (such as providing a report generated in a specific time period).

After you know what obligation(s) to watch and the required operational level, the next step is to make sure that the obligation actually can be observed. Many SLAs are good in theory, but don't provide practical metrics simply because there's no way to know whether they have been met. For example, many parents want to know that their newly-driver-licensed children can't or don't exceed the speed limit... but until there was a device that could watch maximum speed, reliance was upon the integrity of the driver.

Next is determining WHO is responsible for tracking the SLA. This entirely depends upon the product - I've seen the responsibility equally distributed between both licensors and licensees... just make sure the party who is tasked with the job knows that it's their responsibility. But, especially with services-related tasks (or ASP/SaaS products), the job normally falls to the vendor/licensor, as they're in a better position to watch performance.

The "watcher" should then also be in charge of reporting the metrics to the other party on a regular/consistent basis. If the obligation is that a service will be available 24x7x365 with 90% uptime, then it's reasonable that each month a report will be created showing any downtime and how that compares to the 90% requirement.

Lastly, and usually of primary importance to the licensee/buyer, is the issue of what happens if the metric is "blown" and the SLA is missed. Contractually-based remedies are my preferred method for handling this what-if - but unless the true damage of missing an SLA is calculable prior to the missed service level, there's the chance that any contractual remedy will fall short of actually fixing the issue. So rather than focusing on penalties, which is often what happens in the negotiation, focus attention on how much effort will be used to solve the current problem and prevent future problems.

If a vendor is then unable to prevent the problem from recurring, or in the event that the SLAs continue to be missed, financial penalties can be included as a last resort to return some of the fees paid for the lack of 100% guaranteed service.

So, when creating SLAs, take the time to discuss the needs behind the SLAs with each other. As with other sections of the agreement I've discussed in the last few weeks, a little open, honest communication at the beginning of the relationship can avoid lots of future problems.

Term Interrelationships

2007-03-27T00:02:00.000-04:00

If you've been following along with us in the last month or so, you'll have realized that the problem and complexity with software licensing isn't the individual terms themselves, but rather the interrelated-ness and exchange that transpires when you want to cover yourself.

A change in one term, like assignment, might affect a change in the license grant (such as the license metric), which has an effect on the initial price... and probably the maintenance price too. Which creates anxiety on the part of the licensee (who has a constrained budget), and possibly on the licensor, too (especially if they have a limitation of liability clause that's tied to the price paid and as the price goes up, so does their liability).

Net-net is that what happens next is a comedy of errors. Both sides' increasing anxiety comes across as either trepidation/hesitance with respects to closing the deal, or anger as a result of increased pricing and risk. What almost never happens (and what would prevent this increased anxiety and anger response) is an honest disclosure of interests.

The truth with regards to software licensing, and all other contracts for that matter, is that it's a gamble... a risk. Each side is doing everything they can to protect themselves from every conceivable angle. Three page software licenses from the early 90s are now 30 page behemoths - written to close every gap, every loophole, every eventuality. It's just not possible. Risk is the only true eventuality and you can't entirely escape it. The best you can do is to mitigate it, and be honest with yourself and the other side about those things that scare you the most.

If you work together, you'll find a lot of common ground... and ways to balance risk with the possibility of reward.

Assigning Software Licenses

2007-03-20T23:50:00.000-04:00

Last week, we discussed Assignment, primarily as it relates to services-type work and the issues that come up in that particular arena. This time, we'll add additional complexity by dealing with software license assignment.

[Note: the term "assignment" is used with respects to rights and the term "delegate" is used with respects to obligations. I will use the term "assign" or "assignment" through this post for both, but when drafting actual contract language, keep both terms in mind.]

Recall that assignment is the redirection of all or some contractual right(s). Template language in most agreements prevents unilateral assignment, usually requiring the permission of the non-acting party to complete the act. For services-type work, it's fairly common for subcontractors to do bits and pieces of larger agreements... and prime contractors do have a tendency to disappear sometimes. But when you deal with software assignments, the game changes. A lot.

Assignments with respects to software manifest normally in ASP and SaaS relationships. As discussed in this blog before, a service provider relationship for software works by allowing the service provider to have some sort of right to host the software. In some cases, this is done with assignment language, allowing the licensee to grant a service provider the right to host the software on behalf of the licensee during the ASP relationship. With SaaS vendors, however, this right is part of the license itself, as the vendor is the service provider.

Assignments of all rights, however, get a bit more sticky. Software vendors price and license their products based on the perceived customer value that the software brings to that particular customer. The vendors, however, can't know this value explicitly, so they guess and create a price they feel is reasonable and one that will be paid by the licensee. Again, as discussed previously, we've seen that licensing metrics are used as a way to calculate that value.

A customer who assigns all of their rights to another party can mess up this calculation, especially where site-based or enterprise-type licenses are involved. The problem can most easily be illustrated by imagining a licensee with 1000 employees in a single geographic location obtaining an "enterprise license" to a particular software product. They're charged a fee, created by the vendor, based on the number of employees at the time of the initial license grant - and based on an estimate of how large the company will grow over time. This wasn't usually a problem. Until companies began merging like wildfire.

Today, that same 1000 person company could be acquired by a 10,000 person company. If the assignment language isn't written appropriately with this in mind, the software vendor may have unwittingly granted an enterprise license that is now for 11,000 people rather than 1,000. As a result, language in software licensing is now adjusted by software vendors to remove the ability to assign (and fewer enterprise licensing schemes are used, too).

But customers do sometimes need the relatively-automatic ability to assign a contract as a result of a merger, acquisition or other transfer of ownership of the organization. Most contract boilerplate language allows for this. Software vendors who are granting site or enterprise licenses, however, should continue to remember that this could lead to the example situation above. Therefore, take the time to perhaps create a "carve-out" whereby an assignment due to this type of transfer would convert the license to a set number of users... or to a very specific geographic location. This still allows for the assignment, but doesn't open the software usage floodgates.

Assignment and Transferability

2007-03-13T11:00:00.000-04:00

Assignment is the ability to redirect an agreement (or a portion of an agreement) to another party for some purpose. In many situations, it's a way to allow a third party the ability to perform some subset of contractual responsibilities (ie: a subcontracted electrician or programmer). In the case of say, a credit card cardholder agreement, it allows the issuing bank to act in your shoes to receive money, sue, etc. In other words, it allows rights and responsibilities to be "assigned" to another party.

Transferability, on the other hand, is the complete hand-off of an agreement from one party to another.

Language on assignment and transfer typically prevents an agreement from either type of movement, as both parties usually want the original party to perform all of their obligations (otherwise, wouldn't you go contract with someone else if this partner couldn't do what you wanted?). But just as typically, language is also present that allows either assignment or transfer with permission from the side not seeking the action.

Assignment and/or Transfer isn't necessarily a bad thing. As per the examples above, there might be a great reason for a subcontractor's performance of the work. Specialty skills, speed and cost all play into the selection and use of subs. What's important, therefore, is an understanding of how, if you're NOT the one seeking the action, to protect yourself and maintain the contract you originally had.

First, remember that your initial language is key. If you unilaterally allow for assignment or transfer in the contract, you won't have the ability to prevent it later. This is one instance where it's better to have to ask permission later, as situations can change over time.

Second, assuming that you have to grant permission, remember that you do not have to actually grant it, even if asked. Sometimes extra language is inserted to make it appear that you do, phrased as "such consent not to be unreasonably withheld". This makes it sound as if you need a really great reason to say "No." But the truth is that any "reasonable" "No." is good enough. So if you think that the party accepting the subcontracting work isn't of good quality, that's reasonable. If you want to keep the original party responsible because they've had difficulty completing tasks already, that's reasonable. In all, virtually everything can be formed into a good, reasonable reason as to why you're saying "no".

Third, if you DO grant permission, please put it in writing. Create an amendment to the agreement to show exactly "what for" and why you're granting permission. Detail the specific scope of the permission (X may use ZCorp subcontractor to perform the invoice and billing tasks for the duration of and as contemplated by the Agreement). Notice that I also included a time component ("for the duration") as well. Be as specific as possible... and include a way to revoke the permission in the event that the subcontractor/assignee does not perform work in a satisfactory manner.

Fourth, some contract professionals argue that it's wise to have an agreement with the third party directly for the performance of services. To be honest, I'm not sure how I feel about the topic. Sometimes it seems necessary, sometimes it seems like overkill. If you have a great agreement with the prime contractor, for example, simply state in the Assignment Amendment that the terms of the prime must be "flow-down" to the subcontractor, AND state that while the permission may be granted for the performance of those certain activities, that the prime will continue to be held liable for failure to meet any goals, responsibilities or objectives listed in the Agreement. This keeps the original party responsible for the performance of their subcontractors.

Complete transfers of an agreement, however, are a little different... as it's a replacement of the original party with a completely new party (which eliminates much of the ability to hold the original party liable for future failures by the new party). This means that if you perform any sort of background check or other due diligence-type activities with new partners, you should perform the same type of check on the proposed newer partner, as well. In fact, many organizations outright resist transfers except as a result of merger, acquisition or complete divestiture.

Next week, we'll turn the tables about 45 degrees and talk about transfer and assignment from the software licensing perspective - which brings a whole new twist to the impact of the language.

Update: A well-respected colleague, Ken Adams, author of A Manual of Style for Contract Drafting, wrote to let me know that he believes that the use of the term "transfer" is not necessary. Rather, using the term "assignment" and then clarifying which rights are being assigned (none, some or all) would be the more appropriate contract language to use. For obligations, instead of rights, the term "delegate" would be used rather than assign. Thanks Ken. I learn something new every day!

Keeping up with Maintenance Costs

2007-03-06T02:00:00.000-05:00

I keep talking about contracts sitting in file cabinets and drawers and how you need to have some sort of contract management system to keep things organized. This isn't, however, a tip just for the buyers/licensees... but rather it's for everyone involved on either side of a transaction.

Take Maintenance costs, for example. Your average negotiated software license contains a provision for maintenance. Usually based on the initial cost of the licensed products themselves, to some percentage, this provision also usually allows the seller to increase the cost of providing maintenance over time, sometimes limited by a stated percentage. In the event of poor contract management processes, either or both sides can lose out (spending more or decreased revenues) if they don't pay attention.

Let me use a simple example to illustrate. Say that in 2000, you licensed software for $100,000. Also, let's presume that you agreed to maintenance costs of 20% of the price paid for the licensed software (ie: $20,000). So your first years' bill will be $120,000. In 2001, the bill would only be $20,000, and presumably, the vendor would continue to invoice the licensee for $20,000 through this year (2007). Grand total? $100,000 in license and $20,000 * 7 ($140,000) in maintenance = $240,000.

Again, however, it's never that simple. Maintenance costs increase as a result of inflation and other market forces. So back to the language we go, and let's now add an escalator to allow the vendor the ability to increase their license fees by 5% per year (this percentage is completely contrived and does not represent the actual increase percentage of any particular vendor).

Now we have a different scenario. It's still $100,000 for the license and $20,000 for the first year's maintenance. But in 2001, the maintenance fee can go UP by 5% ($1,000), and it compounds each year by an additional 5% (rounding up to the nearest half dollar):

2001 - $21,000
2002 - $22,050 ($21,000 + 5%)
2003 - $23,152.50
2004 - $24,310
2005 - $25,525.50
2006 - $26,802
2007 - $28,140

Difference as a result of the 5% escalation? $30,980!

This may not seem like a huge amount... but what if the initial cost of the software was $1,000,000 as many can sometimes be? Or, what if the maintenance percentage is based on the "then-current list price" of the particular product (language which I wouldn't recommend for licensees)?

And what if rather than 5% increases, the vendor is increasing it by 10% - contrary to the license fee? Do the people who pay the invoices in your organization have ready access to the agreements to confirm the agreed-upon amounts?

In all, it pays to be diligent - on both sides of the equation.

Contract Numbering

2007-02-27T01:00:00.000-05:00

How many contracts do you maintain? As a negotiator for a variety of business sizes, I would guess that if you are in an organization of over 100 people, you have more than a handful of contracts to maintain. Software licenses may be but one of many different types of documents as well. Building and vehicle leases/rentals, event/travel management contracts, employment or consulting agreements, customer contracts, too... the quantity of contractual documents can simply be staggering once they start being pulled out of desk drawers and file cabinets.

But how do you track them all? Even if you have a contract management system, trying to keep your arms around them only by their name or document type, or even by the vendor, customer or service provider is virtually impossible. For this reason, contract numbering (and a contract numbering system) is an absolute for contracting best practices.

Contract numbers have historically been used by ultra-large vendors, where a number relates to a particular sales opportunity. But contract numbers are no longer the exclusive purview of the large business. In fact, a simple contract numbering scheme can be created even if the only contract management system you have is an Excel spreadsheet.

First, remember that contract numbers must be 100% unique per document... but that you want a way to tie related documents together by the contract number so that you know which documents need to be reviewed together when you have a contract issue to resolve.

Second, contract numbers can be created in almost any form or fashion, depending on what you find easy to track. Generally, they contain some sort of party identifier (like the first few letters of the other party's name), a unique number of some form, and an indicator of the document type (so you can watch amendments, SOWs, etc as compared to Master agreements, licenses and so forth).

Third, contract numbers MUST be consistent to be valuable. If you use them sporadically or inconsistently, it will not only not serve you, but it will confuse anyone else looking at your documents later.

With these three rules in mind, the Software Licensing Handbook details a specific contract numbering scheme that works in a variety of situations. But the goal is to simply come up with a scheme that works for you and your organization. Write the number in a consistent location on each of your documents (I prefer the upper right corner of the first page). Track it in some electronic manner for ease of search later.

License Metrics

2007-02-20T18:46:00.000-05:00

Technology is a wonderful thing. As a gadget geek myself, I love the latest tech toys. But some of the latest and greatest inventions have had a less-than-positive impact on software licensing. As you might have guessed, multi-processors and/or multi-core processors have tossed a wrench into traditional CPU-based licensing.

Software vendors decide how to license their products based on the estimated value the product will have to the licensee. For mainframe products specifically, and a few others as well, CPU-based licensing has been an easy way to calculate that value. The speed/type of the processor determines the quantity of processing power, thus the amount of processing cycles that can be utilized by the licensed software. So software vendors licensed the product based on the number of CPUs the licensee would want to use to power the software.

This was actually quite an easy metric to choose, both for the vendor and the customer. Easy to track/count by both groups, CPU-based licensing is not affected by fluctuations in users, helping the customer. On the flip-side, vendors could very easily manage a relatively small number of CPUs (usually monitored by CPU serial number), too.

The problem with CPU-based licensing, however, is that until recently, neither vendors NOR customers anticipated multiple processors or cores on a single chip. So once introduced, vendors predictably argued that each processor/core counted as an individual CPU, and customer obviously argued that a single CHIP was an individual CPU. This fundamental difference is a clear example of how contract definitions can prevent problems, as virtually no software license contained an adequate definition to resolve the definitional dispute.

To compound issues, consider the fact that many of these licenses are perpetual with annual maintenance contracts. If there is a lack of clarity with respects to the definition of a CPU, not only do the parties not have a way to know how many copies of the product are authorized to be used, but it also makes the computation of maintenance dollars unclear, too.

It is now imperative that CPU-based software licenses contain a clear and obvious definition with respects to what constitutes a CPU. Oh, and did I mention virtualization? :) What do your licenses say?

Execution and Follow-through

2007-02-13T19:47:00.000-05:00

Once the deal is done and the documents are ready for signature, what happens in your organization? Do the contracts efficiently move from the negotiator to the approver to signature to the other side for their signature and then back to the contract manager(s) of both organizations? Or, like most places, do the documents get stuck at various points along the way? Let's see if we can work through some ways to grease the skids.

As listed above, there are five key steps to the complete execution of any given document.

1. Ready for Signature. The contract must reach its final stage and be "clean" and ready for signature. This, of course, is the longest stage, as the negotiation leading up to this point can take a long time. To get to readiness, at least one negotiator must take the reins and actually want to complete the document by a certain time (aka, a deadline). If you find yourself in an organization that does not have the discipline to meet deadlines, you will need to take it upon yourself to drive the documents to completion. Phone calls, e-mails, even in-person visits can be useful methods to encourage finalization of the documents.

2. Approved for Signature. At most organizations, someone other than the negotiator must approve the final contract in its "ready for signature" form. Usually this is a business owner or manager who has business authority over the subject matter of the agreement. Generally speaking, this person usually does not block or hinder the signature process as they are the person who desires the completed agreement. In the event that they do not have this vested interest, it is usually a good idea for the negotiator (or the person who has interest in closing the deal) to hand-deliver two originals of the documents for approval and wait for such approval to then hand-deliver the documents again to the person who can really sign.

3. First Signature. Assuming that neither the negotiator nor the business owner have the authority to sign, another individual will need to actually place their signature on the document. The signatory usually needs to see the authorization (many companies have moved to a written "approval" document to show this authorization) and the documents, too.

It's not unusual for a signatory to have questions about the documents and the negotiator and/or business owner should be prepared to answer questions regarding the document, the deal and even the negotiation process itself. A lack of readiness to answer these questions can hold up signature.

Additionally, in companies of this size, the signatory is also usually senior management. This means that the availability of the signatory could also be an issue. Planning ahead (calling the manager's administrative assistant for an appointment, etc) is essential to keep the process moving.

4. Second Signature. While this is technically a compound process (since the other side is probably repeating the first three steps on their side of the fence, too), from your vantage point, it's a single step. Time is always a factor, so remember that your process timeline could be doubled if your counterparts have a similar methodology. It is a mistake to believe that your counterparts will simply sign and return the documents. If, however, you are the other side, you can plan ahead and print your own version of the document for approval, such that you can be ready to take the partially-signed documents to your signatory immediately upon receipt.

You can also help speed the return of the fully-executed contracts by at least providing your name and mailing address (perhaps on a business card) with the packet of paper you send to your counterpart. Sending via a trackable mail service (UPS or FedEx) is also recommended for documents of significant importance, size, uniqueness (such as those with architectural drawings, etc) as it not only allows you to know that the documents arrived safely but also offers insurance for lost documents. Some companies like to always be the second signatory. This helps with the fifth step in the process, discussed in a minute.

5. Contract Return and Management. While this would seem to be quite unlikely, many contracts never actually find their way into the hands of the two parties. Similar to the sock that always disappears in the dryer, contracts seem to go "poof" after they have been signed and sent. To make sure that your organization has a complete contract file, diligence on the part of the contract manager (or whomever is responsible for tracking the contract) is required to ensure a safe return of the fully executed contract to the first-signing party.

As stated above, providing a return address is a necessity. If you want to increase your chances of a quick turnaround, you might also try sending along pre-paid envelopes or airbills, too. E-mails and phonecalls to your counterpart are also recommended. The trick is to realize that you haven't received the document back as quickly as possible.

The reason for the quick turn is that most people have a very short attention span when it comes to document management. It's just human nature. As we have other things demanding our attention, jobs that have been marked "completed" are easily forgotten. For that reason, if you have a contract management system, make sure you have a way to track the physical location of the documents in this process.

By following these five steps and managing this process, you can avoid the embarrassing situation of having to explain why you don't know where a document is, long after it was supposedly signed.

Comments?

2007-02-06T14:52:00.000-05:00

Hey! I know you folks are out there. I see the logs that tell me that there are a lot of visitors reading this page. But I'm not seeing any feedback! Let me know what you think. Do you disagree with me? Agree with me? Have an idea for a topic to cover? Talk to me!

Software as a Service

2007-01-24T22:36:00.000-05:00

About six months' ago, the term SaaS (Software as a Service) seemed to spring from nowhere. Everywhere I turned, every company, contract professional and trade association made mention of SaaS as the latest and greatest software "licensing" methodology. As recently as two days ago, my local paper ran an article the other day touting SaaS as the transforming "event" for the next generation. But things really haven't changed that much and SaaS isn't exactly new.

When computers were new, users accessed them via dumb terminals - where the operating system and all of the software was stored and ran on a computer apart from the terminal from where it was accessed. Service computing was born. As machines became smaller and faster, users no longer needed to rely on a central computer as they had the power at their fingertips, at their homes.

A few years ago, as the internet became popular and businesses installed very-high-speed connections into their offices, Application Service Providers started offering their software... again in a remote, service-oriented fashion. Every vendor wanted to offer an ASP model. Generally, two types of ASPs were created - one in which a third party hosted the application on behalf of the vendor and provided the access to the customer, and the other where the vendor provided the application AND the hosting.

Bandwidth was an issue, of course. But the fundamental problem for ASPs was always the service itself. Vendors had a difficult time maintaining the service levels (sometimes because of bandwidth, sometimes for other reasons). But the end result was the same... vendors made promises that are very hard to keep in a hosted environment.

SaaS is no different today than it has ever been. It's not going to alter the software licensing landscape unless and until the vendors who offer ASP/SaaS are able to maintain the service levels. Once they do, it'll be interesting to see what happens. Until then, traditional software licensing isn't going anywhere.

Now Available on Amazon/Borders!

2007-01-17T23:37:00.000-05:00

After a long introduction, the Software Licensing Handbookis now globally available at Amazon, Borders and any book store near you by title or ISBN: 978-1430305842. However, I can't promise you'll get the lulu.com price via the links from this page. Thank you again to everyone who has supported me in this process!

Warranty vs Maintenance

2007-01-13T18:00:00.000-05:00

A few years ago, it was very common to find one year warranties on products and maintenance and/or support programs that would pick up where these warranties would leave off. As a result, most IT folks still understand Maintenance to be a paid-for version of a Warranty. Unfortunately, vendors do not see it the same way, leading to one of the most contentious parts of a contract negotiation.

As defined, a warranty is a guaranty that the product will work in a certain manner for a certain period of time. The "certain manner" is usually as specified in the product's manual and the "certain period of time" is now substantially less than a year. Maintenance (and/or Support) Programs are then sold to the customer as a way to offer a longer-term availability in the even that the product has functionality problems. Why the difference?

Warranties are sometimes mandated by state and/or federal laws and regulations. You will usually note this not by the warranty itself, but by the warranty exclusions listed that the vendor is disclaiming. Beyond that, warranties were once a way to promise to the customer that the product would work "forever" as stated in the manual. In an age when a particular version of software is obsolete soon after it's released, "forever" is much shorter in the eyes of the software vendor.

Coupled with this is the fact that many customers not only want to make sure that their product works as advertised (which is reasonable) for the time that they use the product, but that they also want access to each new version/release of the product (which may be unreasonable, given the advances in the technology). Software vendors handled this by creating a division between the warranty and the maintenance/support concepts.

So now we're left with a more traditional definition of warranty - a small window of time in which a customer can receive help for a dysfunctional product, along with certain limited guarantees that last for the entire duration of use (such as a guaranty of ownership in the underlying intellectual property). Support (as opposed to maintenance) is then also defined by its dictionary definition - help provided after the expiration of the warranty period. Support plans do cost the software vendor to provide, from technicians to replacement parts, 800 numbers and all the other infrastructure items necessary to be available when the customer calls. These plans also range from the basic, 8a-5p M-F plans, to the 24x7x365 "we're there when you need us" plans, along with every conceivable variant.

Maintenance, as opposed to Support, is the added benefit of being able to receive updates, upgrades or product revisions as they come out. In essence, Maintenance is a fee paid to the vendor that contributes to the R&D of new products. Software development, contrary to popular belief, is a very demanding and time-consuming process. Quality Assurance testing alone can take months of tedious operation by skilled users/developers without a guaranty of ever actually finding every product problem (bug). As stated above, this is one major reason why vendors do not want to just give new products to their customers for free. Add revenue recognition issues into the mix, and it becomes even more complex to provide a contractually open-ended arrangement.

The costs involved in each of the three concepts (warranty, maintenance and support) can be substantial. Vendors interested in their own long-term survival can't reasonably provide perpetual free maintenance or support. In an attempt to provide customers with software packages that meet their different customers' needs, vendors do not usually require all of their customers to buy maintenance and support. That way, customers who do not need/want maintenance or support, don't have to pay for it.

At the end of the day, this is the best way to satisfy the most number of customers, even if it causes some interesting negotiations.

Redundancy

2006-12-25T05:43:00.000-05:00

I was reading a rather long document this past week when I noticed a significant amount of redundancy. In case you haven't ever seen this, it's the practice of double-stating a particular idea, concept or phrase. It is usually done as a result of that idea actually being "at home" in more than one place in a contract (such as an audit right/obligation, a service level metric, etc). If my own experience is any guide, it's also the result of a document that was written and re-written many times, over a long period, by multiple authors.

While this doesn't make it a bad practice or a bad idea, it is worth noting and considering with respects to your own templates. Redundancy in a document is problematic for two main reasons. First, it's confusing for the reader (your customer, provider, etc). As someone who's on the "other side" of a deal almost every day, I can tell you that I do not like reading documents that contain multiple redundancies. It makes me a bit uneasy and a little distrustful. I find myself having to flip back and forth throughout the whole contract making sure that the concepts and language covered in one place are the same as they are in the other. This also tends to make me feel like I'm wasting my time - especially when the document is already long or drawn out.

Second, remember that in most cases, contract language during a dispute will be construed against the drafter. Even contract sections that try to apportion this risk by saying that the parties agree that this contract represents the meaning and intention of both parties and should not be considered the work of either party really doesn't remove the likelihood that your redundancy could land you in trouble if the two sections aren't identical. Does your template agreement have your organization's logo on it? Does it have your organization's name throughout the document and use a generic term to describe your opponent? Are you a giant corporation and your opponents are small? Overall, do you think a court will be swayed by that attempt to rid yourself of the liability?

Reading the contract to favor the non-drafting party will lead to a situation whereby the better of the two paragraphs for the non-drafting party will be the binding paragraph. So, while you may want to state, re-state and triple-state your ideas... don't. Say them once with your true intent. In plain, simple, language. Promote clarity, not obfuscation.

ps. Have a very Happy Holiday season (Christmas, Hannukah, Kwanzaa, New Year)!

Caucus

2006-12-01T15:09:00.000-05:00

Welcome Caucus 2006 IT Procurement Summit attendees! Thank you for your interest in the Software Licensing Handbook. I look forward to any comments you have so that I may continue to improve its content as we continue to develop this important field!

~Jeff

IP Indemnity

2006-10-19T12:06:00.000-04:00

Intellectual Property Indemnification (aka IP Indemnity) clauses are common in software licenses. The specific language usually plainly states that the software vendor will indemnify, protect and/or defend the buyer from any claim made that the software violates the intellectual property rights of a third party.

Fundamentally, this type of protection makes sense. In first-world countries (and most second-world countries, too), intellectual property rights are pretty clearly delineated and it's relatively easy to understand the scope of your property compared to that of another. So it's not a stretch to be able to say that if you know what you own, you can offer assurance to a buyer/licensor that someone else claiming ownership of that property will receive swift action from you rather than the buyer.

Overall, though, it's economic. If you pay for a software license once, you do not want to have to pay someone else for that same license. You want to know that the person receiving your money is the rightful licensor of the product. Pretty simple.

What makes it complex is that IP rights vary from country to country. So the surety you feel within, say, the United States regarding the ownership of your IP is not carried into some third-world countries (and even a first-world country or two, such as China) where a blind eye is turned towards piracy, copying and stealing. Some of these countries even have laws that protect the thief better than they protect the actual owner, depending upon the situation(s). As a result, IP indemnification is based on WHICH IP laws are being upheld by the parties to a software license.

The net result is that most software licenses, even on a global scale, offer IP indemnity based on one of a few country's IP laws (the US or UK, primarily) because these two countries not only have established IP laws, but they also have a relatively fair system of legal enforcement of rights.

What you find in some global deals, however, is that the buyer wants IP indemnification under the laws of each country in which a product will be used or reside. This, beyond being potentially impossible to manage, is also fairly unreasonable. The inventor of the product, while desiring to sell as much of that product as possible, has to be able to manage the potential for damage in the event that someone claims IP infringement. By offering IP indemnification under the laws of all countries (and not just those with established IP rights and enforcement abilities), the seller opens themselves to a large amount of risk and, again from an economic perspective, it becomes an untenable deal.

This however, doesn't mean that the buyer receives no protection in those countries. Rather, they still receive indemnification under claims made under the laws of the country offered in the IP Indemnification section. So, if IP indemnification is offered "for claims made that a product or software violates the copyright, trademark, trade secret or patent laws of the United States", then even claims for products used in China or Niger are covered ... so long as the claim is made that the product violates a US IP law.

The key is to remember that at the end of the day, the deal has to be economically feasible from both sides of the purchasing equation.

Already overwhelming response!

2006-10-05T22:33:00.000-04:00

Thank you to everyone who is responding and sending in comments, suggestions and praise for this handbook! I really appreciate the feedback and I value your input.

I'm contemplating offering this guide via Amazon and Barnes & Nobles (the traditional route, I suppose), but to do so would mean an increase in the sales price, which I'm not fond of. Please then, help me support lulu.com in their quest to offer affordable publishing for all authors!

Thank you!

Book Usage

2006-09-28T23:17:00.000-04:00

I've received a few questions regarding the content of this book and how it should be used. Truthfully, the material is very technical (from a language perspective). That's just the nature of the contract beast. Even those of us who do this day in and day out find it tedious at times. Understanding the nuances of the various sections, however, is what makes this skill so valuable and interesting!

So no, I do not intend for you to read this book straight through. Use it as a companion reference when you have a contract that you need to read and review. Check section against section. Compare language, style, needs, wants.

But for heaven sake, don't read it all the way through.

Unless you're suffering from insomnia. Then by all means, enjoy!

Available Now!

2006-09-28T08:15:00.000-04:00

Well, it's finally here! The Software Licensing Handbook is now available for immediate purchase at Lulu.com!