Released April 2012, Updated September 2012/March 2013 | by Friedrich Florea

Content Executive Summary Introduction I.) Licensing Pitfalls Regarding Installations (Technical Data) II.) Licensing Pitfalls Regarding Application Operations And Server Environments III.) Licensing Pitfalls Regarding Licenses And Customer Agreements (Commercial Data) Conclusion And Recommendations To Oracle Customers   Download PDF Version

 

Introduction

Over the course of the Oracle compliance reviews and counter-audits we perform for our customers, we regularly discover recurring compliance issues, as a result of some typical Oracle licensing pitfalls.

The following report is an aggregation of the most common licensing mistakes that Oracle customers make relating to, among others, metrics, the counting of users and devices, the determination of processor licenses, virtualization, failover clusters, etc. In the following document, these mistakes are emphasized in italics.

Oracle customers already confronted with an Oracle compliance audit will especially be aware of the fact that Oracle licensing is complex, full of pitfalls and that licensing mistakes can occur easily.

Oracle licensing pitfalls may be associated with product installations. The user and processor metrics are both full of pitfalls, often associated with metric calculation, virtualization, high-availability servers or failover clusters.

Also, 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.

Last but not least, Oracle licenses and customer agreements show high complexity and diversity concerning enterprise options and management packs, types of licenses (FU Full Use, ASFU Application Specific Full Use, etc.) and their associated restrictions.

Oracle customers should be aware that this collection of examples is for information and illustration purposes only. The licensing of Oracle products depends on the editions and versions in use. In this report, we show selected aspects of the licensing of selected editions and versions. Always refer to the applicable Oracle licensing requirements, Oracle License and Services Agreement (OLSA), Oracle Ordering Documents (OD), and to your individual customer agreements, such as Oracle’s Enterprise License Agreement (ELA) or Unlimited Agreement (ULA), to take into account your specific customer situation.

 

I.) Licensing Pitfalls Regarding Installations (Technical Data)

1.) Named User Plus (NUP) And Legacy User Metrics

Oracle’s user metrics, such as the current Named User Plus (NUP) metric or legacy user metrics, bear licensing pitfalls often associated with access and accessing users, and with mandatory licensing minimums.

Access:

• Only users actually accessing – but not all users potentially accessing - the database or the Oracle Technology product have been licensed.
• Indirect/multiplexing users have not been licensed.
• Indirect users via daisy-chained applications – e.g. the user accesses application #1 which itself accesses application #2 etc. which eventually accesses an Oracle database or any Oracle Technology Product – have not been licensed.
• Multiplexing users have been licensed at the front-end concentrated as one user, as they are registered by the Oracle product accessed under one unique user login.
• Devices have not been taken into account for NUP licensing.
• The human-operated devices – but not the people operating the devices – have been licensed.
• An automated device with several sensors feeding the database has been counted as one user.

Minimums:

• The actual number of users has been licensed – which may be smaller than mandatory licensing minimums (DB EE: minimum 25 users/processor; DB SE/SE1: minimum 5 users).
• The user minimums have been waived for more than one secondary node in a failover cluster.
• The mandatory minimum for DB EE has been misunderstood as 25 users per software installation, and not per processor license.
• The mandatory user minimums have not been applied to DB options.
• The mandatory licensing minimum for DB SE/SE1 has been misunderstood as 5 users per legal entity or company, and not per database software installation.
• The licensing minimums for Oracle WebLogic server have been mistaken as the same as for Oracle Databases.
• Somebody said, “I license my Oracle DB and WebLogic servers per user, so that I do not have to bother about the hardware”.

 

2.) Processor Metrics

Oracle’s processor metrics (currently based on processor core and core factor) and legacy metrics such as Power Units, bear licensing pitfalls associated with metric calculation, the licensing of virtualization environments and high-availability/ failover servers.

Metric Calculation:

