Released October 2012, Updated June 2013 | by Tim Sommer

Content Executive Summary Introduction 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

 

Introduction

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:

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: http://omtco.eu/references/oracle/top-60-licensing-pitfalls-for-oracle-databases-and-oracle-technology-products/.

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.

 

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
Tools	Management packs for DB/AS/BI/WCE/IDM, application management, application testing
Collaboration	Oracle Beehive
Application Products	Oracle Application Specific Technology Products (many products, eligible only for use with Oracle Applications)
Abbreviations: Products: DB (Database), IAS (Internet Application Server), BI (Business Intelligence), WL (WebLogic) Editions: EE (Enterprise Edition), SE (Standard Edition), SE1 (Standard Edition One) Caveat: 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.

Notes:

• 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).

Notes:

• #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.

• 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).

 

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:

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.

Examples:

• 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.

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 oraclelicensing@omtco.de.

 

(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.

---

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

THE FINDINGS OF THE REPORT DEMONSTRATE THE IMPORTANCE OF UNDERSTANDING ORACLE LICENSING, INCLUDING THE CPU AND NUP METRICS AND LICENSING RESTRICTIONS. WHEN YOU CONDUCT AN INTERNAL COMPLIANCE REVIEW, OR WHEN AN ORACLE AUDIT CONFRONTS YOUR ORGANIZATION, OMTCO IS BY YOUR SIDE TO PROVIDE YOU WITH LICENSING EXPERTISE AND COUNTER-AUDIT EXPERIENCE, AS WELL AS NEGOTIATION SUPPORT.

 

 

 

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 http://omtco.eu/disclaimer.