Table of Contents
The chances are, if your estate runs on an Oracle database, you’ve probably been approached by Oracle’s internal License Management Services (LMS) or Global Licensing Advisory Services (GLaS) for a formal license review.
If so, you’ll know that there’s no getting away from the fact that Oracle licensing is highly complex.
With this in mind, we’ve formally compiled this Essential Guide to Oracle Licensing. From licensing requirements and the ins-and-outs of licensing agreements, to the consequences of improper licensing, this article will help demystify each step of licensing your Oracle estate.
Oracle Software License Agreements
There are three Oracle software license agreements you need to be aware of; SLSA, OLSA, and OMA.
Each differ slightly/wildly from another, so it’s important to gain an awareness of each in order to fully grasp your agreement with Oracle.
Standard License and Service Agreement (SLSA)
The SLSA is an older perpetual agreement, superseded by the subsequent OLSA, and no longer issued by Oracle. However, those with longstanding license agreements may still be running their estate on a SLSA.
The major perk of holding a SLSA is that it governs all of your licenses, rather than the licenses most recently purchased. This means that an organisation’s future purchases can be made under a SLSA agreement, conferring a range of benefits no longer available in later agreements.
For example, minimum purchases per processor are also typically lower on this license than more current arrangements (10 NUP licenses are currently required on Standard Edition & 25 NUP users per core on Enterprise Edition).
Xynomix Tips
Oracle Standard Edition is usually licensed by processor, which Oracle defines as a socket. If you run multi-chip processors, then each chip is counted as an occupied socket.
Oracle Enterprise Edition is calculated by the following formula:
‘# of cores x core factor = # of Processor licenses required’
*Note: this rule changes when dealing with Oracle cloud (more information)
Oracle License and Service Agreement (OLSA)
Much like the older SLSA, the OLSA (Oracle License and Service Agreement) covered the general terms and conditions of Oracle software. However, unlike its predecessor, an OLSA license was issued per purchase, meaning companies could end up with a whole host of different agreements with Oracle.
Many users are still on OLSA agreements with Oracle, with it being the most common agreement for the past twenty (or so) years. However, it was replaced by the OMA in 2013.
Oracle Master Agreement (OMA)
The OMA (Oracle Master Agreement) is the current software license agreement, and is designed to create a single, central agreement across all Oracle services, including licensing, hardware, support, cloud, consulting, and more.
This reduces paperwork, and creates a single point of reference for purchases with Oracle.
Types of Oracle License
Perpetual License
A perpetual license allows continual use of Oracle products and services within your agreement for a one-time fee. And, provided that you pay your annual technical support fee (roughly 22% of the perpetual license cost), you’ll continue to receive updates and patches.
Term License*
A term license is a limited, more temporary alternative to the perpetual license. A more affordable alternative, Term licenses cost a mere 20% of the Perpetual license fee, however the 22% annual technical support fee is still required.
*Term licensing was previously available for up to five years at a time. However, as of September 2021, Oracle stopped selling on-premise term licenses of more than one year per agreement. Find out the full details of the end of Term Licensing – including exceptions.
Unlimited License Agreement (ULA)
An Unlimited License Agreement (ULA) allows for the unlimited use of agreed Oracle products and services, designated over a specified period of time.
At the end of this period, Oracle will quote the user with the number of licenses required for the continued use of these respective services.
Organisations that fall foul of Oracle License Reviews, conducted by Oracle License Management Services and Global License Advisory Services, are often pressured into ULAs, so it’s important to discuss this with your expert licensing partner prior to agreeing to any terms.
Perpetual Unlimited License Agreement (PULA)
A PULA (Perpetual Unlimited License Agreement) is much like the standard ULA, with one crucial difference – there is no specified end to the agreement.
Opting for a PULA gives an organisation greater flexibility and simplifies the software asset management process – but it’s very costly (typically twice the cost of a ULA).
Plus, if you want to get out of the agreement, every single Oracle server will become immediately unlicensed at the same time, if a new agreement is not put in place.
If you plan to sign a ULA or a PULA, it’s worth having a discussion with an Oracle database expert to certify that you’re getting the best value.
Oracle License Metrics
Depending on your agreement, your estate could be licensed in a variety of ways – either by User, Application, or Processor (SE)/Core (EE).
There are a range of differences to these licensing methods.
Processor or Core
Whether your estate is licensed by individual processors, or cores, depends on whether you’re on Standard or Enterprise Edition.
Oracle Standard Edition is licensed per processor, regardless of circumstances.
Meanwhile, Oracle Enterprise Edition is licensed per core.
This is worth bearing in mind, should you be conducting an internal license audit to ensure that your estate is properly licensed.
User (Named User Plus License)
Oracle’s Named User Plus License (NUP) means that you must be licensed per user or device. It also means that any user licensed on NUP can access multiple databases on a single server.
It is, however, a little more complex than this. Oracle lays out the terms in the following way:
Named User Plus: This metric can be used in all environments. Different minimums apply depending on the Database edition:
Oracle Database Standard Edition 2 may only be licensed on servers that have a maximum capacity of 2 sockets. In addition, notwithstanding any provision in Your Oracle license agreement to the contrary, each Oracle Database Standard Edition 2 database may use a maximum of 16 CPU threads at any time. The minimums when licensing by Named User Plus (NUP) metric are 10 NUP licenses per server.
The Enterprise Edition requires a minimum of 25 Named User Plus per Processor licenses or the total number of actual users, whichever is greater.
Example: A customer who wants to license the Database Enterprise Edition on a 4-way box (assuming single core chips) will be required to license a minimum of 4 processors * 25 Named User Plus, which is equal to 100 Named User Plus.
Read more at Oracle.com
Application (Application-Specific Full Use)
Application-specific full use, or ASFU for short, is as the name suggests – a limited use license whereby your server can only be used for a single application.
The benefit here is that, if you only rely on a single application, you’re only paying to license usage of that application. The obvious drawback is that the designated ASFU server cannot, under any circumstances, be used for anything other than the licensed application.
ASFU licenses are acquired slightly differently than normal circumstances. Instead of approaching Oracle, the user must approach the independent software vendor (ISV) for an ASFU license.
This means that in order to audit your estate, the application vendor must be involved in order to supply CSI numbers and validate that you are running the correctly licensing configurations. However, it is still the customer’s responsibility to ensure that the database is licensed correctly.
ASFU licensing offers great value at the expense of flexibility.
Environments Required to be Licensed
Production
Any production environment running on Oracle must be properly licensed, whether it’s on Named User Plus, ASFU, or processor/core licensing.
Test, Development, and Staging
Licensing for testing, development, or staging environments works slightly differently from production. All three areas must still be licensed, but they can be run on free Oracle Testing Network (OTN) licenses.
It is worth noting that OTN licenses are highly restrictive, and breaching the terms can lead to extremely punitive non-compliance fines.
Backup, Failover, Standby, and Disaster Recovery
Simply backing up your server to tape does not require any additional licenses because the backup is not an active, running server.
Standby and disaster recovery DBs must be licensed, however. Active standby must be licensed as a fully-fledged database (identical to PROD).
Meanwhile, failover nodes are also required to be licensed.
Partitioning
Partitioning is where Oracle licensing gets somewhat complicated.
Hard partitioning your server to reduce the number of licenses required is permitted, but only in extremely limited circumstances laid out in Oracle’s Oracle Partitioning Policy – Topic: Server/Hardware Partitioning document.
Soft partitioning, however, is not allowed. According to Oracle ‘soft partitioning […] is not permitted as a means to determine or limit the number of software licenses required for any given server or cluster of servers’.
This means that running VMware or another virtualisation technology could put your organisation at a serious risk of punitive licensing non-compliance fines.
Batching
Batching – the grouping of tasks that typically occur at different times and processing them simultaneously – will depend on whether you’re performing this automating or manually.
Automated batching and copying of data from device to device does not require any licenses.
Meanwhile, users performing a manual batching process – or an import/export of flat files – are required to be licensed on a per user basis through NUP licensing (Named User Plus).
Multiplexing
Multiplexing – where multiple end users use a single portal to concurrently access an application – is required to be licensed at the front end.
The Consequences of License Non-Compliance
The consequences of non-compliance with Oracle licensing can be dire – coming mostly in the form of extremely punitive licensing fines.
Non-compliance fines issued by Oracle’s License Management Services (LMS) and Global License Advisory Service (GLAS) can extend into the millions of pounds.
So, if you’re a small to medium-sized business and get hit by an Oracle licensing fine, you could see an entire year’s revenue wiped out – or worse, bankruptcy.
And these are not wildly extreme examples – our consultants have successfully negotiated license non-compliance fines for years, protecting customers from significant bills.
Without strict internal processes in your technical team, accidental non-compliance can happen with ease.
For example, Oracle databases are typically installed with all services included as standard.
The problem here is that, unless you’re on a ULA with Oracle, you’re probably not going to be licensed for all of these services.
Therefore, the onus is on the DBA to uninstall the services you are not licensed for as soon as possible. Otherwise, you might accidentally activate a service or feature your business hasn’t licensed.
And if LMS or GLAS conduct an audit of your estate – you’re in trouble.
Oracle licensing, therefore, must be considered as part of your organisation’s overall risk management strategy. Failure to do this is a genuine risk to business continuity.
How to Mitigate Oracle License Risks
1) Conduct regular internal audits
Monitoring your licensing policies internally, and on a semi-regular basis, is an effective way to ensure that nobody within the business has accidentally activated or installed an unlicensed Oracle feature.
2) Ensure licensing awareness and training is included as part of your onboarding process
In order to prevent unlicensed features being used, proper training must be given to your internal team both as part of their onboarding process and at intervals, to ensure that their knowledge remains up-to-date.
This training is particularly important in situations where your organisation has a change of staff. New DBAs might not be familiar with your current arrangements with Oracle, so it’s in your best interest to make them aware.
3) Deploy principle of least privilege policies across your organisation
Principle of least privilege (PoLP) – the strategic limiting of access to settings and features are not part of an individual’s day-to-day role – is a cyber security best practice and must be implemented across your entire organisation.
This might also be a good option for junior DBAs, in order to prevent access to unlicensed features.
4) Work with an experienced Oracle licensing partner
Naturally, working with an Oracle licensing expert (like ourselves!) is a great way to mitigate the risk of licensing non-compliance. Plus, if you are audited, a dedicated Oracle licensing partner can negotiate with Oracle on your behalf.
Just make sure that they’re experienced in Oracle (read testimonials, reviews, and case studies) and, crucially, look for assurance that they’re independent consultants, as opposed to an Oracle reseller. Their independence guarantees negotiation on your behalf in good faith.
Our software asset management team are experts in Oracle licensing.
Contact the team for further advice.
Useful Oracle Licensing Resources
- Oracle Software Licensing Basics
- Server Partitioning
- Topic: Database Licensing
- Oracle Term Licensing Ending September 2021
- What does Oracle ASFU License mean to you?
- License Management Services – FAQs
- License Management Services – Tips
- Top 5 Oracle Licensing Audit Triggers
- How to Prepare for an Oracle License Audit
- 7 Costly Oracle Licensing Pitfalls (And How to Avoid Them)
