Five Oracle Licensing Pitfalls to Avoid 🚨

Oracle has been in the process of moving its complex installed base to the cloud ☁️ for some time now, changing from on-premises perpetual software to a subscription-based model 🔄. Those at the helm of SPVM, who may have recently wrestled with the intricate licensing rules and metrics, as well as the ever-present danger of more compliance audits 🚨, must now adapt to a totally new cloud environment.

Putting too much trust in Oracle’s impartiality, even when it’s your strategic partner, might not always be smart when transitioning from on-premises to Oracle Cloud ☁️. For example, while the risks of unused software in on-premises systems are well-known, these same risks continue in the cloud as Oracle has a knack for overselling 📈. The complexity of contracts remains, and getting significant concessions from Oracle hasn’t gotten any easier.

For clients who opt to stick with Oracle’s on-premises software, the twisted nature of licensing terms, metrics, and functionality can quickly lead to non-compliance issues ❌.

This article uncovers risks that present and future Oracle clients might face. It highlights the top five most common traps to watch out for, grouped into two key areas: compliance and pricing 💸.

Recognizing and dealing with these risks when the opportunity arises is vital 🔑.

Java licensing changes

As of 23 January 2023, Oracle shook up its Java licensing structure. Moving away from the Named User Plus and Processor models, it transitioned to a single Employee metric. Now, organizations needing a chargeable Java version must license every employee, agent, and contractor, regardless of their direct Java usage. This is relevant for Oracle Java SE 8 (from updates 8u211 or 8u212 onwards) and all versions of Oracle JDK 11 LTS.

These mentioned versions fall under the My Oracle Support license or the Oracle Technology Network (OTN) License Agreement for Oracle Java SE. This limits its use to personal, development, and certain Oracle-related purposes 🔒. Considering that the majority of Java applications run on Java SE 8 or JDK 11, this might be confusing for many users 😕. For a detailed understanding and a list of Java distributions that don’t require a Java SE subscription, check out the Oracle Java SE Licensing FAQ.

If you’re using Oracle JDK (including both JRE and JDK), you’re likely required to get an Oracle Java SE subscription. However, Gartner’s feedback suggests that many organizations might be unaware of these changes, possibly leading to unexpected costs 💸. Furthermore, Oracle’s specific Java licensing team is actively contacting clients about their Java SE usage and is quick to highlight any noncompliance 🚨. Organizations should be ready for Oracle’s attempts to collect data on Java deployments, possibly seeking retroactive fees from the 2019 licensing shift, or offering to waive these in return for longer subscription commitments.

Recommended steps include:

1. Procuring a Java SE subscription 🖋️
2. Transitioning to the complimentary Oracle JDK 17 🆓
3. Updating to the latest Open JDK version 🔃
4. Considering third-party Java solutions 💡

If you decide on an SE subscription, make sure to familiarize yourself with the Oracle Partitioning Policy and refer to the subsequent Virtualization section for insights 🔍.

Bonus: Be prepared for possible outreach from Oracle’s Java licensing division 📞. When engaging, confirm what data you’re legally required to share with Oracle – they might not have rights to all deployment details 📊.

Oracle’s view on virtualization

While Oracle does recognize the physical division of a server, such as cutting down the need for licenses, it doesn’t give the thumbs up to virtual division through technologies like VMware. In the scenario of physical division, you can distribute licenses less than your infrastructure’s full capacity 📉. However, this flexibility doesn’t stretch into a virtualized setup.

Oracle’s stance on partitioning essentially means that deploying their software on virtualized servers requires payment 💵 for not just the virtual server cores but the entire supporting physical core infrastructure. This problem grows with VMware vSphere version 6.0 and newer, as it allows extensive virtual machine migrations, even between different vCenters.

Imagine you create a virtualized Oracle cluster with three virtual machines running Oracle software 🖥️🖥️🖥️, use VMware vSphere 7 or a more recent version, and have 200 physical servers acting as hypervisors. You’ll need to assign Oracle licenses to all 200 physical servers, not just the three virtual ones in your Oracle cluster 🎫. This principle applies to other virtualization technologies that enable virtual machines to roam across large physical setups.

