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.

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.

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.

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

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.

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…

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.

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.

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.