• Processors – but not cores – have been licensed for a DB EE.
• Processors – but not the number of occupied sockets (for mono-chip modules) or the number of chips on occupied sockets (for multi-chip modules) – have been licensed for a DB SE/SE1.
• A DB SE/SE1 installation has been licensed per occupied socket, although multi-chip modules are occupying the sockets.
• The number of cores has not been rounded up to the next integer for each physical processor.
• The final calculation of required licenses has not been rounded up to the next integer for each installation of the Oracle Technology Product.

Virtualization:

• Logical Partitions (LPAR), i.e. the virtual cores (vPCU) – but not all the physical processors of the underlying hardware – have been licensed (note: a few exceptions apply, e.g. Solaris 10 capped containers, AIX LPARs, AIX 5.2 dLPARs, etc.).
• Only the physical host hosting the LPAR – but not all hosts of the underlying hardware – has been taken into account.
• Restrictions on the type of virtualization permitted by Oracle as a means to reduce license demand has not been strictly observed.

 

II.) Licensing Pitfalls Regarding Application Operations And Server Environments

Oracle imposes restrictions on the operation of cheaper editions, such as the Express (XE) Edition, the Personal (PE) Edition or the Standard (SE/SE1) Editions. Environments which benefit from favorable licensing, such as high-availability and failover servers, are also subject to restrictions on operations.

 

1.) Application Operations

Editions:

• The editions installed have been licensed (XE, PE, SE1, SE), although the mandatory restrictions on the hardware (for XE/PE/SE/SE1: sockets, processors, RAM, DB data size, users) have not all been abided by.
• The customer believes that the free Express Edition (XE) has no licensing requirements.
• Oracle DB Express Edition has been licensed, although the licensing restrictions on software operations have not been followed.
• The customer has installed the same product – Database, WebLogic, etc. – with two different metrics, such as the processor metric and the Named User Plus metric, on the same server.

Data Transfers:

• People triggering manual batches have not been counted as users.
• In the case of data transfer over multiplexing infrastructure and user (NUP) metrics, the users at the multiplexing front-end have not been considered as licensable users or NUP minimums have not been applied.
• In the case of import or export of flat files and user (NUP) metrics, the users or devices performing the flat file transfers have not been considered as licensable users or NUP minimums have not been applied.

Restrictions:

• Only options currently in use have been licensed (note: this is unclearly ruled in Oracle licensing and subject to discussions in an Oracle audit).
• An Oracle software product, containing an ASFU (Application Specific Full Use) license for an Oracle Technology Product, has been customized or modified, and the ASFU license has not been upgraded to a FU (Full Use) license.
• A software product from an independent software provider, containing an ESL (embedded) license for an Oracle Technology Product (often an Oracle DB), has been used in a manner not purchased for (and not permitted explicitly by manufacturer), but a FU (Full Use) license has not been purchased.

 

2.) Server Environments

High-Availability And Failover:

• High-availability servers have been misunderstood as all being free from licensing.
• All failover servers running less than a total of 240 hours per year have been perceived to be free from licensing.
• Failover servers, for which uptime is not tracked and documented, have not been licensed.
• More than one secondary failover server for a single associated primary server has been considered to be free from licensing.
• Primary and secondary nodes in a failover cluster have not been switched back to the primary node after a failover situation.
• Maintenance jobs on failover servers have not been taken into account in the counting of uptime.
• Primary and secondary nodes have been licensed with different metrics.
• DB Options have not been licensed on the secondary node (failover server) instead of on the primary node, although the secondary node would require a higher number of Oracle Processor Licenses if it were licensed.

Standby/Mirroring:

• A standby/mirroring server has not been licensed with the same metric as the cluster environment.
• The Options and Management Packs (except RAC), licensed on the primary server, have not been licensed supplementarily on the standby/mirroring server.
• RAC installed on a standby/mirroring server has been considered free from licensing.

 

III.) Licensing Pitfalls Regarding Licenses And Customer Agreements (Commercial Data)

