Category Archives: maintenance

Internal Business Purposes

How many licenses to your core database software do you own?  I ask about this specific type of license because database software is typically expensive (relatively speaking) and customers license an exact quantity of licenses required based on actual use.  In other words, if you need 5 database servers (or instances), you pay for 5 licenses.

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.


Software Licensing Education Series – 400s Track Now Available!

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

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

Service Level Examples

Two weeks ago, we started talking about service levels.  Last week, we discussed how to write them and I mentioned that the best way to gain experience was to do it – repeatedly.  I stand by that statement, but if you’ve never done it before or don’t have a lot of experience in writing them, then you might need some help getting started.  So I’m going to provide you with some starting points for a few key service level metrics.  These are the ones common for software-related contracts – so they’re not going to be universally applicable to everyone or to all situations.  But they might give you a jumping off point for the creation of your own.

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.

CPI-U All Items

If you’ve taken my advice from the Software Licensing Handbook and included maintenance fee cap language that ties any increase in fees to the Consumer Price Index or x%, “whichever is less”, well, you might be in for a treat! Depending on the index you chose, and the time schedule for it (whether you chose an all-year average, or the average as of a given date for the prior twelve month period), there’s a chance that your CPI number is going to be a negative number.

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.


Some folks think I’m crazy for continuing to include Y2K-type language in my software licenses.

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


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?

Death and Taxes

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

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

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

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

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

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

Maintenance Percentages

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.