Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 2488 invoked from network); 6 Jun 2008 23:15:40 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by air964.startdedicated.com with SMTP; 6 Jun 2008 23:15:40 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A6E2985AC0E; Sat, 7 Jun 2008 00:15:39 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28352-06; Sat, 7 Jun 2008 00:15:39 -0400 (EDT) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2078B85A816; Sat, 7 Jun 2008 00:15:39 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Sat, 07 Jun 2008 00:13:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 0619085A5DC for ; Sat, 7 Jun 2008 00:13:25 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28076-09 for ; Sat, 7 Jun 2008 00:13:24 -0400 (EDT) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.158]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9889E85A561 for ; Sat, 7 Jun 2008 00:13:23 -0400 (EDT) Received: by yw-out-1718.google.com with SMTP id 5so724662ywm.46 for ; Fri, 06 Jun 2008 21:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=QpwLoIZjwMiHpTDeicEmQ69MRp7W4o4S+wNSaeFMKzI=; b=XV3gonqu+yseih87NjJPabRvOBYhYvhLFuP3XK/9D/e9P7ECjYdYGXaY0eKAL0aR0f HecfcpM3pYUq590C+GMOuDGfhZCL9jG2GhH/GZfhOa9XKtQgXIzzpQQ3Tl3xOq5xEQ3y 1p3WF2CZZNX4ZXp0udiYP8tGOPXOHm/iY5rJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=uvPoTOzOJ5a/OaACBvAbYht9EfI2hav8SZ7+GCbjb5jFRqgUsLdgGrp/35YO96HcWx CkKxtmlxiSn/cNzAiz9xrxIFenEjWb7lOipY9+04huimB6y/GHhtvPYSSuPD+y6zTrYO +I5SN3w67CX5iXXUqcKXBIihgIhlNnEgtmp7E= Received: by 10.150.49.2 with SMTP id w2mr1533017ybw.27.1212812003876; Fri, 06 Jun 2008 21:13:23 -0700 (PDT) Received: by 10.150.181.3 with HTTP; Fri, 6 Jun 2008 21:13:23 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 22:13:23 -0600 From: "Mark Brinsmead" To: "Jason Heinrich" Subject: Re: Restricting Oracle to one processor Cc: wjwagman@ucdavis.edu, oracle-l@freelists.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6831_24607123.1212812003880" References: <04DDF147ED3A0D42B48A48A18D574C450BEDA029@NT15.oneneck.corp> X-archive-position: 8677 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: pythianbrinsmead@gmail.com Precedence: normal Reply-to: pythianbrinsmead@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: Debian amavisd-new at localhost.localdomain ------=_Part_6831_24607123.1212812003880 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Jason, The text you cited is exactly correct. And here is the part that makes SE-1 (or any SE product) ineligible for wide ranges of hardware: [Standard Edition] 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*. Why is that? Well, many -- probably *most *-- processors today are implemented as "Multi-chip-Modules". In most cases, a Multi-Chip-Module contains *one* CPU chip, one Memory Controller, and one or more memory chips. A single-core processor manufactured by Intel (or, indeed, by anybody else) could be shipped as an MCM containing a dozen chips or more. *And each and every chip now counts as an "occupied socket" (and therefore, a CPU) for purposes of SE licensing.* Is this what Oracle *meant*? I very much doubt it. But this *is what the license says*. Even if you interpret this rule the way Oracle corp probably *intended* it, a server with 2 quad-core *intel* processors (they have 2 CPU chips each right now) is ineligible for SE-1 licensing because it exceeds the *maximum capacity *for SE-1 (namely, not more than 2 "sockets"). The rules (even as "probably intended") apply differently to quad-core AMD processors, though. Or SPARC processors. Or POWER processors, or... To license Standard Edition correctly, you now need to know details of CPU implementation that are not at all easy to locate, and your server's * eligibility* to run SE products can change over time as manufacturers introduce new (compatible) processor designs with differing numbers of chips. (E.g., if AMD introduced next year quad-core processors implemented with 2 @ dual-core chips, the server you licensed today for SE may no longer be eligible, because its *maximum capacity* has increased!) Not being a lawyer, though, I have no idea whether Oracle would get away with trying to enforce *that* though... You purchase SE licenses today at your own peril. How many chips are in *your* processors? How would you know? (MCMs are so common-place now, nobody really discusses them anymore. Personally, I cannot imagine Oracle corp being foolish enough to enforce this rule exactly as written, but I think potential purchasers would be equally foolish to *accept* this licensing condition as written. On Fri, Jun 6, 2008 at 9:44 AM, Jason Heinrich wrote: > Here's the exact wording on multi-core licensing from Oracle's most recent > price list ( > http://www.oracle.com/corporate/pricing/technology-price-list.pdf): > > [Enterprise Edition] For the purposes of counting the number of processors > which require licensing for AMD and Intel multicore chips, "n" cores shall > be determined by multiplying the total number of cores by a core processor > licensing factor of .50. > ... > [Standard Edition] 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. > > I don't see anything there that would prevent SE1 from being used on his > Intel hardware. A multi-core processor is still just one chip, so my > understanding of the "multi-chip module" wording would be something like a > daughtercard with multiple processors on it. One motherboard socket, but > multiple physical CPUs. However, if you were going to purchase SE or SE1 > licenses, I would definitely ask a licensing expert to be sure. > > On Thu, Jun 5, 2008 at 7:16 PM, Mark Brinsmead > wrote: > >> The OP did not say anything about database editions. Bill, you might also >> want to be aware that with the new license rules regarding >> Multi-Chip-Modules, the hardware you described will not be (cannot be) >> eligible for Standard-Edition One licenses if your quad-core processors are >> manufactured by Intel. (Actually, because Oracle seems to have accidentally >> mis-worded the new license rules, the hardware may be ineligible for SE of >> any flavour with CPUs from any manufacturer.) > > > -- > Jason Heinrich -- Cheers, -- Mark Brinsmead Senior DBA, The Pythian Group http://www.pythian.com/blogs ------=_Part_6831_24607123.1212812003880 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Jason,

   The text you cited is exactly correct.  And here is the part that makes SE-1 (or any SE product) ineligible for wide ranges of hardware:

