Category Archives: warranty

This Week on The Web 2009-09-13 (my birthday edition)

Leave a reply

It happens to be my birthday weekend and between eating some great food, playing Guitar Hero with my wife and hanging with the family, these are the things that happened around the web this week – maybe you already read about them, maybe you need to again – there were some REALLY great discussions going on.  Come join the party on twitter (follow me here and you’ll join the conversation live.)

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like bit.ly to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later and “<” which means that I am commenting on what came before it.

Advertisement

On Acceptance Testing…

3 Replies

My car needed an oil change today.  It’s been about 5 months, 6,000 miles and while I know I can push it that far, it was finally time for me to get it done.  I thought about doing it myself and decided that Jiffy Lube would more efficiently meet my needs.  But I always feel a little weird about oil change places – they show a long list of things that they supposedly check… but unless I stand out there hovering in the bay, I don’t feel confident that they’ve actually completed the work.

Today I didn’t hover, I was reading e-mails.  When they called my name to pay, they quickly read off the list of things they checked and reviewing the computer screen, I asked the guy behind the counter: “Did you check the engine coolant level?”  With a slight hesitation, he replied “Yes.”

I paid, took my keys and walked out to my car.  Deciding to check the coolant level, I popped the hood and looked.  Sure enough, the fluid was below the line marked “Fill”.  I walked back inside and told the same employee that I thought that the fluid wasn’t checked and could he come confirm.  He looked a little shocked, walked out to the car and confirmed that the fluid was low.  He apologized and made some sort of excuse about the shop being busy and that my question during check-out didn’t raise any red flags – that he figured I’d asked them to check it and that his employees did (apparently, he was the manager).  I said it was no big deal, but that I would like it topped off.

[OK.  If you haven’t already figured it out, this story parallels many services-type engagements from the IT world.  You pick a provider when you realize you don’t want to do it yourself, you “order” a set of services… and at the end, you are presented with a completion check-list and asked to pay.  What services providers don’t want prior to payment is anything conceptually equivalent to an Acceptance Test.  They want payment first and then resolution of any “defects” under their services warranty provisions (if any).  This way, they have control of the money and can book the revenue as earned.

But don’t let their desire to avoid Acceptance Testing sway you… and don’t fall into the trap I did today and pay first.  What happened next was predictable and I should have seen it coming.]

The manager then said, “well, we normally charge for topping off the coolant.”

Oh.  Alright, I thought, whatever… just get my car finished and get me on my way. “How much does that cost?”, I asked.

“Five dollars.”

Thank god my negotiation-sense kicked back in … and I just stood there silent for a few beats too many.

“But because of the confusion, I’ll take care of it.”, he continued.

I smiled and said “Thank you.”

While he was retrieving the coolant I scanned the engine compartment and realized that the large rubber gasket between the hood and the firewall had completely come off and was just laying across the engine!  Holy cow.  I was really glad I popped the hood today – this piece of rubber, which probably came off during the oil change and was simply overlooked due to its matching blackness to everything else under the hood, could have gotten wound into various belts, heated and set afire or fallen down to the road and lost.  It was a no-brainer fix to simply push it back onto the car’s frame – but catching it was the biggie.

