By Stephen J. Bigelow, Senior Technology Writer
One of the biggest benefits of desktop virtualization is improved endpoint management. Instead of maintaining a proliferation of different endpoints across an enterprise, administrators can set user configurations and process tasks on virtual machines in the data center. But there's one weakness in this new paradigm, and it's legal rather than technological: software licensing issues.
Software is licensed, not owned, and licensing grants the user or purchaser certain rights to install and use the software. The problem is that desktop virtualization can change the way software is installed and operated, which can violate existing license agreements between the software manufacturer and user -- potentially exposing the user to legal repercussions. The channel is particularly vulnerable, so solutions providers must consider the implications of software licensing in any desktop virtualization project.
Challenges of software licensing
International copyright law governs software rights, but most developers use license agreements as binding contracts to establish expanded rights, restrictions and protections that copyright law does not cover. Examples include provisions that limit use of the software to a certain number of users, devices or sites or to certain geographic locations. In addition, licenses may prohibit use of the software on systems accessed by remote terminals, use of the software on computer networks and copying the software for all but archival purposes. These are common terms, particularly in licenses for shrink-wrapped, store-bought software.
Consider how these software licensing provisions affect desktop virtualization projects. A virtual desktop is basically a terminal that accesses software running on a system -- in this case a server, which could be almost anywhere in the world -- across a computer network. This infrastructure violates several of the most common terms of software licenses, and it can possibly expose the user to civil liability even though there is no nefarious intent and every copy of the software is fully paid for.
Desktop virtualization brings other software licensing issues as well. For example, some licenses allow software use on a single processor. What are the implications when multiple virtual machines run on the same processor and each virtual instance runs a copy of the software? What happens when an operating system or other common software is loaded into server memory as an image that multiple virtual desktops can access?
Most software manufacturers and their licensing standards have not yet caught up to the sheer flexibility that virtualization and networking technologies have enabled today.
"There are some vendors that have started making changes, but overall there are still many vendors that have not," said Barb Goldworm, president and chief analyst of Focus Consulting, an industry research and analysis firm in Boulder, Colo.
The introduction of Microsoft's Windows Vista Enterprise Centralized Desktop (VECD) licensing is just one example of change in the software industry.
"Instead of buying a shrink-wrapped copy of Vista for every desktop running in a [virtual desktop infrastructure] environment, you can license through VECD, paying a certain amount for every desktop running on the back end," Goldworm said.
Handling software licensing concerns
Software licensing should be an integral part of any desktop virtualization project. Proper licensing is every bit as important to customers as implementing a new server or upgrading the network. Unfortunately, there is no single solution to ensure adequate licensing in a virtual environment. Licensing terms and conditions vary by software vendor, and not all software vendors are equally amicable to licensing changes. But solutions providers can follow these guidelines to help their clients remain in compliance with software licensing terms:
- Evaluate each application and its license terms. Before starting a desktop virtualization project, perform a thorough inventory of the software running at the customer site. This evaluation should include operating systems, multi-user enterprise applications and end-user applications. Understand the terms of each license and identify potential problems. Be sure there will be enough licenses or seats for each user after implementation.
- Don't forget terminal services licenses if needed. Application virtualization -- serving up applications through terminal services -- typically requires additional licensing for the terminal services components you'll need to deliver applications to end users. Don't overlook the fact that these licenses can increase the cost of the desktop virtualization project.
- VDI won't change software licensing requirements. Issues with VDI-type desktop virtualization are mainly related to processing, networking and user access. The technology does not change the number of software copies running at the customer site. For example, if there are 100 computers running application X today, and all 100 of the PCs are migrated to thin clients, the customer will still need 100 copies of application X. They'll just be running on virtual machines in the datacenter, rather than on individual PCs.
- Communicate with vendors. Discuss software licensing issues with each vendor. Desktop virtualization is an emerging technology, and solutions providers should begin to see an increasing number of virtualization-friendly updates to licensing terms. Some vendors may be willing to modify or make exemptions to certain terms in their existing software licenses to accommodate proposed desktop virtualization projects. It's ultimately in the vendors' best interests, and vendors that won't at least discuss the matter may lose their customers (and their license renewal revenue) later on.
- Have a software licensing backup plan. Put alternatives in place if key software vendors refuse to budge on their software licenses for desktop virtualization. In some cases it may be necessary to delay a desktop virtualization project if the right licenses aren't in place. In other cases, solutions providers may have to recommend another, more virtualization-friendly vendor's software.
This was first published in March 2009