[Standard Edition] 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.

   Why is that?  Well, many -- probably most -- processors today are implemented as "Multi-chip-Modules".  In most cases, a Multi-Chip-Module contains one CPU chip, one Memory Controller, and one or more memory chips.  A single-core processor manufactured by Intel (or, indeed, by anybody else) could be shipped as an MCM containing a dozen chips or more.  And each and every chip now counts as an "occupied socket" (and therefore, a CPU) for purposes of SE licensing.

   Is this what Oracle meant?  I very much doubt it.  But this is what the license says.  Even if you interpret this rule the way Oracle corp probably intended it, a server with 2 quad-core intel processors (they have 2 CPU chips each right now) is ineligible for SE-1 licensing because it exceeds the maximum capacity for SE-1 (namely, not more than 2 "sockets").  The rules (even as "probably intended") apply differently to quad-core AMD processors, though.  Or SPARC processors. Or POWER processors, or...

   To license Standard Edition correctly, you now need to know details of CPU implementation that are not at all easy to locate, and your server's eligibility to run SE products can change over time as manufacturers introduce new (compatible) processor designs with differing numbers of chips.  (E.g., if AMD introduced next year quad-core processors implemented with 2 @ dual-core chips, the server you licensed today for SE may no longer be eligible, because its maximum capacity has increased!)  Not being a lawyer, though, I have no idea whether Oracle would get away with trying to enforce that though...

   You purchase SE licenses today at your own peril.  How many chips are in your processors?  How would you know?  (MCMs are so common-place now, nobody really discusses them anymore.  Personally, I cannot imagine Oracle corp being foolish enough to enforce this rule exactly as written, but I think potential purchasers would be equally foolish to accept this licensing condition as written.


On Fri, Jun 6, 2008 at 9:44 AM, Jason Heinrich <jheinrich@heinrichfamily.com> wrote:
Here's the exact wording on multi-core licensing from Oracle's most recent price list (http://www.oracle.com/corporate/pricing/technology-price-list.pdf):

[Enterprise Edition] For the purposes of counting the number of processors which require licensing for AMD and Intel multicore chips, "n" cores shall be determined by multiplying the total number of cores by a core processor licensing factor of .50.
...
[Standard Edition] 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.

I don't see anything there that would prevent SE1 from being used on his Intel hardware.  A multi-core processor is still just one chip, so my understanding of the "multi-chip module" wording would be something like a daughtercard with multiple processors on it.  One motherboard socket, but multiple physical CPUs.  However, if you were going to purchase SE or SE1 licenses, I would definitely ask a licensing expert to be sure.


On Thu, Jun 5, 2008 at 7:16 PM, Mark Brinsmead <pythianbrinsmead@gmail.com> wrote:
The OP did not say anything about database editions.  Bill, you might also want to be aware that with the new license rules regarding Multi-Chip-Modules, the hardware you described will not be (cannot be) eligible for Standard-Edition One licenses if your quad-core processors are manufactured by Intel.  (Actually, because Oracle seems to have accidentally mis-worded the new license rules, the hardware may be ineligible for SE of any flavour with CPUs from any manufacturer.)

--
Jason Heinrich



--
Cheers,
-- Mark Brinsmead
Senior DBA,
The Pythian Group
http://www.pythian.com/blogs ------=_Part_6831_24607123.1212812003880-- -- http://www.freelists.org/webpage/oracle-l