Oracle Licensing Guide: A Guide for CIOs and Procurement Teams

Oracle Licensing Guide

Oracle’s licensing policies are notoriously complex, often favoring the vendor if customers are not vigilant.

This guide breaks down key Oracle licensing models across databases, middleware, and applications, highlighting common pitfalls and offering practical advice.

CIOs and procurement teams can use these insights to avoid costly mistakes and negotiate terms that align with their organization’s needs.

Read Oracle Licensing FAQs for IT and Procurement Teams.

Oracle Database Licensing Models

Oracle offers two primary database licensing metrics: Named User Plus (NUP) and Processor licenses.

The choice has a significant impact on both cost and compliance.

Oracle Database is available in multiple editions (Standard Edition 2 and Enterprise Edition being the most common), each with its own rules and add-on options.

Below is a brief overview of pricing and metrics:

Oracle Database License	Metric	List Price (USD)
Oracle Database Enterprise Ed.	Per processor (core)	~$47,500 per processor
Oracle Database Standard Ed. 2	Per processor (socket)	~$17,500 per processor
Named User Plus (NUP)	Per named user	~$800 per user (minimums apply)
Annual Support (SULS)	22% of license cost	22% of the license cost

Named User Plus (NUP) Licensing:

NUP licenses are based on the number of distinct users or devices accessing the database.

This model is suitable for environments with a limited, identifiable user population (e.g., internal applications, development, or test systems). Each user license entitles one named individual (or a single device) to access the database.

Oracle imposes a minimum number of NUP licenses per processor to prevent under-sizing. For Enterprise Edition, at least 25 Named User Plus licenses per processor must be maintained (Standard Edition 2 requires 10 NUP per server).

For example, on a server with 4 Intel cores (Oracle’s core factor for x86 is 0.5, counting as two processors), the minimum NUP count would be 2×25 = 50 NUP licenses. If the NUP list price is approximately $950, those 50 NUPs would cost roughly $47,500.

NUP licensing can be very cost-effective when the user count is small and controlled.

However, tracking all human and non-human users is critical – any person or device that accesses the database (including via middleware or batch processes) must be licensed. If user counts grow or are uncertain (for instance, public-facing systems), NUP becomes hard to manage and may inadvertently fall out of compliance.

Processor Licensing:

Processor licenses allow unlimited users and are based on the processing power available to the Oracle software.

This model is better for high-volume or externally facing systems where counting users is impractical.

Oracle counts “processors” by multiplying physical core counts by a core factor (a hardware-dependent multiplier).

For example, most modern x86 CPUs have a 0.5 core factor, so a server with four cores counts as two processor licenses. Using the same 4-core server example,

Processor licensing would require two processor licenses, totaling ~$95,000 at the list price.

The processor metric covers any number of users on those cores, which provides peace of mind for large user populations or unpredictable workloads.

It’s often the choice for production databases with hundreds or thousands of users (or web applications), as the cost per user effectively decreases as the user count increases.

A processor must license the Enterprise Edition if the user count, multiplied by the NUP price, would exceed the processor license cost.

In practice, a threshold is reached where processor licensing becomes cheaper (often when user counts are in the high tens or hundreds per processor).

Standard Edition 2 is licensed per physical CPU socket (up to certain limits) rather than per core, which can significantly reduce costs on multicore hardware.

Licensing in Virtualized Environments:

Oracle’s database licensing becomes more complicated with virtualization. Oracle distinguishes between “hard partitioning” and “soft partitioning” technologies.

Approved hard partitioning methods (like Oracle’s OVM with pinned CPUs, IBM LPAR, or Solaris Zones configured in certain ways) allow you to license only a subset of physical cores.

In contrast, Oracle does not recognize soft partitioning (most commonly used by hypervisors such as VMware ESXi and Microsoft Hyper-V) to limit licensing.

Read Oracle Licensing in Microsoft Hyper‑V: A CIO Advisory.

Oracle’s policy is clear: if you deploy Oracle Database on a VMware environment, you must license all physical cores on every host where the VM could run, not just the cores allocated to the VM.

For example, a VM with four vCPUs running on a VMware cluster of three hosts (each 16 cores) could be seen by Oracle as having access to 48 cores, requiring that many cores be fully licensed.

This often shocks customers who assume they only need to count the VM’s vCPUs. Oracle’s strict virtualization stance means popular “soft” hypervisors can dramatically increase license requirements and costs.

As a result, many firms isolate Oracle databases on dedicated servers or clusters to contain the spread of license liability.

If using virtualization, it’s crucial to understand Oracle’s partitioning policies and restrict Oracle workloads to known, licensed boundaries or use Oracle-approved partitioning technologies.

(Oracle has an “Authorized Cloud Environment” policy for certain cloud providers, allowing a more nuanced vCPU counting for Oracle Database on AWS/Azure, but still with specific rules. Always consult the latest policy if running Oracle DB in the public cloud.)

Read Oracle Database Licensing FAQs.

Recommendations (Database Licensing)

• Right-size user vs. processor licenses: Analyze your user population and growth patterns. Use NUP licensing for small, controlled user groups, but switch to processor licensing when user counts are large or indeterminate to ensure compliance with licensing requirements. Regularly reconcile named users (including service accounts) against your NUP entitlements so you don’t exceed them.
• Account for minimums and options: Remember the NUP minimums (25 per processor for Enterprise Edition) and include all users (human or device) in counts. If counting users is too onerous, it’s safer to license by the processor. Also, be mindful of Database Options and Management Packs (such as Partitioning, Advanced Security, and Diagnostics Pack), which are separately licensed add-ons. Disable or limit the use of any feature you haven’t purchased; Oracle’s audit scripts can detect usage of options and bill you for them.
• Beware of virtualization traps: Treat any non-Oracle hypervisor as requiring full host (or cluster) licensing. Do not assume that a VM’s allocated CPUs or cores will cap your license needs – Oracle will likely require licensing for all underlying hardware on which the Oracle software can run. To reduce risk, keep Oracle deployments on a restricted set of hosts, use hard partitioning if possible, and document host configurations (e.g., VM host affinity rules) to defend your licensing position.
• Monitor and audit internally: Perform periodic internal audits of Oracle DB usage. Check user counts, processor counts, and option usage. For example, ensure inactive database accounts are removed or don’t exceed NUP counts. That standby or DR databases are properly licensed or configured per Oracle’s policies (Oracle allows certain DR configurations to be licensed differently if truly passive). Identifying issues yourself allows you to address them (or purchase additional licenses at budget time) before Oracle’s auditors come knocking.

