Ten tips for software licensing in a virtual world

Virtualisation sets a number of software-licensing traps for the unwary, but they can largely be avoided through some sensible precautions, says Manek Dubash.

IBM was embarrassed after it launched its new server software licensing model in 2007. The aim was to update its pricing to reflect the growing use of multi-core machines, and to charge for software on the basis of use — utility-computing style.

The problem was that when implementing a tracking tool that allowed customers to plan and track computing resource usage, IBM forgot to take account of virtualisation, and if you ran the tool inside a virtual machine (VM), its visibility was too limited. This, from the company that invented virtualisation technology in the 1960s.

Hopelessly out of date
It is not the only example of its kind, but it highlights the way mindsets and old software licensing models, built up over the years, are hopelessly out of date once the hardware and software exist as separate entities.

In a modern datacentre, an application can move around across CPUs on a number of machines and use a variety of resources, depending on its requirements at the time. An application that runs the billing for a utility might only require maximum resources — CPU, memory, I/O and so on — on one or two occasions a month.

At those points, it may run on several CPUs simultaneously, and since software is still largely licensed on a per-socket or per-CPU basis, this situation can have consequences for the amount you will need to pay the software house.

Some software houses, notably Oracle subsidiary BEA Systems, have abandoned per-socket licensing for at least one product, while others such as IBM have come up with halfway-house answers, such as sub-capacity licensing, where the amount you pay is in proportion to the resources that an application running in a virtual machine will use. It is a form of metering, a pricing mechanism IBM has offered since the mainframe's glory days.

Complexity fears
Naturally, this is not a simple equation and, in a virtualised datacentre with mobile VMs, it often means paying for the most resources that an application will ever need. It is not surprising that, according to a recent survey commissioned by SafeNet, most UK companies fear that introducing new technologies will add complexity to their software licensing arrangements, generating security and cost issues.

Oracle keeps it simple: even if, for example, it is running in a VM-allocated four cores from the server's complement of 16, you pay for all 16, whether it is running native or in a VM. It means that the incentive to run Oracle on the fewest but most powerful CPUs available is strong.

Interestingly, though, you pay 50 percent more to run Oracle on the highest-powered UltraSparc CPUs than you do on Intel or AMD x86 processors. Given Oracle's ongoing acquisition of Sun, you might expect this disincentive to run Oracle on Sun kit to change when — or if — the acquisition is finalised.

So there are many potential traps when it comes to licensing software. Here are 10 ways to avoid paying more than you have to, while staying legal.

1. Know your contracts
Study the licence conditions of all software vendors with whom you deal and note that licensing mistakes can result in costs that significantly exceed any savings in hardware expenses following a programme of virtualisation.

Moves and alterations may mean changes in licensing requirements, so you need a clear idea of how well your software licence contract will fit your needs following any present and planned deployments. Changes could mean adding or subtracting licences, but either way, it is an opportunity to renegotiate the contract — and changes can include installation into a VM.

2. Talk to your software supplier
Renegotiate terms. If the manufacturer is unwilling to do so, examine your partitioning strategy. You might find that savings can be made...

...by running the application on a separate server rather than in a VM. You might even find that your discussion leads to a more enlightened approach by the vendor to virtualisation.

3. Use a software licence management tool...
Such tools help decision-makers be more efficient by providing them with the information they need. This facility is especially useful when servers move around the datacentre, and when IT or users can create virtual machines and consume licences — whether inadvertently or not.

In addition, without a central view of licence allocation and costs, decisions will be made based on purely technical information.

4. ...or find a licence management service provider
If you do not want to use a licence management tool, research diligently for an experienced provider with good references. It will pay to have the provider give training to IT staff on the processes, and to provide them with regular updates on best practices.

5. Rationalise hardware and virtualised operating systems
You can do this by not mixing PCs and Macs, for example. Not only will this reduce your support load, but will provide you with greater flexibility on licences for single-task software, such as Adobe Photoshop, allowing you to move the application from machine to machine, as required, and to create specialised VMs where necessary.

6. Watch out for Oracle
Make virtualisation managers particularly aware of the licensing conditions for applications such as Oracle. If you do not, you may find that automating VM creation, with each VM running an instance of Oracle according to load requirements, could result in unintentional violation of software licence agreements.

7. Do not automatically virtualise Oracle
Licences are counted per CPU, so the fewer CPUs you use, the cheaper it becomes. Use the fastest multi-core chips, and the additional cost will be easily compensated for by the savings on software licences — and you will not pay the small virtualisation performance overhead.

But if you do run Oracle in a VM, give it all the CPUs. Because Oracle explicitly disallows you from using VM partitioning to calculate the number of required licences, Oracle licensing policy means that running the database in a VM-allocated four cores of a 16-core server will be charged for all 16 cores.

8. Examine your disaster recovery processes
Examine your disaster recovery processes carefully and correlate them with your software licences and vendor policies. If you use virtualisation as a component of your disaster recovery setup, you might find that moving applications breaches the terms of licences such as Microsoft's.

9. Stay legal
It hardly bears repeating, but vendor audits can be triggered by a number of events, including corporate restructuring following a merger or acquisition, an IT infrastructure reorganisation as a result of hardware and operating system platform migration and virtualisation initiatives.

Software vendors hear about these changes as a result of case studies in the press, at conferences and marketing initiatives by vendors that have helped the organisation restructure. In addition, when a software vendor audits a company, other vendors might suspect that organisation of violating their contracts, too. Don't become the prey in a feeding frenzy.

10. Put your applications in the cloud
Moving applications to the cloud passes the entire burden of software licence management to the cloud provider.

The provider will include usage in its fees and ensure that the problem of shelfware — software for which licences have been bought, but sits unused — goes away.