Oracle Unlimited License Agreement FAQs
Q1: What is an Oracle ULA?
A: An Oracle Unlimited License Agreement (ULA) is a contract in which Oracle grants an organization the right to deploy an unlimited number of licenses for specific Oracle products over a fixed term (usually around 3 years). In exchange, the customer pays a one-time upfront license fee (plus annual support) for the term.
During the ULA period, you can install as many instances of the covered products as needed without tracking or reporting license counts to Oracle. At the end of the term, you must “certify” your usage – essentially counting all deployments – and Oracle will then convert those deployments into perpetual licenses for you to keep (this is the certification process).
In summary, a ULA offers flexibility to scale your use of certain Oracle software without worrying about additional license purchases during the term in return for a sizable upfront cost and a commitment to stick to the contract’s conditions.
Q2: How does an Oracle ULA work in practice?
A: Once you sign a ULA, you pay the agreed upfront fee and can deploy unlimited instances of the specified Oracle products across the allowed entities for the duration (commonly 3-5 years). No monthly or annual usage reports are required during the term – you simply deploy as needed without informing Oracle.
About 6 months before expiration, Oracle will reach out to determine next steps. By the end of the term, you have two main options: renew the ULA (start a new term, often with additional cost) or certify (exit) the ULA, which means providing Oracle with a formal count of all the deployments you made during the term.
Upon certification, those counts become your fixed perpetual licenses going forward. If you certify, your unlimited deployment period ends on expiration, and your rights are limited to the reported quantities.
If you renew, you continue under another unlimited term (possibly covering a different or expanded set of products). Essentially, the ULA lets you “fill your bucket” with as many licenses as possible during the term. Then, that bucket is sealed at the end (if you exit), so you can use those licenses indefinitely thereafter.
Q3: What products are covered in an Oracle ULA?
A: A ULA only covers the specific Oracle products explicitly listed in your ULA contract. Depending on the negotiation, this could be a broad product set (e.g., all Oracle Database editions and certain options or a bundle of middleware products) or a narrow one.
It is not a blanket for all Oracle software – any Oracle products not included in the ULA are outside its scope and would require separate licensing . For example, you might have an Oracle Database ULA that covers the Enterprise Edition database and some add-on options.
Still, it wouldn’t cover Oracle applications or cloud services unless those are specified. It’s critical to review the ULA’s “Included Products” list and ensure it covers everything you plan to use because the unlimited usage rights will not protect anything not listed. If you deploy an unlisted product, that would be a compliance issue (out of the scope of the ULA). In short, the ULA makes specific software titles unlimited, not your entire Oracle portfolio.
Q4: What does “unlimited” really mean in a ULA?
A: “Unlimited” in the context of an Oracle ULA means you can deploy any instances of the covered products during the active term without obtaining additional licenses from Oracle for those deployments.
It covers those products’ various deployment scenarios (on physical servers, virtual environments, etc., subject to contract restrictions). However, “unlimited” does not mean you can use anything and everything Oracle makes – it’s unlimited only for the products listed in your contract and only for the entities and locations defined (see customer definition and territory questions).
Also, the unlimited usage is time-bound; it lasts until the ULA expires. After that, your deployments are capped at the quantities you certify. So, during the term, you don’t worry about counts for the in-scope products, but the usual license limits apply outside that scope or after expiration. Think of it as an all-you-can-eat buffet for certain Oracle software within a specific period and scope.
Q5: How long does an Oracle ULA last?
A: A typical Oracle ULA term is 3 years. In some cases, organizations negotiate ULAs for shorter or longer durations, ranging from 1 year (unusual) up to 5 years.
Five-year ULAs were more common in the past or for very large agreements, but most ULAs nowadays tend to be 3 years, giving companies a balance between flexibility and commitment.
There’s also a concept of a Perpetual ULA (PULA) with no end date (see later question), but those are rare. At the end of the agreed term (e.g., after 3 years), the ULA ends, and you must either renew it for another term or certify your deployments to fix them as perpetual licenses . It’s important to mark that end date and plan well in advance because the transition (either renewing or certifying) requires preparation.
Q6: What obligations do we have under a ULA during the term?
A: During the term of the ULA, your main obligations are to pay the annual support fees and adhere to the contractual scope. You usually pay for support each year (typically 22% of the upfront license fee – standard Oracle support rate) to receive updates and support services. You also must ensure you only deploy the software within the agreed parameters.
For example, only the legal entities covered by the ULA (the “customer definition”) can use the software, and only in the allowed territory. You’re not required to report usage or true-up licenses during the term. Oracle typically will not audit you on the in-scope products during this period since you have unlimited rights (they might still audit for any out-of-scope usage, though – see compliance section).
Another obligation is to notify Oracle if certain events occur, depending on contract terms—for instance, if you undergo a merger or acquisition, you might need to inform Oracle (because it can affect the ULA). Towards the end of the term, you must provide a certification report of usage by the deadline.
In summary, during the ULA, you must remain compliant with its scope (don’t use it as a free-for-all for unlisted products or unauthorized entities) and keep up with support payments.
Q7: How is a ULA different from Oracle’s other licensing models (like an ELA or standard license)?
A: The main difference is that a ULA provides unlimited deployment rights for the specified products during the term, whereas standard Oracle licenses (perpetual or term licenses) and even Enterprise License Agreements (ELAs) give you a fixed quantity of usage. With a normal license purchase, you buy a certain number of processor or named-user licenses upfront; if you need more, you must buy more. You pay a lump sum in a ULA and can deploy as much as needed without additional purchase until the term ends.
Another difference is that an ELA is usually a large purchase of many licenses at a discount (which might include a clause allowing some growth), but it’s not “unlimited.” An ELA might cap your usage or be a pool of licenses, whereas a ULA truly has no cap on deployments for those products during the term.
Also, ULAs have a defined end process (certification) where your usage becomes fixed, which standard perpetual licenses don’t require – you simply always have what you bought. ULAs focus on flexibility and simplified management (not counting during term), while standard licensing focuses on precise entitlements.
In short, ULAs trade certainty of quantity for a fixed cost, whereas other models trade flexibility for cost that scales with quantity. ULAs can be great for rapidly growing environments because you don’t pay per server, but if your usage is stable or shrinking, a ULA could be more expensive than just buying the licenses needed.
Finally, ULAs typically cover infrastructure software (databases, middleware), which is less common for applications or cloud services, whereas other licensing models cover everything.
Q8: Is an Oracle ULA a good fit for every company?
A: No – ULAs are best suited for organizations that expect significant growth in their usage of the covered Oracle products or have highly unpredictable usage patterns that are hard to forecast. Suppose you anticipate needing more Oracle licenses in the next few years (due to projects, expansion, etc.). In that case, a ULA can provide cost certainty and avoid the risk of running out of licenses.
On the other hand, if your Oracle usage is steady or you’re not planning to deploy much beyond what you already have, a ULA might cause you to overcommit and underutilize (paying for unlimited when you only needed a fixed smaller amount). One of the primary risks of a ULA is that companies overestimate their needs and end up underutilizing the unlimited allowance, wasting money.
ULAs tend to be favored by larger enterprises (with big Oracle footprints) rather than small businesses. However, even a smaller company could consider one if it plans a major Oracle-based expansion.
In general, you should carefully analyze your growth projections. A ULA makes sense if buying equivalent licenses one by one would likely cost more over the term. If not, sticking to regular licenses or a smaller ELA could be more cost-effective. In short, ULAs are powerful tools but only a good deal in the right circumstances—they are not one-size-fits-all.
Q9: How does Oracle determine the price for a ULA?
A: Oracle does not have a public price list for ULAs; pricing is highly negotiable and case-by-case. Typically, Oracle will consider your current license holdings and support spend, projected growth, company size (revenue/employees), and how much Oracle thinks you’d spend without a ULA.
They often use models such as a “growth model” (pricing based on expected increase in usage) or a “historic spend model” (based on what you’ve spent on Oracle historically). Oracle sales might start with an extremely high number (treat it as an anchor for negotiation).
For example, they might calculate that if you doubled your deployments in 3 years, what would that cost in normal licenses and propose a price somewhat below that to make the ULA attractive. There’s no fixed rule – it’s about perceived value and negotiation power.
One common approach is Oracle sets the upfront license fee roughly equal to some multiple of your last annual Oracle spend or the cost of a certain number of processors. Support fees are then 22% of that license fee annually.
Because of this, it’s crucial to negotiate; companies have seen initial ULA quotes in the tens of millions and negotiated down significantly by demonstrating more realistic usage. In sum, Oracle’s ULA pricing is “what the market will bear.” Understand your needs and leverage to push for a reasonable number.
Q10: What are common misconceptions about Oracle ULAs?
A: One misconception is that a ULA covers everything – in reality, it only covers the specific products and entities listed. Another is thinking “unlimited” means forever, only during the term (unless you have a rare perpetual ULA).
A big misconception relates to support costs: some fear that if they deploy a huge amount under the ULA, Oracle will jack up their support fees at the end. In truth, Oracle’s support fees generally remain based on the initial contract value and follow standard annual inflationary increases (typically 0-4%), not the number of licenses you certify.
For example, suppose you paid $X in support during the ULA. In that case, you’ll keep paying roughly $X (plus the small yearly uplift) after certification, no matter how many licenses you have. Another misconception is that being in a ULA means Oracle won’t audit you at all – while you won’t be audited for the covered products during the term (since you’re unlimited), Oracle could still audit for other reasons (e.g. usage of non-included products or verifying your certification).
Also, some think a ULA automatically includes new subsidiaries or lets you use Oracle anywhere – actually, the contract defines where and by whom the software can be used, so assuming you can deploy in, say, a newly acquired company or an unlisted country without consequences is a mistake (you’d need to negotiate that).
Lastly, companies sometimes assume a ULA will simplify everything so much that they don’t need to manage licenses—indeed, licenses are not counted during the term. Still, you need to manage the scope and prepare for the end of the ULA.
Q11: Do ULAs cover Oracle cloud services or deployments in the cloud?
A: Not by default. Oracle ULAs traditionally cover on-premises software licenses and have specific terms about cloud use. Oracle distinguishes between “authorized” and “non-authorized” cloud environments.
If you plan to deploy the covered software on a public cloud (like AWS, Azure, or Google Cloud), you must ensure your ULA contract permits it or that Oracle’s cloud policy covers it. Oracle’s standard policy counts certain clouds (OCI, AWS, Azure, Google) as “authorized” for license use. Still, you need to be careful: deploying Oracle software in a cloud without proper contract language can lead to compliance issues.
Some ULAs explicitly allow cloud deployments (Oracle may include language for OCI or other clouds). If not, you might be restricted or have to bring those cloud deployments into compliance at certification. A common scenario: Oracle LMS’s scripts will detect cloud usage; if it isn’t allowed, Oracle could claim those instances are unlicensed. In short, check your ULA contract for cloud clauses. It’s advisable to negotiate “global usage,” including cloud upfront. So yes, you can use ULA licenses in the cloud only if it’s allowed by your agreement or Oracle’s policies – otherwise, it’s a risk.
Q12: What is meant by “customer definition” in a ULA?
A: The Customer Definition clause in your ULA defines which legal entities can use the Oracle programs under the agreement. Typically, it will list the company name signing the ULA and any subsidiaries or affiliates included.
Often, it covers the signing company and all its majority-owned subsidiaries. If you have joint ventures or less-than-majority-owned affiliates, those might not be included unless specifically added. This clause is critical – if an entity (like a new subsidiary or an acquired company) isn’t included, any usage by that entity isn’t covered by the unlimited rights.
For example, if your Customer Definition is “ABC Corp and its wholly-owned subsidiaries,” then if ABC Corp acquires 100% of XYZ Inc., perhaps XYZ is a wholly-owned sub and can be covered (subject to any contract terms about acquisitions). However, if ABC only owns 50% of another company, that joint venture might not be covered.
If you spin off a business after divestiture, it’s no longer part of the “customer” and thus not entitled to use the ULA software. A precise customer definition helps avoid ambiguity and compliance issues later. It’s often negotiable – you should ensure it’s broad enough to cover any planned corporate changes (see M&A section) and all parts of your organization that will use the software.
Q13: How does Oracle’s ULA agreement structure look (what’s in the contract)?
A: An Oracle ULA contract (often an Ordering Document referencing Oracle’s standard terms) typically contains key sections like: Product list – the specific programs you get unlimited rights to, often with their license metrics (e.g. Oracle Database Enterprise Edition – Processor metric); Term – the start and end dates of the unlimited period; Customer Definition – which legal entities are allowed to use the software; Territory – where you can deploy (e.g., “worldwide” or specific regions); Fee and Payment – the upfront license fee and the annual support fee; Certification clause – details on how and when you must report your usage at the end; Exclusions or special conditions – for example, any specific restrictions (like no use in certain cloud environments, or a requirement that you maintain support on pre-existing licenses).
It may include an M&A clause (discussing what happens if you acquire or are acquired) and other legal boilerplate. Unlike a normal license order, a ULA’s ordering document spells out these unique unlimited deployment and certification concepts.
Pricing is usually a single amount (covering all the products). Support is listed as a percentage of that. For structure, think: front page with key fields (products, terms, entities, territory, fees), the terms and conditions, including the all-important certification requirement. It’s important to scrutinize clauses around territory, mergers, and exits, particularly during negotiation.
Q14: Do support costs change during or after a ULA?
A: During the ULA, you pay a fixed annual support fee (typically pegged at 22% of your upfront license fee). That support cost stays constant in base amount during the term – it doesn’t increase just because you deploy more.
However, Oracle usually applies a standard annual uplift of a few percent (often 8%) to support fees as per their support policy, ULA or not. After the ULA, when you certify and get perpetual licenses, you continue paying support on those licenses at the same annual rate you were paying (with the usual yearly inflationary increase).
A common misconception is that if you certify many licenses, Oracle will charge more support. However, they will not recalculate your support based on the number of licenses certified. The support cost is tied to the contract value, not how much you deployed.
The “hidden” cost here is that support is ongoing—you’ll pay it every year to continue receiving updates and support. Also note: if you had existing Oracle licenses with support and rolled them into the ULA, Oracle might also consolidate those support fees into the ULA support stream.
In summary, support fees are predictable in a ULA (constant base, small annual increase), but they are a significant long-term cost to budget for.
Q15: Can we include all our Oracle products in one ULA?
A: In theory, Oracle would love to sell a massive ULA covering many products, but in practice, you typically include only a defined set that you need unlimited use of. Including every Oracle product you own is generally not wise or cost-effective.
Each product added will raise the price and support cost. Companies often do ULAs for a specific category, like Database and related options, Middleware products, etc., rather than a mix of database, middleware, and applications all in one – though it’s not unheard of. Oracle’s product families have different value metrics, so a broad ULA gets complicated.
Also, including products you don’t intend to deploy massively is usually a mistake (you’d be paying support for them for nothing). It’s better to focus the ULA on products where unlimited usage gives you strategic benefits. You might just keep standard licenses for other stable Oracle products.
For example, you might do a ULA for the Oracle Database and WebLogic servers that you plan to expand everywhere but not include Oracle E-Business Suite ERP software if that user count is stable – that could stay on normal licensing. A ULA is not “Oracle All-You-Can-Eat” for everything by default – it’s unlimited for the chosen products. Be selective to avoid unnecessary costs.
Q16: What happens when a ULA term ends?
A: When the ULA term ends, your unlimited deployment rights cease. You must have chosen one of two paths: renew the ULA (start a new term, essentially extending unlimited rights) or exit and certify. If you exit, you have a contractual deadline (often 30 days after the term ends) to provide Oracle with a certification letter signed by an executive, reporting the quantities of each product you deployed during the ULA.
Those reported quantities become your fixed, perpetual license counts going forward. After certification, you can only use up to those quantities; any new deployments beyond that would require new licenses. If you renew instead, you enter a new unlimited period (possibly under new terms or fees) and postpone the certification until that next term ends.
It’s critical not to ignore the end of a ULA. If you do nothing (no renewal, no certification), you will be in violation because the unlimited right will lapse without any licenses to show for it. So, at the end of the ULA, either sign a renewal (before expiration, ideally) or submit your deployment count to Oracle to lock in your rights.
Oracle will then confirm the certification, and you will continue using the software under normal (fixed license) terms thereafter. Many companies treat ULA end as a project, starting months in advance to inventory everything (we cover that in the certification section).
Q17: Are the licenses we get after ULA certification truly “perpetual”?
A: Yes. Once you complete the ULA and certify your deployment counts, Oracle grants you standard perpetual licenses for those products equal to the quantities you certified. “Perpetual” means you can use those licenses indefinitely for the versions covered without a time limit. You are essentially converting your unlimited right into a bunch of perpetual license entitlements.
You should receive documentation (or the certification letter signed by Oracle) confirming those entitlements. Remember, perpetual rights do not mean free – you will continue to pay annual support if you want Oracle support and updates. But the license itself does not expire. You could only lose it if you breached some contract term (like violating the license agreement).
One nuance: the perpetual licenses are for the specific products and quantities certified and usually tied to the latest version available at the contract end (you typically have rights to upgrade to any version released during your support term as well). If you stop paying support, you can still use the software at the last version you had, but you lose access to upgrades and Oracle assistance. In summary, post-certification licenses are like any Oracle perpetual licenses – yours to use forever under the license agreement terms, with optional support continuation.
Read Oracle ULA FAQs – What Are the Risks?
Q18: What is a “Perpetual ULA (PULA)”?
A: A Perpetual ULA (PULA) is a special ULA variant with no expiration date. It grants unlimited use of the specified products forever (or at least for an indefinite period) instead of for a 3-5-year term.
You do not have to certify usage in a PULA because the agreement doesn’t end. This might sound like the ultimate deal, but Oracle typically prices PULAs extremely high since you’re buying an unlimited right outright. PULAs are relatively rare and are usually only offered to large customers or as part of settlement/negotiation scenarios.
A PULA is like pre-paying for an infinite number of licenses in perpetuity. Support fees still apply annually. Some organizations consider a PULA after doing a couple of regular ULAs if they find they continually need unlimited use – at that point, negotiating a one-time perpetual unlimited can sometimes make sense. Oracle also sometimes calls certain large custom agreements “perpetual ULAs” if they roll a ULA into an unlimited cloud credit deal, etc.
The key point is that a normal ULA ends and needs certification; a PULA does not end, eliminating the need to count deployments at a cutoff. But you’ll pay a premium for that convenience and must be sure your product needs won’t change (because getting out of a PULA or reducing scope is impossible once signed). PULAs are not advertised openly; they come up in high-stakes negotiations.
Q19: What is a “capped ULA”?
A: A “capped ULA” is a less common variant where there is a preset limit on deployments. It’s somewhat contradictory to the term “unlimited,” but essentially, Oracle might agree to a fixed price for up to a certain number of licenses, beyond which additional fees apply. For example, a ULA might allow unlimited use of up to 2,000 processors, which for most customers is unlimited, but it caps extreme usage.
Sometimes, a capped ULA refers to a ULA that automatically converts to a certain number of licenses at the end (the cap) rather than requiring you to count. This can be used if customers don’t want the certification process – they just agree on a cap upfront. Capped ULAs are not typical; most ULAs are true unlimited (uncapped) during the term.
The concept is often seen in other vendors or as a custom Oracle deal. Unless you specifically negotiate a cap, assume the ULA is uncapped until it ends. If Oracle ever proposes a cap, scrutinize it – it might be a way for them to protect against you deploying enormously more than expected.
Q20: Can we end a ULA early if needed?
A: Generally, no – you commit to the full term once you sign a ULA. There isn’t an early termination clause for convenience. You can’t just decide after 1 year of a 3-year ULA that you want to quit and certify early (unless Oracle agrees, which would be unusual and likely involve negotiation).
The only typical scenario that ends a ULA early is if your company gets acquired by another company – most ULA contracts stipulate that in an acquisition of the ULA holder, the ULA terminates, and you must certify at that point. In other words, if your company is bought, you must prematurely count your deployments and end the ULA (with no refund for the remaining term).
Another scenario might be a material breach (if you violated terms, Oracle could terminate the agreement, but that’s not ideal). So, plan to stick with the ULA once signed. If you think you might want out sooner, you probably shouldn’t enter a ULA for that long in the first place.
Some companies negotiate shorter ULAs (1 or 2 years) if they only need a short-term unlimited burst—that’s an early end, but it’s pre-planned by setting a short term. Once in, you ride it out until expiration or the acquisition trigger. Always check the termination clauses in the contract, but voluntary early exit is not a standard option.
Read more about our Oracle ULA License Optimization Service.