Read more about Oracle license compliance.

Oracle WebLogic Server Licensing

Oracle WebLogic Server – a key middleware platform – has multiple editions and licensing options that can significantly impact cost.

The main editions are WebLogic Server Basic, Standard Edition, Enterprise Edition, and WebLogic Suite.

Each offers different features and has licensing quirks. Understanding these will help avoid over-licensing or compliance issues, especially in virtualized or cloud deployments.

WebLogic Server Basic:

This is a restricted-use version of WebLogic that comes bundled with other Oracle products (such as Oracle Forms/Reports or certain Oracle applications).

It isn’t sold separately; if you own those products, you can use WebLogic for their specific purpose.

Important: WebLogic Basic cannot be used as a general-purpose application server, as it lacks features such as clustering and is limited to supporting the included Oracle product.

Using WebLogic beyond the allowed scope (for example, deploying custom apps or enabling disallowed features) would violate your license.

CIOs should ensure that any use of WebLogic Basic stays within the confines of the product it came with, and if requirements grow beyond that, plan to license a full WebLogic edition.

WebLogic Standard Edition (SE):

The Standard Edition is the entry-level standalone WebLogic edition for general use. It provides core Java EE application server capabilities but omits advanced features, such as clustering and high availability.

When using the processor metric, WebLogic SE is licensed per physical processor socket (not per core). This can be cost-efficient on multi-core CPUs—e.g., a dual-socket server requires 2 SE licenses regardless of core count.

WebLogic SE can also be licensed by Named User Plus (with a minimum of 10 users per processor, similar to a database).

Example costs: ~$10,000 per processor for SE; if using NUP, roughly $200 per user (minimum 10 per CPU). Standard Edition is ideal for smaller applications that don’t need clustering.

However, if you ever enable clustering (even inadvertently), that triggers the need for Enterprise Edition licensing.

A common compliance pitfall is deploying WebLogic SE and then turning on a cluster or other EE-only feature, which Oracle would deem unlicensed usage.

WebLogic Enterprise Edition (EE)

Enterprise Edition includes all Standard features plus enterprise-grade capabilities such as distributed clustering, failover for high availability, enhanced management tools, and integration add-ons.

It’s designed for mission-critical applications that require reliability and scalability (e.g., clustered application servers across multiple machines).

WebLogic EE is licensed per processor core (using Oracle’s core factor table) or by NUP (minimum 10 users per processor).

In practice, most customers license EE per processor core, especially for server environments, counting each core times the core factor (for instance, 0.5 per core for Intel, so an 8-core CPU = 4 licenses).

Example costs: ~$25,000 per processor (core) for EE, or ~$500 per user NUP. If you have a cluster of servers, every core in the cluster running WebLogic EE must be licensed.

Remember that Oracle does not distribute separate binaries for Standard and Enterprise—it’s the same software; your license dictates what features you can use.

Therefore, strong governance is necessary to prevent administrators from using an Enterprise-only feature on a Standard Edition license.

WebLogic Suite:

This top-tier offering bundles WebLogic EE plus additional middleware products under one license.

WebLogic Suite includes everything in EE, as well as extras such as Oracle Coherence (an in-memory data grid caching solution), Java SE Advanced (for use with WebLogic), WebLogic Management Pack, Oracle Forms and Reports, and more.

It’s a comprehensive middleware platform license. As expected, it’s also the most expensive—$45,000 per processor core, or approximately $900 per user (NUP).

WebLogic Suite is often used when an organization has broad Oracle middleware needs (e.g., running Java EE applications, plus requiring Coherence for caching and Forms for legacy applications, etc.) and wants an all-in-one licensing deal.

If you only need one or two of those components, it might be cheaper to license them separately; Suite makes sense when you truly leverage most of the included pieces.

Important: If you have WebLogic Suite, it implicitly covers WebLogic EE use, Coherence, etc., but all usage must align with the suite’s terms.

During audits, Oracle will verify whether you deployed Coherence without using Suite or WebLogic EE, but required Suite because you also utilized an included component.

Virtualization and Cloud Impact:

Just as with Oracle databases, virtualization can significantly impact WebLogic licensing. Oracle treats WebLogic the same way in virtual environments – soft partitioning isn’t honored. A common mistake is licensing only the vCPUs of a WebLogic VM.

If that VM can run on a VMware cluster, Oracle will view the entire cluster’s cores as needing licensing.

For example, a WebLogic VM with four vCPUs on a cluster of three hosts (each with 16 cores) could trigger licensing for 48 WebLogic EE instances, even if the VM only uses four cores at a time. Oracle assumes the VM can be moved to any host (e.g., via vMotion) and access those cores.

As a result, running even a small WebLogic instance on a large VMware farm can lead to a huge license requirement.

Many organizations mitigate this by hard-partitioning or isolating Oracle middleware: dedicating specific hosts or clusters for Oracle workloads so that only those need licensing.

If possible, utilize features such as CPU affinity or dedicated resource pools to pin Oracle VMs to specific hardware and document this configuration.

Oracle has historically not accepted VMware’s native controls as a limitation, but containing Oracle software in a limited environment (and being able to prove it) remains a best practice to keep the scope down.

Alternatively, consider using Oracle’s virtualization (Oracle VM) or Oracle Cloud Infrastructure for WebLogic workloads; Oracle recognizes its own hypervisor and cloud partitions for license limiting, which can provide more flexibility.

In any case, always factor in the full physical footprint of any server environment where WebLogic runs when calculating license needs.

Recommendations (WebLogic Server)

