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!
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).
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 24×7 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.
Filed under: contract format, contract terms, EULA, IP Indemnity, license grant, maintenance, negotiation, warranty
[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.
NET(net), Inc. 