Re: Why does Oracle Agrees to the One proc pricing model on IFL?
We're not disagreeing. I forgot to mention machine-specific versus transferable licensing (thinking of Microsoft), licensing which can be support-entitled versus not (ditto), "site" licensing, and "enterprise" licensing. The software vendor gets to decide its licensing metrics and pricing terms in the first instance, yes, but customers get to decide whether they want to license or not (and how much, and under what terms and conditions). Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why does Oracle Agrees to the One proc pricing model on IFL?
W dniu 2013-03-13 08:11, Timothy Sipples pisze:
I don't speak for either Oracle or for IBM in an official capacity, but
I'll take an educated guess: history.
[...]
("Servers" and "processors" were the same thing for many years
[...]
Good explanation, but there are minor inconsistencies.
1. There were different prices for different CPU families (one price for
Intel aka PC server, another for RISC machines).
2. There are other pricing methods like per user, per terabyte, but such
methods are not always applicable for given software products.
3. Terms and conditions are a changing. There is nothing magic which
refrain Oracle (or other company) from changing their rules. Some
long-term contracts maybe, but not new ones. BTW: many moons ago Oracle
did the trick and many customers lost their discounts for upgrade fees
(a product costs X, upgrade cost fraction of X) - due to repackage the
features.
IMHO the answer for Oracle is: Because they WANT to keep the pricing
model as it is. And we don't know how long the will.
QAnswer for other vendors is: IT DEPENDS. There are pricing models, i.e
"per server" where mainframe is significantly more expensive than PC
server. And its not necessarily tied to mainframe capacity.
Mu €0.02
--
Radoslaw Skorupka
Lodz, Poland
--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why does Oracle Agrees to the One proc pricing model on IFL?
I don't speak for either Oracle or for IBM in an official capacity, but
I'll take an educated guess: history. Most of Oracle's corporate history
and technical practice involved customers deploying its software to
discrete servers as individual workloads: one or maybe a pair of servers
per application with widely varying but generally small numbers of users
per application. You've got to license your commercial software somehow,
and those systems don't have SMF or anything remotely like it (even if you
wanted to force customers to buy and to install something), so they picked
servers and processors as the quantity basis for their licensing.
("Servers" and "processors" were the same thing for many years in that
world, generally speaking.) What other options did they have? Then they've
refined that licensing a bit over time. They introduced "core multipliers"
some years ago, for example. Everything is install-based rather than
execution-based because, again, what other choice was there?
IBM mainframes were never like that (in the vast majority of cases).
They've "always" been shared computing resources supporting multiple
applications across multiple constituencies, at first sequentially then
concurrently. The number of processors (cores) was never a particularly
good or sufficiently granular measurement of capacity and value, especially
across model generations, so IBM figured out something else that made at
least adequate sense, with refinements and improvements since. Detailed
system accounting data are available and work, so there are simply more
license metric possibilities.
However, the trend has been for non-mainframe software to get more pricey
and more complex to license. There are now term licenses, restricted use
licenses, tiered editions ("standard," "professional," "advanced
professional," etc.), in-application feature licensing, advertising removal
licensing, limitations and licenses per virtual image, concurrent/floating
user licenses, registered/authorized user licenses, doubly required
server/core and user licenses, role-based licenses, device licenses,
terabyte-based licenses, network port-based licenses, various "cloud"
licensing metrics (e.g. CPU-hours!), point-scored license calculations and
curves for all of the above, prior version restrictions and rights,
documentation and media fees, authorized support personnel fees, etc., etc.
Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Why does Oracle Agrees to the One proc pricing model on IFL?
True question. What interest has Oracle and many other vendors in a pricing model that involve the number of procs used instead on cpu size? The regular pricing model used for mainframes for years is based on measures of the proc size in Mips/MSUs. The vendors are losing licenses (revenue) currently running on Intel or Unix proprietary procs to IBM's z/Linux initiative. IBM states that using IFLs, customers "Consolidate 3x or more* servers per core than virtualized x86 offerings". at same time, as IFL goes neer 100% utilization while other servers uses only about 20% of resources, I can understand why customers goes z/Linux. Oracle on z?Linux is Enterprise Edition, but yet, it is much cheaper if you have ten or so servers. so, why strong vendrs like Orcale agrees to this pricng model? ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