• Match Edition to Needs: Select the most cost-effective WebLogic edition that meets your technical requirements. Avoid “over-licensing” with Enterprise or Suite if Standard Edition’s capabilities suffice. For example, if you don’t need clustering, stick to Standard Edition to leverage per-socket licensing (much cheaper on multi-core hardware). If you only need basic Java EE for an Oracle product, check if WebLogic Basic covers it to avoid buying full licenses but strictly limit use to that scope.
• Govern feature usage: Implement internal controls to prevent teams from enabling WebLogic features beyond what is licensed. This might include using config templates or admin scripts that prevent the creation of clusters on Standard Edition installs, for instance. Oracle audits will flag unauthorized use (e.g. if clustering is enabled without EE licenses). Conduct periodic checks of your WebLogic domain configurations against your licenses.
• Plan for virtualization: If running WebLogic on VMware or similar platforms, physically isolate those VMs. Ideally, pin Oracle VMs to dedicated hosts or a small cluster you fully license. Do not float Oracle VMs across your entire virtual infrastructure. If isolation isn’t possible, be prepared to license every host in any cluster where an Oracle VM resides (or could reside). The safest approach is to treat VMware clusters as the unit of licensing and keep Oracle out of large shared clusters. Document your setup to show auditors that Oracle VMs never run on unlicensed hosts.
• Leverage license options: Remember that WebLogic can sometimes be licensed by the user (NUP). If you have a development or test environment with only a handful of testers or developers, it may be more cost-effective to license by NUP than by processor. Just ensure you still meet the 10 users-per-processor minimum. Conversely, for production with many users, processor licensing is usually simpler.
• Monitor middleware usage: Keep an inventory of all WebLogic installations (including version and edition usage). Remove or repurpose unused instances to avoid accidental app deployment on an unlicensed server. Also, track any Oracle middleware components, such as Coherence or Oracle HTTP Server, that you deploy. If you need several, reevaluate whether a WebLogic Suite license would be more cost-effective overall.

Oracle E-Business Suite (EBS), Siebel, and PeopleSoft Licensing

Oracle’s major enterprise applications, E-Business Suite (EBS), Siebel CRM, PeopleSoft, and others like JD Edwards, each have their licensing models, typically centered around named users or metrics tied to business counts (like number of employees).

Unlike Oracle Database or WebLogic, which are technical products, these applications are licensed by business usage metrics and often bundle certain technology licenses for the underlying database or middleware.

This complexity leads to common pitfalls in module licensing and user counts. Procurement teams must pay special attention to how these application licenses are structured to avoid compliance surprises during an audit.

Application Licensing Structures:

Oracle EBS, Siebel, and PeopleSoft have historically offered a variety of licensing metrics, including Application User licenses (per named user accessing the system), Concurrent User licenses (for a maximum number of simultaneous users), and enterprise metrics such as employee count or Revenue for enterprise-wide rights.

For example, the E-Business Suite has had Named User Plus and Application User licenses, often categorized into “Professional User” and “Self-Service User” types, corresponding to different levels of functionality.

A professional user (with full access) might cost more, while self-service users (with limited capabilities, such as employees submitting expense reports) are typically less expensive. However, both count toward license usage and must be tracked.

PeopleSoft similarly sells licenses per module, often measured by the number of users or employees.

In PeopleSoft’s case, you can license individual modules (such as HR and Finance), each with a specific number of users. Alternatively, Oracle offers a Custom Application Suite (CAS) licensing option, which allows you to bundle multiple PeopleSoft modules under a single user count.

This simplifies management (one license covers a suite of modules for each user) and can be cost-effective if many users need multiple modules.

Siebel CRM is also usually licensed by Application User; each named user authorized in the Siebel system requires a license.

In some cases, there are also Siebel server component licenses (for certain add-on functionality) and options to license by the processor. Still, user-based licensing is most commonly used for CRM purposes.

Read the Oracle EBS Licensing Guide.

Bundling and Module-Based Pricing Pitfalls:

One challenge is that these application suites often include licenses for the underlying technology that restrict its use.

For instance, Oracle EBS includes a limited-use Oracle Database and application server license as part of the app license.

Similarly, PeopleSoft licenses include PeopleTools, which has a restricted Oracle database, and a WebLogic (or Tuxedo) license to run the PeopleSoft environment.

These bundled tech licenses can only be used for the application’s data and functionality; using them for any other purpose violates the terms.

For example, the Oracle Database that comes with PeopleSoft may only host PeopleSoft schemas. If a team unknowingly creates a non-PeopleSoft schema or database on the same DB server, it would require a separate full Oracle Database license.

This is a frequent pitfall: IT teams assume, “We have an Oracle DB license as part of EBS/PeopleSoft so that we can use that database for other stuff.” The answer is no unless you buy additional licensing.

Another common issue is module creep: Oracle doesn’t technically prevent you from activating modules you haven’t purchased.

In EBS, for example, you might only have licenses in financials and procurement. Still, nothing stops an admin from assigning the Payroll module to a user and using it – until an audit finds you’re using an unlicensed module.

The same applies to PeopleSoft – you may license Core HR but not the Payroll module; if someone activates Payroll functionality, that constitutes unlicensed usage.

Indirect usage (multiplexing) is another tricky area: if external systems or web portals feed data into Oracle applications, all those end-users may need to be licensed.

For instance, if customers access an online portal that pulls order data from your EBS Order Management module, Oracle considers those customers as users of EBS who require licensing, even though they never log directly into EBS.

Companies can be caught off guard during audits when Oracle requests counts of internal users and any external or technical users accessing the system indirectly.

Read our Oracle EBS Licensing FAQs.

Examples of License Audits:

Oracle’s License Management Services (LMS) teams frequently audit customers running EBS, Siebel, or PeopleSoft.

In an audit, Oracle typically requires you to run scripts or reports that extract usage information, including the names of several defined users, their roles, and the active modules in the system. For EBS, an LMS script might list all users with active accounts and the responsibilities (modules) they can access.

They will compare that to your license entitlement (e.g., you purchased 500 Financials users and 200 Procurement users, but the system has 550 and 250, respectively – 100 users over).

Oracle also checks user inactivity – licenses are typically based on “named users,” active or not. Suppose you have users who have left the company or no longer use the system. In that case, you might be “using” licenses for them unnecessarily (and Oracle can require you to license them if they exist as active in the system).

Read our Oracle license audit guide.

It’s a good practice to periodically purge or inactivate obsolete accounts to keep the counts accurate. In audits, Oracle will also look for evidence of the use of extra modules.

A real-world example: an Oracle audit of an EBS customer found that a module (say, Project Management) had been accessed by a few users even though the company hadn’t licensed it.

Those few clicks resulted in an audit finding requiring a backup license for that module.

Oracle can also request data, such as employee counts, if a module is licensed per employee (PeopleSoft HR often uses an employee metric).

Any “access” to functionality beyond your contract can be flagged. Another pitfall is misclassifying user types. EBS, for instance, has cheaper Self-Service user licenses for casual use (like employees submitting self-service HR forms).

If an organization purchases mostly Self-Service licenses but then assigns those users responsibilities that require a full Professional license, they’ll be non-compliant. Sometimes, overly customized interfaces blur the line.

