The Licensing Of Oracle Technology Products – Compliance, Metrics, Licensing Restrictions

Released October 2012, Updated June 2013 | by Tim Sommer

Cover - OMTCO - The Licensing Of Oracle Technology Products - Compliance, Metrics, Licensing Restrictions


Executive Summary
I.) Compliance Responsibility And Licensing Pitfalls
II.) Oracle Technology Products
III.) Oracle Licensing Metrics
IV.) Selected Licensing Restrictions
Conclusion And Recommendations To Oracle Customers
Appendix – Results Of The Case Study


Download PDF

Executive Summary

This report is aimed at those in IT leadership and Software Asset Management with a strong background and interest in software licensing. We will analyze Oracle licensing, covering their main metrics for Technology Products and associated licensing restrictions. We give valuable advice and direction to Oracle customers on how to deal with the challenges of such complex licensing.

The report is presented in three chapters:

  • Chapter (I.) gives an overview of compliance responsibilities and licensing pitfalls. Customers are responsible for understanding and respecting Oracle licensing. It is incredibly complex, and has many pitfalls – most commonly related to metrics, the counting of users and devices, virtualization, etc.
  • Chapter (II.) details Oracle Technology Products. The family of Oracle Technology Products is comprised of: Oracle Databases (DB), Internet Application Servers (IAS) and WebLogic Servers, Business Intelligence (BI) Technology Products, WebCenter (WCE) and Identity Management (IDM).
  • Chapter (III.) explains Oracle licensing metrics. Oracle uses two main metrics for Technology Products: the Processor metric and the Named User Plus metric (NUP). The Processor metric takes into account hardware attributes and server/device configurations, such as the number and types of processors (cores or sockets), server operations and virtualization. The NUP metric takes into account the number of users, differentiated by user types (humans or devices), and user access (direct, indirect, or multiplexing).
  • Chapter (IV.) presents selected licensing restrictions. Oracle imposes additional licensing restrictions, such as the restrictions on soft partitioning. Product restrictions include the licensing of user minimums and product maximums.

In the Appendix we provide the solution to a case study on an incompliance situation (compliance audit) and the potential settlement penalty.

In subsequent publications we will provide further contemplation on Oracle licensing, with advice on topics including metrics, licensing restrictions and server and application operations. In the meantime, for those executives interested in sharing their thoughts on Software Asset Management or licensing, we welcome your feedback and comments.



Understanding the metrics used for licensing Oracle product installations is crucial for determining Technical Usage and License Demand. The License Demand is derived by applying the relevant licensing metrics and restrictions to technical installations (the Technical Usage).

In the following technical report, we explain the metrics and licensing restrictions used in the Oracle Technology Products family (including Oracle Databases), with product examples.

We will focus on the two metrics available for Technology Products: the hardware metric (Processor metric – “Proc”) and the user metric (Named User Plus metric – “NUP”).

Licensing restrictions for Technology Products are:

  • Installations (Technical Data) – Restrictions on product installations, e.g. on access and users, virtualization environments, high-availability and failover servers, etc..
  • Operations – Restrictions on product operations, e.g. on data transfers, high-availability and failover, standby and mirroring, etc.
  • Licenses (Commercial Data) – Restrictions on licenses, such as enterprise options, management packs, license terms, etc.

The following document contains selected aspects of Oracle licensing based on Oracle’s standard licensing rules. This document makes no claim of completeness, correctness and currentness – it should not be misunderstood as advisory documentation.

Oracle customers should be aware that the following report is for information and illustration purposes only. The licensing of products depends on the edition and version in use, and on many factors independent from Oracle: your infrastructure, licenses, enterprise contracts, etc. Always refer to the applicable Oracle licensing and to your individual customer agreements, and take into account your specific situation.

For comments and questions please contact OMTCO; contact details are listed at the end of this report.


I.) Compliance Responsibility And Licensing Pitfalls

Oracle’s stance is very clear:

Oracle Statement

“The number one compliance issue is over-deployment. This occurs when users who are not licensed for the software are using it. Naturally, Oracle expects customers to acquire licenses for all use of programs. When software is over-deployed, it is difficult for all parties involved.” (Oracle source)