Here’s what you should consider doing:

• Raise awareness 📢 that Oracle’s partitioning policy has a narrow interpretation and isn’t part of the formal contract.
• Try to negotiate changes to your Oracle contract 📝 by pinpointing the environment that needs coverage. This is also called an isolation clause. Oracle agreeing to define a portion of your physical setup might likely be at the cluster or vCenter level 🎯.
• If it’s financially sensible 💰, think about entering into an Oracle unlimited license agreement (ULA). This can offer, for a limited period, relatively unrestricted deployment. For more details, check out How to Prepare for Certification or Renewal of an Oracle ULA 📘.
• If you find yourself in the middle of an audit 🔍, pinpoint where your virtual machines were located over time to align with Oracle’s definitions (Refer to Take Control of Your Oracle License Audit to Optimize Costs).

Preinstalled Oracle DB features

The complexities of Oracle’s licensing terms often turn Database licenses into a hot spot for audits 🔍. Three main considerations add to the confusion:

First, specific options and packs, like Advanced Compression and Tuning Packs, are only allowed for Oracle Database Enterprise Edition (EE) 🏢. This means they can’t be installed over lesser editions like Oracle Database Standard Edition (SE).

Second, the licensing for these packs and options must align with the number of EEs they enhance, and in the exact same metric 📊. For example, if you have 100 processor licenses for EE, you can’t have just 50 processor licenses for a Tuning Pack, even if you’re using fewer than 100 processor licenses. This rule is often overlooked, leading to instant noncompliance ❌.

Third, it’s commonly forgotten that EE comes with nearly all features, options, and packs by default ✅. However, if the client opts to use these extra components, they must lock in the needed licenses. It might seem counterintuitive to some to turn off functions in a newly obtained license, assuming the vendor would only provide what was bought. Nevertheless, settings can be tweaked to disable particular options and packs on Database servers 🛠️.

To handle these intricacies, here are the recommended steps:

• Continually monitor your consumption and match it with your entitlements and Oracle’s rules 📈.
• Use tools or external expertise to measure your compliance (see Note 2: How to Track Your Oracle Usage) 🔧.
• Tackle the problems with corrective actions like turning off functions or acquiring missing licenses 🛑.
• Implement upstream solutions such as changes to deployment or provisioning policies 🔄.
• Negotiate contract adjustments (which would require some bargaining power on your part) to set up Oracle vCenters both with and without specific options and packs 📝.

Support and maintainace lock-in

Oracle’s software support policy is hidden away without an explicit layout or direct link 🖇️ in the standard Oracle Master Agreement. As a result, many customers overlook the limitations this policy imposes when they decide to cancel support on software licenses that have become unnecessary (commonly known as shelfware) 📦. This confusion often leads Oracle customers down a path of escalating costs 💸 for maintaining licenses that will never see the light of day.

There are two specific clauses in the technical support policy that usually put the brakes on resizing the software estate and reducing expenses:

Matching Service Levels 🔄

This clause states that all licenses in a given set must receive the same level of technical support. Simply put, it stops you from selectively supporting only some licenses within a set. Let’s say you have 50 Enterprise Edition Database licenses but only need 40; you can’t just drop 10 from support, as it would break this rule ❌. Oracle would allow you to terminate the extras with a termination letter 📝, but don’t expect a corresponding decrease in support costs.

Pricing Following Reduction of Licenses 💵

This part specifies that support pricing is set by the number of licenses in the original order, which makes sense since the support fee is a percentage of the license charge. Buy more, and each one may cost less 📉. But if you end some (but not all) licenses under one Customer Support Identifier number (CSI), Oracle will reprice the leftovers on that CSI. You might find yourself with nearly the same bill for fewer licenses 🧾.

Both of these clauses can trap the unwary, making Oracle’s hidden policy a potential pitfall for those looking to streamline their software portfolio. If you find yourself tangled in these terms, seeking professional guidance 🧠 or carefully reviewing the specific language in your agreement may be your best route to a cost-effective solution.