For example, suppose you customize a Self-Service web page to perform an action that Oracle’s terms would consider professional use. In that case, you might need to license those users at a higher level.

Read our Oracle Siebel Licensing Guide.

Managing PeopleSoft and Siebel has analogous challenges:

PeopleSoft licenses are often tied to employee counts – if your company grows from 1000 to 1200 employees, and you licensed PeopleSoft HR for 1000, you’re now 200 over unless you true up.

Siebel may be licensed by named sales representatives or call center agents; if you create more user accounts than are licensed, you’re in violation.

None of these applications will stop you from adding users or functionality beyond your license – it’s all on the honor system and post-use auditing.

For example, “a regional bank licensed 1000 self-service and 200 professional EBS users, but had 1200 employees using self-service functions,” thus exceeding their entitlement without any in-app warning.

For customers, Oracle audits typically occur every 3-4 years, allowing compliance gaps to develop if not continuously monitored.

Recommendations (EBS, Siebel, PeopleSoft)

• Maintain vigilant user management: Implement procedures to regularly review and reconcile user counts in each Oracle application with your licensed numbers. Remove or end-date inactive users in EBS/PeopleSoft, etc., to avoid paying for accounts that are no longer in use. For user-based licenses (Application Users, Named Users), ensure each actual person is counted only once per the rules and that you’ve purchased enough licenses for peak usage.
• Segregate license types: If your application offers different user license tiers (e.g., Self-Service vs Professional in EBS), carefully control what each user can do. Do not give Self-Service users access to functions reserved for full users. Use the provided licensing guide for each app to understand what each license type covers, and then audit your configurations against it. This can prevent accidental “license creep”, where a cheaper license is used inappropriately.
• Track module usage: Keep an internal log of which EBS/PeopleSoft modules or Siebel components you have licensed. Configure the software to restrict access to only those modules. If a new business needs to use a module that you haven’t licensed, go through procurement to obtain the necessary rights first, rather than piloting it without licenses. Oracle software won’t stop you, but an audit will catch you. It’s wise to periodically run Oracle’s provided usage reports (or LMS scripts in read-only mode) to check if any unlicensed modules show activity.
• Beware of indirect access: Analyze any system integrations. If third-party systems or customer-facing portals interface with your Oracle apps, count how many end-users indirectly touch Oracle data. Those might require licenses as “legitimate users” under Oracle’s definitions. For instance, a thousand customers using an online portal that pulls data from Siebel or EBS might technically require each to have a license (or you may need a different license metric, such as a Processor license, to cover them). Design integrations to minimize unlicensed use and consult Oracle’s policies on multiplexing.
• Leverage contract bundles wisely: If Oracle offers a bundled metric (such as an enterprise license based on employee count or a Custom Application Suite covering multiple PeopleSoft modules), evaluate whether it simplifies compliance for you. An enterprise metric can sometimes cover usage surges (all-you-can-use within your org size) and avoid nickel-and-diming each module. However, be cautious: those deals often come at a high price and require a certain level of growth. Only go enterprise-wide if you foresee broad usage of most modules – otherwise, you might overpay.
• Prepare for audits proactively by conducting internal audits using Oracle’s tools. Oracle often provides LMS query scripts, which you can request or find via Oracle’s support, to check your usage. Running them internally (or using third-party license management tools) can flag issues early. For example, you can extract all user accounts, confirm they don’t exceed purchased numbers, or list all installed modules. If you find discrepancies, address them (perhaps by purchasing additional licenses or reducing usage) before Oracle’s official audit. Maintaining evidence (logs of user counts, records of deactivated accounts, etc.) will also help during an audit defense to show your diligence.

Read Oracle Licensing FAQ: EBS, Siebel, JD Edwards, and Primavera.

Oracle ULA (Unlimited License Agreement)

An Unlimited License Agreement (ULA) with Oracle is enticing and perilous.

In a ULA, you pay Oracle an upfront fee for a fixed period (typically 3 to 5 years) during which you can deploy unlimited instances of certain Oracle products covered by the agreement.

At the end of the term, you must certify your usage, and Oracle will grant you perpetual licenses equal to the quantities deployed at that point.

ULAs can provide flexibility; you don’t have to count licenses for a few years, but they come with strict terms and can lead to high costs if not managed carefully.

What a ULA Covers and Typical Terms:

A ULA is negotiated for specific Oracle products (for example, a ULA might cover Oracle Database Enterprise Edition and a list of specific add-on options, or perhaps a bundle of Fusion Middleware products, etc.).

It does not mean “unlimited use of all Oracle software” – only the products explicitly listed. Typically, the ULA fee is based on a certain number of licenses Oracle thinks you would otherwise need.

You also pay annual support on that fee throughout the term. Notably, the support costs stay the same after the ULA ends – they are based on the initial license grant value and do not increase even if you deploy way more licenses.

This can be good or bad: if you significantly expand usage under the ULA, you’re effectively getting a discount on support (more licenses covered by the same support fee); if you deploy less than anticipated, you might be stuck paying high support for relatively few licenses.

ULAs also often have geographic or entity restrictions – e.g., usage might be limited to your company (no sharing with subsidiaries acquired later unless specified) and certain regions.

It’s essential to read the fine print: some ULAs exclude certain deployment types (such as use in the cloud, which may or may not be allowed), or they include specific options.

During the ULA term, you are technically in compliance even if you spin up numerous instances; however, any product not covered by the ULA that you use will still require separate licensing.

Companies sometimes fall into a false sense of security with a ULA, deploying additional Oracle products not in the agreement, thinking, “We have an unlimited deal.” Those would be non-compliant.

The end-of-term certification is a critical moment: You must provide Oracle with a formal count of all deployments of the ULA products as of the end date, which will become your fixed license allotment in the future. Anything deployed beyond the certified number after the ULA is unlicensed if you miscount or forget something.

Certification Challenges:

Certifying a ULA can be a complex project. Oracle typically sends auditors or requires detailed scripts and output to verify the accuracy of your counts.

The contract’s certification clause defines what you must do – ideally, it just requires you to send Oracle a certification letter listing quantities, and that’s it.

Beware of contracts that allow Oracle to audit or second-guess your certification; instead, negotiate that the certification process is straightforward and under your control.

For example, avoid language mandating that Oracle’s LMS team must verify your usage with their tools as part of certification—this can be negotiated out for a more straightforward exit.

