Not long in the past, SQL Server licensing was an easy and straightforward process. You used to take one of a few paths to get your SQL Server licenses. The first and easiest path was to buy your SQL Server license with your hardware. Want to buy a HP Proliant DL380 for a SQL Server application? Why not get your SQL Server Enterprise Edition license with it at the same time? Just pay the hardware vendor for the whole stack, from the bare metal all the way through to the Microsoft OS and SQL Server. Another, almost-as-easy path was to provide Microsoft with the details of your licensing needs: edition (Standard, Enterprise, DataCenter, or one of the other editions), number of CPUs in the server (note, CPUs not cores), and then pay up. Finally, some shops complied with licensing was to buy a lower-end edition, say Web Edition, with as many Client Access Licenses (CAL) as were needed, in some cases saving lots of money in the process.
You could also get discounts through various programs. For example, Microsoft introduced the Enterprise Agreement (EA) program for large enterprises making volume purchases back in the 1990’s. Over time, many more volume programs were introduced like Software Assurance, Open Value, Open Value Subscription, Enterprise Subscription Agreement and the Enrollment for Application Platform. Even then, it was so much easier than the licensing programs of other enterprise DBMS vendors.
That was then, but this is now.
Nowadays, it’s hard to get the same answer in two separate calls to two different Microsoft licensing representatives. And reading the SQL Server 2012 Licensing Reference Guide, available at http://go.microsoft.com/fwlink/?LinkId=230678 , is a lot like trying to translate the Codex Sinaiticus (http://codexsinaiticus.org/en/) when your entire knowledge of Greek is based on the university fraternity system.
Why? The complexity and ambiguity of licensing is entirely due to the way that virtualized CPUs can be used. Here’s an excerpt from page 11 of the licensing reference guide:
To license individual VMs using the Per Core model, customers must purchase a core license for each v-core (or virtual processor, virtual CPU, virtual thread) allocated to the VM, subject to a four core license minimum per VM. For licensing purposes, a v-core maps to a hardware thread.
Additional licenses are required when:
?? A single hardware thread is supporting multiple virtual cores. (A core license is required for each v-core.)
?? Multiple hardware threads are supporting a single virtual core. (A core license allows a single v-core to be supported by a single hardware thread.)
One way to get great clarity is not to rely on the licensing guides, since they are frequently out of date almost as quickly as they are produced, and use Microsoft’s volume licensing site using actual licensing details available at www.microsoftvolumelicensing.com/userights/DocumentSearch.aspx?Mode=3&DocumentTypeId=1 and www.microsoftvolumelicensing.com/userights/ProductPage.aspx?pid=397.
The most current (at time of printing) Microsoft Volume Licensing Product Use Rights (PUR) is where the best data is to be found at http://www.microsoftvolumelicensing.com/userights/Downloader.aspx?DocumentId=5752 (Note: this link directly downloads a DOCX file). For example, the PUR contains this better set of explanation for virtualized server licensing on page 54 concerning licensing individual Operating System Environments (OSE):
Licensing by Individual OSE
The number of licenses required equals the number of Virtual Cores in each Virtual OSE in which you will Run the server software, subject to a minimum of four licenses per Virtual OSE.
If any Virtual Core is at any time mapped to more than one hardware thread, you need a license for each additional hardware thread.
You may use any number of Running Instances of the software in any Virtual OSE for which you have assigned the required number of licenses.
Additional Licensing Requirements and/or Use Rights
License Mobility - Assigning Core Licenses and Using Software within and Across Server Farms
You may reassign licenses for which you have active Software Assurance coverage to any of your Servers located within the same Server Farm as often as needed. You may reassign licenses from one server farm to another, but not on a short-term basis (i.e., not within 90 days of the last assignment).
See how much easier this was to understand?!? In addition, I like how the final paragraph above makes it clear the flexibility (or lack thereof) that you get with a Software Assurance agreement in a virtual environment. You can simply move your licenses as much as needed!
While Microsoft has added complexity to the licensing and compliance aspects of SQL Server, it’s still a cakewalk compared to Oracle or DB2. And, as far as I can see into the future, SQL Server will still be a product which, when licensed, includes all features in the box, including the relational engine, reporting services, job scheduler, replication, data warehouse and business intelligence features, and so forth. That alone makes it a much easier product to license and maintain than its competitors.
(Special thanks to Microsoft MVPs Jonathan Kehayias and Allen Kinsel for helping me understand these licensing mysteries).