I saw an interesting article today that high-tech vehicles were posing problems to some mechanics.  The mechanics claim that they can’t afford the thousands of dollars that are necessary for them to obtain the specialized diagnostic tools for each auto manufacturer.  The manufacturers are claiming that they’re trying to protect their intellectual property.

Sound familiar?  Yup, it’s exactly like the issues Frank Scavo and Ray Wang have written about with regards to third-party software providers being blocked from performing various maintenance/implementation tasks by the contracts and software licenses and services agreements of certain primary vendors.

On the automotive side, it’s apparently gotten to be such an issue that there’s a congressional bill called the Motor Vehicle Owners Right to Repair Act of 2009.  The stated purpose of this Bill is to “protect the rights of consumers to diagnose, service, maintain, and repair their motor vehicles”.  What’s really interesting are the Bill’s findings, among which say that:

• Motor vehicle owners are entitled to choose which service provider will diagnose, service, maintain, or repair their motor vehicles.
• Promoting competition in price and quality… will benefit consumers.
• Only service technician with the necessary tools and information can access the computers to perform diagnosis, service, maintenance and repair…

And the requirements of the Bill, specifically:

• Duty to Make Tools Available:  The manufacturer of a motor vehicle sold, leases or otherwise introduced into commerce in the United States must offer for sale to the motor vehicle owner and to all service providers on a reasonable and non-discriminatory basis, any tool for the diagnosis, service, maintenance, or repair of a motor vehicle, and provide all information that enables aftermarket tool companies to manufacture tools with the same functional characteristics as those tools made available by the manufacturers to authorized dealers.
• Replacement Equipment: The manufacturer of a motor vehicle sold, leased, or otherwise introduced into commerce in the United States must offer for sale to motor vehicle owners, and to all service providers on reasonable and non-discriminatory terms, all equipment for diagnosis, service, maintenance, or repair of a motor vehicle.

The only thing the Bill protects for the manufacturer are things that are actual trade secrets.

Wow.  Of course, there are a LOT of people (and more specifically, a lot of trade association and advocacy groups) behind this Bill.

Could you imagine what would happen if this passes and someone realizes that software in cars isn’t that dissimilar to plain old enterprise software?  If only there was a trade association group for buyers of enterprise software apps. 

But let’s talk about the other side of the issue for a moment.  Do consumers have a right to have third-party companies provide service?  A right?  No.  I don’t think there’s a right to be able to have third-party providers.  [Keep in mind, when we're talking about rights, we're talking about things equal to "life, liberty and the pursuit of happiness...".]

Absent a right, should third-party providers still be allowed/encouraged?  I’m really torn on this.  On one hand, I’m all in favor of things that inspire commerce.  I like behaviors that create business, allow more people to work… and of course, things that drive down costs and dissipate apparent monopolies.  On the other hand, an individual or organization who creates something should be able to protect their idea/invention and not have to give up the secret sauce simply so that other people can benefit.  But there seems to be a line somewhere that once you cross it should allow for third-party companies to fill available niches.  Maybe it’s where the original vendor is no longer able to provide a quality-level of service.  Maybe it’s a situation where the original vendor is charging exorbitant rates.  I’m not sure.

Anyone have a solution?

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

Start with fundamentals on negotiation.  Think outside the box.

Then go through the basics on firesales.  If you want more, buy the Firesale Concall Recording.

Understand pricing, and when it might pay to avoid maintenance costs.

Start your deals from good templates.

And, lastly, consider the reasons for agreeing to renegotiating deals.

To my faithful readers: Thank you for listening to me for another year.  I hope you have a very joyous holiday season and a happy New Year.  See you in 2010 (unless something really awesome in the licensing world happens between now and then).

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

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.