Oracle has been known to pressure companies to renew rather than exit a ULA. Near the end of the term, Oracle might hint that if you try to certify out, you could be at risk of non-compliance, thus suggesting that renewing for another period is “safer.”

They often push new ULAs or extensions (sometimes offering cloud credits or discounts as sweeteners) to keep you from exiting. It’s critical not to be intimidated by this.

If you have accurately tracked your deployments, certification can be completed with confidence.

Another challenge is ensuring you capture every instance of the ULA-covered software. This involves conducting a thorough internal audit of all environments – including production, development, test, DR, and others – to accurately count installations.

You’ll want to remove or consolidate any deployments you don’t need before the end (there is no point certifying unused installations, as they will inflate support costs later).

Conversely, if you anticipate needing more of something soon, plan that carefully: for example, if a project will require 50 more Oracle DB instances next quarter, and your ULA ends this quarter, you might deploy them a bit early to include them in the certified counts (provided that’s within the ULA’s allowed software).

Timing matters. One strategy is to maximize legitimate usage before ULA expiration to maximize value (this must be real usage, not fake, as Oracle may scrutinize sudden spikes in usage at the end).

There’s also the risk of “out of scope” usage—ensure that your teams know which products/features are unlimited throughout the ULA.

It’s a common mistake for IT folks to think, “We have an unlimited license, so any Oracle product is fine,” which is untrue.

For instance, if your ULA is for Database and WebLogic only, using Oracle GoldenGate or Oracle Cloud services would be outside the scope and require separate licenses. Education and internal communication during the ULA term are vital.

Renewal Strategies:

As the ULA end date approaches, you must decide whether to certify (exit) or renew your certification.

Renewing means negotiating a new ULA or converting to another model (for example, Oracle might offer to move you to cloud subscriptions).

Don’t let Oracle automatically roll you into a renewal without analysis.

The decision should hinge on your future needs:

• If your Oracle usage is expected to grow significantly, a renewal may be a good option (but negotiate terms based on what you plan to deploy, rather than unnecessary products).
• If your usage has plateaued or you plan to reduce your reliance on Oracle (perhaps by migrating some systems off Oracle), then certify and exit, retaining the licenses you’ve deployed. Oracle will often try to entice a renewal by offering a slight discount or adding a product; this is weighed against the benefit of ending the unlimited period.
• Some companies leverage the end of a ULA to transition to Oracle’s cloud (OCI). Oracle sometimes will let you apply your ULA value toward cloud credits, or they’ll offer a new type of agreement (like a Perpetual ULA or a Pool of Funds for cloud). Again, evaluate whether those options benefit you or lock you in further. A strong negotiation stance is to prepare for certification (show Oracle you’re ready to exit), which can pressure Oracle into offering a better renewal deal if they want to retain you.

Another strategy is to consider third-party support once you exit the ULA, especially if you don’t anticipate needing Oracle’s upgrades.

Some firms certify out of a ULA with many licenses and then move support to a third-party provider to save on the 22% Oracle support fees (since Oracle’s support bill might be very high relative to actual usage if you “over-deployed” during the ULA).

Be aware that Oracle may audit a year or two after a ULA ends, especially if you didn’t renew, as they suspect you might exceed the certified counts afterward.

Therefore, it’s essential to freeze deployments of those products once you have certified (or ensure that any new deployment is within the number you certified).

Recommendations (Oracle ULA)

• Negotiate upfront: If you’re entering a ULA, negotiate the terms aggressively. Include only the products you need in the unlimited scope – each additional product will raise the cost. Ensure a clear “certification” clause lets you self-certify usage with a simple letter and no mandatory Oracle audit as part of the exit. Clarify any ambiguities (e.g., how VMware or cloud deployments count) in the contract. Also, negotiate a clause for divestitures or acquisitions if applicable (ULAs usually don’t automatically cover new acquisitions – you might need Oracle’s approval).
• Maintain discipline during the term: Treat a ULA not as a holiday from license management but as a period of active monitoring. Regularly (e.g., quarterly) measure your deployments of ULA-covered products. Keep a detailed spreadsheet of all installations, CPU counts, user counts – whatever metric would apply if it weren’t unlimited. This way, when you approach the end, you have an internal Effective License Position. It also helps you catch if any team has deployed something not covered by the ULA (so you can remediate or license it separately before it becomes an audit issue).
• Optimize before exit: Scrub your environment in the ULA’s final 6 to 12 months. Uninstall or shut down any Oracle instances that are not needed – there’s no sense in certifying and paying support for things you don’t use. Conversely, forecast future needs: if you know you’ll need more of the Oracle product soon, consider deploying it during the ULA term so that it gets counted in your certification. Many companies do a “final push” to deploy as much as is legitimately useful. For example, if you plan to expand into a new region with Oracle within the next year, deploying those servers now (before the ULA ends) could make them effectively free (aside from support costs). Be cautious to deploy only genuine needs; artificially inflating the count could raise flags.
• Decide exit vs renewal with data: Well before the ULA expires, present a clear picture to your executives: “We have deployed X worth of licenses under the ULA. Following the ULA, our annual support cost will be $Y. Our projected growth is Z% annually.” If future growth is modest and you have plenty of headroom from the ULA, exiting may save money (you avoid another big ULA fee). If you foresee a massive expansion or a new project requiring significantly more Oracle resources, a renewal or a different licensing model might be warranted. Use this data to drive negotiations. Oracle sales will often come in hot, trying to convince you to renew; having your analysis insulates you from sales FUD (fear, uncertainty, doubt).
• Execute the exit carefully: If you choose to certify out, follow the contract to the letter. Submit any required notice of intent to certify (some ULAs require you to notify Oracle 30-60 days before the term ends if you plan to certify). On the certification date, count everything twice. Consider hiring a third-party license specialist to validate your counts – the cost of an expert is trivial compared to potential license exposure if you undercount. When providing the certification letter, list all quantities in detail and get Oracle’s written acknowledgment. After certification, closely monitor to ensure you do not exceed those quantities. If you accidentally exceed the limit, you must purchase additional licenses; otherwise, you may be subject to an audit claim.

Java Licensing Changes

Oracle’s Java licensing has undergone major changes recently, catching many enterprises off guard.

Historically, the Java Development Kit (JDK) was free for all purposes (under Oracle’s Binary Code License).

