Oracle

Oracle’s licensing rules: Five common pitfalls to watch out for

IT managers: Don't let your hard work be overshadowed by being caught out by Oracle's overly complex licensing rules.

Oracle’s range of databases and applications are excellent and a critical part of many organizations' IT infrastructures. While customers generally agree about the benefits of Oracle products and the value they add, they are less complimentary about the complexity of managing Oracle enterprise licenses.

Enterprise application licensing tends to be universally vague, but experts agree that the rules governing Oracle’s licensing agreements are perhaps the most complicated and difficult to grasp. This is because users are required to factor into license entitlement calculations hardware processing power, details of whether expensive management packs and options have been enabled and the numbers of users requiring access – both directly and indirectly. Being able to do this effectively requires ongoing license management.

Peter Björkman, CTO of Snow Software outlines some of the top problems users encounter as a result of not proactively managing their Oracle licensing entitlements. In virtually every scenario, the outcome equates to unforeseen (and often unnecessary) expenditure by the organization.

This comes in the form of additional licenses to be purchased either as a result of non-compliance, or because insufficient data exists to accurately negotiate a cost effective enterprise licensing agreement. And that is without considering the possibility of a penalty for non-compliance, which can easily reach millions of Pounds.

1. Insufficient visibility of management packs and options

A very common pitfall for organizations facing difficulties with their Oracle license management comes from not having the right options granted and management packs installed for their needs. When the Oracle enterprise database edition server is installed, by default all the enterprise options are installed too and it is important to know what you are actually using, and whether you need it.

There are two aspects to this, firstly you need to know what databases are installed and what editions they are i.e. standard or enterprise. Secondly, you need to know whether any management packs have been ‘accepted’ or options "granted," to use Oracle's terminology. Interpreting this incorrectly can significantly affect licensing costs from anywhere between $163,000 (£10,000) and $800,000 (£50,000) per processor, because options and management packs require additional licensing and should not be present if not needed as this rapidly adds to the total cost.

2. Not appreciating the rules of virtualization

When Oracle is run on virtualized servers, there are specific licensing rules to follow and non-compliance can very feasibly and conservatively generate a non-compliance penalty in the region of  5 million for a large enterprise.

Many organizations have viewed virtualization as a quick and easy way to deploy more Oracle databases without understanding the licensing rules. This has left them exposed to compliance costs, especially where organizations have virtualized Oracle databases using non-Oracle platforms. Oracle doesn’t support soft partitioning on VMware clusters, so it's important to have full visibility of exactly where Oracle is deployed in the estate and what the underlying virtual server architecture relates to.

A common scenario we uncover when working with customers is that the IT administrator installed Oracle database products on a virtual server, but failed to recognize the licensing impact of this action. They may have assumed that only the virtual server needed to be licensed, when in fact, they should have taken into account the underlying architecture of the physical servers. Or, in the case of a VMWare cluster, the whole cluster needs to be licensed for every physical server where the virtual server could potentially be running.

Small "oversights" like the one illustrated above can be very expensive mistakes to make – to the tune of millions of dollars in penalties. It's only really now that CIOs are uncovering the extent of any non-compliance with Oracle licensing rules, as they either renew their license agreements or respond to requests for an audit.

3. Project slippage creates unforeseen costs

The commercial risk of not proactively monitoring Oracle usage extends beyond the issue of compliance and penalties. A potentially far more expensive mistake to make, which has an impact outside of compliance and is related to purchasing license agreements, arises because of poorly calculated enterprise license agreements.

For many organizations, because they lack the data required to forecast current and future licensing requirements, they are forced into purchasing an unlimited license agreement (ULA) for a fixed time period. Here they end up over-paying for an "all you can eat" version, simply because they want to protect themselves from an audit. This "protection reflex" scenario can also arise because the user is embarking on a project to implement Oracle over an estimated time period, but subsequently finds that project timescales have slipped.

When a ULA is entered into, the organization is obliged to pay a fixed fee for licensing and support, on the basis of deploying a pre-specified number of users in a certain timeframe, regardless of whether those users are live or not.

For example, a company may be implementing Oracle and purchases a ULA for 12 months based on deploying a 100 processor license but actually only deploys 50 licenses before the contract expires because of project slippage. They still need those additional 50 licenses, and effectively end up paying for them twice. In monetary terms, this can mean spending an additional two thirds of the original ULA cost again, because the license was inefficiently managed.

Regardless of the circumstances for purchasing a ULA, experience has shown they are not for everyone and need careful management to ensure they deliver value for money. Otherwise, your Oracle license agreement could end up costing a lot more in real terms than if the organization purchased exactly what it needed. But to achieve the latter position, requires data and proactive license management. Ultimately, whether you choose a ULA or another form of Oracle license agreement, you need to know exactly what your needs are for it to be financially beneficial.

4. Not having a single window on Oracle assets

This is an issue for Oracle license management but is equally relevant for any other enterprise application. Traditional WINTEL environments of the past have been superseded by heterogeneous platforms combining Linux, Mac, Windows, virtualization and now, software as a service (SaaS) applications.

