Recently, while answering a question, I came across what appeared to be a change to the rules for licensing Oracle Standard Edition — a change that appears to be subtle on the surface, but one that could have significant and surprising repercussions.
It was with considerable fanfare that Oracle announced, several years ago, the last major change to the licensing rules for Standard Edition — that multi-core processors would be counted as a single CPU for the purposes of licensing Standard Edition products. (For Enterprise Edition, Oracle continued to count each core as a separate “processor”, but then provided price discounts, presumably in recognition that a 2- 4- or 8-core CPU rarely provides equivalent performance to an equivalent number of single-core processors running at the same clock rate).
The revised licensing rule went like this (I have highlighted the relevant text in bold):
Processor: shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on a processor basis may be accessed by your internal users (including agents and contractors) and by your third party users. For the purpose of counting the number of processors which require licensing for a Sun UltraSPARC T1 processor with 4, 6 or 8 cores at 1.0 gigahertz or 8 cores at 1.2 gigahertz for only those servers specified on the Sun Server Table which can be accessed at https://oracle.com/contracts , cores shall be determined by multiplying the total number of cores by a factor of .25. For the purposes of counting the number of processors which require licensing for AMD and Intel multicore chips, cores shall be determined by multiplying the total number of cores by a factor of .50. For the purposes of counting the number of processors which require licensing for all hardware platforms not otherwise specified in this section, a multicore chip with “n” cores shall be determined by multiplying “n” cores by a factor of .75. All cores on all multicore chips for each licensed program for each factor listed below are to be aggregated before multiplying by the appropriate factor and all fractions of a number are to be rounded up to the next whole number. When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to a socket.
This is exactly the definition you will find today today in Oracle’s online store, for example here.1 In fact, being lazy and not having access to a two-year-old copy of the OLSA, that is exactly where I got the text above.
Now, that little bit of bold text was a pretty big deal. As I understood it, and everybody I could find seemed to agree, this affected both the licensing cost and the eligibility rules. These 23 simple words now meant that Oracle Standard Edition was limited to computers with a maximum capacity of four (4) CPU sockets, not four processor cores. Although multi-core processors were — at the time, several years ago — relatively new, at least in the “commodity hardware” space, we all new that Intel and AMD had near-term plans for 4-core and eventually event 6- and 8-core processors. Suddenly, we could build an Oracle database server with 16 processors (cores) and 16GB of RAM or more, for less than $200,000. (Prior to this change, you would pay $640,000 — list price — just for the Enterprise Edition database licenses.)
But now, it seems, all of this is changing again, only this time, not for the better.
So what exactly has changed? The text above came right off of Oracle’s website this very day, right? Yes, it did. But it did not come from the Oracle License and Services Agreement (OLSA).2
Here is the new definition, from the current OLSA (revision V050108, last updated 01 May, 2008 it would seem):
Processor: Processor: shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on processor basis may be accessed by your internal users (including agents and contractors) and by your third party users. For the purposes of counting the number of processors which require licensing for a Sun UltraSPARC T1 processor with 4, 6 or 8 cores at 1.0 gigahertz or 8 cores at 1.2 gigahertz for only those servers specified on the Sun Server Table which can be accessed at https://oracle.com/contracts , cores shall be determined by multiplying the total number of cores by a core processor licensing factor of .25. For the purposes of counting the number of processors which require licensing for AMD and Intel multicore chips, cores shall be determined by multiplying the total number of cores by a core processor licensing factor of .50. For the purposes of counting the number of processors which require licensing for all hardware platforms not otherwise specified in this section, a multicore chip with “n” cores shall be determined by multiplying “n” cores by a core processor licensing factor of .75. All cores on all multicore chips for each licensed program for each core processor licensing factor listed above are to be aggregated before multiplying by the appropriate core processor licensing factor and all fractions of a number are to be rounded up to the next whole number. When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.
Yes, they printed the word “Processor” twice. I did not add that. All I have added is the boldface.
Oracle has added 18 new words to the definition of “processor” as it applies to Standard Edition products. Now, a “processor” is a “socket”, but where “multi-chip-modules” exist (note: no definition is provided for that), each chip in the multi-chip module is a “socket”.
So, now you want to license Oracle Standard Edition for a commodity server with 4 quad-core Intel Xeon processors. Your server has only four “physical sockets” (places where you can plug a CPU module into the motherboard), so this everything is good, right?
Not so fast! Intel’s quad-core Xeon processors are (for now, anyway) implemented as Multi-Chip Modules (MCM). Well, at least some of them are. They each contain two processor “chips” or “dies”, each providing two processor cores. So now, each of these CPU modules counts as at least two sockets. The server now has eight sockets, and it is no longer eligible for Standard Edition licenses.
But wait. There’s more. Remember — each chip in the multi-core module counts as a socket. That is what the OLSA says. But exactly how many chips are in this Multi-Core Module? We know there are two processor chips. But there could be other chips in there that we don’t know about (and Intel may not be talking about them either). I tried to find this information on Intel’s website, to my complete dissatisfaction. All I could find was a drawing (i.e., an “artistic rendering”) of what the quad-core Xeon chips look like when you take the top off. The drawing shows two processors dies, as expected, but it also shows nine other smaller “chips” that look like they may be RAM modules. (Makes sense; since we have an MCM anyway, we might as well stuff some extra L2 cache in there, right?)
But whatever the purpose of these “chips”, they are still “chips” — assuming they are actually there. And under the new licensing rules, they are counted as “occupied sockets”, just like all the other chips in the MCM. My hypothetical “cheap and powerful” Oracle database server now has not four “sockets”, but 44 sockets. Even if it was still eligible for Standard Edition licensing, the list price for Standard Edition on this server is now $660,000; a little more than twice the list price for Enterprise Edition on the same hardware.
And it gets even worse! “Multi-core” processors are not the only ones implemented with multi-chip-modules. Multi-chip-modules were considered “innovative” in the 1990s, as we see with this example. Once their advantages became known, it became a relatively common practice to deploy single-core processors (they were pretty much all still single-core back then) like the Pentium Pro and Pentium-II as a multi-chip-modules with a processor chip, an SRAM cache chip, and maybe a memory controller all bundled together in a single package. (This photo of the guts of a Pentium-II seems to show 23 distinct chips inside the module. This article describes a single-core SPARC CPU designed in 1994, packaged as an MCM containing six distinct chips.) There are lots of cost/performance advantages to building MCMs, so I expect that this must still be a common practice even today — such a common practice that it probably isn’t even discussed any more.
Do you know how many chips are in the CPU modules you are using today? Well, if you plan to buy new Standard Edition licenses, is seems that you now need to know!
This just can’t be right, can it? Somebody must have made a mistake. I hope it’s me!
Mistake or not, though, there is a clear moral to this story. You need to read the license agreement, even when you are only planning a purchase. Trust me — reading the license after the P.O.s have been cut will not make you look good in a situation like this. And not reading the license would be a major mistake indeed!
1. Chances are the last hyperlink will not work for you. You may have to go visit the Oracle online store, choose your country of preference, then find and click on the link labeled “License Definitions”.
2. Again, that hyperlink probably will not work for you; if you followed my earlier description to find Oracle’s “License Definitions (Abbreviated)”, you can get a copy of the current OLSA by clicking the hyperlink labeled “Oracle License & Services Agreement” on that page.
40 Comments. Leave new
I’m not entirely surprised by this move. I have previously discussed with customers how you can buy a two-node SE RAC cluster, each server having 2 quad-core CPUs, i.e. a total of 16 cores across the cluster… both powerful and resilient (and probably not what Oracle intended for SE).
By the new rules above, the AMD Opteron quad cores (Barcelona), which I think are one chip with four cores, will have a maximum of 4 CPU/16 cores for an SE licence. In other words SE can have a maximum of 2 Intel quad-cores (which are two dual cores back-to-back at the moment) but 4 if you choose AMD! That’s quite an advantage for AMD.
Hmmm… Actually, this article was released a little prematurely. I was planning to add a little bit of preamble about the ubiquitous nature of Multi-chip-modules, but my editors struck first and published.
Sadly, I think an important part of this message may have been lost…
We used to hear a lot of hype about multi-chip-modules — back in the 1990s. For the first few years they existed, they were cool and innovative, and therefore worthy of mention in marketing materials. You almost never hear about them now, but you could well be getting them anyway.
On occasion, somebody comes up with a new twist on MCMs — like IBM placing 4 full RS6000 CPUs in a single MCM the size of your hand. (See https://en.wikipedia.org/wiki/Multi-Chip_Module)
It may be MCMs like these that Oracle was responding to with the new license rules; some clever person having discovered that they can license Oracle Standard Edition One on a machine with two of these (like maybe an IBM P550Q) for a small fraction of the cost of the hardware. But I can only guess about that.
Anyway, there is a major point that I may not have explained very well. Look at the new license definition. Look at the photo of the large IBM MCM on the wikipedia page I mentioned. How many CPUs? How many sockets? Yikes!
Intel has been shipping (single core) processors as MCMs for years. From what I can see, they are commonly CPU + MMU + Cache. At least 3 chips in every MCM. And now, under the new rules for Standard Edition, they count as three *sockets*.
Is there a machine sold anywhere that is still eligible for SE-1 licensing? I don’t know.
[…] Standard Edition One (‘SE1)’ definities. En het lijkt erop dat, met uitzondering van een enkel oplettend individu, de wijziging bijna ongemerkt is ingevoerd. Wij hadden een oproer verwacht. Er is een namelijk een […]
hi guy’s,
I don’t think the trackback works correctly. However here it is:
https://www.licensingtruths.com/oracle-standard-edition-databases-to-become-obsolete
We have a new project where we were planning to use Oracle SE. This new multi-chip policy led us to check with our Oracle sales representatives. After several misfires, here is what we got back: “Multi-Chip modules (MCM) refers to implementations where multiple dies are packaged as a single unit.”
So I explained that the Intel Quad Core CPU is actually two dual-core dies in a single socket. I also explained that the Intel Xeon 7000 series ***DUAL CORE*** CPU is actually two seperate dies. Oracle confirmed that the Intel 5000 & 7000 quad core, as well as the Intel 7000 dual core are considered MCMs. This means that even some dual-core Intel processors count as two sockets for SE/SE1.
So you make the call. For the same license cost you can have a single Intel Xeon 7000 series dual core CPU or two AMD quad core CPUs. Wonder which configuration customers will choose?
When you compare Intel performance to AMD make sure you are considering the Oracle license costs!
Yes. This is exactly as I expected Darin. Well, not the specifics, of course.
In the past (like, about 1985 or 1990), MCMs were novel, even “state-of-the-art”, so you almost couldn’t buy a processor implemented as an MCM without knowing about it because the marketing hype was so intense.
Now, MCMs are commonplace, so chip manufacturers rarely mention it and when they do it receives little or no media attention. (Except for rare cases like Intel’s quad-core versus AMD’s quad core.) But even there, only be very best informed consumers know whether or not their CPU “chips” are really on one die or several, and almost none seem to know what that actually means.
Something that seems to have been lost in my original message, though, is that Oracle Corp has made an error in the wording of the license agreement! (If that message had not been lost, I would have expected a *riot* by now.) It is not just *processor* dies in an MCM that are being counted as “sockets”. It is *all* dies. Including memory, memory controllers, discrete logic, *anything*.
Even worse, as Intel (or others) start introducing new processor implmentations for existing product lines, they can retroactively change the eligibility of your (old!) hardware to run SE or SE-1 by altering your servers maximum “socket” count as defined in the OLSA.
You could purchase a server, license it (correctly) for SE, and then 6 months later discover that you are required to upgrade to EE simply because Intel has deployed a new processor design.
You’re right Mark. Very interesting point also about the *all dies*. Contractually you’re right, however I don’t think Oracle will (or can) enforce this. At least not in my jurisdiction.
My point is however that it seems impossible to license SE1 at all, or to implement SE including RAC:
1. SE1 can only be licensed on servers that have a maximum capacity of 2 sockets.
2. SE can only be licensed on servers that have a maximum capacity of 4 sockets.
3. If each chip in the mcm is to be counted as a socket:
a) ALL entry level servers from Dell/HP have 2 physical sockets.
b) ALL entry level servers are capable to be provided with QuadCore processors.
Conclusion SE1:
-SE1 cannot be sold to current hadware, as the minimum requirement of SE1 cannot be met. SE is the only option.
Conclusion SE:
-SE environments cannot include RAC anymore: Each RAC environment will size over 4 sockets (as 2 servers will be used, and the maximum capacity of sockets combined will always be greater than 4).
In general: Prices have tripled, or more. In our region (Europe) however it was never sold this way, even by Oracle. Oracle has not yet responded to the situation, yet more and more questions arise from customers and partners. So maybe (finally) the *riot* is at hand…and we’ll get some clarifications soon.
I totally agree that the original contract language is vague and ambiguous. If we were to interpret MCM to mean ANY chip then you are dead on that every single processor today has multiple chips.
So the good news, bad news of it. Good news is that in most states the courts will be prejudiced against the author of the contract in the case of contract language ambiguity. The bad news is that most of us wouldn’t want to go to court over it.
I still cannot believe that Oracle would take a position that is so slanted towards AMD. There is no way one dual core Intel Xeon 7000 series is roughly equivalent to two quad core AMD Opteron processors. Why should they be licensed as if they are? I wouldn’t be surprised to see this change in the near future.
DJ,
You are absolutely right! Yet another point that I was trying to express in my original post, and bungled badly, I think.
Actually, there are two aspects to this. First, as you point out, it is almost impossible to license SE-1 under these rules, at least on Intel processors. Second, the eligibility of a piece of hardware to run SE/SE-1 changes over time, as new processor packages are brought to market.
—————-
Darrin,
You are correct that most courts will rule against a litigant trying to take unfair advantage of “vague” contract language. At least, that is consistent with my understanding. Sadly, though, there is a word for people who rely on such things: “respondant”. (I.e., “the guy who is facing a lawsuit”.)
Here is a big part of the problem. I see *nothing* “ambiguous” about this language. It says (to paraphrase) “each chip shall be counted as a socket”. What could be less ambiguous than that?
Of course, that is where the lawyers come in. (And *I* am *not* a lawyer.) I am sure that one set of lawyers will argue that the term “chip” is perfectly clear, while another will argue that because the term is not defined in the contract it is meaningless.
Myself, I would (sadly) expect most judges to rule in favour of the set of lawyers with the best funding. In the case of a lawsuit between myself and Oracle Corp., I am pretty sure that I know which lawyers will be the better funded. Hint: they won’t be mine! :-)
There is, however, an *easy* way to defend yourself in this case. Just refuse to accept the licensing terms. To not purchase or deploy Oracle “Standard Edition” products until you can get Oracle Corp. to amend the license agreement to say (at the very least) “Each *processor* chip will be counted as a socket”.
Sadly, I doubt most customers (aside perhaps from a national government) would have enough “juice” to get Oracle to amend their licensing terms while negotiating a $6000 deal. But if several thousand customers were to raise their voices together, I am sure the change could be made.
Mark,
I am no lawyer either. But here is why I argue the language is ambiguous. A court would try to get to the intent. If you interpret the language literally, then every processor made today would count as more than one socket…. even single processor, single core chips! Clearly Oracle’s intent was allowing for two distinct possibilities in licensing as evidenced by the “…however, in the case of multi-chip modules…”
So Oracle could not reasonably argue that they added that exception language and the exception applies to every case unless they have some reasonable explanation of their (non-deceptive) intent to do so.
I am going to follow my sales representative’s advice on how to decide which chips are MCM chips, that way I have a written explanation if needed for a future audit of our environment.
Darin,
You could be right. All I am saying is that I am not prepared to bet hundreds of thousands of dollars of *my* money on the outcome of an argument like that, especially when it is carried out between the kind of lawyers I can afford versus the kind of lawyers Oracle can afford.
I too have recently had conversations with sales reps myself, where they said “obviously, what we really meant to say was…”. Even so, is seems that *nothing* is really obvious in a court of law, at least until a decision has been handed down and all available appeals have been exhausted (and a whole lot of money has been spent).
That aside, have you ever noticed the “Entire Agreement” clause of the OLSA? In a nutshell, what it says is that anything your sales rep says (or provides in writing) is completely irrelevant with respect to the license or your compliance with it.
Anyway, the whole thing is kind of silly. Oracle Corp. knows (or *should* know) exactly what they meant in the license agreement? So why didn’t they just say what they meant? Or, having realised that they did not say what they meant, why do they not just correct it? That would probably be best for everybody, I think.
As for me, I just don’t think I am ever likely to sign any contract with any large corporation under the assumption “I can probably beat them in court”. Happily, Oracle does not have a reputation for being litigious, but things like this can can always change…
Hey, a general comment…
Much earlier in the feedback here, Darrin Brown remarked:
“I still cannot believe that Oracle would take a position that is so slanted towards AMD.”
I find this to be a very interesting comment. While I have no real knowledge of Oracle’s actual motives for this licensing change, my *guess* is that it has nothing to do with either Intel or AMD.
My guess (and that’s all that it is) is that this has to do with customers — and probably just a small number at that — who discovered that they could run Oracle Standard Edition on some very large enterprise-class hardware.
Some vendors (e.g., IBM) have been manufacturing *very* large MCMs. They are not quite the size of a typical dinner plate — yet — but they are much larger than most MCMs. In these very large MCMs, they can place what amounts to most of an SMP computer system — multiple CPUs, memory controllers, IO controllers; really the sky is the limit, as the only factor limiting the size/complexity of an MCM is heat dissipation.
(Well, that’s the only factor that comes to mind right now.)
Is Oracle really trying to discriminate against one CPU manufacturer in favour of another? I doubt it. I think it is at least as likely that Oracle was just trying to establish a standard for what is or is not a “multi-core processor” (effectively trying to say: “a full-blown SMP in a dinner-plate sized MCM is *not* a multi-core processor”), and maybe in an effort to keep this as vendor neutral as possible got the language just a little bit wrong.
(I also wonder whether maybe the managers and lawyers responsible for this language perhaps did not fully understand exactly what an MCM is, nor how ubiquitous they really are.)
But then, perhaps I am wrong. I’m sure I will never know one way or the other.
Exactly that is the point Mark. I am pretty sure that the rule has been created for the IBM Power platform. In the Power playfield, ‘sockets’ don’t really exist in that area, only MCM (MultiCoreModules) and QCM’s (QuadCoreModule’s) that you plug on the board. As such they had to find a way to work with IBM Power. Oracle simply tried to make a price that meets the performance – which is fair enough – but missed the fact that an MCM is not Power-specific terminology.
If you take a Power 520 and crunch it up (4 processors, 64 GB of RAM) you could run half an enterprise on it and still outperform a dozen clustered blades. Will look forward to the verdict though…can’t really take much longer, the story stirred up enough dust as it is and nobody dares to order anything :-)
Anyway, my 5 cents
Oracle Licensing is an area I have specialized for quite a long time. As it has been stated the legal interpretation is a bit vague at the moment, but the common denominator seems to be that Oracle just wants to get a return on the amount of processing power. Unfortunately it seems to be spiraling out of control, for EE anyhow. With SE cores don’t come into the equation just MCM and the related ‘socket’ debacle, and since the number of ‘specific’ processor chip dyes seems to be doubling we will probably end up in a situation where Intel Processors are given a ‘break even’ factor but larger servers like Sun et al will be unable to run SE or SE1…….a major license restructure is due…..
I used to work for Oracle License Management Services.
No one can give me a straight answer on this from within Oracle. At the moment, most sales people don’t understand the finer points, and aren’t pushing it.
I agree with most of the comments here – this is about IBM and Sun, not Intel and AMD.
But as always with these issues, you have to stick to the letter of the definition (theirs, not yours!) and for the moment Intel Quads are a bit iffy. The company I now work for positions a lot of SE RAC, 2 x 2 quads, using Intel Quads. That means EE under a strict interpretation of the current rule.
By the way, you can only be audited on the basis of the contract that you signed – so they idea that they can retro-fit this or other SE definition to older purchases is not true. And if they try to do that, get out the definition that was in place when you signed the contract governing the licences that they are questioning.
Agreed. Oracle license audits can only be based on the terms of the contract you signed. (Although Oracle *has* retroactively relaxed the contract in the past, e.g., allowing SE RAC on 9i after it was permitted on 10g.) Oracle cannot “tighten” licensing conditions after the fact.
What *can* change retroactively is the eligibility of your *old* hardware to run the SE licences you bought *two* years ago.
Eligibility to run SE is determined by *maximum* socket *capacity*. That is determined not by what is *in* you machine, but rather by what you *can* put in it. And I see nothing in the license that limits this to what you “can put into the server at the time of purchase”.
If AMD and Intel suddenly start selling 16-core processors with 8 2-core chips in one MCM (that fit the sockets in your server), the “maximum capacity” of your old hardware changes , potentially years after you bought it.
Nothing in the license has changed — retroactively or otherwise. What has changed is the hardware. Well, the hardware you *could* be using, not the hardware you *are* using.
Of course, this is not the real point of the discussion, and it probably is something of a stretch. I really doubt that Oracle LMS would *ever* try to prosecute somebody on this basis, and the might even lose if they tried. (I, for one, am not going to bet against anyone who can afford to spend $1Billion on lawyers, though.)
I just thought this was an interesting (and maybe scary) side-effect of a new license condition that almost nobody seems to be aware of or to truly understand.
You are right about no one understanding it!
I have discussed it with ex-colleagues in LMS and all I get is silence. I even asked for it to be kicked up to Infoprice (who set pricing and licensing rules) only to be told that LMS were awaiting “clarification”. No clarification yet….
I’m advising people not to use intel quads for SE or SE1 for the moment. I personally think the “capable” thing is a bit of a stretch. However, there is nothing to stop and agressive sales person with knowledge of this grey area, a tough target and a economic recession looming, hitting this hard, and terrorising and confusing a customer into submission.
Any other MCM is pretty much ruled out as far as I’m concerend for SE.
A client puchased an Intel based server containing Quad’s. They asked Oracle LMS about the situation, and got confirmation that, to the best knowledge of the consultant, the processor does not contain any MCM’s. As a result, the client could work with SE versions.
Intel has confirmed that the processor contains MCM’s.
Again this underlines my earlier suspicion: The MCM wording was included for POWER processors, and they totally forgot that Intel also has MCM processors.
Interesting this is going to develop a scenario similar to the CD licensing of the 1990’s. If you are lucky enough to have one of those unrestricted MCM contracts and have 4 licenses you are free to buy the beefiest MCM server so long as it has 4 sockets….
“When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to a socket.”
This is a classic licensing blunder!
Sounds like a license management nightmare; although if you do it right you can save a boat load of money.
Doug Burns pointed out the above to me. I’ve been involved in much db licensing over the years, and this is, to my mind, an attempt to tighten up a vague license definition, and to not get it right (again). From what I can see, the rules around multi-core chips and further, aix capped and uncapped sub-capacity lpars are still vague.
I’ve had many conversations with Oracle over licensing nuances, and agree that the only safe course of action is to have someone at Oracle underwrite any interpretation you have. That way, it might end up still being incorrect, but at least you’ll have evidence that it was santioned by someone at the company.
I had several scenarios for deployment signed off by our Oracle account team before proceeding. It’s not perfect but I sleep slightly more soundly :-)
Tam,
Thanks for your feedback. AIX capped and uncapped LPARs, huh? I haven’t had the pleasure of researching that particular topic, although I did have a rather interesting time researching “partitioned” servers (including LPARs) a few years ago. What a (virtual) maze that was!
Your practice of having licensing “issues” clarified in writing is a good one. However, if you read your license agreement carefully, you are likely to find that it says that no statement or document uttered by any Oracle agent or employee alters the license agreement in any way, unless it is a formal amendment to the license signed by a duly authorized officer of Oracle Corporation.
Your sales rep, and even your region sales manager, almost certainly does not have the authority to amend your license agreement. So, while the documents they offer may allow you to sleep better at night, they are likely to have little bearing in the event of a “dispute”m except perhaps to demonstrate “good faith” on your part. (That good faith might be enough to help you avoid criminal charges and maybe even get you a modest discount on additional licenses.)
I suppose, though, that these written assuuurances might at least help you get your (former) sales team fired, but that will probably be cold comfort as you (or your boss’s boss) sign and hand over a multi-million dollar cheque.
Now, don’t get me wrong here. I don’t mean to portray Oracle Corp. as some sort of lurking predator waiting to lunge at customers who have unwittingly violated their (extremely complex) licenses. Some other companies in the software industry *do* have such reputations — often well deserved. In my experience, Oracle Corp is relatively benevolent in this regard, but I suspect that a major economic downturn could prompt almost anybody to re-think their business practices.
Mark,
I have checked OLSA and Online Store licensing today (July 2nd, 09) and it seems nothing has changed.
In addition, Oracle updated the “Oracle Processor Core Factor Table” on March 16th, 2009 to specifically noting AMD Third Generation Opterorn or earlier Multicore chips, Intel Xeon Series 74XX, 55XX series or earlier Multicore chips, Intel or AMD Desktop, Laptop/Notebook, Netbook Multicore chips (all these have a core processor licensing factor of 0.5 in this document), the list includes other non Intel/AMD chips as well, but at the end of the list it lists “All Other Multicore Chips” with 1.0 core processsor licensing factor.
Any update on your part ? Oracle Partner Network calls was not fruitful to get a “clear” answer (so far) :(
R/ Zafer
Zafer,
I only look into Oracle licensing occasionally, as the need arises. (I spend most of my time managing databases.)
Your update on the “Oracle Processor Core Factor Table” is definitely interesing — as you now need to know what “generation” of processors you have before you can tell whether you have licensed a server correctly — but it really applies only to Oracle Enterprise Edition, as the “standard” editions are still licensed by “socket” not by core, and these “multipliers” never applied to the standard editions.
I had been wondering what Oracle’s response to 6-core and 8-core processors from Intel was going to be. Perhaps we are seeing the first wave of that, but this is certainly not the response I would have expected.
Having not yet looked at the updated “Factor Table”, I am not quite sure where your confusion lies, but I do sympathize with your efforts to get answers. I have found this something of a challenge myself, on occasion.
Mark, I got confused when I read the following in the OLSA. Then started searching the internet, OPN, OTN, Metalink and found your posting.
“When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.”
given that I can not find a definition of MCM in OLSA or anywhere on official Oracle homepages, I am planning to call OPN again to discuss how it is defined, where it is defined and how to determine if a AMD or Intel chip is considered MCM or not. I checked the AMD homepage for the 4th generation Barcelona CPU but it was not clear to me if it is considered as MCM or not. And how about the Intel Xeon chips ? are they considered as MCM ?
That “however, …” clause in the OLSA bothers me. How to interpret it – that is where I am confused. Because, Oracle recently updated their OLSA to include (as reference) the new Oracle Processor Core Factor Table.
Regards
Zafer
I think the recent tpc-C benchmark (https://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=109052101) using Oracle SE1 (https://www.oracle.com/solutions/performance_scalability/database-se1-tpc.html) helps to clarify that indeed “socket” = “physical CPU” and that should apply to SE as well.
If you look at the full disclosure agreement, it states 1 Quad-core Xeon E5520 (recent Intel Nehalem class) and the cost of SE1 is US$5800, exactly the per-processor cost stated in the Oracle store. If it were cores instead of sockets, using the core factor of 0.5 as is done with EE would have given the SE1 cost as 2 x US$5800 – so if Oracle would treat processor as socket for MCMs Intel/AMD chips, that would make the benchmark invalid!
Sorry, submitted that post too soon.
It was US$2900 for a 3-year 1 processor term license (I was looking at the FD for the older benchmark that used Windows). Still, it’s clear that socket = physical processor for SE1 and it also follows for SE
Raffy,
I am afraid you are only half-right.
Yes, Oracle “Standard Edition” products are licensed “per socket”, not “per core”. In this statement you are correct, but then, I have never said anything contradictory to this.
The thing that is at issue in this blog is the definition of “socket”, and here you seem to have completely missed the point.
Specifically, not only is it NOT clear that “socket = physical processor” as you state, it is not even the case that “socket = physical socket”. (READ the OLSA — you will see.)
In the terms laid out in the OLSA, a “socket” is a logical “idea”, not a “physical entity”.
In order to correctly determine the “socket count” for a database server built on Intel “Quad-core Xeon E5520” processors, you first need to know how many silicon chips are packaged inside that little piece of black goo that you refer to as a “processor”. Under the definitions provided in the OLSA, EACH such chip is deemed to be a “socket” for the purposes of licencing, pricing, and even eligibility to run Standard Edition products.
Is the benchmark you cited invalid? It could be. I don’t know. I don’t know because I also don’t know how may pieces of silicon are inside an “Intel Quad-core Xeon E5520” package, and chances are the only way I can really find out is to purchase one and cut it open.
And THAT is the real point to this blog post. :-)
I found this pdf published by HP: https://h40089.www4.hp.com/integrity/pdf/pricingsept08.pdf
They explain that MCM refers to IBM chips, this is the quote:
“This licensing policy had created a particular issue with
respect to IBM’s Q series servers. IBM has promoted
that its 560q and 550q could be licensed for SE and
SE1, respectively, which would have given them an
impressive price:performance. IBM has a daughterboard
approach that allows them to fit 2 Power 5
processors into a single socket. However, Oracle, in
late 2007, added this statement to their price list:
“When licensing Oracle programs with Standard
Edition One or Standard Edition in the product name,
a processor is counted equivalent to an occupied socket;
however, in the case of multi-chip modules, each chip in
the multi-chip module is counted as one occupied
socket.” This undermines IBM’s statements and should
be used to refute IBM’s claims if encountered in a sales
situation.”
This was already mentioned in some other comment and it sounds like it would make sense.
just had a teleconference with the OPN folks on the OLSA / MCM issue for Standard Edition One and Standard Edition licensing. What I was told is that the key factors in licensing for SE1 or SE are:
1. the number of “occupied” sockets on the physical machine
2. the number of “cpu” s in the occupied socket.
I asked them about the Xeon or Opteron cpu’s to be very specific for SE1 and SE licensing and I was told that the core count table does not apply to SE1 and SE licensing. It is the “number of cpu’s in the occupied socket”.
So, here some examples we spoke: a Dell or HP box with 1 socket hosting an opteron or xeon quad core CPU for SE1 – no problem – single CPU license applies. If it is a 2 socket box, but only 1 socket is occupied (quad core opteron/xeon) – single cpu license for SE1 applies. If both sockets on the machine is occupied (quad core opteron/xeon) – 2 cpu license for SE1 applies. If the machine has 4 sockets but only 2 sockets are occupied – SE1 license can be used instead of SE.
note: they mentioned that this issue was discussed internally and they have been receiving many calls from partners on this issue.
I can install Standard ONE (11g SE1 for Linux) on a 2 quad-core opteron box :)
hope this will be useful to other folks.
R/ Zaf
Zafer,
Sadly, the information you were given is not completely accurate.
Oracle Stanard Edition products are indeed licensed by SOCKET, not by CORE. This fact has been consistently stated throughout my writing.
But in the OLSA, the terms “socket”, and “physical socket”, are NOT interchangeable, and must not be confused.
Yes, you can indeed license Oracle Standard Edition ONE for a server with 2 @ quad-core Opteron processors (providing that is the maximum capacity of the server), as AMD Opteron processors are NOT (to the best of my knowledge) implemented as MULTI-CHIP-MODULES.
You MAY NOT, however, license Oracle Standard Edition ONE on a similar server with Intel Quad-core Xeon processors, as (many) Quad-Core Xeon processors ARE implemented as multi-chip-modules, and EACH such processor actually counts as (at least) TWO “sockets”.
By the way, the last time I read the OLSA, the statement “If the machine has 4 sockets but only 2 sockets are occupied – SE1 license can be used instead of SE” is entirely FALSE.
Let me repeat that: THAT STATEMENT IS FALSE.
Oracle Standard Edition ONE cannot be licensed on a server with more than 2 physical sockets, regardless of how many sockets are left unoccupied.
The eligibility to of a given server to run SE or SE-1 is determined by its MAXIMUM capacity, not by its CONFIGURED capacity.
At least, that is how it was the LAST time I read the license, and I have never heard of this particular rule changing.
I am guessing the final authority on the MCM issue is the Oracle Sales. I specifically asked the OPN folks (recently) if the Quad-Core Xeon and if it is considered as MCM or not, and the answer that was given to me by the OPN rep (he joined to the telecon from India) that it is not MCM. I told them exactly what you mentioned here and provided this page as reference. So, I would suggest to talk to your Oracle sales rep and ensure that the CPU type in your server (if you are purchasing one for hosting the db server) is not considered as MCM. Even after the recent telecon with OPN, I am more confused. Besides, they told me that it is the occupied socket count – I asked them again based on what you mentioned above. He said in the case of 2 sockets, 1 AMD quad core processor occupies 1 socket, second socket is empty – it is counted as 1 CPU for SE1 licensing (I asked if the second can be empty – and he said yes – can be empty and we don’t have to pay – because it is the “occupied socket count”). It boils down to the OLSA and the Oracle sales rep of your account (because they are going to have the final say on how the OLSA will be interpreted).
R/ Zaf
Sadly Zafer, your Oracle Sales Rep is ABSOLUTELY NOT authoritative in these matters. The “Entire Agreement” clause of the OLSA (or just about any other contract or license you will ever see) specifically nullifies absolutely *anything* your sales rep might say or write.
The only “authority” here is the license agreement itself (which does not define “MCM”) and — ultimately — the judge who will eventually rule in Oracle’s lawsuit against you (or the judge ruling on the appeal in the unlikely event that Oracle loses the first time.)
Let’s be completely clear here: Oracle sales reps do NOT have a say in how your license will be interpreted. That is done by Oracle “License Management Service” (I think I have the right name there) and ultimately by the courts.
If your sales rep promises you that your multi-die Intel (or other) processor is not an “MCM”, just follow up with this:
“The, of course, you will be happy to have an Oracle Vice President provide me a signed amendment to the OLSA to that effect.”
Don’t hold your breath waiting for that amendment, though. And without it, the “word” of your sales rep (or any other Oracle employee) is worthless.
Finally, while it is true that you do not need to purchase licenses for unoccupied sockets, the unoccupied sockets *do* affect the eligibility of your hardware to be licensed for SE ot SE-1.
In the meantime, it is the definition of the word “socket” that is the crux of the matter here. A “socket” is no longer a physical piece of metal and ceramic on a circuit board — it is now a “logical” construct defined (vaguely) by the license agreement.
The bottom line here is this: If you are concerned about complying with your license, hire a lawyer before you make a purchase. And for heaven’s sake, don’t rely on your Oracle Sales Rep — nor on me — to interpret your license for you! Hire a lawyer. Your own lawyer.
In this case, be sure to get a lawyer who understands the meanings of the words “chip”, “wafer”, “die”, and “carrier” and the subtle distinctions between them.
And one last time, DO NOT RELY ON ME. I am not a lawyer, and even if I were, I am not YOUR lawyer.
Thank you for the information Mark.
Please refer to the following URL on OTN if you have a chance. Especially look what Hans Forbrich wrote (contradicts to what you are saying when it comes to OLSA vs Oracle Sales). BTW, I never said that SE1 is qualified to run on a 4 “pysical” socket box when only 1 socket is occupied. And we have our own lawyers ;) but thanx for pointing that out.
Here is the related URL:
—————————-
https://forums.oracle.com/forums/thread.jspa?threadID=923590
The following is from the same OTN posting (provided by MrFaize)
—————————————–
Some much conflicting information around. Here’s some more to add fuel to the fire:
A 2x quad core (eight cores) HP Server running SE1
https://tpc.org/tpcc/results/tpcc_result_detail.asp?id=109033001
and this HP sales PDF (dated Sept 2009) offering configs with 2x quad core running SE1 (see page 3 of link)
https://h20195.www2.hp.com/v2/GetPDF.aspx/4AA2-9228ENW.pdf
————————–
Anyway, thank you again
R/ Zaf
Zafer,
Hans Forbrich does not appear to contradict me in any way. Nor I him.
Hans simply points out that people in the sales organization can initiate the formal process needed to produce a formal (written and signed) amendment to the OLSA.
I simply point out that in the absence of such a written amendment (signed by a duly authorized officer of Oracle Corp.) nothing your Oracle sales rep tells you is enforceable in any way.
Your Oracle sales rep (unless he/she is a VP or better) does not have the authority to execute these agreements.
I see no conflict.
Anyway, your license agreements are your business, not mine. Conduct your affairs any way you (and your lawyers) see fit.
Cheers!
Thank you Mark.
I appreciate for your input after reviewing that posting on OTN.
I realized that Oracle removed the “socket” term from their OLSA – at least for the international customers – and now uses the term “processor” (again). I checked the following link (https://www.oracle.com/corporate/license/agreements.html) and read multiple OLSA’s and related definition docs for different countries (UK, Israel, Greece, Turkey, Ireland). That page did not list the OLSA for USA (therefore, I can’t tell if it is different or not).
note: the Oracle processor core factor table (www.oracle.com/corporate/contracts/library/processor-core-factor-table.pd) was updated as of 04/08/2010 and lists the core counts for specific CPU’s, therefore making life easier to determine which CPU types are considered as MCM or not – but if Oracle changed their OLSA again from socket to processor (at least for the international customers) – that creates another confusion ?
Thank you for your valuable inputs. It helps when I present the issues to others (including the Oracle Sales, OPN and our legal counsel).
R/ Zaf
How can you tell from the table which processors are considered MCM?
Ariel,
I really can’t see how you possibly can determine that from this table. Furthermore, the “Processor Core Factor Table” is really relevant only to Oracle Enterprise Edition.
Here, we are discussing Standard Edition, where it is not “cores”, but “sockets” that matter.
Perhaps Zafer can explain what he means. For myself, I see nothing in the “Processor Core Factor Table” that would be relevant in any way to a dispute over licensing for Oracle Standard Edition.
the correct url to the core count pdf document is:
http://www.oracle.com/corporate/contracts/library/processor-core-factor-table.pdf
Zafer,
You raise a very worthwhile point here.
The blog-post we are discussing here relates to an edition of the OLSA that is nearly two years old. The OLSA has doubtlessly been updated many times since this was originally posted.
In addition, OLSAs do vary from region to region.
When considering license compliance, you need to be certain you are looking at the correct version of the license for the appropriate region.
When purchasing Oracle products, it is probably also a good idea to print and keep on file the OLSA that was in affect at the time of your purchase, as I have yet to see “historical” versions of the OLSA available on the internet.
But then, the purpose of this blog was never really to “advise” people on licensing issues, but rather to point out what was — at the time — a new and interesting feature in the OLSA.
Hi,
i am using SE1 version, and i want to know which dba views i should not use. Please help me on that.