Among the largest software vendors, Oracle is infamous for its aggressive audit practices. Oracle has built a compliance machine comprised of over 150 practitioners worldwide, known as License Management Services (LMS), which conducts audits of its customers in all major geographies. Due to the complexity of Oracle’s licensing rules and policies, and the costly nature of these software reviews, an audit can last for months until an official conclusion is reached.
Put simply, Oracle’s audits are one of the most feared in the software licensing world and they can bury your IT resources if you are not well prepared.
To help Oracle customers gear up and survive an Oracle license audit, we have compiled a list of common software issues that have caught many customers off-guard, leading to excessive fees paid to the vendor. We also share leading practice recommendations so you can mitigate licensing risks and reduce findings during an Oracle review.
Don’t fall into the Virtual Machine (VM) trap
If you use VMware or other virtualization solutions to host your Oracle products you need to be aware of the difference between soft and hard partitioning. Sometimes known as segmenting, partitioning occurs when CPUs on a server are separated or partitioned into individual sections, each operating as its own individual system. Partitioning can be accomplished virtually by having the OS limit the number of CPUs for a particular server, known as soft partitioning, or by physically separating segments of a server, known as hard partitioning. See Oracle’s official definitions here: http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf.
As it relates to Oracle’s licensing metrics, soft partitioning is not permitted as a legitimate method of determining or limiting “the number of software licenses required for any given server or cluster of servers.” Basically, if you’re using a virtual machine to limit the number of CPUs used by your Oracle product and only expect to pay for that usage, you will be met with an unpleasant surprise during an audit. That’s because Oracle will take into consideration all CPUs on the server or cluster and not just your virtual machine setup when calculating your deployment. Said another way, if there is a single VM on a node within a server cluster that is running Oracle, all CPUs within the cluster will need to be licensed for the Oracle application under Oracle’s soft partitioning rule.
Obviously, customers have raised a lot of complaints about this practice, but Oracle remains adamant in rejecting soft partitioning, despite most VMware environments being set up through this method. Oracle is unlikely to change its stance on this issue, so we strongly recommend that you review your entire system architecture and underlying hardware’s physical processors before setting up a virtual environment with Oracle software.
License all non-production environments
One of the most frequent mistakes that Oracle customers make is installing software on their non-production environment without paying for it.
According to Oracle’s licensing rules, it is mandatory for organizations to license all development, test, staging, and pre-production environments the same way they would license production environments. Keep in mind that you are required to use the same licensing metrics for both production and non-production environments. When you calculate your license requirements, you also need to consider all instances within your organization, including database and application software. Be especially careful when there are any changes to your system architecture that may increase the processor count, such as the addition of new servers or moving a node from one Oracle server cluster to another.
Some customers may have negotiated special clauses in their agreements to license non-production environments differently, but you should assume that’s not the case for you unless you’ve verified otherwise in your contractual language.
Take the time to understand your Unlimited License Agreement
The Unlimited License Agreement (“ULA”) is one of the most confusing agreements that Oracle offers to its customers. You might think that having “unlimited” in its name grants you full rights over how you use the software and what software you can deploy. In fact, this agreement very specifically limits the number of products you can use, where you can use those applications, and how long you can use them.
ULAs are generally limited to specific entities and include a pre-defined list of products which require an upfront payment. They also include specific provisions regarding the termination of the contract. At the end of a typical 3-year term, customers have two options: to renew the ULA or to terminate it. If you end your ULA, you are required to certify all Oracle products and this certification must be signed by a C-level officer of your company. This means you need to declare installations of each ULA product, providing the required license counts across your IT environment. Oracle then draws a “line in the sand” and grants you perpetual rights to the declared software quantities for which you pay support and maintenance fees, governed by the ULA clauses. Be advised that Oracle may challenge your certification numbers and request additional support or detail to verify the figures. In some cases, the sales team may suggest that you work with LMS to obtain more specific or accurate certification numbers by running their home-grown scripts across your Oracle landscape. In these instances, there is likely suspicion that your counts are inaccurate or that you’re “stockpiling” your deployments which is prohibited by your license agreements.
Also, if you miss any installations during the certification, your usage will not be entirely covered by the perpetual licenses granted at the end of your ULA, and you will be non-compliant for any undeclared software running in your environment. Another licensing “gotcha” is that Oracle does not allow you to declare software licenses deployed in the public cloud (e.g., AWS or Azure). You can deploy software in these environments, but they are not counted as part of your certification, so upon ULA expiration, you’ll likely be out of compliance for these cloud-based deployments.
In order to avoid paying extra fees after your ULA terms, we recommend performing an internal assessment each year to have a definitive summary of your Oracle deployments before the expiration date approaches. It’s leading practice to leverage LMS scripts or utilities that are recognized by Oracle to baseline your software installations on-premise and in the cloud, and to begin this process at least 6 months before your ULA end date.
Don’t be fooled by pre-installed options and packs
Another issue frequently identified during Oracle audits is the deployment of product options and packs that were not intended. These licensing pitfalls mainly apply to Oracle database products since they have a plethora of supporting features. Depending on the version, the database product includes additional options and packs (e.g., fine-tuning pack) that are automatically enabled during installation, and it’s not highly intuitive for IT users to “unselect” them. This is very common for customers who leverage Oracle Enterprise Manager (“OEM”) to manage their Oracle deployments. Before the release of the 11gR2 database, end-users had the ability to select or deselect the desired options during the installation of the database. However, it was still an issue because most end-users believed they were entitled to use everything that was being offered in the installation panel.
We believe this is the most covert licensing tactic that Oracle employs since the vendor allows you to install these options by default and without any disclaimers, and they are not generally covered by the standard database license in your agreement.
So, what can you do? Although Oracle software which is installed and/or running technically needs to be licensed, in practice LMS usually only charges for options found in use at the time of the audit. Since LMS has its own scripts to scan Oracle environments, it is only during the audit that most of the customers are faced with non-compliance findings and are required to pay extra fees. In order to avoid these unplanned fees, it is recommended to have your Oracle administrators implement internal controls and procedures to keep track of all these enabled options and the associated usage. You should instate a process that allows you to self-audit your Oracle environment and disable features, options, and packs that aren’t needed to support your applications.
Spend a bit more time to understand your licensing metrics
Metrics are often treated lightly by organizations when they buy software, but they are at the core of any licensing model. Despite its importance, most organizations don’t have the expertise or enough bandwidth to go through their agreements, identify their licensing metrics, and understand how they affect purchasing and software requirements.
It certainly doesn’t help that Oracle offers a wide range of licensing metrics and policies for their growing product portfolio. Customers can easily get confused with the various metrics including “Named User Plus” (NUP), “Processor,” “Application User,” “Monitored User,” “Expense Report,” and so on. Each licensing metric measures deployment differently and is used to calculate the applicable fee for the associated software product.
We recommend checking the metrics defined in your agreements with your Software Asset Management (SAM) department or software experts familiar with Oracle licensing, compliance, and audits. Creating a centralized matrix with each Oracle product and the corresponding metric may help you keep track of your Oracle licenses and usage. Ideally, this information should be maintained within your SAM tool, where automated reconciliations are performed against your Oracle deployments referencing these product metrics. At a minimum, mock audits should be conducted to proactively identify and remediate Oracle licensing gaps, well ahead of any ULA certification or contract renewal.
Connor Consulting is here to help
Although Oracle’s licensing rules may seem overwhelming and are not always easy to follow, Connor Consulting can help you successfully navigate through the pitfalls of Oracle’s licensing environment. Our practitioners have years of software licensing, contract compliance, and IT sourcing experience for major vendors including Oracle, SAP, and IBM, and we have helped many IT organizations prepare for difficult vendor audits and boost the effectiveness of their SAM programs.
To learn more about our SAM and Audit Defense offerings, contact Connor Consulting at email@example.com today.