By: Craig Guarante
I’ve written frequently about Oracle and the company’s strategy of milking its customers for as much revenue as possible through a rigorous and intrusive auditing process. In a recent conversation for the Early Adopter Podcast with Palisade Compliance’s CEO Craig Guarente, I learned about Oracle’s newest auditing angle: Java audits.
Increasingly, as the business has aged, Oracle has focused less on technological innovation to attract and please clients, and more on licensing and audit practices to generate maximum revenue. The latest example of this involves the Java language, which Oracle acquired in its acquisition of Sun Microsystems.
Java has a runtime that is widely available and used for free most of the time, powering many software programs. Oracle also sells a licensed version of the runtime with enhanced support and security patches. Oracle has long been in the business of using its leverage on software audits to encourage customers to buy more products. It’s now starting to do audits aimed at promoting sales of its premium Java version.
Guarente and I delved into this topic during the podcast (you can read a full Q&A of the conversation here), as well as discussing Oracle’s overall approach to audits. His company, Palisade Compliance, is a consultancy that helps Oracle clients navigate licensing audits and negotiations. I have worked with Guarente and Palisade Compliance on content and research projects for several years. He can offer a unique perspective into Oracle, as he worked there for 16 years and managed Oracle’s compliance team. This is a condensed version of the most salient points from our conversation.
Can you explain the way that Oracle uses audits and license and how it differs from most other software companies?
Oracle software is found throughout the stack. It’s the database, it’s the middleware, it’s the applications. Now it’s embedded in the hardware. So that’s one thing that’s different about Oracle: they want to be in end-to-end. It makes it really difficult for customers to just stop using Oracle and to use something else. They embed some pretty onerous terms into their contracts, to the point where even if a customer can technically move away from Oracle products, contractually they still pay Oracle for products they’re not even using, which is pretty amazing.
In the world of Oracle, the prior restraint has been taken away from the use of the software. Unlike most software vendors, Oracle takes all the license keys off of software that it buys when it does an acquisition and Oracle software doesn’t come with any license keys. So clients can use it as much as they want. Why does this lead to problems?
The interesting thing is it’s often the customers who wanted those keys removed. They want to use more stuff from XYZ company, and they didn’t want to go through the contracting process. Oracle is more than happy to oblige. But be careful what you wish for, because you may get it. Oracle pulls all the license keys out, and now you’ve got DBAs and technical people downloading software from the Oracle website and the company doesn’t know what they’re licensed for. They just start using the software or premium features because they think use is unlimited or included with what they already bought. That presents a challenge for customers.
Oracle is not just saying, “We trust you to pay us.” They then have an audit process. And could you explain how the process works?
With Oracle, you can use whatever you want, technically. But contractually, there are limitations on what you can use. Oracle’s audit team will send a letter to a specific Oracle customer and say, “Hey, per our contract we’re allowed to audit you, and we’re going to conduct an audit right now.” And there’s a back and forth, and information is shared from client to Oracle and Oracle will generate a position. They take a very liberal interpretation of what’s required for licensing. If you get an audit letter from Oracle, it’s not an accident. You’ve been targeted for an audit and Oracle thinks that there’s money to be had.
After the audit finds that you’re in violation, there’s a big number that companies have to pay to come into compliance. And that’s when the negotiations begin. What happens at that stage?
You must negotiate with Oracle. Through the audit, Oracle will throw the biggest number against the wall and then the sales team will say, “But if you do this unlimited deal for $10 million, we’ll let go of that $100 million. We’ll forget about the noncompliance.” So a client looks at that and goes, “Well, it’s either $100 million or $10 million. Boy, $10 million looks really good.” And what they’ve done is not only give Oracle $10 million that they might not have had to but now Oracle puts all new contracts in place, tightens them up, and limits a customer’s future flexibility. So it’s a double win for Oracle. They get money, and they lock you in even further. It’s a huge revenue source for Oracle. On the other hand, you upset a lot of customers by doing this. And the more aggressive you are with your auditing, the more frustrated your customers get with you.
Now the audit process is looking not just at traditional software licenses, but also at the use of Java. What strategy is Oracle using for auditing Java?
They’re approaching Java differently right now. It’s taken them about ten years to try to monetize Java. Oracle’s being really smart about this, because they’re not auditing customers to get them to buy Java, but they’re worrying customers to get them to buy Java.
Can you explain the vulnerability that customers have with respect to Java?
Oracle made many changes in how they distribute and support Java. It changed this month. You use a version of Java, the current version of Java, Oracle will support that version, quote-unquote, for free for six months. After six months, if you want support for that version, you have to pay for it. So customers are left with two choices: either get a license from Oracle and pay for support, or run a version of Java for free that’s unsupported. So if there’s a hole or a patch or an update or something security-wise, they’re running without that. So technically, it’s possible to run without that license and not to pay Oracle.
When is this a serious problem for a company?
I think it will become a serious problem if you are out of compliance with your license, and you haven’t bought that license from Oracle, and you’re using it in a noncompliant way. And they’re going to go back and they’re going to find these huge audit problems. I think people need to worry about it now. The rules changed in June. Now, if you’re using a prior version and you’re going onto Oracle’s support website and downloading patches and updates for something that technically you can’t use anymore, that’s a problem. It’s only a matter of time.
How can people reduce their risk of a Java audit?
The first thing is getting educated, really understanding what the rules and the policies are. Look at how you’re using Java. And consider your options and alternatives, not only options in terms of licensing from Oracle but also options in terms of Java products that are not Oracle, like open source Java.