Manage Learn to apply best practices and optimize your operations.

The seven deadly sins that lead to an Oracle audit

Oracle is notorious for its confusing licensing policy. Robert Sheldon presents seven behaviors that can lead to an Oracle audit and costly audit fees.

Oracle's licensing policies are notoriously vague and confusing. One misstep and you can end up owing thousands of dollars in audit fees. Yet Oracle software, with its dazzling array of management packs and pre-installed options, is easy to misuse; so easy in fact that you could find yourself out of compliance and sailing the piracy high seas before you can say "Black Bart."

And don't think Oracle won't hunt you down. According to a recent Flexera/IDC report, 63% of the surveyed organizations were audited by a software vendor in the past 18 to 24 months -- and 56% had to pay additional fees, many over a million dollars. Oracle is routinely recognized as one of the top auditors among software vendors, gladly exercising its right to ensure customers toe the line no matter how confusing the rules.

This prospect is particularly sobering when you consider that 85% of the surveyed organizations are out of compliance with their software licensing agreements. Chances are your company is one of the offenders, especially if you're running Oracle products. Even so, it's not always clear what sins you've committed to get there. Here we look at seven of the most common -- and often deadliest -- behaviors that can result in those contentious Oracle audits and exorbitant licensing fees that follow.

Lack of licensing inventory

Tracking your software's licensing documentation can be a daunting task. In addition to the Oracle License and Service Agreements (OLSAs), you should have access to the full order histories, renewal dates, discount offerings and any other information relevant to your software investments. If you're working with older OLSAs, you also need to track product names and metrics that have changed over time.

The availability of your licensing information is essential to fully understanding what products you've purchased and how you're permitted to use those products. A Full Use (FU) license, for example, is very different from an Application-Specific Full Use (ASFU) license. By not tracking this information, uncertainty can arise in a number of areas, including the precedence of contracts when conflicts occur between an OLSA and the various addendums.

Not knowing what's installed where

As equally important as knowing what you're permitted to do is knowing what you're actually doing. Yet few organizations have a complete inventory of which products they've implemented, let alone which editions or versions. What complicates matters is that you can easily use options and management packs without their being licensed.

The challenge with Oracle software, in particular, is that product options and management packs are installed with the main products and enabled by default. This is particularly true for enterprise editions. Administrators can easily use these features even if they haven't been licensed. For the organization deploying software to numerous servers in multiple locations, the chances of being out of compliance grow exponentially.

Metric misunderstanding

Determining proper software usage can be tricky business when it comes to applying the right metrics. For example, an administrator might use both the Processor and Named User Plus (NUP) metrics when installing a product on a single server. Another administrator might confuse legacy metrics, such as Concurrent Users, with current metrics, such as NUP.

Many of the issues related to metric misuse come about because of improper counting. For example, an organization using the Processor metric might fail to count cores or occupied sockets or fail to round up the number of cores to the next integer for each processor. When using the NUP metric, companies routinely underestimate the actual number, not accounting for minimum requirements or failing to count indirect users, such as those accessing the software through daisy-chain applications. Whenever you're dealing with Oracle products, you can be certain there's no such thing as a simple metric.

Indiscriminate virtualization

One of the biggest gotchas in the world of Oracle licensing is virtualization, where it's so easy to fall out of compliance that you might as well write the check now if Oracle decides to audit. One of the challenges is that Oracle supports only hardware partitioning, not software partitioning like you get with VMWare. As a result, you must license all processors and cores accessible to the Oracle product.

But that's usually not what happens. Instead, organizations license the logical partitions, but fail to account for the underlying hardware's physical processors. When setting up a virtual environment, you need to take into account the entire system architecture, including virtual machines, clusters and storage. One small slipup could cost you more than the original license.

Mismanaged fault tolerance

Organizations also tend to fall out of compliance when implementing disaster recovery and high availability. For instance, they might fail to license failover cluster nodes or servers used for mirroring and standby, often because they believe these components don't need to be licensed. In other cases, they might use different metrics to license different nodes.

Many organizations also fail to take into account maintenance jobs on failover servers or forget to switch back from a secondary node to a primary one after a failover situation has been resolved. In addition, they might forget to license the options and management packs on their standby servers, even though they're licensed on the primary ones. Clustered environments also tend to exacerbate other violations, such as those related to misapplied metrics and wayward virtualization.

License misuse

Whether intentional or not, many organizations use Oracle software in ways the licensing doesn't permit. The classic example is the Unlimited License Agreement (ULA), which is often interpreted as a software smorgasbord that grants you the right to use just about anything anywhere you want. However, a ULA limits which products you can use, where you can use those products, and how long you can use them.

But ULAs are not the only trap. An organization might modify an Oracle application without upgrading the license, run multiple product editions on a single server but license only one, or fail to adhere to mandatory hardware restrictions when installing specific software editions. In fact, you can find yourself using Oracle products in many ways that the licensing doesn't intend, and such practices can turn into costly ventures if Oracle should ever find out.

Indiscriminate implementations

The last of the seven deadly sins, but certainly not the least, is to install products without paying for any licensing whatsoever. Non-production environments are perhaps some of the biggest culprits. Oracle fully expects you to license your development, testing and preproduction environments, as you would a production environment. You must account for users, processors, editions, versions, management packs and all those built-in options. And don't be fooled into complacency by Oracle Technology Network (OTN) licensing. It's not as freewheeling as you might hope.

Then there are all those other places you can slip up, such as non-human operated devices. They might not require an actual person to run them, but they still must conform to Oracle licensing and be counted like other users. Data transfers can also fall into the licensing black hole if you're not careful. Users who trigger manual batches must be counted, as must users (or devices) that perform flat file transfers. Even data transferred over a multiplexing infrastructure requires users be licensed.

Don't be a piracy victim

It's easy to fall out of compliance with Oracle software licensing, especially if you're working with many Oracle products across distributed environments. The seven behaviors described here paint only part of the picture. Oracle makes it easy to goof up in a number of ways, and the company is happy to reap the benefits of your pain. Clearly, if your organization is running Oracle products, you should continuously monitor your entire Oracle estate across all platforms. Anything less could turn into an auditing nightmare and leave your organization owing astronomical licensing fees that you never suspected were on the horizon. And if that's not piracy, what is?

Next Steps

Showing Oracle you're in control is key to avoiding audits

Pay attention to support cost when purchasing an Oracle license

One report shows that Oracle's licensing policies lead to hostility

This was last published in December 2014

Dig Deeper on Oracle support services



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What are your biggest Oracle audit/licensing woes?
The biggest problems come from the changes that appear that relate to the licenses that I bought.  Licensing changes can be a major headache when it relates to updated definitions and databases or management software. I don’t want to assume definitions because I might affect my cost or compliance.
"One of the challenges is that Oracle supports only hardware partitioning, not software partitioning like you get with VMWare. As a result, you must license all processors and cores accessible to the Oracle product."

That is incorrect. Oracle indeed supports what is in the contract because when push comes to shove, it has no other choice. And the contract's processor-based licensing metric is processor-based, not server-based. Soft-partitioning on VMware is your contractual right.