The promise of moving your company’s software and data systems into the cloud grows more enticing by the day. Virtualization, 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 license 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 virtualization and grid computing in mind.
Unlike in a typical computing environment, virtualization, 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 license fees.
Legacy Licensing Practice
Traditional licenses fall into one of these three categories:
The CPU license 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 license compliance. For some software (for example, certain middleware server software), the licensed product may support alternative or enhanced server configurations, but separate license entitlements must be purchased.
Under a CPU license, 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 licenses in a grid or cloud context is that licensors expect licensees to buy additional licenses 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, license fees can easily rise because various processors are running the licensed software.
The seat license designates the number of “seats” that can use the software. The license entitlement doesn’t flow to any specific users. There are two common seat license 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 licenses 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 license 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 license because occasional users can be discounted when determining how many seats to purchase.
Of these two, the concurrent-user seat license may be the most desirable if you’re moving to grid computing and a virtualized 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 license 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.
The site license is a variant that restricts to a specific site either the installation or the location from which users can access the software. Each additional site requires a new license.
Large companies regularly negotiate long-term custom enterprise and site licenses. These require lengthy negotiations and large lump-sum payments to the licensor. Given the cost and negotiation leverage necessary to make this strategy work, enterprise and site licenses are often impractical.
The Path Forward: The Transactions License
There’s another, better licensing structure that fairly balances the interests of licensors and licensees: a transactions license. This embraces some of the elements of an enterprise license, but it is adapted to serve organizations of all sizes.
Applying a transactions license, the licensee can use the software without geographic limitations, restrictions on the number of users or devices accessing the software, or arbitrary processor accounting rules. There are no limits on the number of copies or instances.
The license fee and entitlements are based on the licensee’s transaction volume. As long as the actual transaction volume is within a preset range, there is no need to purchase additional license entitlements or receive underutilization credits. The transaction limits can be tailored as narrowly or as broadly as the licensees and licensors agree.
To keep track of transaction volumes, the licensed software can be enabled with software agents that monitor and report on the transaction volume during the appropriate measurement period. (Annually makes the most sense. It accounts for seasonality and avoids introducing too many burdensome electronic audits.)
Determining which transactions for a given piece of software will be relied on for pricing and then developing reliable monitoring agents are among the technical challenges transactions licenses present. Forward-thinking licensors should be motivated to overcome these challenges, however, because the rewards are worth the effort.
Licensors will be able to offer many of their potential customers a more rational pricing option that doesn’t force them to purchase more license entitlement rights than they actually use initially and allows them to purchase more as needed. Because licensees won’t feel cheated by the licensor, more will resist the temptation to abuse their license rights. Licensors that evolve their software designs and license practice to keep pace with the virtualization and grid computing technologies will have a competitive advantage.
The promises of virtualization and cloud computing are tempting. But when moving forward with virtualization, make sure your head is not lost in the clouds. You should be clear about what you’re getting yourself into. Identify the real costs, pin down the scope of your use rights, put protections in place in case things don’t go as planned, and lay a strong licensing foundation that will serve you in the future.
Gamboa and Lindsey are partners at Washington law firm Levine, Blaszak, Block & Boothby LLP (www.lb3law.com ). Contact them at jgamboa@lb3law.com and mlindsey@lb3law.com.