Recommended actions to steer through these complexities include:

• Consider bundling multiple separate support contracts through a co-terming exercise 📑. It might look good on paper, but tread carefully! Make sure to keep individual CSIs separate, and don’t lump all licenses under a single CSI number 🔢.
• Keep an eye on shelfware 👓. This often sneaks in when you buy extra licenses to snag higher discounts. Be smart, and only grab what’s necessary when it’s needed, because surplus licenses can turn into a real headache to get rid of 🤕.
• When you’re shopping for technology licenses with application licenses on the same order, be extra careful 🛒. Since these two types might live different lives within your organization, don’t rush into merging them in the same Unlimited License Agreement (ULA), without some serious thought 🤔.
• Lastly, don’t skip out on reviewing the Oracle software support policy 📜. Zero in on the license set definition and repricing clauses before splashing out on new licenses. A little homework upfront can give you a clear view of the potential long-term effects on your support costs, saving you from any unpleasant surprises down the road 🚧.

Hidden complexities in BYOL when oving to OCI or other clouds

Deploying Oracle software, including OCI ☁️, in public cloud settings is on the table, but there’s a twist. When using the bring your own license (BYOL) model, you have to be mindful of certain aspects when implementing Oracle programs, as cloud licensing requirements diverge from on-premises setups 🏢.

Only a few non-Oracle public clouds get the green light for Oracle software use, like Amazon Web Services (AWS) 🌐 and Microsoft Azure 📘 (aka “Oracle Authorized Cloud Environments”). With OCI, Oracle dishes out BYOL pricing at a thriftier per unit rate 💲 compared to the license-included option, but heads up – BYOL might not be on the menu across all product SKUs or for all versions (e.g., having version 10 at home but the BYOL equivalent is version 12 🔄). Conversion ratios, such as “1 Processor License = 2 Oracle Compute Units (OCPUs)” or “25 Named User Plus = 1 OCPU,” also come into play.

When deploying on AWS and Azure, you’ve got to tally up the max possible virtual CPUs (vCPUs) of an instance type as:

• 2 vCPUs = 1 Oracle processor license (if multithreading is on ✅)
• 1 vCPU = 1 Oracle processor license (if multithreading is off ❌)

These calculations can pad your licensing needs in these environments, potentially even doubling them ↗️. Plus, you might stumble upon some compliance risks 🚧 with BYOL usage under OCI. Oracle underscores that customers must keep perpetual license usage within bounds 📏, and that means staying in line with existing licensing entitlement quantities. Mixing BYOL pricing with license-included Platform as a Service (PaaS) for a particular workload? That’s a no-go 🚫. If you’re looking to scale, BYOL pricing might be best left on the shelf.

Recommendations:

• Scope out if any Oracle applications are buzzing in Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS), or Microsoft Azure. Tap into Oracle’s Licensing Oracle Software in the Cloud Computing Environment to tally up license needs, making sure you’re all covered ☂️.
• For OCI, verify the BYOL conversion must-haves and what’s in the package 🎁. Peek at the Oracle PaaS and IaaS Universal Credits Service Descriptions for SKU details.
• When hopping from on-premises to the cloud, Oracle only lets you have a 100-day window for the transition, with only a few exceptions. So, plan the switch with precision ⏳.
• Snoop around for Oracle’s Support Rewards program, which could be your golden ticket 🎫 to trimming down your on-premises tech support bills.

Navigating Oracle’s licensing labyrinth is no simple task. From understanding Java’s new licensing structure to the unseen challenges of virtualization and support maintenance, a wrong step can lead to unexpected expenses and non-compliance. Whether you are an existing Oracle client or considering a future engagement, arming yourself with these insights and suggested actions will help you to make informed decisions.

By being proactive, vigilant, and engaging expert assistance where necessary, you can successfully steer clear of these pitfalls. Remember, the journey with Oracle is not just about choosing the right technology but about understanding the terms and making wise strategic choices that align with your organization’s needs and budget. 🌐🎓

If you find our articles useful, register for our monthly newsletter for regular industry insights 👇