The traps and pitfalls of Oracle’s ULAs
What is a ULA?
A ULA is an agreed contract between Oracle and an organisation. The organisation is charged one, up-front fee which pays for licenses on an unlimited basis, covering a selected set of Oracle products, and lasts for a fixed period. A typical ULA term is three years.
However, Oracle will use any angle in order to get you to extend your ULA. Being in a ULA allows Oracle to lock you into their contract, and regularly stack up your support costs at each renewal. But ULAs also come with a number of additional ‘convenient’ traps – convenient for Oracle, at least – for organisations to innocently fall into.
Here’s what to watch out for:
The Top 5 ULA “Gotchas”
1. Pay attention to your deployment/asset management discipline
It’s common for organisations to have Oracle products on their agreement that were purchased on a fixed quantity basis (e.g. a set number of licenses), as well as products on an unlimited basis.
What you need to watch out for is your teams assuming everything is unlimited, and then deploying the fixed licenses without counting them. The final result is the organisation could easily be left noncompliant.
Should Oracle then appear, to audit your estate, they’ll find the limited products which have been over-deployed. It then essentially comes down to: “You’ve deployed these but didn’t have the rights through the ULA”. Oracle will advise a true-up figure, as an extension to your ULA, in order to bring the other products in.
Their true-up figure will not come cheap. We consider this to be Oracle’s favourite trick.
So, you need to be aware of your estate and your agreement with Oracle. Be sure not to deploy anything as unlimited, which you own on a limited basis.
2. Pay attention to the entities and geographies you’re going to deploy
When you signed up to Oracle’s ULA, you’ll have declared which entities (organisations) and sometimes regions you’ll be deploying to. If, however, you assume you can use licenses for an entity which isn’t named on the contract – like a UK-based company believing that they can use the ULA to cover a subsidiary in the US – that’s noncompliant with the terms of your contract, and you will not be covered.
Sooner or later along come Oracle, with ULA extensions and bills!
Again, it’s a matter of knowing your estate. Understand which geographies and entities you’re licenced for and ensure that you and your teams only deploy to those.
3. Don’t leave it until the last minute
Leaving, or “certifying out” of a ULA isn’t necessarily a complex process, but it is vital that you get it right. If you don’t finish the certification process correctly, and on time, Oracle will have you pay for another extension. Another three years (or however long) of paying for your ULA.
If you’re in the last 12 months of your ULA, we recommend you start planning right now. You need to be reviewing deployment and using asset management tools. Consider any outstanding projects, and the Oracle products/licences you need in order to complete them.
If any project completion is due to fall outside the ULA, bring it forwards. It’s better to review and revise project plans, than pay huge sums to extend ULA agreements.
That way, you can be ready on time and maximise the full use of your grant in the ULA period. We maintain that you should be escaping your ULA; but, as you’re paying for it, you might as well make the most of it while it lasts.
4. Manage certification yourself
Oracle may offer to come in and complete the certification process for you. “They’ll provide and ask you to run a series of ‘scripts’, SQL commands which will catalogue your estate, detailing which products you are using and how many licenses of each are deployed. And when the scripts are done, you send the output back to Oracle, for them to turn into meaningful information.
It sounds like a good deal; they take care of the certification process, freeing up your time elsewhere. But even so, we strongly recommend that you remain in charge of the process. You need to be transparent, and compliant with your licence grant. You need to thoroughly manage your own tools, use the resources that are available to you, make sure you’ve got independent Oracle experts looking at your contracts and installs.
Then, when you share your information with Oracle, you know it’s correct, and you’re still in control. Better that, than letting Oracle take over and going along with whatever they say. They want you in the ULA – there’s little more to it than that.
We have seen Oracle use these scripts on customers’ estates many times. They use the output from these to come back and present the license position to the customer. In a large number of cases, the facts they present are wrong.
Do not fall into this trap.
Even if you agree to what they say and pay a fine, Oracle will never state that you are compliant. They might say that you are compliant at that moment, but they will reserve the right to come back at any time and revise their view. Making sure that you know how your licenses are deployed means that you can challenge any view Oracle has, and if you need to purchase more licenses, make sure you only pay for what you are actually using.
5. Beware of the independence of Oracle SAM companies
And finally, if Oracle themselves don’t offer to help, there are always Oracle SAM (Software Asset Management) companies that can offer help with the certification count. If you use one of these companies, you must ask if they are an Oracle partner – because if they are, are they truly independent? Or are they too finding ways to sell you more licences?
We suggest you approach a fully independent company to help with certification, who provide expertise, and complete impartiality.
How to escape your ULA
The ‘Top 5 Gotchas’ come down to a few, key pieces of advice: be aware of your estate, leave nothing to the last minute, and stay in control. It’ll help save you from any additional problems until your ULA period is over.
And even then, Oracle will still want you to keep your ULA. That’s why we’ve written a guide to help you escape: