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.
LicensingHandbook Archive 
Jeff, you make some good points about the financials related to development/test copies. You always end up paying somehow. Licensing can get a lot more complicated depending on the vendor’s licensing scheme too.
The big database players typically license by the number of CPUs, not per server. Some charge half price for test server, some full price. I could go into great detail about some of those schemes, but I don’t want to get off into a tangent.
I’ve got to disagree about not keeping dev/test servers on maintenance. You should want them to be on maintenance, but at a reduced rate if possible. For instance, typically with maintenance you not only get support, you get updates. It’s rare that the vendor will break out support and updates in the overall maintenance fees. You’ll need the test servers to be on the same version as the production servers so you’ll want to pay for the updates. Also, I see the tech staff calling in for test servers all the time. Testing can be nearly as critical as production in some cases and support has to be maintained on those servers.
Hi Chris: Thanks for your comments. I think I might have been not clear enough on maintenance for test/dev servers. It’s not that I don’t think you should be covered by maintenance on those boxes, I just don’t think you should have to pay for maintenance on those boxes. And it’s exactly for the reasons you state – that testing/development is understood to be necessary for the successful management of a database environment – so you shouldn’t have to pay extra to make it work properly.
I think you are absolutely correct when you say that you always end up paying somehow. So while I can rant as much as I like about not paying for test/dev servers, I know, deep down, that I’ll end up paying for them somehow. I just think it’s not really right to have to do so.