This leads to strict compliance principles, applicable to any Oracle customer:

  • The customer is fully responsible for compliance, not Oracle. Oracle licensing requirements must be observed to the letter.
  • The customer’s obligation is to
    • apply applicable licensing to its license estates and technical infrastructure,
    • stay informed about new or modified licensing requirements published on Oracle website,
    • understand and correctly interpret Oracle licensing,
    • archive and be able to retrieve the whole history of purchases, license contracts, licensing publications, etc.,
    • apply all licensing requirements at any time to the whole estate.
  • Oracle has the right to verify compliance and to perform audits at customer sites.
  • If incompliance is discovered, customers must pay a penalty based on list price, plus retrograde maintenance (exception: Oracle talks the customer into an Oracle ULA – Unlimited Licensing Agreement –  thus masking the penalty as a commercial agreement).

Oracle Licensing Pitfalls

Oracle licensing is complex – and licensing pitfalls numerous. The most common pitfalls are related to metrics, the counting of users and devices, determining processor licenses, virtualization, failover clusters, and others. We can summarize Oracle licensing pitfalls with three categories:

  • Product installations – The user and processor metrics are both full of pitfalls, often associated with metric calculations, virtualization, high-availability servers or failover clusters.
  • Operations – Application operations and server environments, over which the customer has full control, often do not abide by Oracle’s strict restrictions, such as hardware restrictions for specific editions, or operations in failover clusters.
  • Licenses – Oracle licenses and customer agreements show high complexity and diversity regarding enterprise options and management packs, types of licenses (FU – Full Use; ASFU – Application Specific Full Use; etc.) and their associated restrictions.

These are summarized in the following overview table:

Pitfall category Explanation
Installations (Technical Data) For Named User Plus (NUP) and legacy user metrics: pitfalls often associated with access and users, and with mandatory licensing minimums.For Processor metrics (based on core and core factors) and legacy metrics (e.g. Power Units): pitfalls associated with metric calculations, licensing of virtualization environments, and high-availability/failover servers.
Application Operations And Server Environments For application operations: pitfalls associated with editions, data transfers and restrictions.For server environments: associated with high-availability and failover, standby/mirroring.
Licenses (Commercial Data) Pitfalls associated with enterprise options, management packs, license types (e.g. FU, ASFU etc.) and restrictions.

For a detailed report on Oracle licensing pitfalls that we regularly discover during compliance reviews and audit support for our customers, please refer to “Top 60 Licensing Pitfalls For Oracle Databases And Oracle Technology Products”, available at:

Licensing Complexity And The Audit Process

The complexity of product licensing and the thoroughness of compliance audits (compliance process) differ between software vendors. Larger vendors – such as Oracle or IBM – have complex licensing, partly due to their extended product palette. Smaller software vendors – such as Attachmate or Informatica – pose various challenges for their customers during audits and compliance reviews.

Exhibit 1 - Licensing Complexity And The Compliance Process

Exhibit 1: Licensing Complexity And The Compliance Process


II.) Oracle Technology Products

Oracle’s definitions of its product families are slightly ambiguous – families seem to partially overlap, as some products can be found in multiple families. For instance, the Oracle Technology Product family is comprised of Business Intelligence Technology Products (such as BI SE, BI SE1, BI Suite EE plus, etc.), but the Business Intelligence Application family also includes BI Applications (such as BI Applications Fusion Edition for CRM Analytics, ERP Analytics, etc.). Furthermore, Hyperion BI Technology Products are found in the Oracle Technology Product family, whereas Hyperion Enterprise Planning Products belong to the Business Intelligence Application family.

We define the main Oracle families as:

  • Oracle Technology Products
  • Oracle BI (Business Intelligence) Applications
  • Oracle Fusion Applications
  • Oracle E-Business Suite Applications
  • Oracle Managed Cloud Services (On-Demand), which is a cloud-based service providing existing Oracle products – this will be disregarded for the purposes of this report.

Oracle Technology Products, Oracle’s most renowned product family, is comprised of:

