OK Sam & Jeff, here more thoughts from my side.
I guess you have to separate two things:
- What is really allowed within the limits of licencing contracts (and the law)
- What can be reliably measured using available tools (logs, audit trails, etc)
I don't know the contents of licence agreements but I guess it says something like that you have to licence Oracle on a specific processor (i.e. a piece of silicon in a black plastic case with a serial number printed on it).
The fact that I can ditch audit trails when moving (i.e. vmotion) a running database from a licenced physical processor to another server with an unlicenced processor and back without being detected, means I am violating the policy - it's just that they can't catch me.
(but I risk that the auditors are smarter than me and find out a way to figure it out anyway and use it to legally send me a huge bill)
Which suggests that using VMware affinity to keep Oracle DB within certain physical CPU/server boundaries is playing (strip) poker with licence policies and the hostile auditors.
They might also be smart enough to claim that (for the same reason) even if you might not have really moved the database anytime to unlicenced CPUs, the technical possibility was there all along and therefore we owe them licence fees anyway.
I would not recommend to customers to do it this way...
Let me start by bringing all of you into the courtroom. There are three issues that you will observe me as counsel provide to the jury as part of my allowed instruction (I am not an attorney in real life).
I offer the definitions in this paragraph only to make this post as self-sufficient as possible and not with intent to talk down to anyone. Case law refers to precedents established in other court cases. Case law can supplement statutory law enacted by legislative bodies and can stand in lieu of statutory law when applicable statutory law does not exist.
Back to the courtroom:
I offer the following as the exclusive binding source documentation for this post:
The OLSA is bi-laterally executed between Oracle and the customer. I have seen many of them as you can imagine in my role as the lead of House of Brick’s Oracle Enterprise License Assessment business line. The OLSA always contains:
The sum and detail of the stock published OLSA and its external Software Investment Guide for at least the last decade and to-date with respect to processor-based licensing is two-fold:
When discussing Oracle licensing, there are two common areas of confusion.
I tried to force both clarifications into Gartner Group’s Chris Wolf’s November 10, 2010 blog thread via comment posting. I feel that I failed to get Mr. Wolf to directly address my point before he elected to close the thread. I feel that I failed both verbally and in writing during the pre-publication interview process to preventively insert the clarifications into TechTarget’s Beth Pariseau’s May 4, 2011 article titled “Oracle licensing for vSphere 4.1 irks VMware pros.” Furthermore, the TechTarget article’s title unfortunately implies that Oracle may have licensing terms specific to vSphere version 4.1, which it does not, or licensing terms specific to VMware technologies in any way, which it does not. Thankfully the VMware Corp. November 2011 whitepaper (to which I contributed) “Understanding Oracle Certification, Support and Licensing for VMware Environments” got it right. I can confirm that the entire white paper received all the multi-disciplinary pre-publication review that you would imagine appropriate for a piece of its importance and ramifications.
House of Brick is occasionally invited by customers and/or partners to get on the phone with Oracle to deal with Oracle licensing concerns that Oracle has verbally conveyed to the customer. We always welcome these opportunities. The most recent call was a couple months ago. An Oracle Corp. licensing specialists was on the call. The impetus for the call was that Oracle had previously told the customer that all nodes in a physical cluster must be licensed, not just those where Oracle executables are “installed and/or running.” We asked the Oracle licensing specialist about the statement. He informed us that it was Oracle’s policy. We asked where the policy was written. He replied that it is an unwritten policy. At this point, we reminded him of the binding OLSA language whereby all verbal conveyances and understandings were voided at the execution of the document leaving only the printed OLSA terms in effect. That was the end of the discussion. The customer left the call entirely and appropriately satisfied as to their full legal compliance with their proposed sub-cluster licensing scenario. This vignette is by no means an isolated incident. The outcome is always predictable and consistent.
A previous post on this thread states ‘I've heard Dave at HOB contend the same thing you've heard, which is essentially: "DRS/Host Affinity SHOULD be fine"...’ The quote could be interpreted inappropriately out of context of my consistent, persistent statements. What I have always said is that any method (manual or automatic) to restrict movement of Oracle executables to a licensed sub-cluster of physical hosts is fully OLSA-compliant and legally defensible. At the release of vSphere 4.1, I added the statement that DRS Host Affinity Rules happens to be one, the newest, and the easiest of multiple available methods of restricting Oracle executables’ movement.
There are comments on this thread that I believe fall under the umbrella of attempting to prove negatives. Oracle has no legal obligation to go on paper with sub-cluster licensing clarifications specific to vSphere. In my view, Oracle has no financial incentive to do so. Stop looking for that to happen.
Occasionally people actually insist that I produce an Oracle-authored document that says Oracle will not ding them for not licensing all nodes in a physical cluster. That strikes me like asking me to provide an Oracle-authored document that says Oracle will not make a claim against me for choosing to drive a Ford as opposed to a GM. Not only is it asking me to prove a negative which I cannot do, but it delves into an area that is none of Oracle’s business since it is not listed in my OLSA obligations.
I see no need for Oracle to comment on their recognition of the validity of vSphere logs to prove vSphere VM movement. vSphere logs may well be the best available mechanism to document Oracle executables’ travels. Although vSphere logs may not be identical to “best available image” case law, “best available image” is instructive to the audit log/verification concept under discussion. As of November, 2010, the majority of the world’s servers are virtual. ~85% of those virtual machines are VMware. That is tenured technology and no one is questioning the de facto authority of those logs. Oracle has the OLSA-granted right to present themselves at any time without notice for the compliance inspection of their customers’ physical hardware. Oracle has options to audit the current and historical location of where their executables are “installed and/or running.” That those options may rely on mechanisms not provided by Oracle is beside the point.
As for the question on the thread as to whether vSphere logs could be maliciously manipulated, security industry experts have said that eighty percent of security breaches come from within the firewall. I see a corollary to that statistic. Oracle has plenty of financially incented prospective friends inside its customer organizations. It is sad that human integrity is such that posting of large rewards has become necessary to incent individuals to turn in their employers for knowing theft of software. To me, OLSA obligations are like the U.S. tax code. I believe in paying every penny I owe. However, beyond that, it is my discretion to who or what I donate and in what amount. I have no patience with individuals or entities that premeditate the creation of OLSA compliance issues. I similarly have no patience with the knowing spreading of FUD by some professionals in what could be construed as extortion of funds beyond customers’ executed contractual obligations. I will continue to vigorously promote and defend the legal rights of both software vendors and their customers even if that means I induce accelerated hair loss through rapid, frequent hat swapping.
What Oracle verbally represents on this or any other contractual topic for that matter is of absolutely no relevance whatsoever. Look to the OLSA and extant external referenced documentation as of the OLSA’s execution date. Should you still be dissatisfied, look to court history of judgments against customers attempting to exercise their sub-cluster licensing rights. Let me save you some time. Relevant court history does not exist. There is a simple reason: the terms of your executed OLSA are clear, sufficient, binding. The terms explicitly invalidate any and all verbal representations.
Given what I have presented here, I see no legal, risk management, or moral need for and am not inclined to encourage and/or endorse air gap clusters strictly for Oracle licensing purposes. I am concerned that such talk may scare parties away from investigating, understanding, and asserting their legal rights. Furthermore, in my observation, such talk gets quickly quoted out of context of the original motive. I believe such talk has a similar long-term effect on the market as paying ransom for hostages has on future hostage taking. The SMB market has every contractual right to leverage sub-cluster licensing to facilitate crossing the chasm over to Business Critical Application virtualization. That larger enterprises may find it convenient to use air-gap cluster separation of their Oracle workloads is great, but to do so has absolutely no bearing whatsoever on their legally binding contractual obligations to Oracle Corporation.
Some on the thread have suggested this or that course of action to minimize risk with Oracle. Occasionally people express concern to me that Oracle has far deeper legal pockets than they do. I believe those that make these points do not understand the power of their position. I cannot think of one reason that Oracle could possibly want this thing to go to court and indeed I believe Oracle has everything to lose minimally moving forward if and when it does. Once such a judgment was out, it would cause an immediate slow-down on non-contractual cash donations that some of Oracle’s customers have felt induced to make.
Interesting point, and very interesting and useful discussion. I have a fulltime job assisting Oracle clients independently with licensing issues and would like to share my 5 cents with you and look forward to hear your (dis)agreements.
1. I don't care what's in the SIG. I don't care what's in the Partitioning whitepaper. I don't care what's in the 'licensing data recovery' whitepapers. Look at the footnote and understand why. It serves no contractual purpose at all, period.
2. Oracle does take stance toward clients who defend themselves against the practice of 'licensing the entire cluster'. I've adviesed multiple clients to argue their case with Oracle Legal, in writing. Not one time Oracle Legal replied, only LMS (specifically the regional LMS manager). That must be because the Legal department don't want to burn their fingers on this item. LMS will always answer this (freely translated):
"Our agreement is defined in the OLSA. Such a license agreement only describes under what conditions you are allowed to use Oracle software within your organization. If a certain usage type has not been described in the agreement, it does not mean that this type of usage is therefore allowed".
I've seen multiple lawyers laugh at this statement. The OLSA is a restricted license, and all restrictions are in place. And if they were not, Oracle would certainly not be allowed to randomly come up with new restrictions as they see fit. "Where the Programs are installed and/or running" covers it all. But Oracle tries to get the money, and use LMS as a vehicle. Why? Because LMS is funded by Sales and have a revenue target.....simple as that.
In any situation I've run into, I will tell the client not to pay for the whole cluster if the software is not 'installed and/or running' on every ESX. DRS or not. We have a saying here "wie eist bewijst", or "who demands, must deliver the proof". so if Oracle would demand licenses for the entire cluster, oracle must proof that software is installed and/or running on every ESX....it's not for the client to proof it is NOT running. DRS or not.
It's not the client's fault that Oracle is not exhaustive in their description of OLSA interpretations. Microsoft does it much better, and has for each virtualisation example contractual binding scenario's written out in the binding Product Use Rights documents.
In every case I've run into, Oracle eventually backs out. Unfortunately many un-informed client's don't dare to push back and simply pull their wallet and pay. If any such case would make it to court, upon the client's initiative, Oracle would lose a lot of money as hundreds if not thousands of clients would want their money back....and rightfully so. With the agressiveness Oracle is auditing in this region, it's only a matter of time until a client will sue them for attempted theft. It would be an interesting case to follow.
Now if you compare the SIG with any signed OLSA - customized or not - you'll find that many things could be interpreted differently than they are being interpreted by Oracle's auditors. Virtualization is just one out of many issues.
We are currently audited by Oracle and we have the VM ware cluster issue ....
As you are an Oracle independend consultant can I contact you in this matter ?
Do you provide consultancy in this topic ?
LVP may also want to review this blog entry from Michael Webster giving the “right questions to ask” and knowing your Oracle obligations when the Oracle Sales Team (think audit) questions you:
At Blue Medora we are building a plugin for Oracle Enterprise Manager (em12c) that is specifically designed to help customers deal with the technical aspects of the 'Oracle on VMware Licensing' problem referenced in this thread.
The particular focus of this Oracle EM plugin is to to provide Oracle EM based alerting, visibility, and reporting on Oracle workloads running in vSphere including whether or not an Oracle workload (database typically) is on a Oracle licensed ESX hypervisor or not, whether the VMware configuration is locked down in a manner that the Oracle workload is prevented from vMotioning to a non-Oracle licensed host, and historical views of VM mobility within the vSphere environment to understand the complete trail of where the VM has been.
Anybody who is interested in participating in the beta for the Oracle EM plugin for 'Oracle on VMware LIcensing' can do so here.