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