Family Products
Oracle Database (DB) Products
  • Available in six editions: EE, SE, SE1, PE, Mobile Server, No SQL DB EE)
  • EE Options (16)
  • DB Enterprise Management, also named Management Packs (6)
Application Server (AS) Products
  • Available in seven editions: Internet Application Server (IAS) SE1, IAS SE, IAS EE, TopLink and Application Development Framework, WebLogic (WL) Server SE, WL Server EE, WL Suite
  • WL Suite Options (5)
  • AS Enterprise Management (5)
Business Intelligence (BI) Technology Products
  • Several editions, including: BI SE, BI SE1, BI Suite EE plus, Server EE, BI Mobile
  • BI Server EE Options (5)
  • BI Suite EE Plus Options (1)
  • Hyperion BI Technology, Essbase
WebCenter (WCE)  Products
  • WCE Suite Plus, WCE Portal, WCE Content, WCE Sites, WCE Sites Satellite Server, WCE Universal Content Management, WCE Imaging, WCE Forms Recognition, WCE Capture, WCE Distributed Capture, WCE Real-Time Collaboration
  • WCE Adapters (7)
  • WCE Management (1)
Identity Management (IDM) Products
  • Various editions: Identity Governance Suite, Access Management Suite Plus
  • Identity Management, Enterprise Management
  • Management packs for DB/AS/BI/WCE/IDM, application management, application testing
  • Oracle Beehive
Application Products
  • Oracle Application Specific Technology Products (many products, eligible only for use with Oracle Applications)

  • Products: DB (Database), IAS (Internet Application Server), BI (Business Intelligence), WL (WebLogic)
  • Editions: EE (Enterprise Edition), SE (Standard Edition), SE1 (Standard Edition One)


  • Snapshot at the time of publication, June 2013 – subject to changes by Oracle.
  • Classification by the author – no claim to completeness as some products have been excluded.

It makes sense to consider the licensing of all Oracle Technology Products together as they have similar metrics and licensing restrictions, even if some restrictions and obligations differ by product, edition or version. The following chapter will review the two main metrics used for Oracle Technology Products, the Processor (hardware-based) and Named User Plus (user-based) metrics.


III.) Oracle Licensing Metrics

Oracle uses two main metrics for Technology Products:

  • Processor metric (often abbreviated as CPU or Proc) – Based on number and types of processors (cores or sockets), server types and brands, server configuration (high availability), and virtualization information.
  • Named User Plus metric (abbreviated as NUP) – Based on number of users, user types (humans, human-operated devices, non human-operated devices), user access (direct, indirect e.g. by daisy-chained applications, multiplexing e.g. access through a multiplexing platform).


1.) The Processor Metric

The number of processor licenses required by an installation is determined by the metric and the licensing restrictions associated with the Oracle product installed (including its edition and version). The processor metric takes into account relevant hardware attributes, such as number and types of processor cores, server operations (high availability), and virtualization (hardware <> cluster <> virtual machines).

Enterprise Edition

The processor metric of the Enterprise edition Technology Products assesses the number of processor cores, counted on all processors to be licensed (also considers underlying hardware in the case of virtualization – exceptions apply), and the PCF (Processor Core Factor), determined for the processor cores counted.


Formula For Calculating Processor Licenses For EE


  • Roundup – The number of cores must rounded up to the next integer (for each processor). The final result must again be rounded up to the next integer, for each product installation.
  • #Cores – All hardware with Oracle installations must be licensed. Hardware partitioning is taken into account as a means to reduce technical usage. Software partitioning (LPAR) may not be taken into account as a means to limit the #cores, i.e. all hosts in a hypervisor cluster must be counted (exceptions apply for Oracle cloud and for selected software partitioning technologies, such as LPAR AIX). Hyper-threading (HT) is not to be taken into account (only the physical cores must be licensed). Deactivated cores need not be licensed (example: IBM POWER).
  • PCF – The Processor Core Factor is determined by the Oracle PCF Table. Possible values are 25%, 50%, 75% and 100%.

Standard Edition, Standard Edition One

The processor metric for Standard Edition and Standard Edition One (all software from the Technology Product family with either of these editions in the title) takes into account the maximum of the number of occupied sockets (if sockets are occupied with single-chip modules) or the total number of chips in the occupied sockets (if sockets are occupied with multi-chip modules).


