Virtualisation, cloud computing and grid networks have a lot to offer enterprise users. But you could put your company and your job at risk if you fail to consider certain factors that are key to getting the right licence at the right price.
Whether you plan to use your own grid infrastructure or someone else's cloud computing platform, your licensing structures must accommodate the applicable virtual environment. Although many factors should be considered when licensing software, we'll focus on the available framework for licensing proprietary software, with virtualisation and grid computing in mind.
Unlike in a typical computing environment, virtualisation, coupled with grid computing, enables the disaggregation of operating systems, middleware, data stores and application software from the limitations of physical machines and the local-area network. This new world is colliding with traditional vendor licensing practices, producing software compliance nightmares for both licensees and licensors, and often resulting in irrational licence fees.
Legacy Licensing Practice
Traditional licences fall into one of these three categories:
The CPU licence is typical for operating system software, middleware and some application software. It enables licensees to use the software on one machine and often identifies specific compatible-equipment configurations. Any equipment configuration limitation is generally based on design, not licence compliance. For some software (for example, certain middleware server software), the licensed product may support alternative or enhanced server configurations, but separate licence entitlements must be purchased.
Under a CPU licence, the fee may vary based on the processing power of the designated CPU. The number of users who access the licensed software is irrelevant.
The biggest problem with CPU licences in a grid or cloud context is that licensors expect licensees to buy additional licences for each processor (by number and type) that executes the licensed software. This is true even if multiple virtual machines or processors are simply sharing the load -- without increasing capacity or transaction volume -- of a much smaller number of legacy physical machines or CPUs. In a cloud environment running multiple virtual machines, licence fees can easily rise because various processors are running the licensed software.
The seat licence designates the number of "seats" that can use the software. The licence entitlement doesn't flow to any specific users. There are two common seat licence methods.
The first calculates the fee by counting the total number of people who use the software. This method correlates poorly with actual use. There may be a significant number of potential users who rarely or never actually use the software. Worse, some licences define a chargeable seat as an instance of a user accessing the software from a particular machine (virtual or otherwise). Consequently, a single user or device can give rise to multiple seats - causing the licensee to pay multiple times for use by one individual or device.
The second method determines the licence fee by calculating the total number of concurrent users permitted to access the software at one time. This more closely corresponds to licensee use patterns than the total-seat licence because occasional users can be discounted when determining how many seats to purchase.
Of these two, the concurrent-user seat licence may be the most desirable if you're moving to grid computing and a virtualised infrastructure. Under concurrent-user models, licensees should be charged based upon the greatest number of seats (whether individuals or devices) that use the application at any one time. Whether the users operate one or more physical or virtual machines shouldn't matter.
This can be an imperfect indicator of usage patterns, however, because not all users are equal. A company that has many power users would pay the same fee as a company with an equal number of users whose usage is average. And from the licensor's perspective, the concurrent-user model is undesirable for back-office or middleware software, since a few administrative users can serve as transaction conduits.
The enterprise or site licence allows the licensee to use the software without geographic limitations, specific limits on the number of users or devices accessing the software, arbitrary processor accounting rules, or prohibitions on the number of copies made or used by the licensee. There may be restrictions on the types or configuration of the equipment on which the software may be installed, as well as some business operation boundaries.