A Guide to Oracle License Audits .pdf
Original filename: A_Guide_to_Oracle_License_Audits.pdf
Title: Microsoft Word - Article A Guide to Oracle License Audits.docx
This PDF 1.7 document has been generated by Word / Mac OS X 10.12.3 Quartz PDFContext, and has been sent on pdf-archive.com on 23/03/2017 at 15:10, from IP address 158.58.x.x.
The current document download page has been viewed 406 times.
File size: 41 KB (4 pages).
Privacy: public file
Download original PDF file
A Guide to Oracle License Audits
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. 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.
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.
Oracle License Inventory
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.
Oracle License Metrics
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.
Oracle Partitioning Policy with VMWare
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.
Oracle Disaster Recover Licensing Misuse
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
Oracle ULA Problems
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.
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.
Oracle License Audit
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 nine pitfalls described here in
this Oracle Infographic 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?