This changed in 2019, when Oracle began requiring a subscription for commercial use of Java SE, and was revised again in 2023 to a new licensing model.

CIOs and procurement teams must understand what is free and what is not, as well as how the new Java SE subscription model works to avoid surprise costs.

From Free to Subscription (2019 Changes):

In January 2019, Oracle stopped providing free public updates for commercial users of Java 8 (which was widely used).

This effectively ended the “free Java for business” era—companies that wanted security updates or newer versions of Oracle JDK for production use now needed to pay for a Java SE subscription.

Oracle introduced the Oracle Technology Network (OTN) License for Java, which permitted the free use of the Oracle JDK for specific purposes, including personal, non-commercial use, development, testing, or demonstration environments.

Any commercial use in production requires a paid license. If your internal servers or applications were running Oracle’s JDK (Java 8, Java 11, etc.) in production after 2019, you should have a subscription (or use an alternative JDK).

Many companies were unaware of this change and continued using Oracle JDK as they had before, until Oracle’s auditors began including Java in their license reviews.

By 2020, Oracle’s License Management Services had actively begun auditing Java usage. This led to “Java audit ambushes,” where companies that had never paid for Java were found to be non-compliant.

The cost at that time was based on the number of processors or named users running Java (Oracle had subscription metrics similar to database–per–processor or per-user metrics).

Oracle also attempted to relieve those who kept up with the latest version.

With Java 17 (released in 2021), Oracle provided a new Oracle No-Fee Terms license for that version, allowing free use (including in production) for one year after the next Long-Term-Support version is released.

This meant organizations could temporarily use the latest JDK (17) for free but would eventually need to upgrade to stay free or start paying once the free period ended.

While helpful to some developers, this scheme did not eliminate the need for a subscription for those who stayed on older versions, such as Java 8 or 11, which many enterprises maintained for application compatibility.

Java SE Universal Subscription (2023 Changes):

In January 2023, Oracle introduced a significant update to its Java licensing model.

They introduced the Java SE Universal Subscription, which is based on an employee-based metric.

Instead of counting processors or named users of Java, Oracle now requires subscribing for all employees in your organization if you want to use Oracle Java SE commercially.

This represents a significant shift: the price is based on your total employee headcount (including full-time, part-time, contractors, and consultants), regardless of the number of employees who use Java.

In other words, Oracle assumes that Java is widely used across the company and prices it accordingly, per employee.

The list pricing was roughly $15 per employee per month for smaller organizations, with volume discounts at higher employee counts (scaling down to around $5-$10 at large scale).

For example, a company with 500 employees would pay 500 × $15 = $7,500 per month ($ 90,000/year) to cover Java SE, even if only 50 of those employees’ machines run Java.

This model immediately raised concerns and backlash in the industry.

Analysts noted that it could increase Java licensing costs by 2- 5 times for the same usage in many cases.

Gartner found that costs could increase by up to five times, and a survey indicated that nearly 90% of Oracle’s Java customers were considering switching away to avoid this “predatory” pricing.

The dissatisfaction was especially high in Europe, where over 90% of organizations surveyed in some countries planned to seek alternatives (such as OpenJDK distributions from vendors like Azul, IBM, Amazon, etc.).

Scope of Commercial vs. Personal Use: It’s essential to clarify what a Java license entails.

Under Oracle’s policies:

• Personal use of Oracle Java (an individual using it on a personal machine for non-business purposes) is free.
• Under the OTN license, development, testing, and prototyping—using Oracle JDK in a non-production environment—are allowed without a subscription. This allows developers to freely download and write Java programs without needing to deploy Oracle JDK in production.
• Commercial use / Production—Any internal business or production system running Oracle’s JDK (versions 8 through 17 under their respective licenses) triggers the need for a subscription. This includes server applications, desktop applications used for work, and other similar applications.
• Notably, the open-source OpenJDK (the open-source reference implementation of Java) does not require a license, and many vendors provide builds (such as Adoptium/Temurin and Red Hat OpenJDK) at no cost. Oracle’s own OpenJDK builds are free, but they are only updated for 6 months after release. Many companies now use these as an alternative to avoid Oracle’s fees.
• Oracle’s Java SE subscription also includes certain commercial features (like Java Flight Recorder, Mission Control, etc.) that were not in the free version. If you need those, that’s another reason to pay. But most standard Java applications don’t require those add-ons.

Example Scenarios and Impact:

Consider a mid-sized financial services company that has Java deployed across all its systems, including internal applications, middleware, and employee desktops for various tools. They assumed Java was free and never tracked installations.

After Oracle’s 2019 policy change, they technically needed subscriptions but were not aware of it.

In 2023, when Oracle switched to per-employee licensing, this company, with, say, 2,000 employees, suddenly faced either paying for 2,000 Java subscriptions or urgently removing Oracle JDK from its systems.

The cost could be $12 per employee per month (with a volume discount)—roughly $288,000 per year—whereas previously, they paid $0 because they used the free JDK.

This prompted immediate action: the company had to inventory all Java installations, decide whether to uninstall or replace Oracle Java with OpenJDK on many machines, and then purchase subscriptions only for the systems that needed Oracle’s version (if any).

Many enterprises are going through this process: determining how much Oracle Java they use and weighing the steep subscription cost against the effort of migrating to a non-Oracle JDK. The impact has been so significant that, as noted, most of Oracle’s Java customers are exploring alternatives.

These alternatives include builds such as Azul Zulu, Amazon Corretto, IBM Semeru, and BellSoft Liberica, which are Java SE implementations that avoid Oracle’s fees.

Some organizations that require long-term support for older Java versions and don’t want to pay Oracle have turned to third-party support providers or multi-vendor setups (for example, maintaining Oracle JDK for critical applications that require it, but using OpenJDK for others).

One specific scenario: If an organization has, say, 100 Java applications running on 10 servers and 500 developer laptops under the old model, they might have needed (for example) 10 processor licenses for the servers and 500 NUPs for the users or something similar.

Under the new model, if the company has 5,000 employees, they’d pay for all 5,000, even though only 500 use Java directly. This effectively taxes the whole organization for Java usage.

The sticker shock is driving some to reduce their Java usage footprint—e.g., uninstalling Java from machines that don’t need it (so they can credibly reduce the “employees using Java” count, although Oracle’s contract metric includes all employees).

In some cases, Oracle may adjust the count (excluding employees who never use a computer, etc.), but that’s all on a case-by-case negotiation and not guaranteed by policy (the contract wording for the employee definition is pretty broad).

