Interviewer: ULAs are a major licensing strategy for Oracle. How do you support clients dealing with these agreements?
Fredrik: We help companies evaluate, negotiate, and exit ULAs. These contracts sound simple, but the exit process is full of traps. You need to plan from day one.
Morten: We’ve supported more than 100 ULA certifications. Our team knows the patterns Oracle uses to push renewals. Our goal is to help clients certify cleanly and avoid getting locked in forever.
Interviewer: Oracle’s Unlimited License Agreement (ULA) sounds like a silver bullet for licensing. What is a ULA exactly?
Fredrik: A ULA is a contract where you pay a set fee up front, and for a fixed term – typically three years, sometimes up to five – you can deploy as much as you want of the specific Oracle products covered. It’s “all you can eat” for those products during that period.
Morten: It’s basically Oracle saying: give us a big sum now, and you don’t have to count licenses for those products for a few years. At the end of the term, you either stop and declare how many licenses you ended up using – that’s the certification – or you renew the ULA for another term. ULAs are Oracle’s way to lock in big customers with growing needs.
Interviewer: Why would a company sign a ULA? What’s the benefit for the customer?
Fredrik: If you expect your use of Oracle software to grow a lot, a ULA can be cost-effective. Instead of buying incrementally and possibly paying higher prices later, you pay once and can scale up freely. It also simplifies things during the term – you’re not constantly worrying about buying more licenses if a new project starts. For a fast-growing environment, it can provide cost predictability.
Morten: There’s also an appeal of simplicity. Companies in a ULA don’t have to count every processor or user for those products while the ULA is active. It can reduce the compliance headache temporarily. And sometimes, Oracle gives a ULA as a carrot – for example, after an audit, they might propose a ULA instead of paying a one-time fee, so the customer feels they’re getting future value.
Interviewer: And the downsides? What risks do ULAs carry?
Fredrik: The risk is that you’re locked in and might overpay if your usage doesn’t grow as much as you thought. If you sign a ULA for $10 million thinking you’ll deploy a ton of Oracle, but then your business changes and you don’t deploy that much, you just paid more than necessary. There’s no refund for underuse – you pay that big fee regardless.
Morten: Another downside is at the end of the ULA term. You have to go through certification, which means counting everything. If you mess that up or miss something, you could inadvertently certify fewer licenses than you actually need, leaving you short. Also, ULAs often have a clause that they are only for your company, so if you get acquired, the ULA might end right there, which is a huge risk. And because you’re unlimited during the term, some companies get complacent with tracking usage, which makes the end very stressful.
Interviewer: How should a company negotiate a ULA going in? What key points should be addressed up front?
Fredrik: First, scope of products – only include products you know you’ll need a lot of. Don’t let Oracle pack your ULA with products you might never use; you’d be paying support on all of them later. Keep it focused. Second, try to negotiate the certification process details: for example, ensure you have the right to certify and get your perpetual licenses without a lot of hurdles.
Morten: Also, negotiate the support cap or uplift. When the ULA ends, you’ll pay support on the licenses you certify. If you massively deploy, that can be a huge support bill. Some customers negotiate a cap on how much support can increase. And importantly, clarify any cloud usage rights during the ULA – if you plan to use, say, Oracle on AWS or another cloud, make sure the ULA allows it, or you could be in breach. Oracle likes to restrict ULAs to on-prem or Oracle Cloud use only unless otherwise stated. You need to get these terms clear in the contract before signing.
Interviewer: During a ULA term, what if you realize you need an Oracle product that isn’t included in your ULA?
Fredrik: Then you have a problem. The ULA only covers the specific products listed in the contract. If you suddenly need a different Oracle product, you can’t just use it under the ULA. You’d have to either purchase that product’s licenses separately or try to amend your ULA with Oracle – and they’ll charge you for it.
Morten: We’ve seen this. A customer in a ULA wanted to deploy a new Oracle software that wasn’t covered. Oracle treated it as a separate sale. Sometimes Oracle might update the ULA to include it, but they’ll ask for more money, effectively a mid-term ULA expansion. It’s a reminder to include everything you might need in the ULA upfront, because mid-term additions are expensive and not guaranteed.
Interviewer: Let’s talk about the end of a ULA. What happens when the term is up?
Fredrik: You have a choice: renew the ULA, or exit it by “certifying.” Certification means you take a snapshot of all your deployments of the ULA products at the end date. Oracle will then give you perpetual licenses equal to those counts. After that, you’re no longer unlimited – you just own whatever number you certified.
Morten: If you choose to renew instead, you basically start a new term (often with additional cost, maybe including more products or a higher price if your usage grew). The key is, by the end of the term you must inform Oracle what you want to do – either you negotiate a renewal, or you tell them you intend to certify and exit the ULA.
Interviewer: What is the certification process like? Is Oracle involved heavily in that?
Fredrik: During certification, Oracle will usually send you a questionnaire or have their audit/licensing team work with you to verify your deployment numbers. Lately, they’ve been sending out a very detailed questionnaire – dozens of questions asking for deployment data, environments, even things beyond what the contract requires.
Morten: It’s almost like an audit. Oracle’s license team will scrutinize what you report. You are contractually required to give a number of licenses deployed for each product – but Oracle might ask for extra info like server details, usage of features, etc. We advise companies to be very careful here: only give Oracle exactly what the contract says you must. They have no contractual right to demand detailed architecture diagrams or how you plan to use the licenses going forward, but they will try. The process can be nerve-wracking because you’re essentially proving you’re compliant at the end of the ULA.
Interviewer: Does Oracle make the certification easy for customers?
Fredrik: Honestly, no. Oracle has no incentive to make it easy. Think about it: if you certify, you stop paying those big ULA fees and just keep your licenses. If you renew, you pay Oracle a lot more money. So Oracle would prefer you to renew.
Morten: We’ve seen Oracle do things that feel like traps – like that long certification questionnaire that goes way beyond anything in the contract. If you fill it out completely, you might accidentally reveal some deployment that’s outside the ULA scope or a usage in a way that Oracle then questions. Oracle’s auditors will use any info they get. They’re basically hoping to find something that scares you into extending the ULA. It’s a bit of a game.
Interviewer: What if a company undercounts during certification? Can that come back to bite them?
Fredrik: Yes, if you certify fewer licenses than you actually use, then the day after certification, you are technically under-licensed. Oracle could audit you and say, “hey, you only certified 100 of Product X but you have 120 installed.” Then you’d have a compliance problem right after your ULA.
Morten: That’s why the end of a ULA is so critical. You have to thoroughly inventory everything. We sometimes find clients forgot about some DR (disaster recovery) environments or test instances. If those aren’t counted and certified, they become unlicensed installations after the ULA. Oracle can and will pursue that. There’s no forgiveness just because you had an unlimited deal – once it’s over, it’s over, and you live with whatever number you locked in.
Interviewer: Could Oracle audit a company shortly after a ULA ends?
Fredrik: It’s possible. If Oracle suspects you didn’t report everything, they might. Or if, during certification, they saw hints that something was off but you insisted on certifying your counts, they may initiate a formal audit later to catch any omissions. We consider the certification itself as a kind of audit in disguise. Oracle sometimes says, “we reserve the right to verify your counts.” So yes, post-ULA audits happen, especially if the relationship soured during the exit.
Morten: Again, it comes down to Oracle’s incentive. They’d love to find that you didn’t capture all deployments, because then they can hit you with a license claim or push you back into some sort of unlimited or large purchase. It’s cynical, but that’s the dynamic.
Interviewer: Under what circumstances does it make sense to renew a ULA instead of certifying out?
Fredrik: If your Oracle usage is still growing rapidly and you foresee a lot more deployment in the next few years, renewing can make sense. Also, if new projects are coming that would need expensive licenses, staying unlimited a bit longer could be beneficial. Some companies also renew because they failed to prepare for exit – they don’t have confidence in their internal counts, so they renew to buy time (which is what Oracle counts on).
Morten: Another scenario is if Oracle offers some tempting additions on renewal – for instance, including additional products or some cloud credits. We’ve seen Oracle try to sweeten a ULA renewal by adding, say, a new cloud service to the bundle because they want to drive cloud adoption. But remember, renewal means another big check to Oracle. You have to weigh that against the alternative of walking away with the licenses you have.
Interviewer: What are the drawbacks of renewing a ULA?
Fredrik: The obvious one is you keep paying Oracle a lot of money. You continue to be tied to them with an unlimited promise that might outlive its usefulness. Also, every time you renew, it’s usually at a higher price or with more products – so your support costs go up too because you eventually will certify a higher number of licenses.
Morten: And strategically, you’re delaying the inevitable. Unless you plan to be on a ULA forever (which some do, essentially), you will have to exit at some point. The longer you stay, the more entangled you get. It’s like a golden cage – comfortable, but still a cage. Another drawback: if you renew without addressing issues, you might carry forward compliance problems. For example, if there was ambiguity about some product not in the ULA that you were using, renewing the ULA doesn’t fix that; it just kicks the can down the road.
Interviewer: How can a customer maximize the value of an unlimited agreement before it expires?
Fredrik: They should deploy the covered products as widely as makes sense for their business. Since you can install without incremental cost during the term, it’s smart to fully utilize that. Some companies will push as much Oracle software out as possible – obviously within reason – to ensure they end up with a high count of licenses at certification.
Morten: Exactly. If you know you’ll need certain deployments in the future, get them out there while you’re unlimited. Also, do a thorough sweep of your environment for any and all usage. You don’t want to miss something and under-report. The idea is to come out of the ULA with the maximum number of perpetual licenses. Just be careful to stay within genuine usage; artificially pumping up usage in ways that provide no business value could raise eyebrows during certification. But definitely take full advantage of the “all-you-can-use” period.
Interviewer: We’ve heard of an Oracle “Perpetual ULA” or PULA. What is that?
Fredrik: A Perpetual ULA, or PULA, is like a never-ending ULA. Instead of a 3-year term, it’s unlimited use of certain products with no expiration date. In theory, you pay a massive amount once, and then you have unlimited rights for those products forever.
Morten: It’s basically buying out an unlimited license. You still pay annual support on whatever value they attribute to the deal, but you don’t have to certify or renew – it’s perpetual rights. Oracle usually only offers a PULA to very large customers who might otherwise leave or do something drastic. It’s extremely expensive upfront, but it gives certainty of use forever (at least for the versions covered).
Interviewer: How is a PULA different from a normal ULA beyond the term?
Fredrik: The key difference is no end date, so no certification process. Once you sign a PULA, you have those unlimited usage rights going forward. You still need to stay compliant with any terms, but there’s no countdown clock.
Morten: However, you might still have conditions, like which legal entities can use it or which products exactly are covered. And usually the support fees on a PULA are huge because Oracle calculates it based on an enormous license value. One other thing – you often can’t include cloud usage unless specified, similar to ULAs. PULAs are typically for on-prem use, unless Oracle explicitly allows cloud.
Interviewer: Is a PULA a good deal for customers? It sounds convenient.
Fredrik: It can be, if a company knows it will be using Oracle’s software at a large scale indefinitely. It gives peace of mind – no more audits for those products, no more negotiations every few years. But the cost is so high that it’s really only justifiable for the largest enterprises.
Morten: Also, with a PULA you are basically married to Oracle for life for that technology. There’s a psychological shift – since you have unlimited use, you might never consider alternatives, even if in the future non-Oracle solutions become better or cheaper. You’ve sunk millions or tens of millions in, and you’re paying support forever. In that sense, it’s the ultimate lock-in.
Interviewer: Do we see many customers opting for a Perpetual ULA?
Fredrik: They are rare. We see them mostly when Oracle uses it as part of a settlement or a strategic deal – like if a client was thinking of leaving Oracle or got acquired by a company that standardizes on Oracle, they might do a PULA to sort of buy insurance. The average Oracle customer would never even be offered a PULA.
Morten: Yes, typically it’s the top tier. Or if a company’s ULA has been renewed multiple times and Oracle figures they can convert it to a PULA for a lump sum now. It’s a tactic to monetize the relationship long-term. But ULAs (term-based) are far more common than PULAs.
Interviewer: Oracle also has something called a “Pool of Funds” agreement. What is that?
Fredrik: A Pool of Funds is kind of like a flex spending account for Oracle licenses. Instead of unlimited usage, you commit a certain amount of money to Oracle, and over a period (say 2-3 years) you can allocate that money to licenses for different Oracle products as you need them.
Morten: Think of it as pre-paying for licenses without deciding exactly which ones upfront. Oracle gives you a big discount because you’re paying in advance. Then you “burn down” your pool as you order licenses over time. It’s not unlimited – you have a cap in money that you can spend on licenses – but you have flexibility on which products you consume under that cap.
Interviewer: Why would Oracle push a Pool of Funds deal? What’s in it for them?
Fredrik: Oracle loves upfront money. With Pool of Funds, they get cash now, rather than piecemeal over a few years. It also locks the customer in – you’ve given them say $5 million in advance; you’re going to be buying Oracle products with that, not a competitor’s product. So Oracle secures the customer’s commitment.
Morten: Also, if the customer doesn’t use the full amount by the end of the term, guess what – Oracle usually keeps the difference. There are cases where companies didn’t consume all their Pool of Funds and basically donated the remainder to Oracle. So Oracle wins either way: they either get all your money used on their licenses or they get free money for nothing at the end.
Interviewer: What are the risks or downsides for a customer with a Pool of Funds agreement?
Fredrik: One risk is overestimating your needs. If you overcommit funds and can’t use all those licenses, you lose the unused value when it expires. Another is the reporting requirement – typically you have to periodically report what you’ve deployed from the pool. If you don’t, you could be out of compliance or even forfeit some rights.
Morten: It also doesn’t cover unlimited growth. If you consume your pool early because you needed a lot of licenses, you might have to go back to Oracle and spend more anyway. And all licenses you do pull from the pool get added under one support contract often, subject to Oracle’s repricing rules. So after the pool term, you might face a big support bill on everything you allocated. It can be complex to manage and requires good forecasting on the customer’s part.
Interviewer: Which do you think is riskier for customers: signing a ULA or doing a Pool of Funds?
Fredrik: Both have risks, but in different ways. A ULA carries the risk of the end-of-term trap – you need to utilize it fully and exit correctly, or you might lose out. Pool of Funds carries the risk of unused value – essentially giving Oracle free money – and the complexity of planning exactly what to spend it on.
Morten: ULAs at least guarantee you can deploy a lot if you need. Pool of Funds guarantees you a discount but not unlimited use. I’d say Pool of Funds can be higher risk if a customer is unsure of their needs, because miscalculating means wasted budget. With a ULA, miscalculating (i.e., not growing enough) means you overpaid, which is also wasted budget. Oracle typically wins in both scenarios unless the customer is very strategic.
Interviewer: Can companies negotiate these agreements to be safer?
Fredrik: Yes, for ULAs you can negotiate clarity on the certification and maybe include certain explicit rights (like including disaster recovery servers clearly, or allowing cloud deployment). You might also negotiate a shorter term if you’re uncertain – Oracle sometimes does 1-year ULAs called “Simple ULAs” or so as trial.
Morten: For Pool of Funds, negotiate the terms of the reports, and perhaps a clause to carry over some unused funds or convert them to cloud credits or something at the end. Try to include as broad a range of products as possible in the eligible pool so you have flexibility. Also, negotiate the discount rate strongly; since you’re paying upfront, you should get a steep discount.
Interviewer: What should a company do before signing a ULA or Pool of Funds?
Fredrik: Do a full assessment of your current and projected Oracle usage. You need to have a very clear picture of how many licenses you actually use now and what you’ll likely need in the future. Without that, you’re flying blind.
Morten: Also, get independent advice if you can. Oracle will pitch these as great solutions, but you need someone to help you see the fine print and the traps. Understand the exit strategy from day one. For a ULA, plan how you’ll manage it and exit it even before you sign it. For a Pool of Funds, plan how you will allocate it and track it to maximize use. In short – go in with eyes open and a plan.
Interviewer: ULAs are “unlimited,” but are there hidden restrictions in these unlimited agreements?
Fredrik: Yes, “unlimited” applies only to the specific products listed and for the entities listed. If your ULA says it covers Oracle Database Enterprise Edition and a couple of options, you can’t suddenly use it for WebLogic or some other product not in the list. Also, geography or entities can be a limit – maybe it’s only your company and not subsidiaries, unless they’re explicitly included.
Morten: Another one is cloud use. Many older ULAs didn’t allow deployment on AWS or Azure without approval, effectively pushing you to only deploy on your own data centers or Oracle’s cloud. So unlimited had an asterisk: unlimited in certain environments. If you deployed in an unapproved way, Oracle could say those deployments aren’t covered. So it’s critical to know those boundaries. Unlimited doesn’t mean you can do anything you want with Oracle software; it’s unlimited within the defined scope.
Interviewer: What if a company is acquired or merges with another during a ULA?
Fredrik: Most ULA contracts have a clause that a change of control (like being acquired) terminates the ULA unless Oracle agrees otherwise. That means if your company gets bought, the ULA could end right away, and you’d have to certify immediately or the unlimited rights cease. That’s a big gotcha.
Morten: If you acquire another company, typically their usage isn’t covered by your ULA unless you bring them into the ULA contract and Oracle approves it. We’ve seen companies buy a firm and then realize they need to license all of that firm’s Oracle usage because the ULA didn’t automatically cover it. So M&A events are tricky. Ideally, if you anticipate being acquired, you might avoid a ULA or get Oracle to explicitly allow transfer. But Oracle usually wants a fresh negotiation if there’s an acquisition.
Interviewer: Ultimately, what is Oracle’s goal with these ULAs and deals from your perspective?
Fredrik: Lock-in and revenue. Oracle wants to secure your commitment and make sure you continue paying them. A ULA locks you in for that term and usually beyond, because once you have tons of Oracle everywhere, it’s hard to switch out. And when it ends, they either get a renewal or you freeze with a huge support stream for them.
Morten: Right. Oracle’s goal is to maximize the money you commit while minimizing your chance to escape. ULAs, PULAs, Pools of Funds – they all serve that strategy. They’re not offering these out of generosity; it’s calculated. The customer can benefit, but you have to be very savvy to turn these agreements to your advantage.
