Everything is running along just fine for your organization’s Oracle product – or so you think. But many organizations using Oracle products don’t know until it’s too late that a feature – or multiple features – has been turned on without their knowledge.
When this happens, there are typically no signs that could alert admins something has been activated; while DBAs with licensing issue experience sometimes set up alerts to notify them when a feature has been turned on, the uninitiated rarely think to do this.
Often, admins only learn about this when Oracle slaps them with a large bill for the unused feature.
If you didn’t know better, you might think that a simple phone call to your account rep would clear this up – but that’s never the case. When Oracle discovers a feature has been running, they collect fees to the tune of cost-of-the-feature-plus-30% annually for the Oracle support fees accrued, regardless of how long you’ve been a customer, how big your contract is, or how many drinks you bought your sales rep when they came to visit the office last year.
Got $200,000 in Your Wallet?
Just ask our client, who we’ll call Quality Enterprise Service Solutions, or QESS. QESS is an enterprise software solution provider and had been an Oracle customer for over a decade. When QESS was audited by Oracle, the organization was found in violation of its licensing agreement – the Oracle Diagnostics and Tuning pack had been turned on without the knowledge of QESS’s admin.
QESS did not use any of the Diagnostics and Tuning pack features, but its leaders suddenly found themselves owing Oracle $200,000 in unpaid fees. To eliminate future compliance problems, QESS purchased an Oracle Database Appliance (ODA), which is a preconfigured engineered system including hardware, networking, storage, and software. With the ODA, QESS believed their organization was protected from future license agreement violations.
But that wasn’t the case.
Don’t Flip That Switch
The consequences of turning an unneeded Oracle product on can be far-reaching and very, very expensive. In QESS’ case, they engaged a managed services provider (MSP) that accidentally violated QESS’s license agreement with Oracle. And they aren’t alone; 56% of organizations outsource their Oracle management. If any employee or third party — including an MSP — inadvertently violates the Oracle agreement, you’re on the hook.
The same is true if Oracle support asks an admin to execute a script that uses a feature outside of their organization’s licensing agreement. Another common time to lapse into non-compliance is during an infrastructure change. Whenever hardware is updated, organizations always run the risk of a misstep that could cause a licensing violation. Additionally, Oracle’s products default to turning on when installed, so they’re likely “on” unless someone manually turns them off. One way around this is to create custom templates, which QESS eventually adopted, specifying exactly which features will be allowed.
Other methods to avoid running afoul of Oracle’s licensing include disabling features or uninstalling components. However, there’s no substitute for employing an expert ally to let you know what Oracle is going to see before it does.
Catch It Before Oracle Does
After replacing some hardware two years later, QESS engaged LicenseFortress to make sure it was still operating in compliance. On day one of the audit, LicenseFortress discovered that QESS was once again in violation of its licensing agreement with Oracle. Had Oracle caught these violations instead of LicenseFortress, QESS would have been assessed over $3 million.
The moral of the story is simple: Anyone can lapse into non-compliance, and it’s tough to catch unless you know exactly what to look for. The best way to prevent this is to partner with a compliance monitor who has the experience and know-how to know what to look for and has your back. I think I might know a good one.