Read Oracle Java SE Licensing Compliance FAQ.

Recommendations (Java SE Licensing)

• Audit your Java usage immediately: You can’t manage what you don’t know. Do a comprehensive scan of your environment for Oracle JDK installations – servers, VMs, developer PCs, build servers, etc. Determine which versions are in use and for what purpose. Many organizations were surprised to discover old Java 8 or 11 installations embedded in software build processes or third-party apps. Document all of it.
• Evaluate the necessity of Oracle’s JDK: For each use case, decide if you need Oracle’s Java. In many cases, switching to a free OpenJDK distribution (such as Eclipse Temurin/Adoption, Amazon Corretto, or Red Hat OpenJDK) is relatively straightforward and provides the same functionality. These are essentially the same base code as Oracle JDK (since Java is largely open-source now), but without cost. For example, you might replace Oracle JDK 8 with Amazon Corretto 8 on your servers. Test your apps to ensure there are no issues, and you’re done – no license is needed. Reserve Oracle’s JDK only for cases where you truly benefit from Oracle’s support or specific commercial features.
• If you must stay with Oracle Java, consider the following: Perhaps you have an application certified only for Oracle JDK, or you require Oracle’s support for Java. In this case, right-size the subscription. Under the new model, it likely means negotiating the employee count or price. Scrutinize Oracle’s definition of “employee” in the contract. It typically counts contractors, etc., but you may be able to exclude part of the organization (for instance, if a subsidiary doesn’t use any Oracle software, you might keep them out of scope through legal structuring). Work with Oracle or a licensing advisor to see if there’s flexibility (though Oracle’s default stance is that all employees count). Additionally, consider the following terms: you may not want a long-term Java contract, given the rapidly changing landscape – a shorter subscription can allow for re-evaluation later.
• Stay updated on Java licensing news: Oracle’s Java policy has changed more than once and could change again. There are indications that customer pushback might force Oracle to adjust pricing or terms. Keep an eye on Oracle announcements or consult with Oracle licensing specialists each year to ensure you’re aware of the latest policy (for example, Oracle’s introduction of the no-fee license for the latest LTS versions was a response to community feedback). You can take advantage of new free options or prepare for changes by staying informed.
• Educate and enforce internally: Just as important as knowing the policy is ensuring that your IT staff is aware of it. Many Java developers have been accustomed to freely downloading Oracle JDK from java.oracle.com for years. Institute a policy that no Oracle JDK is to be used on new projects or installed on machines without clearance from the license management team. Provide links or internal repositories for approved Java distributions (e.g., an internal download site for OpenJDK builds you’ve standardized on). This will prevent well-meaning employees from accidentally incurring license obligations by pulling down Oracle JDK out of habit.
• Leverage alternatives and community support: The good news is that Java, as a technology, is not proprietary to Oracle – you have options. If Oracle’s model is too costly, you can migrate to other JDKs with minimal hassle. Also, consider if all those applications using Java are still needed; it might be an opportunity to decommission legacy apps or upgrade to versions that run on newer Java (where you might get free support for a while under the no-fee terms). Additionally, some organizations purchase Java support from third parties (e.g., Azul offers Java support at a potentially lower cost per Java instance than Oracle’s per-employee model). Compare these options to find the most cost-effective way to stay secure and up-to-date.

Licensing in Virtual Environments

Virtualization and cloud deployments pose some of the trickiest challenges for Oracle licensing. Oracle’s policies were largely written in the era of physical servers and have only been selectively updated to account for virtualization.

The result: Oracle often insists on a broad interpretation that maximizes license requirements in virtual environments unless you use Oracle’s technologies.

CIOs must understand Oracle’s definitions of hard vs. soft partitioning and how they apply to platforms like VMware or risk a costly compliance gap.

Hard Partitioning vs Soft Partitioning:

Oracle defines hard partitioning as methods that physically segment a server’s resources, which Oracle accepts for limited licenses.

Examples include Solaris Zones (configured non-dynamically), IBM’s LPAR with a static configuration, or Oracle’s own Oracle VM (OVM) when configured with hard processor affinity, among others (Oracle publishes a list of approved hard partitioning technologies).

Using these, you can license only the assigned subset of CPUs.

Soft partitioning refers to logical or software-based partitioning that can be changed dynamically—this includes most mainstream hypervisors, such as VMware ESXi, Microsoft Hyper-V, KVM, etc.

Oracle explicitly states that soft partitioning “is not permitted to limit the number of licenses required”. Essentially, Oracle treats a soft-partitioned environment as if no partitioning exists for licensing purposes.

The VMware Scenario:

VMware is the poster child for soft partitioning in Oracle’s eyes. Oracle’s standpoint (not written in your contract but enforced via policy) is that if any Oracle software runs anywhere on a VMware cluster, you must license all processors on all hosts in that cluster and potentially even beyond.

Why beyond? Oracle has argued that with vSphere 6 and above, features like vMotion can migrate VMs between clusters and even across data centers.

Therefore, they have at times required licensing of all hosts that are part of a vCenter environment, even if there’s no network or management connection between them and the Oracle workloads.

For instance, before vSphere 6, they’d say “all hosts in the cluster where Oracle runs.” With vSphere 6+, some Oracle assertions have been updated to “all clusters under the same vCenter must be licensed if Oracle VMs can move between them.”

This is extremely punitive, and many customers push back on it, but it’s not unheard of for Oracle to present that position during audits.

The safe assumption is to license every physical core that could run your Oracle software. If you have VMware, that generally means the entire interconnected cluster.

One consequence is that some companies maintain separate vCenter environments for Oracle workloads to protect them.

Oracle’s Audit Approach in Virtual Environments:

In an audit, Oracle usually asks for documentation about your virtual setup: cluster configurations, vCenter screenshots, DR plans, etc.

They look for any sign that an Oracle-installed VM has access (even theoretically) to unlicensed hardware.

For example, if you have an Oracle database VM on a VMware host, Oracle will likely require a list of all hosts to which the VM could migrate.

If that includes hosts where Oracle isn’t currently running, Oracle’s stance is that you still need to license them (because nothing technical prevents you from moving the VM there).

This catches out many organizations; perhaps they had Oracle on one host, but the whole cluster became in scope.

Oracle’s partitioning policy document says, “Soft partitioning is not a valid means to limit licensing; you must license the entire server or cluster in which the software is installed.”

