X
Tech

Oracle under fire with x86 hypervisor licensing

Burton Group's Chris Wolf has fired a salvo in Oracle's direction concerning its x86 hypervisor licensing policy. This is a long extract from a much more in depth piece but it is necessary to see what Chris is saying in order to understand the context (my emphasis added and apologies to Chris for ripping so much of his excellent post):Oracle is requiring customers who wish to deploy Oracle products on x86 hypervisors to license Oracle software by physical server CPUs.
Written by Dennis Howlett, Contributor

Burton Group's Chris Wolf has fired a salvo in Oracle's direction concerning its x86 hypervisor licensing policy. This is a long extract from a much more in depth piece but it is necessary to see what Chris is saying in order to understand the context (my emphasis added and apologies to Chris for ripping so much of his excellent post):

Oracle is requiring customers who wish to deploy Oracle products on x86 hypervisors to license Oracle software by physical server CPUs. Suppose you had two Oracle Database VMs (each with two virtual CPUs) running on a two-node ESX cluster that uses two four-socket servers. Since it’s possible that you’d have a VM on each node, you’d need to purchase licensing to cover the 8 total sockets. If you ran Oracle’s hypervisor, you could license by virtual CPU, however this is only allowed if you pin the VM to fixed CPU cores by hard coding CPU bindings. You can read more about that here. This does create a slight advantage for OVM over competing products, but by binding a VM to one or more physical CPU cores, you have to give up advanced virtualization functionality such as live migration. If I’m using application-level high availability features, this configuration may not be a big deal and would in turn favor Oracle; however it is far from ideal.

Oracle’s competitors in the database arena allow their products to be licensed by virtual CPU without requiring physical bindings (see Microsoft’s and IBM’s policies), and so should Oracle. Doing so allows VMs to move about the physical infrastructure as required to support IT operations. Binding enterprise software licenses to physical assets is a legacy licensing model, and Oracle is practically alone in their licensing policies.

Oracle’s strategy with regard to licensing is one that I’ve seen before. Oracle is effectively taxing organizations for running Oracle Database in a VM. In most cases, organizations will have to pay increased licensing fees. This policy hurts the customer, and in my opinion is an attempt to stall market adoption while Oracle finishes building out its own x86 virtualization platform.

Oracle, it’s time to classify all x86 hypervisors as “hard partitioning.” Our clients are increasingly deploying enterprise applications on x86 virtualization hypervisors. You’re putting them in a tough position, and many consider the virtual infrastructure the foundation for their cloud architecture. Some clients have told me they are now considering moving forward with DB2 or SQL Server because they are unwilling to pay a penalty to run Oracle on any x86 hypervisor. In the end, our clients shouldn’t have to make that choice. They should have the freedom to run the applications they want on the platform they want. This licensing policy is affecting the bottom line of our clients and could ultimately affect your bottom line too. It shouldn’t have to come to that. Let’s just "right the wrong.” Besides, your “Partitioning” document which describes software licensing for virtual environments was last updated in January 2008. In response to my last blog post, you were able to revise a support statement within two days. How about taking the time to revise a licensing policy that is clearly outdated and places an unnecessary burden on our clients?

I asked Oracle for comment on Chris's position but I did not receive a response in time for this post.

At the top of his post, Chris describes the policy as 'unfair.' That's pretty harsh but given he has tried numerous times in the last few days to get some sense out of the company, it should not be surprising that he goes into the public domain. I would go further - this is typical Oracle and representative of the company's addiction to satisfying its Wall Street masters at the expense of its customers. Want a discount? How much more software are you buying first and then maybe we can talk?

The good news is that an industry analyst is prepared to put his head above the public parapet, explain the problem, note that customers are considering alternatives yet is still prepared to give Oracle a 'get out of jail free' card. If it chooses to listen.

A frequent thread among my Irregular colleagues can best be described as 'vendor DNA.' Just as some of us shake our heads at certain of the goings on at SAP and IBM, the same is true of Oracle. As time passes, we see a widening gap between the attitudes of the incumbent players to their customers and vendors emerging in the cloud computing era. We see a growing tide of discontent among customers where the word 'support' could easily be replaced by 'tax.' These customers are increasingly relying on industry commentators to adjust their vendor centric positions and speak out as Chris has done. This is not the way it should be. Now more than ever, vendors should be actively helping customers drive value. Even so, the attitude is understandable when you can look back over a long period of success and have billions of dollars in the bank. It's their DNA.

As I've said before, double digit margins of the kind Oracle promises are unsustainable. Giving the impression of nickel and diming customers in the process is intolerable. Far better to give customers choice, let them see you'll play fair or otherwise watch as the market decides.

Customers should recognize that while they may not be equal partners in the power relationship between themselves and vendors, they do have ways to make their voice heard.

As an aside to this, note that Chris is positioning Oracle as a cloud player. Watch this space.

Editorial standards