1.) Licenses And Maintenance

Oracle licenses show high complexity and diversity concerning products (including enterprise options and management packs), entitlement types (licenses, maintenance, reinstatements), terms (perpetual, FTL Fixed Term Licenses) metrics, restrictions (FU Full Use, ASFU Application Specific Full Use, ESL Embedded Licenses) and rules on maintenance. Oracle maintenance is associated with restrictive rules concerning termination, renewal and reinstatement.

Restrictions:

• A database (or any Technology Product) licensed with an ASFU (application specific) or ESL (embedded) license has been used for another purpose or another application.
• Entitlements with a legacy metric have not been migrated to a current metric and do not reflect current technical usage of the respective products.
• Licenses with legacy metrics have been migrated to a new metric but the legacy metric is still used to calculate the usage.
• Licenses with legacy metrics have been migrated to a new metric but those licenses are no longer under maintenance.
• FTL Fixed Term Licenses have been considered to be perpetual and the FTL term has not been respected.

Development:

• Oracle Technology Network (OTN DEV) licenses have been used to license software in test, staging or production servers.
• The restrictions of Oracle Technology Network (OTN DEV) licenses have not been strictly abided by.

Downgrades:

• The customer has multiple editions (e.g. EE+SE) on one server but has only licensed the highest edition (EE).
• Downgrade rights on editions have been taken into account (EE -> SE -> SE1 -> PE), i.e. a license EE covering an installation SE, etc.
• Downgrade rights on versions have been taken into account even though some licenses are no longer under maintenance.

Maintenance:

• Licenses not under maintenance have been believed to cover installation, whereas their versions have been released after the end date of the last maintenance.
• Maintenance has been partially terminated for one specific project.
• Licenses for a specific project have mixed support: some licenses are under active maintenance, others are not.
• Support calls have been placed for licenses not under active maintenance.
• Support calls have been placed for licenses which are only partially under maintenance.
• Software has been upgraded/updated to a version released after the last day of active maintenance (maintenance end date).

 

2.) Customer Agreements

Oracle proposes customer specific agreements, for instance an Unlimited License Agreement (ULA). ULAs solve some licensing issues – but create others.

ULA – Unlimited License Agreement:

• A ULA has been misunderstood as an “all-you-can-eat” contract, and the Oracle customer thought they may benefit from unlimited use of all Oracle products.
• The customer has been deploying Oracle products not reflected in the ULA.
• The Oracle customer has not provided the documentation detailing all Oracle deployments at the end of the ULA term (usually three years) to Oracle.
• The customer thought that they would have full property of the Oracle licenses at the end of the ULA term.

 

Conclusion And Recommendations To Oracle Customers

We have discussed selected Oracle licensing pitfalls. In fact, the licensing of Oracle Databases and Oracle Technology Products is complex. The pitfalls reflected in this document are the most common ones – each Oracle customer generates a unique combination of IT infrastructure, server and application operations, Oracle licenses and agreements; the potential penalties due to incompliance may be legally and financially disastrous. Though comprehensive documentation is publicly available from oracle.com and various internet sources, Oracle licensing still bears much room for interpretation: Oracle licensing expertise should be supplemented by practical counter-audit experience.

The role of the Software Licensing Expert and the Software Asset Manager is to understand the full spectrum of metrics and licensing requirements applicable to their IT assets. In doing so, they may propose to their IT leadership ways of optimizing assets, reducing capital and operating expenditures, and minimizing financial risks from Oracle compliance audits.

We recommend customers to seek assistance from Oracle product and licensing experts, augmented by IT infrastructure understanding and Oracle counter audit experience.

OMTCO’s Oracle product and licensing expertise, supplemented by extensive experience in Oracle compliance reviews and customer-sided counter-audits, 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 April 2012, Updated September 2012/March 2013)

 

---

Top 60 Licensing Pitfalls For Oracle Databases And Oracle Technology Products