Oracle auditors will stick to this line. There’s often debate and pushback from customers, citing that the contracts don’t explicitly mention VMware.

While the standard Oracle license agreement doesn’t mention VMware, Oracle relies on contract language that requires you to license the program “where it is installed and/or running.”

They interpret a clustered environment as a program that is potentially installed and running on any host. Unless you’ve negotiated a contract exception, fighting this after the fact can be an uphill battle.

Read Licensing Oracle Database in VMware and Virtualized Environments.

Practical Implications and Strategies:

First, contains Oracle workloads.

If you use VMware, a best practice is to create dedicated clusters for Oracle and disable VM mobility between Oracle and non-Oracle clusters (for example, do not connect Oracle clusters to the same vCenter or configure strict affinity rules).

Some companies even maintain older versions of VMware, just to argue that vMotion isn’t possible to a certain extent.

Other licensing consultants have detailed strategies for architecting VMware for Oracle, but this boils down to isolation and documentation.

Second, consider using Oracle’s hypervisor (OVM) or Oracle Linux KVM with hard partitioning if you want to partition Oracle workloads on a host.

For instance, the Oracle VM Server for x86 is recognized by Oracle for partitioning if set up with capped vCPU assignments.

Also, running Oracle on physical hardware or engineered systems with capacity on demand (like Oracle Exadata) is straightforward in licensing (you license the enabled cores).

In cloud environments, Oracle has an “Authorized Cloud Environment” policy, which allows certain providers (such as AWS, Azure, and Google Cloud) to set rules like “count vCPUs: 2 vCPUs = 1 Oracle processor license” for Enterprise Edition, subject to minimum requirements.

Using these authorized clouds can sometimes be more license-efficient than on-premises VMware, as Oracle has defined a formula for them.

However, be cautious: if you use a cloud that is not on Oracle’s authorized list, Oracle may not accept any soft partition logic.

Auditing and Full Capacity:

Oracle audits in virtual environments often yield the most significant findings.

It’s not uncommon for an organization to think it was fully licensed, only to have Oracle say, “Actually, you needed to license these 200 extra cores in your cluster—here’s a $10 million compliance bill.”

A classic scenario involves placing a small Oracle database on a large ESXi cluster.

In an audit, Oracle claims you owe processor licenses for the entire cluster (e.g., 4 hosts × 20 cores each = 80 cores, multiplied by the core factor of 0.5 = 40 licenses of Database Enterprise Edition). 40 licenses at $47.5k is $1.9M, whereas the company thought they might need two licenses for that one VM (worth $95k).

These situations can often be negotiated down (especially if you can quickly isolate and agree not to use Oracle on those large clusters), but it’s a painful negotiation.

The lesson is to never assume Oracle will give you the benefit of the doubt in a virtualization scenario. Oracle’s default audit methodology is to err on the side of counting as much as possible.

Read Oracle licensing VMware – Audit Strategies.

Recommendations (Virtual Environments)

• Isolate Oracle workloads: This cannot be overstated. If you run Oracle products on VMware or other non-Oracle virtualization, dedicate specific hosts or clusters to those Oracle workloads. Physically segregate them from other infrastructure. This limits your licensing scope and provides a clear boundary. Document these boundaries (for example, cluster names “Oracle Cluster A, B” and show that Oracle VMs never run in others).
• Leverage hard partitioning where possible: If your environment and technical skills permit, utilize Oracle-approved partitioning technology. This could involve using Oracle Linux KVM with CPU pinning, Oracle VM Server, or even Docker with hard CPU limits (although Oracle doesn’t officially support Docker as hard partitioning). Some technologies, such as IBM PowerVM, can limit the number of cores, and Oracle accepts specific configurations. Review the latest Oracle Partitioning Policy document for the list of acceptable methods and see if any align with your infrastructure capabilities.
• Cloud with caution: If moving Oracle to the cloud, use Oracle’s cloud (OCI) or an “Authorized Cloud” provider under Oracle’s cloud licensing policy. In such cases, adhere to Oracle’s rules (for example, Oracle Database Enterprise on AWS counts two vCPUs as 1 license, with a minimum of 4 vCPUs). Ensure your cloud architecture doesn’t inadvertently violate policies (e.g., using an unauthorized cloud region or provider). If you use VMware Cloud on AWS or a similar solution, treat it like on-premises VMware for licensing purposes – the same issues will apply.
• Explicit licensing agreements: Sometimes, you can negotiate contract clauses that specifically allow your partitioning strategy. For instance, you might get Oracle to agree in writing that only certain hosts will be counted. This is best done at the time of purchase or when the ULA is signed. If you have a heavy VMware-based environment, consider negotiating a custom clause. It’s not easy – Oracle sales reps prefer to avoid deviating from standard policies – but large deals have seen concessions that can be referenced during audits.
• Continuously monitor compliance: Virtual environments change frequently – VMs move, and clusters expand. Make license compliance checks a part of your change management process. Immediately assess the license impact if a new host is added to an Oracle cluster. If an Oracle VM accidentally runs on an unlicensed host, make a note and ensure it doesn’t happen again (and be prepared to defend why that shouldn’t count, though Oracle might count it anyway if seen in audit logs). Some companies utilize features like VMware’s affinity rules to technically prevent Oracle VMs from being moved to certain hosts. Use these features and keep screenshots or records as evidence of your controls.
• Bring in experts if audited: If Oracle announces an audit and you have a complex virtual environment, strongly consider getting a third-party Oracle licensing expert or legal counsel experienced in Oracle audits. They can help push back on overreaching and navigating Oracle’s claims. For example, Oracle’s position on VMware has been challenged in some legal cases (because the contract doesn’t explicitly mention it). While most customers settle, you may have more leverage than you think – specialists can advise where the “give” is in Oracle’s stance.
• Cost-benefit analysis of consolidation: Sometimes, the simplest solution is to reduce the footprint of Oracle software in virtualized environments. For example, consolidate databases to fewer servers (even physical if needed) to minimize the number of hosts you must license. Alternatively, consider using alternative technologies for certain workloads to reduce the size of that Oracle cluster. It’s a strategic decision: perhaps it’s worth having a dedicated physical machine for a specific Oracle DB instead of virtualizing it in a large cluster to manage the licenses. Evaluate these trade-offs as part of your capacity planning.

🔍How CIOs Can Regain Control of Oracle Licensing

Do you want to know more about our Oracle Advisory Services?