Virtual Appliances Cause Software License Confusion

By ghosting in an OS and an app in the same software package, and replicating themselves with little trouble and no notice to license administrators, virtual applicances can create some questions regarding sofware licensing.

Licensing has been an issue in virtualization ever since virtual servers began multiplying the number of operating systems and applications that could run on physical servers. Virtual appliances—preconfigured packages of the application and OS that can run on either physical servers or virtual machines—are causing some confusion by increasing the amount of software that runs on a network, often without processes designed to prevent license violations.

Virtual Appliances are shipped around the network with several repositories. The most common one for VMwareproducts is described here. However, quite a few software companies ship their demos and products using virtual appliancesoften without making license implications clear.

They may include within the appliances software that is not licensed for this task. They may even violate U.S. export licensing by including encryption software more powerful than that allowed for export.

There are rumors of demo software arriving at customer sites with fully licensed versions of Microsoft Windows 2003 and Windows XP installations. Now, granted, Microsoft does have licensing for virtual appliances, but the appliance would need to be in its format and not VMware's. This would be a clear licensing violation.

Other appliances include at least one instance of the VMware Infrastructure Software Developers Kit (VI SDK). A recent discussion on the VMware Communities forum showed that at one time the VI Perl Toolkit was licensed under open source but now is not.

The discussion thread shows two things. The first is that licensing, export controls, and the laws involved are not easy to unravel, and generally the people doing them are not lawyers, so mistakes will be made.

The other: if you want to install VI SDK software on a system you will have to get the vendor software and also download VMware's software. This is in effect twice the amount of work that a single download would provide.

The above scenario has the benefit that you leave the issue of export controls between the end user and VMware, but it makes third party software for VMware's products more difficult to install. Some may refuse to do so, if this is the case.

This is a sticky issue, as one version of the VI SDK could be legal to distribute, and another is not. This creates quite a bit of confusion for users.

This also demonstrates that normal licensing schemes no longer work.

OS Licenses depend on you installing them onto physical hardware, which is difficult to transport. Even on a laptop, an OS stays within your control.

However with a virtual appliance, the installed media is no longer within your control. This has been addressed by Microsoft and other vendors.

Unfortunately, some vendors may ignore licensing issues when they send out virtual appliances to customers. This could put both parties in jeopardy. This makes you think: if they violate licensing what else are they violating and is this the way to start a trusting relationship with the vendor?

Licensing responsibility is yours.

Virtualization expert Edward L. Haletky is the author of "VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers," Pearson Education (2008.) He recently left Hewlett-Packard, where he worked in the Virtualization, Linux, and High-Performance Technical Computing teams. Haletky owns AstroArch Consulting, providing virtualization, security, and network consulting and development. Haletky is also a champion and moderator for the VMware discussion forums, providing answers to security and configuration questions.

Related:

Copyright © 2008 IDG Communications, Inc.

7 secrets of successful remote IT teams