Introduction

Oracle customers who find themselves in certain precarious situations relative to their Oracle licensing often find that the cure-all salve from Oracle is the offer of a ULA (alternately referred to as either an Unlimited License Agreement or Unlimited License Amendment). As with most offers from Oracle, they package a ULA to look very appealing, especially given the inherent worry that the customer might have of being otherwise out of compliance and facing a huge unbudgeted license shortfall. Situations where Oracle seems to offer ULAs to customers include:

• In resolution of a claimed dramatic shortfall of license entitlement in an audit (even though this claimed shortfall may have in fact been a non-contractual contrivance on Oracle’s part)
• To facilitate a platform or cloud migration where the possibility of dual-site licensing may be expected
• In organizational restructuring, such as mergers, acquisitions, or divestitures

House of Brick has deep experience with evaluating ULA proposals from Oracle in each of these use cases, as well as others, and have learned to decipher the core value tradeoffs for our customers. While there are certain scenarios where choosing a ULA can be an overall benefit to the customer, in our experience those scenarios are not frequent. In a preponderance of customer engagements, we have found that choosing a ULA from Oracle led to dramatically high expenses in the short-term, and an unnecessarily high annual support stream ongoing that cannot be reduced.

Frequently asked questions

We have compiled a list of frequently asked questions and concerns about Oracle ULAs that will be addressed below. Of course, the answers may vary for you if your agreement with Oracle is different from our experience, or if they insert unique terms and conditions. If you ever have specific concerns about whether a ULA is right for your organization, please reach out to us. We would be happy to discuss your situation with you.

What is an Oracle ULA?

An unlimited license agreement from Oracle is just that – the ability to deploy an unlimited quantity of specified software. ULAs generally have a specified term, usually three years, after which the customer will need to either negotiate a new ULA or exit the ULA by “certifying” the then-current usage.

How are ULA costs calculated?

We have not deciphered the precise formula for calculating the proposed ULA fees, if there is one. In general, it seems that Oracle will propose charging an amount about 50% to 70% lower than the claimed or anticipated license deficiency, and that will result in at least a 100% increase on the current support payments being made. Oracle hopes (and many times this hope is realized) that customers will view the proposal as a dramatic reduction in what they should have had to pay, and eagerly accept the offer.

The diagram below illustrates how the current support payments, and the one-time ULA fee combine into the total cost of a ULA. In this example, the customer who is paying $1M in annual support, now has to pay a one-time fee of $5M, and an ongoing support fee of $2.1M per year with 8% annual increases (the annual fee may remain flat during the ULA, with annual increases added after ULA exit).

Are these take-it-or-leave-it offers?

Since ULA proposals are typically made in an environment of urgency (audit resolution, etc.), Oracle exerts extreme pressure on customers to agree to the deal within a very tight window of time. The Oracle sales representative may claim that if they do not agree before a deadline (conveniently aligned to Oracle quarter-ends) that the wonderful offer they are making will expire, and the customer will face the full cost of their non-compliance. This pressure to make a summary decision prevents the customer from fully evaluating all of the nuances and cost implications that the ULA entails. Our experience is that these offers remain, even after one or more quarters of deliberation.

Does a ULA mean I can use any Oracle product?

No, it does not. In every ULA, there is a section that defines the “Unlimited Deployment Right Products.”  This list likely (but not necessarily) includes Enterprise Edition Database, and some number of applicable database options and/or management packs. The list may also include non-database products such as WebLogic Suite.

In some ULAs there is another section for “Limited Quantity Licenses.” Just as the name implies, only the listed number of licenses may be used. Any other product that is not listed on either the unlimited or limited quantity lists cannot be used under this agreement.

What happens to all my perpetual licenses that I purchased before the ULA?

They are gone. The ULA process cancels all previous licenses, as well as their terms and conditions of use, and subsumes them into the unlimited agreement/amendment. Even when exiting the ULA, those licenses in their previous form and metrics do not come back.

Are there risks in having a ULA?

Yes. The first risk is entering into the ULA in the first place and paying the exorbitantly escalated fees. The most frequent risks we encounter during a ULA are in the lack of governance of software deployment and usage. If, for example, the ULA did not contain a right to Oracle Advanced Security Option, but the customer assumed that the ULA covered it, then there will be a large compliance issue and fees to deal with. Oracle will happily add Advanced Security to the ULA, but there will be a new one-time fee, and a corresponding 22% increase in the annual support payments. The risks at the end of the ULA are that not all usage is reported, calculating cloud usage is insufficient, or that future license growth is not anticipated and accounted for.

Can I use a ULA to cover Oracle in a public cloud?

