The promise of moving your company's software and data systems into the cloud grows more enticing by the day. 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 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 license 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 licencees 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 licenced 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 licenced software is irrelevant.
The biggest problem with CPU licences in a grid or cloud context is that licensors expect licencees to buy additional licences for each processor (by number and type) that executes the licenced 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 licenced 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 licencee 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 licencee 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, licencees 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 licencee 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 licencee. 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 licence 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 licence.
Large companies regularly negotiate long-term custom enterprise and site licences. 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 licences are often impractical.
The Path Forward: The Transactions licence
There's another, better licensing structure that fairly balances the interests of licensors and licencees: a transactions licence. This embraces some of the elements of an enterprise licence, but it is adapted to serve organisations of all sizes.
Applying a transactions licence, the licencee 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 licence fee and entitlements are based on the licencee's transaction volume. As long as the actual transaction volume is within a preset range, there is no need to purchase additional licence entitlements or receive underutilisation credits. The transaction limits can be tailored as narrowly or as broadly as the licencees and licensors agree.
To keep track of transaction volumes, the licenced 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 licences 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 licence entitlement rights than they actually use initially and allows them to purchase more as needed. Because licencees won't feel cheated by the licensor, more will resist the temptation to abuse their licence rights. Licensors that evolve their software designs and licence practice to keep pace with the virtualisation and grid computing technologies will have a competitive advantage.
The promises of virtualisation and cloud computing are tempting. But when moving forward with virtualisation, 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 firstname.lastname@example.org and email@example.com.