Jeff Stonacek, Principal Architect

Currently, the most common licensing metrics for purchases of core technology products are the following:

• Processor – Per-core licensing based on a platform dependent core factor
• Named User Plus (NUP) – Based on the number of named users, with a minimum number of licenses per processor

In the past Oracle has used other metrics. In the late 1990’s, Oracle decided to license servers based on the compute performance of the hardware. The basic metric used in this licensing model was labeled the Universal Power Unit (UPU). We described UPUs in more detail in this House of Brick blog.

UPUs were calculated by multiplying the number of cores in the server by the clock speed of the processor (in MHz) all multiplied by a platform factor. The platform factor for Intel x86 processors is 1.0, whereas the platform factor for RISC based processors is 1.5. For example, a two-core Intel x86 server running at 800 MHz required 2400 UPUs for licensing. The obvious problem with this model is that processor speed doubles roughly every few years (Moore’s law). So over time, as processor speeds and core counts increase, these licenses become useless. The UPU licensing model only lasted a couple of years before Oracle abandoned this model for the current Processor and NUP licenses.

However, we occasionally run into clients who have these UPU based licensing artifacts hanging around on their support contracts. The Oracle contract can make de-supporting unused licenses prohibitive in some cases, and if these licenses cannot be dropped from support, then annual payments continue to be made for them.

Named User Single/Multi Server

During the timeframe when the UPU licensing model was in play, there were two named user metrics available, Named User Single Server (NUSS) and Named User Multi Server (NUMS). As the name implies, the NUSS licenses were for a single, named user who was able to access one physical server. NUMS allowed a named user to access multiple servers. On the surface, these licenses seem handy to keep on the books. However, as with the current NUP licenses, the NUSS and NUMS licenses have minimums associated with them, and these minimums are what make the NUSS and NUMS licenses untenable. The minimum associated with these licenses is 30 UPUs per named user license. For example, 100 NUSS licenses are limited to the following server configuration:

100 NUSS/NUMS * 30 UPUs per license = 3,000 UPUs for Intel x86 servers (remember the platform factor)

These licenses would be in compliance on an Intel server that is running at 3 GHz in aggregate across all cores. But using these NUSS/NUMS licenses on a server with any more processing power will put you out of compliance from a UPU minimum standpoint.

• One core at 3.0 GHz
• Two cores at 1.5 GHz
• And so on…

This example shows how useless these licenses have become with modern hardware.

Example Documentation
It is not easy to find public facing examples or documentation for these antiquated licenses. The following example is a contract between the state of West Virginia and Oracle Corporation. Since this is a contract from a state government, it is public facing.

The contract is dated 3/6/2001 and contains the licensing definitions, including the full definitions of all of the metrics. It also includes the Oracle technologies price list from that time period. The definition for Named User Single/Multi Server can be found on page four:

Page seven lists the licensing minimums for the named user metrics:

This lines up with the minimums listed in the attached price list.

Summary

These old, deprecated licenses are problematic several different reasons:

• Licensing based on server horsepower quickly becomes unusable with faster hardware
• Minimums can make the named user metrics completely unusable
• Oracle is not contractually bound to convert the licenses to a usable metric for their customers
• Support payments can be up to six times higher than those for equivalent new licenses

The best option for these old licenses is to simply stop paying support on them, if possible. However, this action needs to be reviewed by a qualified license consultant to determine if it is even contractually possible. As these licenses are unusable, this option makes the most sense. If extra licenses are needed, the support savings can be used to purchase new licenses.

Option two would be to request a license metric upgrade from Oracle. If Oracle grants an upgrade from NUSS/NUMS to NUP, then the licenses can be more easily used with modern hardware. Of course, if Oracle grants the license migration, then the licenses will be issued on a new ordering document. At that point, support on the converted licenses can be dropped, as they will be on a separate order.

Options are really limited for these licenses, as using them rarely makes financial sense and may even put you out of compliance.