• RT @rwang0 @dealarchitect: Don’t cry for me Germany. SAP had plenty of warnings. http://tinyurl.com/mclvbm < I can’t wait to see who’s next
• RT @richards1000: Tuunanen et al. on Automated Software License Analysis http://bit.ly/svjQR < Cool but irrelevant. FOSS license are nonneg.
• RT @rwang0: reading the new twitter terms of service. like the fact that you and only you own your content. < At least for now.
• RT @jimcalloway @ernieattorney Important safety tip for ‘would-be lawyer bloggers’: if you lack common sense don’t blog http://bit.ly/2fFcBH
• New blog post: Content, Value and Commoditization http://bit.ly/27HVx
• RT @btannebaum: Lawyers, do you care about transparency on twitter? http://mylawlicense.blogspo…
• Contract negotiation according to the Marx Brothers: http://bit.ly/12U7pY
• US Registrar of Copyrights opposes Google book deal: http://bit.ly/KhP83 … so do I. Unwarranted monopoly.
• … and then there was a whole discussion on what constitutes being an expert at something, sparked by one lawyer’s assertion that it takes 6 months’ of research and then a good SEO strategy to get yourself to the top of the Google rankings.  I, and others, disagreed.  (RT @nikiblack @Adrianos: “How To Become An “Expert” In Your Niche In 6 Months” http://bit.ly/pIj2Q < I really do NOT like this!)
• New blog post: On Acceptance Testing… http://bit.ly/s0zsV
• @JasonAnderman The author misses part of the value of the lawyer – understanding that a form isn’t 1sizefitsall. Available /= viable.
• @ferrusi @PeterKretzman When discussing vendors, not having them in the room usually leads to more openness. It can also reveal biases.
• @PeterKretzman @mckenziesa: RE: Find a way to get the salesmen out of our vendor discussions! < Um, Ask them to leave?
• RT @glambert: Blogging Lawyer Charged with Confidentiality Violations – http://bit.ly/mLcTj (Public Defender tells a little too much)
• RT @rwang0 Cloud computing model – IDC numbers show s that its … 1/2 the cost < How does that translate to customer fees?
• RT @PeterKretzman @testobsessed Source code, like invty, is a liability, not an asset. (PK: indeed. It’s why I laugh at source code escrow)
• RT @vpynchon @tamerabennett: Disney, Pixar Sued by Luxo Lamp Co: http://bit.ly/MO4X7 < Shouldn’t matter. Pixar’s not selling lamps.
• RT @fscavo: @negot8or thinks #saas providers should set up living trusts (my word) for their customers. Read comments: http://is.gd/34L65
• Kate Gonzalez’s Tom Ten Force Majeure Imposters (via @superbuyer): http://bit.ly/Ol4Wy
• Confessions of a Car Salesman: meeting, greeting and dealing: http://bit.ly/3nihk (via edmunds.com)
• Antitrust lawyer slams Google book pact: http://bit.ly/83Hqp (via All Things Digital)
• RT @LeighMonette: RT @PrivacyLaw: “’Anonymized’ data really isn’t—and here’s why not” http://tinyurl.com/ksxz8t
• RT @fscavo: Just blogged: SaaS contingency plans need more than software escrow http://bit.ly/r2cJn < Escrow is wasted money IMHO.
• RT @jimcalloway: Blogged about lawyers taking their laptops across the U.S. borders. http://tinyurl.com/n4bfms
• RT @BrettTrout “World Patent” good for M$, bad for most everyone else. http://bit.ly/o0rbZ
• Jeremy Telman, contracts prof @ my almamater, on why execution before performance is a good idea: http://bit.ly/1iJjY7
• RT @vpynchon: http://twurl.nl/tiuvp7 the negotiation analysis of the lessons of the Cove (which halted the killing of dolphins for one day)
• RT @bobambrogi: LawSites blog: Plaxo’s New Terms of Service http://bit.ly/1BNRy
• RT @bobambrogi @paulzink: You and your attorney colleagues (esp. those in copyright law) may get a chuckle from this: http://bit.ly/jJd6G
• … and then we had a long discussion on the tweeting of the play-by-play via twitter of a NFL game (the NFL likes to exert some extreme control over their content).  Some folks thought that twitter was a game-changing technology.  I argued that it was control-changing…. that they should tweet every game in their own words: @FlashFusion @julito77 @gtiadvisors It’s only a copyright issue if you tweet the actual broadcast wording/play-by-play. Make up your own.
• RT @doctorow: Another reason you can’t outsource your kids’ online safety to spyware companies: http://tinyurl.com/n934fh < Read the EULAs!!
• RT @gtiadvisors @GregBufithis @BrettTrout Proposed U.S. patent law reforms would stifle innovation and injure entrep’s http://is.gd/2ZXza
• RT @OmarHaRedeye: Blawg Review #228 is live http://bit.ly/11D50J/ < Thanks for the inclusion!
• Sometimes is pays to see how the software sausage is made: http://bit.ly/S3b5p

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

And, even if you could, your organization probably doesn’t have tracking enough to make it possible – just remember that if you overuse your permitted license count, chances are there’s another provision in your license that allows the vendor to charge you (perhaps at non-discounted pricing) for the overage.

What I DO like about Ray’s suggestion is that idea that you should try to negotiate for a recapture of maintenance fees on unused licenses.  If you can’t resell them, the least you can do is take an annual count and only pay maintenance on the ones you’re using.  There is, of course, trouble with this thought, too – as there are some vendors that used to allow this (the last one I remember was Autodesk).  But the trouble is that you can get into a situation where you only upgrade SOME of your licenses to the current version because not all of them are currently covered by maintenance and the upgrades provided under such program.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Hmmm… the more I think about this, the more I think it would be really easy to convince my clients of this.  Anyone have a counter argument?

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

“For ten years, we’ve been driven by a simple vision: The End of Software.  Now it’s time to take on a new challenge: The End of Maintenance.

Let me tell you about a customer that I met on our Cloudforce tour. This customer currently uses Siebel software to run her call center.  She pays more than $15 million a year for the privilege of having to implement the updates that Siebel sends her.  That does not include backup. Or disaster recovery. And of course, it does not guarantee that she will be using the latest technology.  The maintenance agreement only assures her that her outdated software will continue to work.  She is paying tolls on a road to nowhere.

We can help her, and many other customers, and deliver much more for a fraction of what they currently pay in maintenance. It’s time to open up a new front in “The End of Software”– one that is long overdue.

It’s time for The End of Maintenance.

Every year, companies spend billions on maintenance fees and get relatively little in return. Maintenance fees cover updates that are mostly  patches and fixes, but they stop far short of the kind of innovation every that enterprise needs to survive.  Companies pay to keep the past working and they end up doubling down on technology that can never keep up with their needs.  The fees that companies pay have actually been rising, from something like 17% a few years ago to numbers more like 22% today. Every four or five years, companies are paying for their software all over again.

It’s time to set these businesses free and make them successful in the Sales Cloud,  Service Cloud and on our Force.com platform.

Our new mission begins at a critical time in the economy, when companies are questioning conventional wisdom as they never have before.  That, of course, extends to their IT budgets as well. The CIO is in a tough spot right now.  Corporate budgets are tightening.  And our rivals in the legacy client-server world are using this opportunities to extract more money from their customers by raising maintenance fees.  I call this phenomenon “the compression of IT” and it resonates with just about every CIO I speak with these days.

We have a better vision. We sell our customers a service and every customer is able to use the latest. Innovations are included. Upgrades are automatic and invisible. Customers’ intellectual property of customizations and extensions is rigorously preserved, and carried forward without disruption.

The service gets better, not just less buggy. That’s not what people are getting for all those fees that supposedly buy them “maintenance.”

It’s time to set these business people free: to give them the experience of being wildly successful in the Sales Cloud, the Service Cloud, and in their own unique applications that they can build on our Force.com platform. This is the time to do it, because this is when people need it: their IT budgets are tight, their business situations are critical, and their old-world software vendors are taking care of themselves instead of meeting the needs of their customers.

We’ve raised people’s expectations for better alignment of business value with IT cost. We’ve earned our leadership position in enterprise cloud computing. It’s time for us to set people free from paying more and more to get less and less. It’s time for The End of Maintenance.

Aloha,

Marc”

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Of course, it’s never that simple.  Because your IT department usually also wants a development server for each database instance.  This makes sense – development should be done separately from production (you wouldn’t want some experiment in design to bring down your production server).  Oh, and what about testing?  This is the middle-of-the-road between development and production… where something that your developers believe is ready for production goes to receive significant QA attention.  That’s yet another set of databases.

So, now we’re talking about 15 licenses: 5 production + 5 QA/test + 5 development.  If 5 were expensive, imagine what 15 could become.

Database software developers understand this dilemma.  They know that if you’re really making use of their products, whatever you have in production has to be supported by nearly as many dev/test environments.  Back in the day, this was usually a pretty simple situation – you asked for, and usually received, “free” dev/test licenses.  I say “free” because they were never really free, they just didn’t separately price them.  You paid for them then, just as you pay for them now.  The difference is that the cost was built into the production licenses back then because the hardware wasn’t strong enough to support some of the tricks that can now be used to run multiple databases within a single hardware environment.  Once the hardware was strong enough (about 8 years ago), savvy licensees didn’t actually need 5+5+5 … they could find ways to do 5 + 3 + 2 or some other combination in something other than a 1:1 relationship.

The net result is that these same savvy licensees started asking for discounts on the initial 5 production licenses because they knew they were no longer needing the triple-play effort of that single license.  Instead, they argued, they only needed a few “extra” licenses (now really for free) because it was understood that to make use of the product, you needed these extra environments.  They just didn’t need them in the same quantities as before, so it had the appearance of being less of a freebie than before.

Software vendors reacted in the best way they could – through changes in language.  The phrase “internal busines purposes” became the expected response.  “Yes”, the vendors said, “you can have a few extra licenses – but only for internal business purposes.”  The meaning wasn’t always clear, of course, but the intent was to say that the licenses you purchased were the ones that could see the light of day (be used by regular users, etc), but that the extra licenses were only for back-room development and testing.  You were signing a license agreement confirming that you wouldn’t take these fully-functional licenses and put them into production.

No problem.

Until ASP/SaaS offerings came along.  Now you have databases that are serving data to the world 24/7/365.  Licensees still need dev/test environments… but these are now potentially available online, too.  And, in rare cases, serve as the backup production environment in the event that the usual production environment goes down.

Has this really created a problem?  No.  The case remains that licensees should have frank and honest conversations with their vendors about how they intend to use the products rather than try to sneak some form of unintended or unexplained use by the vendor.  If licensees want “free” licenses for dev/test, they should expect to see (and respect) “internal business purposes” language.  And they should discuss the possibility of needing to put a dev/test server into production in the event of a disaster.

Lastly, licensees should also remember that such licenses are never free.  Whether you have a line-item cost that shows you paying full-price, partial-price or no-price, the cost is still baked into the deal in some way.  However, one key advantage to calling out the pricing specifically for dev/test environments is the ability to get them excluded from maintenance costs – as there should be no need to pay for maintenance on a dev/test box needed to provide support for a production server.

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

The 400 Track videos include:
SLES 401 – Services Issues 2
SLES 402 – Maintenance and Support 1
SLES 403 – Maintenance and Support 2 (special 1-hour course)
SLES 404 – ASP and SaaS Issues

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

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

So, before you can measure a service level, you have to define one (or more).  As I stated before, software-related services are typically measured by two major factors: Problem Response (how quickly the vendor responds to a call for help) and Problem Resolution (how quickly the vendor solves the problem).  As two measures of time, they’re similar, but these are two independent measures – a vendor can do well with one and poorly with the other, for example.  Additionally, embedded in both of these metrics is a key definition – the concept of Severity.  So we actually have to start with the definitions and work forward.

Not all problems are created equal.  Severity is the disambiguation of a particular issues’ importance.  You should create at least three Severity levels, perhaps four, but never more.  I like four because I think that it offers enough distinction between each Severity level without becoming so nuanced as to be irrelevant.  I define Sev1 Problems as any problem resulting in a full or partial production stoppage or data inaccuracy.  Sev2 Problems are a significant production inhibitor.  Sev3 Problems are those where we can do our work, but only through manual intervention that requires significant production or performance inefficiency, or where reporting functions are unavailable.  Finally, Sev4 Problems are any condition in/of the software other than those defined as Sev1-3, which affects the service or operation of our systems or network, but does not render such system or network unusable or inoperable.

The net result is that Sev1′s are “the sky is falling” moments; Sev2′s are “holy crap”; Sev3′s are “we’re pulling an all-nighter” and Sev4′s are “I don’t like having to do something in this really wacked-out way because the software doesn’t work to the manual’s spec”.  Now, you can redefine these Severity Levels any way that you wish… but the general formula should be followed (not just because I say so… but because these are almost industry standard).  As you’ll see in a moment, the distinction between each level is also important in terms of how it impacts your metrics.  Additionally, the “missing” 5th severity level is one I simply don’t include anymore – but if you do so, it would be the “user interface” issue – the color palate that makes things hard to read, the minor nit that isn’t inhibiting in any way, it’s just an annoyance.

OK, so now that you have the Severity Levels defined, you can get back to the creation of metrics for Response and Resolution time.  As I said before, Response Time is how quickly the vendor is going to answer a call for help.  Thinking logically then, the higher the Severity Level, the more quickly the vendor should respond because the more damage delay in response would cause.  My standard starts with 2 hour response time for Sev1, 4 hours for Sev2, 8 hours for Sev3 and 12 hours for Sev4.  Remember, this is just response time – the time it should take the vendor to give you a PLAN for a resolution, not to actually solve the problem.

With Resolution Time, I’m measuring time, but I’m also measuring completeness, as Resolutions are dependent upon the problem being fully solved (hence the definition of the word “resolution”).  For Sev1 Problems, I need immediate assistance, tempered with a little understanding of how software development works.  So I ask for 100% of Problem(s) resolved in 24 hours.  I follow an almost identical geometric path as the Response Times.  Sev2′s should be resolved in 48 hours, Sev3′s in 72 hours and Sev4′s in 96 hours.

Seems pretty simple, actually.  And, in many cases, it can be.  But again, if I didn’t have a fairly thorough understanding of the software development, testing/QA and bug identification/repair process, I might be tempted to ask for unreasonable metrics, or alternatively, be willing to agree to extremely long times as well.  Again, the moral of the story is to know what you want to measure and why and go from there.  Next week, we’ll talk about what happens when someone blows a service level.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Yup, that’s right, you might have a built-in maintenance fee decreasing mechanism in your contract. Now, you only have to go find it and find your CPI number.  Oh, and it might also be the time to hope that you have a contract management system and that this is one of the data points you’re tracking.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

[Special appearance of the Wayback machine: For those of you who don't even know what I'm talking about, back in the day, we were concerned that software was going to stop working on January 1, 2000. The fear was that since some sloppy programmers wanted to save computer memory by shortening dates to only two-digits, that once the year moved into 2000, date calculations would no longer work. Thousands of programs had to be tested and patched. Almost every organization did some sort of Y2K audit to figure out whether they were going to have problems.]

Oh, and did I mention that many software vendors were charging for the privilege of getting replacement software that wasn’t coded in this sloppy manner? Yep. Not to mention the fact that the memory problem that precipitated the sloppy coding was solved somewhere around the mid-80s (and even if you want to balk and say that this type of memory problem wasn’t fixed until the early 90s, we’re still talking about having more than 10 years to fix, or prevent, the problem).

So, in typical contractual knee-jerk manner, the legal/contract community’s response was to start including contract language that said that a computer program would work properly after 1/1/2000. At first, this was problematic, as vendors sometimes didn’t really know whether their application would work correctly. Then they were concerned about the interaction between their application and other people’s applications. Ahhh… and let us not forget those lazy vendors who didn’t fix the application properly… they just patched it to still use two-digit years, but make some sort of logical calculation that if the 2 digits were between 0 and 40 (or so), it would be read as 2000 – 2040, and if the 2 digits were between 41 and 99, it would be read as 1941 and 1999.

Craziness, right?

Well, I never stopped including language in my contracts that addresses this problem. Of course, I don’t specify that I’m talking about the Y2K problem specifically – I just have as part of my warranty language that:

“at no additional cost to Licensee and without human intervention, the Software will correctly recognize and correctly process data and formulas relating to the year 2000 and beyond (including arithmetic, comparison, sorting, day-of-week and day-of-year functions), will produce expected results (including correct leap year calculations) and will provide all such date-related data and formulas used by other applications in a format that will permit the correct recognition of dates by the other applications”

Most vendors don’t even blink at this anymore. In fact, I’m not even sure they think about it at all. But for the last ten years or so, I’ve included something similar.

And now it’s time for me to reap the rewards. For I knew a little-known fact (at least in the contract/legal community, that is)… the Y2K problem was a toll-booth on this highway. One of many similar issues. The next one is coming in 2038.

News: Saturday 19 Janurary 2008 is coming soon: this date is exactly 30 years before the bug. Will 30-year bonds and retirement schemes be affected? Let’s wait and see.

The year-2038 bug is similar to the Y2K bug in that it involves a time-wrap problem not handled by programmers. In the case of Y2K, many older machines did not store the century digits of dates, hence the year 2000 and the year 1900 would appear the same.

Of course we now know that the prevalence of computers that would fail because of this error was greatly exaggerated by the media. Computer scientists were generally aware that most machines would continue operating as usual through the century turnover, with the worst result being an incorrect date. This prediction withstood through to the new millennium. Affected systems were tested and corrected in time, although the correction and verification of those systems was monumentally expensive.

There are however several other problems with date handling on machines in the world today. Some are less prevalent than others, but it is true that almost all computers suffer from one critical limitation. Most programs work out their dates from a perpetual second counter – 86400 seconds per day counting from Jan 1 1970. A recent milestone was Sep 9 2001, where this value wrapped from 999’999’999 seconds to 1’000’000’000 seconds. Very few programs anywhere store time as a 9 digit number, and therefore this was not a problem.

Modern computers use a standard 4 byte integer for this second count. This is 31 bits, storing a maximum value of 2³¹. The remaining bit is the sign. This means that when the second count reaches 2147483647, it will wrap to -2147483648.

The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence it is possible that the media will call this The Friday 13th Bug.

-from www.2038bug.com

So… might I suggest that you include Y2K related language now? Sure, some folks might think you’re a little loopy. But isn’t our job to protect folks from the risks they don’t understand?

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering a licensing topic every week, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

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.

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.

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.

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 24×7 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.

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.

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.