You can more - Fotolia
Licensing is a challenge for many companies. Confusing terms, unique conditions and different product variations make it complicated and time-consuming. Still, one thing remained consistent: the hardware. Licensing moved with hardware and, though troublesome, was still workable.
That all changed with virtualization. We are no longer bound by hardware restrictions and can allocate core, CPUs and memory as needed. However, many software licensing models have struggled to keep up, leaving customers to wonder whether what they're doing is legal. The gray area is wide, and the consequences of not following the rules can be severe.
Core changes in software licensing models
One of the most popular ways companies license is per CPU. Before Intel's Hyper Threading and multi-cores, a processor had a single brain and things were simple -- one CPU, or brain, usually equaled one license. Servers that needed multiple CPUs would often have dual or quad CPUs, but still just one brain per CPU.
With the evolution of hardware came the introduction of the core concept. This enables multiple cores or brains per CPU, which skews licensing in favor of the customer, as they receive more horsepower while still paying for a single CPU license.
Intel went a step further, enabling a single core to virtually split the workload between two virtual cores per single physical core. You could now have a single CPU with four physical cores, and each core could do the work of two cores. Your single CPU could now look like it had eight brains. In most cases, this benefited the customer, so it was only a matter of time before licensing caught up with the hardware.
Now many vendors use a per core model for licensing, and this approach has added confusion. For example, Microsoft's Windows Server 2012 Datacenter edition was licensed per CPU -- not core -- and allowed users to run unlimited VMs per host in virtualized environments once they licensed all of the physical CPUs. It was simple concept that benefited the customer. Now, in the 2016 Datacenter release, Microsoft requires a license for each core. The core licenses are sold in packs of two and are about the same price as the old licensing scheme -- until you go above eight physical cores per CPU socket, which is the minimum number of cores per CPU you can use with Datacenter.
While this may sound reasonable, the real issue is what happens when a company goes above eight cores per CPU. In early 2016, Intel was shipping CPUs with up to 18 physical cores per CPU. This could potentially cause Microsoft to dramatically increase the price from the eight-core base model. The price could soar so high that it would cause companies to rethink how they configure servers. The concept that more cores are better may fall away in favor of reducing cores to better take advantage of the software licensing.
When it comes to virtualization, the server license is often the easy part for administrators. Placing desktops or using virtual desktop infrastructure (VDI) is so complex that it practically requires legal assistance to make sense of the agreements. Desktop OSes have always been tied to the hardware in an original equipment manufacturer agreement, which made them fairly easy to work with. Now, you'll need to pay for services such as software assurance or Virtual Desktop Access subscriptions to run virtual desktops. These software licensing modes can be confusing in what they include and are often licensed per user, which can be difficult to track in an environment with shared resources.
Additionally, the thin-client itself may require an OS license to access your virtual desktop. This is, in large part, why VDI has struggled with cost benefits. Some virtual desktop licenses may come with certain hardware; verify it with the OS manufacturer, as it subject to change.
Oracle presents challenges
Licensing often applies to the application world as well. Application licensing can differ, being tracked by the number of users, or by CPUs or cores for unlimited connections. Several products, including Microsoft SQL, have now made the transition from CPU to core models.
While this concept is generally as straightforward as server licensing, there is one notable exception: Oracle. Since Oracle is in direct competition with other major hypervisors vendors, the company has gone to great lengths to discourage the use of any hypervisor except its own.
For starters, Oracle supports its application on a non-Oracle virtualized platform, but does not certify it. This means that if a known issue crops up with an Oracle product, you can obtain support. If it is a new issue, you will have to contact the hypervisor vendor for support and, in some cases, replicate the issue on physical hardware. It gets worse: Additionally, Oracle does not support what it calls "soft partitioning" of resources. This means you cannot use a hypervisor to limit the number of CPUs or cores in a VM. Therefore, all CPUs/cores must be licensed in the host, as the VM can run on any of them. For many, this simply makes it too expensive to virtualize Oracle on a traditional hypervisor.
The evolution of licensing
Licensing is full of unclear language, terms with limited descriptions and software licensing models that confuse as much as clarify. A few things, however, are becoming certain: For one, per CPU licensing is being dislodged by the core licensing or per user model. Also, memory limits on licensing have mostly faded away.
Subscriptions and bundles are becoming the norm, but users must take great care, as the different products they contain may have different software licensing models. It will take time and research to determine what you need. Take into account what you're currently using, what you want to use and the interaction between the different products. It's not an ideal situation, but with time and diligence, you can be successful.
Making sense of Windows Server and Hyper-V licensing
The seven deadly Oracle licensing sins
How virtualization can lead to software licensing woes