"We don't have a position with respect to dual-core processors. A core is equal to a CPU, and all cores are required to be licensed. Therefore, if you have a dual-core processor, you are required to have two processor licenses." -- Oracle, 2005
"At the fourth Open Source Performant Database conference in San Jose, 2007's star start-up MetaPeta announced that more than 250 Fortune 500 companies – and nine of the top ten – were now clients. "We are delighted with the rapid acceptance of our product and services," said Jason Mitchell, the 29 year old chief executive of MetaPeta. "The figures speak for themselves". He celebrated the announcement during his keynote speech by having his four year old son Tux double the performance of an MPGrid XV system through plugging in five more PlayStation 4 consoles. "He can pay for the software licences out of his pocket money", Michell told the crowd, "and still have change for a Larry Ellison inaction figure."" -- ZDNet newsfeed, 2010.
It's not likely that General Electric or Texaco will be running their businesses on games consoles any time soon, but it is absolutely guaranteed that the next five years will see servers make a complete transition to multicore processors. Nothing will stop this, because it's now the only practical way to make faster chips.
It is also true that the most economic and effective way to make multicore chips will be to go as massively multicore as the basic technologies allow. While Intel and AMD are gingerly feeling their way into that world with their existing designs, IBM has taken the opportunity of a clean slate to introduce the Cell chip with nine cores and promised performance in the stratosphere. It's going into games consoles, it has to be cheap. The bang per buck will be astonishing.
Which brings us back to Oracle's problem. If it insists on sticking to its arbitrary per-core licence -- why not license per GHz, or by amount of storage attached? -- then it will become not just the major expense in a database, but overwhelmingly, massively so. Even a relatively low-power database program will give Oracle a run for its money if it can run in five hundred processor cores for the same price as Oracle running in thirty two. Needless to say, open source has the ideal licensing regime for multicore: fudging the TCO figures to say otherwise will prove a challenge to the most inventive marketing team.
Oracle's current strategy will be disastrous. If the company insists on sticking to it, then we can only hope the death throes won't slow down the rest of the industry for too long.
Talkback
Its a very childish argument Oracle has put. This dispute can be resolved in a very simpl way i.e. If the PID Processor ID will remain same through all cores then we should call it one CPU single/undividable. since cores cannot be removed/added in CPU, therefore one cannot borow someone's CPU core for a while hence opening a concern of missuse or cores working on different Motherboards etc.
multi proc, multi core, same issues, less real estate, what I have a problem with is their
pricing per cpu. just another reason to push
us to an alternate solution.
"why not license per GHz, or by amount of storage attached?"
Yes, the old per CPU model doesn't work for multi-core, but don't forget that Oracle did try the per GHz route (remember the "universal power unit "). That flew like a brick in a glass house. But, pricing based on the amount of storage is equally foolish (very large databases (VLDB), data wherehouses (DW), and GIS sites be damned).
The real question to ask (and what to base a price on), is how much work is accomplished? To this date most software licenses (including Oracle’s current ones) are based on peak load (or in many cases) best guess of what may be needed. Most of that license cost is wasted in lost CPU cycles (you can’t bottle them for later).
Many laugh at Sun's "$1 per CPU per hour" scheme, but with the logging Oracle 10g does on what is actually happening in the database, that is a much more reasonable way to charge for a product. You charge by what get accomplished, not by what could be accomplished. Of course most software houses want to get paid up-front, not in the rears (on demand). This will need to change to make this work, and I see no other option as we move forward with the grid architectures Oracle itself is pushing (every five words).
Now defining that CPU has been the tricky part, but for Oracle it’s cake. Instead of GHz or MIPS or any other meaningless benchmarks of speed, base it on X number of IO’s per hour. Maybe just charge a low entry fee (basic support with people you can understand (hint) and updates), and then just charge for work (insert / update / delete) IO’s. That gets those VLDB’s. DW’s, and GIS sites into the clear – and helps encourage efficient SQL coding at the same time.
Example: One single core CPU working for one hour (60 minutes) at 100% doing X work I/O’s = $1. Ten 2 core CPUs working for (60/20) 3 minutes = $1. You choose how fast you need the results, and decide when to upgrade (or use “grid”) hardware. The customer wins - and everyone is treated fairly.
If Oracle insists on doing the swan dive, sell off JDE World first because it will float on its own.
Oracle is primarily a sales organisation, it's product set/s still are licensed to support maximum profit potential.
History will tell, that when overwhelming technical developments they will quietly fall into line BUT not before they have made more bucks!!!