Oracle License Definitions — what do they mean (Oracle Entitlement series part 4)
Oracle licensing is such a specialised subject that not many can master, but if you do manage to comprehend the core pillars of Oracle licensing, you will realise the importance of License Definitions.
In part 2 of this series, I explained some of the more important parts of Oracle Agreements and contracts. This post will take a look at license definitions and rules and will highlight some of the key things you should look out for.
Oracle has a reference booklet on their website, which gives you a good and knowledgeable guide on license definitions and rules. There are over 250 license metrics — so for me to cover each and every one of them would take a massive amount of time, and you, the reader would log off rather quickly.
So, for a single source of all of them, please refer to the reference booklet I mentioned above as a starter, however, please be aware of what your contract references or whether it contains its own definitions. In this post, I will pick out a few of the more common license metrics and discuss:
Application User: is defined as an individual authorized by You to use the applicable licensed application Programs which are installed on a single server or on multiple servers regardless of whether the individual is actively using the Programs at any given time.
This means that if a customer has a product that has ‘Application User’ as the license metric, for this application program the customer must ensure that they have enough licenses for all users that have been provisioned with access to the application/module. Even if they do not use the application or have never used the program but have been given or granted permission and the responsibility in the application, Oracle will still expect that the customer should have a license for that user(s). It is a case of making sure that the users in a specific group or role must actually be users of the program and not given blanket access to everyone — or else the customer will have to license everyone! Giving every user access has its benefits in terms of speed to set up and simplicity, but the net effect is the customer would have to license every single user given access!
Processor: shall be defined as all processors where the Oracle Programs are installed and/or running. Programs licensed on a processor basis may be accessed by Your internal users (including agents and contractors) and by Your third-party users. The number of required licenses shall be determined by multiplying the total number of cores of the processor by a core processor licensing factor specified on the Oracle Processor Core Factor Table which can be accessed at http://oracle.com/contracts. All cores on all multicore chips for each licensed Program are to be aggregated before multiplying by the appropriate core processor licensing factor and all fractions of a number are to be rounded up to the next whole number. When licensing Oracle Programs with Standard Edition 2, Standard Edition One or Standard Edition in the product name (with the exception of WebCenter Enterprise Capture Standard Edition, Java SE Subscription, Java SE Support, Java SE Advanced, and Java SE Suite), a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.
This is one of the most common license metrics for Oracle technology, such as database and middleware. We regularly see customers misunderstanding the definition. You must be aware that the definition itself can be misleading, as it talks about cores, when the naming convention is processor. When dealing with Enterprise edition of Oracle Database (if licensing by Processor) you must count the number of cores, then multiply by the respective multi core factor (if Intel it is 0.5 — but there are others, such as Sun 0.25 and IBM P series 1.0 — so please check first). For Standard Edition databases, it is slightly different, in that you count the number of processors/occupied sockets and there is a restriction on the amount allowed per server. In addition, the Processor metric is available for other technology programs such as Data Integrator, GoldenGate with subtly different Processor definitions — so please check (or get expert advice) before ordering your hardware and discovering that if you looked closer, a different server model or processor chip may have resulted in less license expense.
Enterprise $M in Cost of Goods Sold: Enterprise $M Cost of Goods Sold is defined as one million U.S. Dollars (or the equivalent amount in the applicable local currency) in the total cost of inventory that a company has sold during their fiscal year. If Cost of Goods Sold is unknown to You then Cost of Goods Sold shall be equal to 75% of total company revenue. The value of these Program licenses is determined by the amount of Enterprise $M Cost of Goods Sold. For these Program licenses, the licensed quantity purchased must, at a minimum be equal to the amount of Enterprise $M Cost of Goods Sold as of the effective date of Your order. If at any time the amount of Enterprise $M Cost of Goods Sold exceeds the licensed quantity, you are required to order additional licenses (and technical support for such additional licenses) such that the amount of Enterprise $M Cost of Goods Sold is equal to or less than the number of licensed quantity. You are not entitled to any refund, credit or other consideration of any kind if there is a reduction in the amount of Enterprise $M Cost of Goods Sold.
This is another license metric currently being sold by Oracle, and one that customers should be aware of if used for applications products. The license metric is based on the amount of inventory sold in their financial year. If it is unknown, then Oracle will base it on 75% of the total company revenue (details are usually available publicly in end of year financial reports — which Oracle will reference). Also, there is an obligation on the customer to report annually (in case of any increases). If there are any decreases, the customer will not get reimbursed for any overage in licensing.
In Summary
There is a wealth of information on license definitions — too much for me to go through in this post, so please do refer to the relevant definition booklet for more detail on the meanings and how to apply a license metric to your ordered software application.
Sometimes customers can outgrow the license metric either by number of users, number of processors, edition used, quantity of sales, number of subscriptions etc — so it is easy to be non-compliant quickly without proper monitoring and controls in place.
My recommendation is to have experts on hand, ideally an independent consultancy such as Version 1 to explore which license metrics you have entitlement for, how they should be applied and whether or not your business is conforming to the restrictions of the metric definition.
On numerous occasions I’ve observed customers renewing Oracle support thinking that they have a license so they are fine, but failing to understand that even though they may have the ‘right’ license, it’s possibly not the correct license metric definition or quantity.
In my next post, I’ll share my insight on ECPU’s — the new billing metric that Oracle has introduced in Oracle Cloud Infrastructure as the default for Autonomous Database.
As Oracle license experts with a deep understanding of Oracle policies, commercial agreements and technical deployments, we are here to help answer any questions you may have on this topic, or any other license concern. Contact us for help.
About the Author:
Johnny Cree is an Oracle SAM Licensing Consultant at Version 1.