The same is true for many acceptance testing issues – the no-brainer is to look for them at the right time (preferably before payment).  Don’t get suckered into someone else’s process (they moved my Jeep out of the repair bay and into the parking lot (keys in it and running) as “customer service” perk.  But it’s meant also to get you off the lot before you notice anything wrong (where they can attempt to reasonably say that the problem happened outside their control).

One again, learn from my mistakes.  🙂

Warranty Elephant

Leave a reply

Even if you have the Novatus Contracts system, warranties for your one-off hardware purchases (software, too) are not easy to remember.  Typically, you don’t even get more than the warranty card that comes in the box.  When your hardware breaks, do you know what the warranty will cover?  Probably not.

Neither did the creators of Warranty Elephant.  This simple (and free) service allows you to record your purchases along with their associated warranties.  No more forgotten warranties, no more misplaced warranty documentation.  Granted, this system was developed for personal use, but here are a few commercial uses I’d find valuable:

  • fleet warranty management (ie: if you have a bunch of vehicles, reminders about when the transmission is about to come off warranty is helpful)
  • one-off hardware or volume hardware that doesn’t come with a more robust specific warranty (such as TVs/monitors, laptops, Aeron chairs)
  • items you used to think were cheaper to simply replace than to monkey around with warranty info (keyboards and mice)

Customer Audits of Your Contracts

3 Replies

I was recently asked whether I would ever allow a customer to audit my contracts.  The simple answer is No!

Of course, the original question wasn’t this simple.  The person asking the question had some interesting constraints.  Specifically, they were licensing software on an exclusive basis, with exclusivity carved out by geographic region.  So a prospective customer wanted to review the vendor’s contracts to make sure that they weren’t getting into an overlap situation.  My answer was still No!

First, contracts are, even at a fundamental level, based on trust and honesty, and not based on a lack thereof.  If you don’t trust the person you’re contracting with, the contract isn’t going to help you too much.  In other words, you can’t contract trust.  It just doesn’t work that way.  So if the vendor in this situation was going to be dishonest in overlapping exclusivities, what would make the customer think that they would allow the customer to actually audit all of the agreements?  A dishonest vendor would simply hide a portion of the contracts that they didn’t want discovered.

Second, with minor exception (such as during due diligence in a M&A transaction), I would never allow anyone to review my contract files.  There’s too much confidential information – and general poking around to see what’s in them isn’t a narrow enough reason to go looking.  In fact, even if the looking was just at license grant language, I still think you’re potentially revealing too much information (exclusivities for geographic regions aren’t the only way to restrict licenses and perhaps you also license based on user counts – allowing others to see the full license grant can give them a sense of pricing, perhaps).

Third, there’s a better way to handle the situation:  provide a warranty and a specific remedy for breach of this particular warranty.  Warrant that you are providing an exclusive license in exchange for specific consideration (probably money, but perhaps something else).  If you (vendor) breach this warranty, the sole and exclusive remedy could be the repayment of the specific amount of consideration provided for the exclusivity.  So, imagine a situation where you license exclusively by country (perhaps your product handles some sort of sales-related transactions).  In exchange for an exclusive license, the customer pays you an extra $1,000,000 in license fees and that this also adds into the annual maintenance costs.  If you later decide to break a previously-licensed country into smaller bits, you simply would have to pay back the $1M plus the accrued/paid maintenance fees for the breach.

Now, this sounds like it may provide you with license to later break the agreement – no, I’m not suggesting that, I am however suggesting that you promise not to and a specific penalty for doing so.

Warranty Reminder

Leave a reply

I had a conversation with a few folks the other day about warranties.

The end of the discussion was a reminder that just because a statement falls outside of the warranty section doesn’t mean that it’s not a warranty.

Warrants are promises.  Dictionary.com defines them as “something that serves to give reliable or formal assurance of something; guarantee, pledge, or security.”  The law.com defintion goes even further “a written statement of good quality of merchandise, clear title to real estate or that a fact stated in a contract is true. An “express warranty” is a definite written statement and “implied warranty” is based on the circumstances surrounding the sale or the creation of the contract.”

Which means that sometimes you’ll see them called “covenants” or “obligations” … but whatever the title, they’re still warrants, even with no title at all.

“But wait!”, said one person.  “We use section headers to delimit our contracts – so warranties are clearly sectioned off from the rest of the agreement.”

Hmmm… good thought.  But don’t you probably also have a section of your agreement where you state that section headers are for reference only and that they shouldn’t be used to interpret the agreement?  Oops.

They’re not discouraged.  “Not only that, but our warranty remedy language says that our warranty remedies only apply to the warranties listed in this warranty section.”

OK… now they might be getting somewhere.  The warranty remedy language probably gives a few “extra” remedies in the event of a warranty breach.  Most likely something along the lines of time to repair or replace the warranted good/service and avoid termination of the agreement.  Who does that remedy language benefit?  I would argue that it benefits the service provider.  Because it gives them the opportunity to stop a breach of contract claim (and thus one for damages) as a result of a warranty problem that they can fix.

But that also means that any of the OTHER warranties provided throughout the agreement not in your warranty section aren’t covered by this remedy language – and thus the only available remedy to “fix” the problem is a breach of contract claim (and probable termination).

What the warranty section is thus really for is to call out special warranties that should have extra protection – and thus extra damages.  The problem I see most frequently is that the “extra damages” portion of the remedy language is missing.

“Um, what do you mean, extra damages?” says the crowd.

Well, I mean that an uncured breach of these warranties should result in something more than termination of the agreement and a modest amount of damages.  In fact, in most cases, I argue successfully that the types of things I have in my warranty section (such as warranties of title/license, 4-digit-year processing, etc) should entitle me to a full refund of all fees paid in the event that the provider isn’t able to fix the problem.

“Holy cow!” shout the providers.  “Are you friggin’ kidding us?  We’re not going to give a full refund.”

Why not?  I’m entering into this agreement under the color of the promises that you’re making to me pre-contract.  You fully expect me to live up to my end of the agreement (you included language for payment, invoicing and penalties for late-payment).  So why shouldn’t I get to rely fully on your promises?

Just a thought.

Software Licensing Education Series – 300s Track Now Available!

Leave a reply

Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics.  Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics!

The 300 Track videos include:
SLES 301 – Warranties
SLES 302 – Indemnification
SLES 303 – Limitation of Liability
SLES 304 – Services Issues 1

(400s-500s Tracks are currently in production and will be released shortly!)

Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!

As promised, purchasers of the Second Edition of the Software Licensing Handbook are eligible for a discount on the purchase of a Track from the SLES.  When redeeming your free Software License Risk Matrix, you’ll receive a coupon code for the SLES via e-mail.

Two-Top Tuesday

Leave a reply

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.

Letters of Intent

Leave a reply

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.

Take this EULA… and shove it!

Leave a reply

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