Yes. The ULA covers public cloud environments for the unlimited deployment products. In general, there is no restriction on using an Oracle Authorized Cloud Provider. This means that even though the Google Cloud is not authorized by Oracle to count vCPU licensing, it may be used to deploy Oracle software with a ULA. Counting cloud usage on ULA-exit is a bit more complex and will be addressed below.

What about a PULA?

A PULA is a Perpetual ULA, or a ULA that does not have a defined term and end date. The up-front cost will be higher, but there is no need to certify or renew. The customer simply pays the annual support cost with 8% (as of most recent uplifts) per year increases. Some larger customers stay on a PULA indefinitely, but others have gotten to the point of wanting to exit the PULA.

What happens at the end of a ULA term?

You have a choice. You can either negotiate a new ULA or exit the ULA by “certifying” your current usage. By default, the ULA will end, and the customer will need to certify usage within 30 days. Once certification is complete, Oracle will issue new Processor metric licenses to cover all of the certified current usage.

The Oracle sales team will be promoting a renewal of the ULA. Oracle will attempt to assess your current Oracle deployments and will likely propose a higher-prices ULA, with the possibility of additional unlimited-use products. If the ULA is renewed, the customer will follow the same process as the diagram above, only with the new elevated support amount as the input. Continually renewing becomes an ever-increasing spiral of cost escalation.

What is involved in certifying off a ULA?

The certification process is typically included in section C.1.b of your ULA agreement document. It states that within 30 days of the ULA term ending, the customer must certify where the unlimited deployment right products are “installed AND running” (emphasis added). For those familiar with the standard license definitions, a license is required for all Oracle software that is “installed and/or running.” For a ULA, the “or” is removed. What this means is that you can only count Oracle software that is actually running on a physical, virtual, or cloud server, and may not count instances that are installed on servers, but where the software is not actually running. If a customer has a lot of quiesced Oracle instances (installed but not running), these will immediately be out of compliance after the certification.

It is obviously in your best interest to obtain as many Processor licenses as possible as a result of this certification process.

Can I count cloud usage in the certification?

You will need to check the language of your particular ULA. Until a few years ago, Oracle said that no cloud usage could be counted. More recently, they say that cloud usage may be counted, but only as a running daily average of the past 6 or 12 months. This sounds better, and it is, but there are risks associated with this. If you have made a new cloud deployment in the past 3 months before certification, for example, then your average daily usage may only be 25% of the licenses you actually need. Another risk that needs to be evaluated is whether the ULA restricts cloud certified licenses to only that cloud environment, thus limiting license portability.

What if I am using my ULA in a non-authorized public cloud?

This situation presents an interesting opportunity for users of Google, IBM, Alibaba, or other non-authorized (AWS & Azure) public cloud environments. You will need to check your particular ULA document, but it may contain language that lets you certify cloud usage as long as that cloud supports virtual CPUs and a designation of hyperthreading on or off. In this case, the customer can count vCPUs in the Google Cloud, for example, and continue to use vCPU licensing after ULA certification, even though there is no other public authorization for you to do so. Again, these licenses will likely be restricted to that particular cloud, but it opens a door to elastic cloud usage in the non-authorized clouds that was not available before.

Can I reduce the amount of annual support that I am paying if my usage goes down?

No. The annual Total Support Stream is established when you execute the ULA document. If your usage goes down during or after the ULA that annual support amount will not go down. In fact, it will continue to go up by 8% per year. The only way to reduce this payment is to purchase new perpetual licenses, and terminate support on all post-ULA licenses.

Should I expect an audit during a ULA?

No. But you should expect one following a ULA exit. Monitoring for software usage and license compliance, both during and after a ULA, is critical to managing risk.

Conclusion

In general, ULAs from Oracle are unnecessarily expensive. The customer would be better off to slow down and consider the alternatives. If you are already in a ULA, you are probably thinking about how to exit. There are a few things to consider when doing your exit planning:

1. Be sure you know all the Oracle software you are running, and if you have any usage outside of the ULA prescribed software list.
2. Be sure you have enough post-ULA licenses to cover your cloud usage.
3. Do some growth projections to determine how many licenses you will need in the future, and plan accordingly.
4. Prepare for an audit – there should be no surprises.

House of Brick has helped thousands of customers and defended hundreds of Oracle audits. Our software and services solutions will monitor your environment for compliance, alert to risky usage conditions, and model future-state environments that optimize licenses while reducing costs. If you feel like a ULA is your only option, talk to us first. We can help you evaluate your options and recommend the path that will be best for you. If you already have an ULA and want to maximize your return on certification, we can help with that too.