Formula For Calculating Processor Licenses For SE And SE1


  • #OccupiedSockets – the number of occupied sockets on the full underlying hardware (in the case of a virtual cluster with several physical hosts) must be counted. This applies only if a one-chip module is mounted in the occupied socket: then for this socket, the number of occupied sockets (#OccupiedSockets) is counted, which for one-chip modules will be equal to #Chips, e.g. 1 occupied socket = 1 chip.
  • #Chips – If a multi-chip module is mounted on a specific occupied socket, then for this socket #Chips on the occupied socket is counted (and not the occupied socket itself).


2.) The Named User Plus Metric

The number of Named User Plus licenses required by an installation is determined by the metric and the licensing restrictions associated with the Oracle product installed (including its edition and version). The NUP metric takes into account attributes related to hardware and users.

Exhibit 2 - User And Access Types

Exhibit 2: User And Access Types

  • Hardware – Certain Oracle Technology Products require a minimum absolute number of users irrespective of hardware (e.g. DB SE/SE1 requires 5 NUP licenses per database installation), or a minimum relative number of users depending on the hardware (e.g. DB EE requires a minimum of 25 NUP per processor; IAS EE/SE requires 10 NUP per processor). In the latter case, the hardware configuration has to thus be assessed using the processor metric, before the user minimum can be calculated.
  • Users – Users are defined by type, such as humans or devices (see 1, 2, 3 in the following exhibit), and how they access the database, such as direct, indirect, or by means of multiplexing (see a, b, c in the following exhibit).

The exhibit above shows how all nine possible combinations: 1a, 1b, 1c, 2a, 2b, 2c, 3a, 3b, and 3c.


3.) Case Study

Does the hardware upgrade generate incompliance risks? If yes, calculate the incompliance financial risk. (The results are provided in the Appendix).

Exhibit 3 - Hardware Migration And Incompliance Risks

Exhibit 3: Hardware Migration And Incompliance Risks


IV.) Selected Licensing Restrictions

The metrics and rules used to determine licenses needed are not all; Oracle imposes further restrictions on Technology Product licensing. These restrictions have a direct impact on applying metrics and subsequently calculating the necessary licenses. We will discuss two types of restrictions:

  • Licensing restrictions – These have a direct impact on the calculation of the number of licenses needed for any particular installation
  • Product restrictions – These have an indirect impact on license calculation, but impose obligations upon the customer.

Licensing Restriction: Partitioning

Partitioning is categorized by Oracle as either soft or hard partitioning. Oracle defines hard partitioning as physically segmenting a server, by taking a single large server and separating it into distinct smaller systems (each with separate CPUs, OS, memory, I/O, etc.). Oracle defines soft Partitioning as segmenting the operating system using OS resource managers, where the number of CPUs allocated to the Oracle product is limited by the OS. Oracle imposes licensing restrictions on soft partitioning:

Oracle statement:

“Soft partitioning is not permitted as a means to determine or limit the number of software licenses required for any given server.”

However, some selected soft partitioning technologies are approved by Oracle for qualifying as hard partitioning (no other technology or configurations qualify). Furthermore, some selected cloud computing environments are permitted by Oracle, such as Amazon Web Services, Amazon EC2 and S3.

Licensing Restriction: Licensing Minimums

Oracle imposes licensing minimums, depending on the edition and version installed. For instance, the licensing of certain products and editions using the NUP metric requires a minimum to license. Examples: DB EE requires 25 NUP licenses minimum per processor license; DB SE/SE1 require 5 NUP licenses minimum.

Product Restriction: Product Maximums

Oracle imposes product restrictions, expressed as maximum values to be abided by. These maximums depend on the edition and version installed. For instance, maximums are defined by hardware attributes (configurations) and number of users.


  • SE and SE1 only permit a maximum of 4 and 2 sockets respectively – occupied or not – on the physical hardware where the database is installed (alternatively, on each of the single physical hosts of a virtualization cluster). Note: the sockets to be counted for the purpose of determining the maximum number of sockets permitted is defined for single hosts, and counts all occupied and non-occupied sockets. This is a different method of counting compared to when calculating the necessary processor licenses (only occupied sockets in full underlying hardware).
  • DB PE only allows 1 user per installation.
  • DB XE imposes restrictions on further attributes: the number of processors, the size of the database in GB, and the RAM allocated to the database.

The Five-One-Zero (111110) Rule For DB PE 11g

The Oracle Database Personal Edition (DB PE) 11g only permits:

  • 1 – one single instance on any server where DB PE is installed
  • 1 – one single processor for execution of the database (but the server may have more than 1 processor)
  • 11 – eleven GB maximum of database data
  • 1 – one GB maximum of RAM allocated to the database (but the device may have more RAM)
  • 0 – zero support, zero upgrade, zero update

Note: A different rule applies to DB PE 10g (different restriction on RAM applies).


Conclusion And Recommendations To Oracle Customers

Oracle metrics and licensing restrictions – and hence the licensing pitfalls – are diverse and varied.

Oracle licensing is detailed in the applicable Oracle licensing documentation and in customers’ agreements and purchase history. Additional information needs to be obtained from supplementary Oracle licensing-relevant documentation, such as Oracle white papers on virtualization, product-specific licensing documented in specific Oracle publications, price lists, etc..

The role of the Software Asset Manager is to understand the full spectrum of metrics and licensing requirements applicable to their IT assets. In doing so, they permit their IT leadership to optimize assets, capital and operating expenditures.

We recommend customers to seek assistance from Oracle product and licensing experts, augmented by IT infrastructure understanding, to ensure that the metrics and licensing requirements are fully and correctly determined.

OMTCO’s Oracle product and licensing expertise, supplemented by knowledge of IT infrastructure, ensures competence above and beyond practical requirements. Should you wish for advice tailored to your specific needs, please call your OMTCO representative directly or contact OMTCO at


(Released October 2012, Updated June 2013))

Appendix – Results Of The Case Study

The hardware upgrade from Configuration 1 to Configuration 2, which is not permitted with DB SE, generates incompliance (SE installed, but EE should be licensed). This incompliance is either corrected by the customer at the regular, discounted price – or is discovered in an Oracle audit and corrected with settlement licenses at list price with a markup for retrograde maintenance on top.

Exhibit 4 - Results Of The Case Study

Exhibit 4: Results Of The Case Study


OMTCO does not disclose clients’ names, client projects or data. The case study and data published in this report is generic and derived from years of compliance reviews. All analysis presented and information disclosed in this document are exclusively based on public information. Should you wish to learn more about our confidentiality practice or about this case study, please contact an OMTCO representative.

The Licensing Of Oracle Technology Products – Compliance, Metrics, Licensing Restrictions



Dr. Yvan Philippe Luxembourg - OMTCO - Software Asset Management - Licensing Expertise - Counter Audit
Dr. Yvan Philippe Luxembourg
is a consultant
at OMTCO Munich Office.

00 49 170 6003451
Tim Sommer - OMTCO - Software Asset Management - Licensing Expertise - Counter AuditTim Sommer, MBA
is a consultant
at OMTCO Vienna Office.

00 43 699 15007391


OMTCO provides its clients with the best, thought-out advisory and line services, ranging from design-stage to implementation in Operations, Management, Technology and Consulting.

OMTCO works with the highest possible level of expertise – taking into account our know-how and our pragmatic experience from market analysis, competitive projects and professional references.

OMTCO has Oracle licensing expertise at its disposal, in addition to extensive experience in Oracle compliance reviews and customer-sided counter-audits.

Should you wish for advice tailored to your specific needs, raise comments or ask questions, please contact OMTCO at or call your OMTCO representative directly.

For Software Asset Management, visit:

For counter-audit experience, visit:

For licensing expertise, visit:

For further references, visit:


This document is current as of the initial date of publication and may be changed by OMTCO at any time. Not all offerings are available in every country in which OMTCO operates. THE INFORMATION IN THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING NO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT. This report is for information and illustration purposes only. It is not an advisory document and does not take into account your specific customer situation. Please refer to the disclaimer published at