Released April 2012, Updated March 2013 | by Tim Sommer

Content Executive Summary Introduction I.) Determining the Technical Usage and The License Demand II.) Determining the Compliance Position and Financial Liability III.) Optimizing the Technical Footprint and Relicensing Costs Conclusion And Recommendations To Oracle Customers Appendix   Download PDF Version

 

Introduction

Our client, a German energy group, initiated an internal audit reviewing its compliance position – and possible financial risk – deriving from its installations of Oracle Databases. All organizational units in Germany and all international subsidiaries of the group were under review.

As for the Oracle databases, all commercial and free editions – in all versions – were under review. Indeed, not only the compliance position of commercial editions needed to be reviewed, but also whether the restrictions of the free edition (DB XE) and the restrictions of the installations in development environments (licensed per Oracle Technology Network licenses / OTN DEV) were abided by.

A team of OMTCO Oracle licensing experts was sent in to work alongside, and support, the client’s own team. We worked through the following steps to tackle the demand, the compliance balance, and the compliance optimization.

In order to proceed:

• Step 1: Demand – We determined their technical usage and (draft) license demand;
• Step 2: Compliance – We determined their license demand, compliance position and resulting level of financial liability;
• Step 3: Optimization – We optimized their technical footprint and the relicensing costs involved.

This report is for information and illustration purposes only. The licensing of Oracle products depends on the editions and versions in use – always refer to the applicable Oracle licensing requirements and to your individual customer agreements.

 

I.) Determining The Technical Usage And The License Demand

Firstly, details of installations of Oracle databases were gathered, and their complete product names, editions, versions, enterprise options and management packs were documented. All Oracle database installations were relevant – independent of ownership of hardware, Operating System (OS) or software. In fact, the primary user(s) of Oracle software bear responsibility for their licensing.

An initial set of attributes were collected, providing information in relevant key areas. In order to drive the data collection process more efficiently, we supported the process with OMTCO’s Oracle Server Worksheet (O2SW).

Collect Your Technical Data In OMTCO’s Oracle Server Worksheet (O2SW)

OMTCO’s Oracle Server Worksheet examines all information and attributes necessary to determine the technical usage of all permitted metrics, optimize the technical footprint and ultimately reduce financial liability.

O2SW is comprised of five essential information categories – ISAAC (Installations|Servers|Attributes|Access|Costs):

• Installations – Oracle products installed, including complete product names, editions, versions, enterprise options and management packs;
• Servers – Information on servers, including unique server IDs, server relationships in virtual and clustered environments, e.g. information on virtual machines (VM), physical hosts and clusters, and on hardware partitioning and Logical Partitioning (LPAR) (note: workstations operated as servers, often for development purposes, are taken into account);
• Attributes – Hardware attributes, e.g. processor identification, number of processors and processor cores, and information on occupied sockets and chips (for the editions SE/SE1);
• Access – User access, including direct access (primary overlying applications), indirect access (via daisy-chained applications) and multiplexing access (via web-front engines, concentrating applications and platforms), and access by human-operated devices or automated devices;
• Costs – Information on license price, i.e. valuation at current price, with and without applicable customer discount.

Technically Optimize Your License Demand

Both technical usages – derived from the alternative processor and Named User Plus (NUP) metrics – have been calculated at installation level. O2SW computes both of these, and pre-selects the metric that should be applied in order to minimize each installation’s technical footprint.

The pre-selection is determined by weighing the metrics with their respective technical usages for each individual Oracle installation. This exclusively takes technical data into account – such as hardware attributes and user access – not yet considering commercial data. Furthermore, it is a local sub-optimization, as each installation is optimized with regards to its technical usage individually. Hence, this metric pre-selection is a technical optimization based on partial information, and must be confirmed in step 2, when technical data is linked with commercial data.

 

 

II.) Determining The Compliance Position And Financial Liability

In this second step, we collected commercial data, i.e.:

• Proofs of Entitlement – Proofs of Entitlement (PoEs) for licenses and their associated maintenance, reinstatements, license trade-ins for metric migration and license trade-ups (ASFU/FU), and
• Commercial agreements – Individual customer agreements, such as Oracle’s ELA Enterprise License Agreement or ULA Unlimited License Agreement, purchase documentation (OD Oracle Ordering Documents), and standard terms as in the OLSA Oracle License and Services Agreement.

Furthermore, contract and purchase information for all projects had to be analyzed, as Oracle imposes commercial restrictions depending on purchase information – for instance, regarding partial vs. full maintenance termination. Wherever entitlements had not been collected already, we ran through all purchase documentation – extracted from SAP and in paper format – and if need be, we recommended involving local Oracle sales representatives.

We then collated (in licensing terms: assembled) the use rights from entitlements and customer agreements in order to build complete threads of licenses / maintenances / reinstatements / trade-ins / trade-ups. These threads generated the so-called Effective License Positions (ELP), i.e. the use rights with the highest value, derived from the assembled entitlements. After matching up to the release dates – specific to each market – of the different product versions, we consolidated the Effective License Positions in terms of covered products, editions, versions, packs and options. This gave a clear picture on the most Effective License Position of the customer and made sure that each purchase was converted into the correct rights.

Consequently, the consolidated Effective License Position of the company was matched to the license demand (determined in the previous step). Deviations and project-specific requirements were taken into account in order to confirm or change the pre-selected metric, and to determine which metric should be selected for each single installation in order to reach the lowest level of incompliance. This generated the customer’s license demand, which was then matched with the consolidated use rights in the customer’s Oracle compliance balance.

Determine Your Financial Liability

We applied the current list price to each individual incompliance position – and added the correct number of years of retrograde maintenance – to evaluate their financial liability and simulate a compliance settlement.

If a product is legacy and not in Oracle offering anymore, the replacement product – or if none exists, a similar product – was taken into account. All prices revert to list price, as the customer’s specific price reduction is not taken into account in a settlement – which makes a difference, considering Oracle’s high discount system in the range of 50% to 80% (depending on customer’s purchase volume). If the installation date could be proven, a shorter time period for the retrograde maintenance was applied.

 

 

III.) Optimizing The Technical Footprint And Relicensing Costs

In this third step, we generated a set of optimization options to tackle the financial liability determined previously. Any optimization option must, however, be in agreement with the production side of the applications (application operations), i.e. with the people responsible for applications and the server administrators. Therefore, Oracle installations must be allocated to applications and projects – should this allocation not yet be done, it should be completed before proceeding further.

Optimization is possible on the two sides of the Oracle licensing balance:

• Technical side – Optimizing the technical footprint, for instance by reducing the infrastructure footprint or optimizing application operations.
• Commercial side – Optimizing costs, for instance by reducing purchasing price per unit or avoiding purchasing at all.

Optimizing On The Technical Side

Optimizing the infrastructure in order to decrease technical usage is considered with respect to the Oracle processor metrics (and Oracle user metrics for the calculation of user minimums), for instance:

