Category Archives: warranty

Two-Top Tuesday

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 (, 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

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!

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

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.

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.

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.

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.

Open Wha?

[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)!

Warranty vs Maintenance

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.