Ten tips for software licensing in a virtual world

• Tags:
• Datacentre,
• Virtualisation,
• Licensing

Manek Dubash ZDNet UK

Published: 16 Nov 2009 12:13 GMT

• 
• 
• 
• 
• 

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...

• 
• 
• 
• 

• Share this article:
• Digg
• Slashdot
• Del.ici.ous
• Stumble
• Reddit