Oracle Audit Risks
Oracle maintains what I consider to be the most aggressive audit program of any major software publisher. Its licensing rules can be extremely difficult to understand, and they frequently are not clearly stated in the applicable license agreements. Moreover, Oracle’s License Management Services (LMS) team typically is unforgiving when it comes time to apply those rules, and it often uses Oracle’s ambiguous license terms and confusingly constructed contracts to prepare audit findings that can cause heart palpitations for business owners.
Companies that have been audited by Oracle can (and sometimes do) attest to its distinctiveness in this regard. Among other publishers, Microsoft is similarly inflexible in the application of its license rules, but those rules generally are more clearly stated and accessible for software asset management teams. Conversely, IBM’s licensing rules can be even more byzantine than Oracle’s, but my experience is that it often is more willing to work toward a fairer compromise when an audited company can point to mitigating factors that resulted in audit shortfalls. In contrast, Oracle really does seem to be unique in insisting on rigid and uncompromising application of unreasonably complex licensing rules and metrics.
Oracle’s audit practice also is noteworthy for the fact that it usually conducts all of its audit in-house, through LMS. By contrast, Microsoft, IBM and many other publishers often work with officially impartial, third-party accounting firms, such as Deloitte, KPMG, PwC and E&Y, to conduct their reviews. Participation of such external fact-finders typically affords a better opportunity to provide meaningful clarification and comment before the publishers receive the audit findings.
Given those facts, business and IT leaders of companies that have invested in any quantity of Oracle software products need to pay special attention to their usage of those products, and they also need to be mindful of what to expect when Oracle eventually pulls their number eventually for an audit by LMS. Here are some of the most important audit risks to keep in mind when using Oracle products:
Tread Carefully When Virtualizing – Oracle’s requirements when using its products in virtualized environments can be daunting, depending on the hardware where the Oracle solutions are to be deployed. Oracle allows its licensees to us “Hard Partitioning” to limit the number of software licenses required for a server or a cluster of servers. However, while Hard Partitioning may mean different things to different IT administrators, it means a set of specific requirements for Oracle, all of which must be carefully controlled in order to avoid unpleasant licensing surprises. In particular, Oracle does not recognize any VMware technology as a satisfactory “Hard Partitioning” technology, even though VMware is a recognized market leader for virtualization solutions.
Here are the requirements set forth in Oracle’s current Partitioning Policy:
- You must use Oracle-approved technologies to hard-partition your servers. Those technologies currently include the following:
- Physical Domains (also known as PDomains, Dynamic Domains, or Dynamic System Domains),
- IBM’s LPAR (adds DLPAR with AIX 5.2),
- IBM’s Micro-Partitions (capped partitions only),
- vPar,
- nPar,
- Integrity Virtual Machine (capped partitions only),
- Secure Resource Partitions (capped partitions only),
- Fujitsu’s PPAR,
- Solaris Zones (also known as Solaris Containers, capped Zones/Containers only) (provided additional requirements are satisfied), and
- Oracle VM Server (provided additional requirements are satisfied)
- If the software is to be deployed on certain Oracle Engineered Systems, then the licensee needs to use Oracle VM Server and Oracle Enterprise Manager (OEM) to set up and report on “Trusted Partitions” where the software will be running. OEM can be deployed in either “Connected” or “Disconnected” mode: in the former, OEM reports on software usage directly to My Oracle Support, while in the latter the licensee is required to generate quarterly usage reports and to retain those reports for at least two years.
- In every case where an Oracle technology is to be used as a Hard Partitioning technology, it is necessary to follow Oracle’s technical instructions for the use of that technology:
Failure to adhere to Oracle’s requirements can result in the virtualized environment being licensed for installed Oracle products based on all physical cores used to support the infrastructure, even if there is only one VM running the product on a single host in a virtualization cluster. Never mind the fact that this effective prohibition on the use of VMware with Oracle products may not be mentioned anywhere in the applicable license agreements or in any document incorporated in those agreements. In effect, LMS merely applies the assumption that since VMware makes it so easy for VMs to migrate to other hosts, the processors on those hosts must be licensed for the Oracle software.
Know What is Installed and Running – Another favorite tactic is to surprise customers with licensing fees associated with product options that the company never actually used. Many Oracle products – such as its ubiquitous Database software – are deployed from installation files that include a catalog of added-cost options and packs. Those options sometimes inadvertently may be enabled during the installation process or at some point thereafter and then turned off without ever having been used. However, the software’s usage logs record the enabling of the options, and that log data often is among the information demanded by LMS during an audit. If LMS determines that the options were enabled at any time – even if only once, seven years or more before the audit data were collected – it is common for those options to be included among the audit findings.
Companies using Oracle Database products therefore are well-advised to work with knowledgeable consultants when setting up their systems, to ensure that only those product features licensed and intended to be used are enabled on the company’s computers. To the extent that Oracle products have been running in the environment for some time, it may be worthwhile to undertake an initiative to confirm what is currently enabled and what the logging date say about the options that may have been enabled in the past.
Know How to Scan – Finally, Oracle audits also are noteworthy for the limited set of tools that LMS will accept as sources of audit data. The auditors’ first choice is always a set of proprietary LMS scripts and other tools that it will make available to the company at the outset of the review. However, those tools do not generate outputs in a format that is easy for anyone other than Oracle to review, so companies that use them may not know what they are telling LMS about the environment. We typically do not recommend that our clients share any deployment information with any auditor without first reviewing that information internally for accuracy and completeness.
Fortunately, LMS also accepts outputs from a limited number of third-party tool providers, as follows:
However, the tools published by those vendors typically are not free for larger organizations to use. Furthermore, even though they may gather information that LMS is willing to accept, they may not gather all of the information that LMS says it requires to complete an audit.
Therefore, it is a wise practice for companies using Oracle products to consider engaging and periodically working with a knowledgeable, third-party Oracle licensing consultant as a necessary cost of business for using Oracle’s products. Many consultants have experience working within LMS, and they typically can provide insights regarding the best tools and methodologies for staying on top of how many Oracle products require licensing within an environment.
