Oracle ULA customer? Beware these five traps

What is a ULA?

An Oracle ULA (Unlimited Licence Agreement) is an agreed contract between Oracle and an organisation. The organisation is charged one up-front fee which pays for licences 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 “convenient” additions – convenient for Oracle, at least – for organisations to innocently fall for.

The Top 5 ULA traps to look out for

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 licences), 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 licences without counting them. The organisation could easily be left non-compliant.

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 be small. 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 that 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 non-compliant with the terms of your contract and you won’t be covered.

Sooner or later, along come Oracle with ULA extensions and fines!

Again, it’s a matter of knowing your estate. Understand which geographies and entities you’re licensed 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. That’s 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 licences 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 licence 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 licences are deployed means that you can challenge any view Oracle has, and if you need to purchase more licences, 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 – are they truly independent, or are they trying to find 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

When it comes to ULAs, we have three 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:

[ivory-search id="29433" title="Default Search Form"]