What does it mean to be Oracle compliant?
Oracle is intentionally vague on what it means by 'compliance'. Let's clear the smoke from the mirrors.
Compliance is a complicated topic full of traps, misdirection, and vagaries.
Sifting through the jargon can feel like an uphill climb whilst wearing a blindfold, but it’s something all organisations need to constantly remain aware of and work on to avoid fines or penalties.
But throughout this guide we’ll be focusing on one area of compliance: Oracle license compliance.
As you’ll be aware, Oracle will only support a certain product for a few years until it falls down the pecking order of the support pyramid where it falls out of support entirely.
The trick here is that customers are expected to continuously upgrade to the latest version to maintain the top-tier level of support.
Along this upgrade cycle, Oracle customers will be in the ever-present shadow of Oracle’s ‘licensing police’, looking for any opportunity to catch them red-handed and fine them — and/or force them towards upgrading to its Cloud.
How do they do this? Well, with a lot of smoke and mirrors.
We’ll explain how by first highlighting 3 ‘tools’ Oracle likes to wield to confuse customers and keep them worrying about licensing compliance.
1. Matching Service Levels Policy
From Oracle’s own Software Technical Support policy document:
This policy simply states that if you use two or more products from the same license set, not only do you have to license them on the same basis - i.e., per processor - but you must have them on the same (matching) support level too.
It’s essentially an ‘all-or-nothing’ approach to support.
For example, an organisation has a license for both Oracle Database Enterprise Edition AND a related product like Partitioning, both of these must be on the same level of support, whether that’s Premier, Extended, Sustaining, or not at all.
Oracle’s Matching Service Levels Policy is regularly used as a tool by its sales teams to keep customers hooked on its upgrade cycle, but we’ll go into that more in the next section.
For now, let’s look at another of Oracle’s sticks it uses to beat the compliance drum…
2. Vendor Audits
Oracle audits its customers to monitor how organisations are using its software.
There are many triggers that could put your organisation in the crosshairs of an Oracle audit.
These include, but aren’t limited to:
- Acquisitions or mergers
- Employees raising support calls with Oracle for products that you are not licensed for or are under-licensed for
- Requesting an optimisation from Oracle, or even visiting certain optimisation webpages on its site
Customers who are subject to an audit will receive notification from Oracle that it is exercising its contractual rights to delve into how the customers are using its software.
Organisations will typically have 45 days to respond to this initial notification and come up with a plan before Oracle conducts its analysis and then reports its findings.
Again, we’ll go more into the tactics Oracle adopts in the next section.
Oracle also conduct what many call ‘soft audits’.
These can occur when an organisation contacts Oracle looking for help managing their licenses, or when it offers to help with their ULA certification.
When Oracle acquires the necessary information to ‘help’, it may pass this information onto its audit teams to review, commencing an official audit process.
3. Market Driven Support (MDS)
Finally, we come to MDS; we spoke about MDS at length in our previous guide.
MDS is a limited and less common support option, separate from the standard levels of Premier, Extended, and Sustaining support.
It’s sold on the idea that it helps organisations remain supported, even outside the Premier Support cut-off date (our previous guide explains the flaws in this offer).
MDS is essentially a stopgap before an organisation is forced to upgrade at great cost and time.
These are just three of the ways Oracle uses compliance either as a marketing tool (MDS), or a scare tactic (Matching Service Levels Policy, Audits).
And remember, this is Oracle license compliance, and has nothing to do with corporate or regulatory compliance.
But simply using the word ‘compliance’, and threatening ‘noncompliance’, is sometimes enough for this tactic to work in Oracle’s favour.
In our next section we explain why this doesn’t have
to be the case >>
Oracle’s third-party scare tactics.
Oracle will suggest that choosing third-party support could make you noncompliant. But this is not true...
Oracle’s approach to compliance is built around confusion and vagaries that confuse the customer.
If it confuses them enough, they’ll stick with the ‘devil they know’ rather than seeking better alternatives.
But organisations can remain ‘Oracle license compliant’ by partnering with a third-party support provider such as Support Revolution, whilst saving at least 50% - alongside many other benefits.
This is further supported by the customers that have chosen to go with third-party support.
Our customers include global authorities, world banks, and bodies at the highest levels of government - like the Financial Conduct Authority (FCA).
This is the financial regulatory body that sets the standards for financial compliance. If compliance was an issue, it simply would not have used us for support.
But Oracle don’t want organisations knowing this.
In fact, compliance is a prominent sales and marketing tool to keep customers hooked on its support, despite alternative cheaper options being available.
Support is a big cash cow for Oracle. In order to retain this significant portion of its revenue*, it needs to keep its customers hooked. What better way to hook them than to create the image that third-party alternatives could render them noncompliant?
The more Oracle can get its customers questioning the legitimacy of third-party support, the more likely they are to stick with them based on familiarity alone.
This is the beginning of its smoke and mirrors tactics. But let’s shed some light on all the uncertainty.
Matching Service Levels Policy
Oracle’s business model depends on strong retention for its support business, with all roads lead to getting customers to upgrade to the latest supported version, even if this isn’t in their best interests.
Its Matching Service Levels Policy is a case in point.
Customers must have the same level of support for all licenses in any given license set.
This means many customers are forced to pay for support on licenses they may not want support for, or may not even use anymore, just to keep other licenses in that set (that they do use) supported.
This forced license support compliance pushes customers down a much more expensive path than they otherwise need.
Consider a customer that buys Oracle Database licenses for one system from one vendor, and then a couple of years later, buys another set of Oracle Database licenses for another system from a second vendor.
All good so far.
But, a few years down the line, Oracle will want you to maintain all Oracle Database licenses on the same support level.
Vendor 1 may have a new version of their software running on the latest Oracle Database version – all good still.
Vendor 2 may not offer a new version and need you to run on the
older version of Oracle Database, which is likely “unsupported” by Oracle.
So now to stay “compliant”, you need to pay Oracle for Premier Support for one system, but the older system version is already out of support.
According to Oracle’s rules, you must pay them for Premier Support on both, but Oracle will only offer you Premier Support on one system and Sustaining Support on the other (where you get no new patches, bug fixes or security updates), so you are paying for services you cannot possibly receive. Oracle knows this.
Its Sales Reps may try to confuse customers around what level of support they think they should be on; remember it’s all in black and white in the terms of your contract.
If you’re unsure of something they’ve said that doesn’t match your contract, get them to put it in writing.
Managing and keeping track of all your license agreements can be a complicated administrative task.
Keeping track of all the licenses you need to be supported on will help to prevent Oracle pushing you into an unnecessary upgrade.
Third-party support offers a much more flexible option where organisations can choose what licenses they want supported, whether current or legacy – no desupport dates here.
This is possible as Support Revolution aren’t aiming to make large profits from our customers. We provide the flexible support service that Oracle should have offered all along.
Oracle uses licensing compliance as a stick to beat the Cloud upgrade drum with.
It audits its customers’ usage of its software to squeeze every penny from the support cash cow and push them towards upgrading to its Cloud services.
Each audit can be different from the last, but they all follow a similar ABC methodology…
The ABC tactic
This involves Oracle looking anywhere it can to challenge the customer on its license compliance. In many cases, customers will fall foul of being ‘compliant’ and therefore deemed ‘noncompliant’ (as defined by Oracle).
But this will be partly due to the customer’s misunderstanding of the requests made by Oracle around what they need to provide for the audit, and partly due to the maze of contracts and vague policies that Oracle can utilise to always find something to pull them up on.
Oracle knows its customer.
So, it will know the compliance challenges it will be facing beforehand and will use this as leverage to bargain with once it inevitably finds something to fine the customer for upon completing the audit.
But fear not weary customer!
Oracle has a convenient solution to its self-imposed problem.
It will be willing to offer a deal to move to Oracle’s Cloud deal.
Now, the customer may reduce or even ‘get out’ of the fine, but they have potentially signed up to a multi-year software service that they aren’t ready for, may have no use for, and/or are paying way over the odds for.
This tactic helps Oracle to inflate its fledgling Cloud numbers (compared to the likes of AWS, Microsoft, and Google) as it struggles to keep up with the bigger names in the Cloud race*.
Oracle has created a convenient win/win game for itself…
It imposes an audit on a customer at any time (it chooses the rules).
If the customer doesn’t comply, they will be in breach of their contract (all licensees in their contract agree “to cooperate with Oracle’s audit and provide reasonable assistance and access to information”).
If the customer does comply, Oracle will almost certainly find something they don’t like, and as a result, be subject to fines and pressure to move to its Cloud.
So, when it comes to licensing compliance, Oracle are self-appointed judge, jury, and executioner. It chooses the game, who can take part, and has already decided the outcome before it’s even begun.
We’ve even seen Oracle go to court because of its egregious licensing audits.
The court cases (summary):
Oracle vs Carrefour
- Oracle took Carrefour to court after it refused to run certain scripts on its system as part of an audit.
The court ruled Oracle could not order Carrefour to run the scripts because:
- there was no obligation in the contract for the licensee to do so.
- running scripts is not recognized as a valid investigative measure under French procedural and intellectual property laws.
Mars vs Oracle
- Oracle requested Mars provide information regarding its virtualized environment.
- Oracle specifically requested Mars provided information regarding all clusters and servers in Mars’ virtual environments.
- Mars had already provided 230,000 pages of documentation, and subsequently refused additional requests for yet more information.
- Oracle accused Mars of being in breach of its licensing agreement.
- Oracle then issued successive notices of termination of Mars’s right to use any Oracle software.
- The case didn’t end up going to court, but with Mars requesting a dismissal of the case, with prejudice.
Oracle vs AFPA
- After several audits against the AFPA (the French national association for the education of adults) – a long-term customer of Oracle nonetheless – Oracle highlighted significant licensing shortfalls, and demanded they pay over EUR 3million.
- After negotiations fell through, Oracle sued the AFPA for copyright infringement.
- The Paris District Court dismissed Oracle’s claims, which it appealed.
- The AFPA filed a counter claim for damages and the court awarded them EUR 100,000 citing: “Oracle abused its audit right in order to put pressure on its licensee to acquire new licenses which were, in fact, not necessary.”
Market Driven Support (MDS)
MDS is Oracle’s version of third-party support – albeit the poorer and more costly relation.
Oracle’s advice with MDS is that it can support an organisation’s critical systems, keeping them compliant without needing to upgrade.
As previously mentioned, we wrote about how MDS falls far short of this in our previous guide.
And while MDS delays the customer’s need to upgrade, it merely pushes the cost down the road as Oracle will be expecting the customer to upgrade eventually whether they want to or not.
Remember, choosing MDS is all in the name of remaining supported and compliant while the customer readies themselves to upgrade.
But customers don’t have to stick with the vendor during this process to remain supported and compliant.
Third-party support can act as a long-term solution to support, or a temporary stopgap while an organisation prepares to upgrade or transition to a new provider.
Oracle uses MDS as yet another hook – sold on the promise of remaining compliant – to keep organisations within their support eco-system.
Avoiding Oracle’s pitfalls and traps >>