• Processors – Migrating to different processors in order to reduce the result of the calculation roundup[(#cores) X (core factor)]. For instance, migrating to more powerful processors available in the same factor category (.25, .5, .75 and 1), consequently reducing the total number of processors, would reduce the total number of processor licenses needed for the Enterprise Edition.
• Edition – Downgrading Oracle Database installations from the Enterprise Edition (EE) to the Standard Edition (SE) or Standard Edition One (SE1), if possible considering the limitation on the number of sockets for SE/SE1, thereby reducing the processor count from cores to occupied sockets (if one-chip boards) or number of chips (if multi-chip boards).
• Downgrade – Downgrading any Oracle Database edition to a lower edition in a production environment (EE -> SE -> SE1) or in a development environment (EE/SE/SE1 -> PE/XE), reducing the total price to pay, provided that the limitations on operations and licensing are respected.
• Upgrade – Upgrading the lowest edition out of two installations in a single environment in order to match the highest installed edition – avoids the need to license the lowest edition, e.g. an EE and an SE edition co-exiting in an environment must be both licensed, but if the SE is upgraded to EE then only the EE edition needs to be licensed (once).
• Dedicated Clusters – Creating dedicated clusters for Oracle installations (licensed by processor or socket metrics), reducing the size of virtual environments to be licensed.
• Partitioning – Replacing software partitioning (not permitted as a means of limiting the number of software licenses required for any given server – some exceptions since 2011) with hardware partitioning.
• Packs And Enterprise Options – Uninstalling proactively unused management packs and enterprise options, thus reducing the number of required licenses for packs and options.

Optimizing applications operations reduces the number of users, for instance:

• Oracle Credentials – Differentiating Oracle credentials, which allow access to the Oracle product running on a specific server, from the server’s general credentials, which allow access to installations of all products on the server. This reduces, by technical means, the number of unnecessary direct users.
• User Credential – Introducing user-specific credentials supplementary to application-specific credentials – reducing the number of indirect users in daisy-chained applications.
• Automating Data Feeds – in the case of NUP (Named User Plus) licensing, this reduces the number of users, as batch-processing from one relational database to another is free under the NUP (Named User Plus) metric.

Optimizing On The Commercial Side

Reducing purchasing price per unit, for example:

• Customer’s Discounts – Purchasing at a discounted price outside of any settlement, as customer specific discount is lost in an audit settlement. Oracle offers high discounts on its list price, usually between 50% and 80% depending on the customer’s size. Any purchasing within an audit settlement thus doubles (i.e. when there is 50% discount outside of the settlement), triples (i.e. 66% discount), or quintuples (i.e. 80% discount) the unit price.
• Compliance – purchasing to re-establish compliance should take place after a customer-driven compliance review – not after an Oracle compliance audit.

Avoiding purchasing at all, for instance:

• Reinstatements – Reinstating maintenance of older licenses instead of purchasing new licenses replaces the costs of new licenses (100%) by reinstatement costs (3 years valued at 22%, hence 66% of new license costs).
• Metric Migration – Trading in licenses for metric migration from older metrics, and migration from Named User Plus to processors, is possible and may avoid unnecessary purchases by trading in unused licenses. However, any migration is associated with a decrease in value, and therefore must be well thought out before pursuing this course of action.
• Terminating Maintenance – Terminating unnecessary maintenance reduces costs by avoiding maintenance purchase; however, attention must be paid to Oracle’s restrictions on partial maintenance termination.

 

 

Conclusion And Recommendations To Oracle Customers

The licensing of Oracle Databases – and, more generally, of Oracle Technology Products – is complex.

Though comprehensive documentation is available from many internet sources, Oracle licensing still bears much room for interpretation. In our experience, a thorough internal Oracle compliance review requires the commitment of the client’s organization from their licensing, IT and purchasing departments, supplemented by Oracle’s licensing expertise and by pragmatic counter-audit experience.

We suggest conducting an Oracle internal compliance review with both Oracle licensing expertise and counter-audit experience. This minimizes the workload in the client’s organization, makes sure that Oracle licensing and possible incompliance are understood, and lastly eliminates the aforementioned incompliance and financial risk.

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, please call your OMTCO representative directly or contact OMTCO at oraclelicensing@omtco.de.

 

(Released April 2012, Updated March 2013)

---

Appendix

 

---

Internal Compliance Audit of Oracle Database Products

THE FINDINGS OF THE INTERNAL AUDIT OF ORACLE DATABASE PRODUCTS DEMONSTRATES THE IMPORTANCE OF UNDERSTANDING THE LICENSING COMPLIANCE RISKS WHICH ARISE FROM THE IMBALANCE BETWEEN ORACLE PRODUCT INSTALLATIONS AND COMMERCIAL USE RIGHTS. WHEN AN ORACLE AUDIT CONFRONTS YOUR ORGANIZATION, OMTCO IS BY YOUR SIDE TO PROVIDE YOU WITH LICENSING EXPERTISE, COUNTER-AUDIT EXPERIENCE AND 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.