In the past, companies would have used an array of disparate software asset management tools to monitor usage in different environments. With Oracle database applications being so complex, working in this way leaves too much room for error as it becomes impossible to account for the interrelationships between these different environments and groups of users. It can be unclear where the responsibility for license compliance lays in such situations. What's needed is continuous monitoring of the entire Oracle estate across all platforms, with data aggregated to a single view on an ongoing basis.

5. Underestimating the difficulty of creating an Oracle Server Worksheet Report

Related to the issue of inaccurate data, another pitfall would be to underestimate the time required to gather licensing information for an Oracle audit. The vital piece of information required is an Oracle Server Worksheet Report (OSW). This provides an overview of the entire IT estate and shows what is installed and used, plus how many users are accessing the Oracle database servers. In addition it includes how they are partitioned, and what the processing power of the hardware is.

A common mistake users make is underestimating the time required to gather this information and compile the OSW. Without tools to automate the process, Oracle licensing specialists claim manually gathering this information can take up to four hours per server. In commercial terms, it means that when negotiations with Oracle commence, the user is in an unfavorable position, without the right data to back up their arguments. This scenario is true for both audit/compliance negotiations and for enterprise license renewals.

In the end, all these pitfalls return to the same fundamental issues – good data, a proactive mind-set and the need for continual monitoring. Even modest users of Oracle licensing can accrue huge commercial risk running from tens of thousands to millions of pounds to millions for not effectively managing their licensing agreements.

These costs may proportional to the size of organization but the impact of the risk is the same. Most IT directors are doing a fantastic job of keeping ahead of technology, ensuring their organizations get the value they need from IT and reducing its cost burden. It's a shame if that good work becomes overshadowed through being caught out by Oracle’s overly complex licensing rules.


8 comments
Elwood Diverse
Elwood Diverse

It would appear that IT Manager and possibly the CFO positions are made or broken by the decision to go with Oracle. From the opening bid: "How much does your company have?" to the final days: "There appears to be a license discrepancy", you put yourself into Oracle's hands.  

2lip
2lip

It seems as if these "licensing" pitfalls have been delibaretely concocted by Oracle to ensnare companies! I'm sure Larry Ellison is VERY proud of his bunch of overachieving lawyers! And his bank manager too!

As with Microsoft and other companies that exploit companies regarding licensing, I find it strange that CIO's have not teamed up to reverse the tide on this unethical practice by dictating acceptable terms to Oracle and the like in the form of a user group of sorts...


This coercion is successful because your data lives in the product, and the cost, effort and time required to remove it from there exceeds many demands that the software manufacturer may have regarding licensing costs and "penalties". This tactic is as old as the hills.

Better to not get involved with this lot from the outset! I'm sure one can find more accommodating terms elsewhere. Startups everywhere be VERY aware!

Rory Canavan
Rory Canavan

Also; check the T&Cs of your Oracle purchase have not altered vastly between the contract and the Ordering Document that ships with your most recent purchase.  The standard T&Cs are over-written by the newer T&Cs of the Ordering Document, and so previously granted rights may no longer be in play.

johnmalaney
johnmalaney

One option to control costs on development and implementation projects prior to go live can be the use of named user licences rather than CPU licences. this can allow the use of devlopment and test environments at a far lower cost than CPU licenses would require on the same hardware platform.

SnowSoftware
SnowSoftware

Hi IT Pixel that's a good point to raise. Apart from the Oracle/Microsoft press release, we haven’t yet seen any official documentation from Oracle stating new licensing rules in regards to Microsoft Hyper-V, however Oracle published the document “Licensing Oracle Software in the Cloud Computing Environment” outlining licensing/pricing in cloud solutions, including Microsoft’s Windows Azure platform. In this document Oracle describes how virtual processors in the Windows Azure platform (and other Cloud platforms) should be considered when licensing Oracle programs.

Have a look at the links below for more info:

Press release from Oracle:

https://blogs.oracle.com/cloud/entry/oracle_and_microsoft_join_forces

Licensing cloud platforms:

http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf

IT Pixel
IT Pixel

Could anybody clarify the new position regarding Oracle licensing on a Hyper-V host.  I know that Oracle and Microsoft recently struck an agreement so that Oracle is now supported on Hyper-V and can also be deployed on the Microsoft Cloud.  However, I have not seen a definitive article detailing how the software must be licensed on a local Hyper-V server with regard to virtual processors.  Do Oracle now permit this on the Microsoft virtual platform without the penalty associated with VMware hosting?

Piaras MacDonnell
Piaras MacDonnell

A few more pitfalls to be aware of :

* Not differentiating between "installed" verses  "in-use" products

* Options an Packs installed by Oracle to support another application (free) and installed by the user (cost)

* Not counting the total cores potentially available in a Virtual Host

* Calculating your core-factor incorrectly

* Unlimited License Agreement only ever applies to specific products

The list goes on.....


Editor's Picks