Perhaps the most challenging concept in the IT industry is software licensing. Unlike physical resources such as servers, storage, network hardware and user endpoints, software is intellectual property. Although you buy the discs and manuals inside the shrink-wrapped box, an organization doesn’t actually own the software. They’re merely purchasing a limited agreement -- a
A software license bestows limited rights to use the software, but it also imposes restrictions and threatens serious penalties when license violations occur. The explosive growth of virtual data centers has further complicated the concepts, construction and management of software licensing.
It’s important to understand the challenges of virtualization licensing. This article provides guidelines that can help software users remain compliant no matter how large their virtual infrastructure becomes.
Why good software license agreements go bad
Software licensing is a victim of traditional concepts that have not been updated or defined in a uniform manner. Every piece of software runs on a CPU, so software was traditionally licensed “per CPU.” It was then a simple matter of purchasing enough software licenses to cover the number of CPUs that would be running the software. For example, if you ran software on a total of four CPUs in the enterprise -- perhaps two servers each with two CPUs -- you paid for four software licenses.
It’s the same idea with software licensing today, but the notion of what constitutes a “CPU” has changed dramatically in recent years. The introduction of multi-core CPUs means that a single device mounted on a motherboard may hold two, four, eight or even more fully functional and independent processors.
This raises the first point of major confusion in virtualization licensing. Users may perceive a CPU as the entire “chip,” even though there may be multiple processors on it, while software vendors may perceive a CPU as each independent processor on the chip.
Suppose that a CPU chip has four processor dies on it. If the user allocates all four dies to running that software -- figuring it’s all the same CPU -- but the license considers each processor die as its own CPU, it’s easy to see where software licensing problems can occur. Some software vendors may choose to license their software per socket, allowing some latitude for multiple processors on the chip, so now software licenses need to differentiate between CPUs, dies, processors and sockets.
How virtualization affects software licensing
Today, virtualization obscures software licensing even further because applications don’t access computing hardware directly. Resources like CPUs are presented to software as virtual entities that can be shared, scaled or moved at any time.
Virtualization and the flexibility that it provides make it extremely difficult to quantify CPU
use for software licensing purposes. “Licensing does not accommodate dynamic scenarios like that,”
said Amy M. Konary, research director of software licensing and provisioning at IDC, a market
research firm in Framingham, Mass. Some software vendors might opt to set some kind of absolute
maximum number of CPUs and offer software licenses accordingly, but virtualization users quickly
push back, noting that CPU usage may vary and there’s no point in paying for software licenses that
are not always used.
The virtualization licensing confusion that plagues the industry generally results in several common types of software license violations, Konary said. The first is over-utilization, where software is run on more CPUs than there are licenses for. For example, two virtual processors are allocated to support an application, even though the software license is only for one CPU.
Another problem is over-deployment, where an application in one virtual machine (VM) is duplicated to create multiple VMs. This kind of virtualization sprawl is often encountered in virtual environments, and it creates copies of the software that the license might not accommodate.
The third violation that can occur in software licensing is through VM live migration itself. For example, moving a VM from one server to another with substantially different -- or usually more -- processor resources may break a software license that contains mobility restrictions.
This article originally appeared in the Virtual Data Center E-Zine.
This was first published in March 2011