Module 8 opens on Oracle's most surprising audit front. Java ran everywhere and was free for most of its life, then Oracle moved commercial use to a paid subscription priced on an employee metric, your whole headcount, not your Java usage, so a firm running Java on 30 servers still licenses all 5,000 employees. This session reads the history, the metric, and the audit campaign built on Oracle's download records and friendly outreach, treated with full module 5 discipline. The decisive fact is that free, equivalent OpenJDK distributions exist, so for most estates the answer is migrate, which removes the metric bill entirely and gives you the leverage to settle any past claim from strength.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the 5,000 employee firm running Java on 30 servers that the employee metric still charges for all 5,000; the friendly Oracle compliance call that is an audit opening, not customer service; and the large quote answered by a tested OpenJDK migration. It closes with one Java estate decided, audit discipline plus a tested migration turning a headcount bill into a zero license outcome.
The full narration of this session, section by section, for reading and reference.
Welcome back, session thirty six of forty, and the opening of module eight, special topics and the capstone. We start with the one that surprises more estates than any other: Java licensing. Here's the whole story in miniature. Java runs almost everywhere, in servers, desktops, and embedded inside applications, and for most of its life it was free, so it was installed freely and tracked by no one. Then the licensing changed. Oracle moved commercial use of its Java build to a paid subscription, and then moved that subscription to an employee metric, priced not by how much Java you run but by how many people your company employs. The binary looked the same; the bill underneath did not exist before and now scales to your entire headcount. And most estates kept downloading and updating Oracle Java exactly as before, unaware, accruing a liability that only surfaces when Oracle makes contact. Today: how Java went from free to fee. The employee metric, and what it actually counts. The Java audit campaign, built on download records. OpenJDK and the free, equivalent alternatives. And the decision, stay, migrate, or subscribe, which for most estates has a clear answer. Module eight opens. Let's begin.
Five takeaways. One, you'll know the history: understand how Java went from free to a paid subscription, and why so many estates were caught unaware, still assuming free. Two, you'll read the employee metric: see why Java SE is priced by total employees, not by Java users or installs, and what that does to the cost. Three, you'll recognize the audit: spot the Java campaign, the download records, the soft outreach, and how Oracle builds the claim. Four, you'll know the alternatives: understand OpenJDK and the major distributions, and that they're free and functionally equivalent. And five, you'll decide the path: weigh staying on free builds, migrating off Oracle, or subscribing, with the real cost and risk of each. One sentence to carry: the free, equivalent OpenJDK builds are real, which makes the Oracle subscription a choice, not an obligation, and a tested migration is your leverage over both the future bill and any past claim. How Java became a bill, next.
Four words that frame Java. Free: what Java was, for most uses, for most of its life, and that long history is exactly why the shift to paid caught so many estates unprepared, because the habit of treating Java as free outlived the terms that made it free. All: the employees the current metric counts, not Java users, not installs, the whole organization is the unit, which makes the number large and the arithmetic brutal. Audit: the active enforcement front, because Oracle holds download records and runs outreach campaigns that turn a free assumption into a compliance claim, quickly. And zero dollars: the cost of the alternatives, because OpenJDK builds are free, functionally equivalent, and supported by others, which is why migration, not negotiation, is the real leverage in Java. Here's why Java earns the opening slot in module eight. It's the clearest case in the whole course of a licensing change catching estates by surprise, a free thing that quietly became a headcount sized bill. This session is about seeing that clearly and choosing deliberately, from your own assessment, rather than reacting to an audit letter on Oracle's timeline. The history, first.
Free to fee, how Java licensing changed, in stages, each one widening the gap between what estates assumed and what Oracle now charges for. The free era: for most of Java's life the Oracle JDK was free for general use, so it was installed everywhere, on servers, on desktops, embedded inside applications, with no license tracking anyone thought to keep, because why track something free. The paid pivot: Oracle changed the terms so that commercial use of the Oracle JDK, and crucially its updates, required a paid subscription, and the binary looked identical, the license underneath had changed. The metric change: the subscription then moved to an employee based metric, pricing Java by the whole organization's headcount rather than by installs or users, which enlarged the potential bill dramatically. And the gap that formed: estates kept downloading and updating Oracle Java as they always had, unaware the terms had shifted, quietly accruing a liability that only becomes visible when Oracle makes contact. Here's the precise nature of the danger, and it's not what people assume. It isn't that Java is unusually expensive per unit. It's that the metric and the terms changed while the habit of treating Java as free did not, so the exposure built silently, in the gap between assumption and reality. The metric, next.
The employee metric, in plain terms, because understanding exactly what it counts is the whole cost story. It counts all employees: the metric is total employees across the organization, full time, part time, and often contractors and agents too, not the number of people who use Java and not the number of installs. Not usage based: whether Java runs on ten machines or ten thousand, the count is the same, your headcount, which decouples the bill entirely from actual Java use, and that decoupling is what makes it so large. The arithmetic is brutal: a ten thousand employee company with Java on a handful of servers still licenses ten thousand employees, and per employee rates times the whole workforce is a very large annual number for a very little Java. And this is session thirty one's employee metric, returned: the same trap as the HCM versus Financials lesson, an employee metric applied to something only a fraction of the company touches charges for everyone, except here that breadth is the entire design, not a mistake to avoid. Here's why this matters so much for what follows. When the bill is your entire headcount regardless of use, even a modest per employee rate becomes a number worth engineering around, and that's exactly why Java migration economics are so compelling. Knowledge check one makes the count concrete.
Knowledge check one. A five thousand employee firm runs Oracle Java on thirty servers and a few dozen desktops. It considers an Oracle Java SE subscription. What does the employee metric charge for? A, the thirty servers and few dozen desktops actually running Java. B, all five thousand employees, regardless of how few machines run Java, because the metric is total headcount, not Java usage or installs. C, only the employees who personally use Java applications. Or D, a per install fee for each Java copy. Pause here. Does the Java employee metric count machines, users, or the whole company?
The answer is B, and this is the entire point of the employee metric, the reason it shocks buyers. The subscription is priced per employee across the whole organization, so all five thousand employees are counted, even though Java runs on just thirty servers and a few dozen desktops. The size of the Java footprint is irrelevant to the bill; the size of the company sets it. So a firm with a tiny, contained Java estate pays exactly the same per employee as one running Java on every machine it owns, which means the effective cost per actual Java workload here is enormous, five thousand employees licensed for what a few dozen machines use. B states it plainly. A applies the intuition from the perpetual world, license what runs it, which is precisely the assumption the employee metric overturns. C is the reasonable guess that the metric counts Java users, and it's wrong, the metric doesn't care who uses Java, only how many people the company employs. D imagines a per install fee, the old model, which isn't how the current subscription works. The lesson, and the reason this whole session exists: when the bill is your headcount and not your usage, a small Java footprint carried on the Oracle subscription is one of the worst value ratios in enterprise software, and that ratio is exactly what makes migrating off Oracle Java so attractive. Know what the metric counts before you ever discuss a subscription. The audit, next.
The Java audit campaign, because Java is enforced through a distinctive campaign that blends soft outreach with hard data, and recognizing its shape is the first defense. The download records: Oracle knows who downloaded Java updates from its site, tied to company domains and accounts, so that record is the evidence base, and it's often the opening move, we can see your downloads. The soft outreach: it frequently starts not as a formal audit but as a friendly review or a security advisory, an offer to help you get compliant, which is module five's soft audit in Java form, the same wolf in a helpful coat. The employee number: because the metric is headcount, the claim scales to your whole company instantly, so an initial figure can be very large, and that size is deliberate, it's designed to make the subscription feel like relief by comparison. And the module five discipline applies, all of it: verify the claim, don't volunteer data, control the scope and the channel, and never accept the opening number as fact. Here's the frame to hold: the Java campaign is engineered to convert a free assumption into a paid subscription quickly, using download data and a headcount sized number. It is an audit. Treat it with the full audit discipline of module five, no exceptions. Knowledge check two.
Knowledge check two. Oracle emails to say its records show your firm downloaded Java updates, and offers a friendly call to review your Java estate and get you compliant. What is the right first move? A, take the call and walk them through your full Java deployment openly. B, treat it as the audit it is: pause, assess your own Java estate internally first, control scope and channel, and don't volunteer deployment data before you understand your position. C, ignore it entirely, a friendly email isn't binding. Or D, immediately buy the subscription to be safe. Pause here. Is a friendly review an act of customer service, or the opening of an audit?
The answer is B. The friendly framing is the tactic; the audit is the reality, and module five taught you not to confuse the two. Oracle's outreach, however cordial, is the opening of a commercial enforcement action built on its download records, and the friendly call exists to gather the deployment detail that turns a general claim into a specific, priced one. B applies the audit discipline directly: pause, assess your own Java estate internally before engaging, so you understand your true position before Oracle does; control the scope and the channel so the conversation covers only what it must; and don't volunteer deployment data, because in an audit every fact you offer unprompted becomes part of the claim against you. A is the mistake the friendly tone is engineered to produce, an open walkthrough hands Oracle exactly the evidence it needs and forfeits your ability to shape the scope, and it's the single most common way Java reviews escalate. C is the opposite error, ignoring genuine outreach backed by real download data doesn't make the exposure disappear, it just forfeits your chance to manage it on your terms and can harden Oracle's posture. D panics into the subscription, the most expensive resolution, before even checking whether you can migrate off Oracle Java entirely and owe nothing going forward. The rule, straight from module five and now applied to Java: a vendor's friendly compliance review is an audit, so you run it like one, from a position you've assessed yourself, first. The alternatives, next.
OpenJDK and the free distributions, and this is the decisive fact about Java licensing: Oracle's JDK is not the only one. OpenJDK and its distributions are free, open source, and functionally equivalent. OpenJDK is the foundation: Java itself is open source, OpenJDK is the reference implementation that Oracle's own JDK is built from, so the language and platform aren't proprietary, only Oracle's specific build and support are paid. The free distributions: multiple vendors ship production ready OpenJDK builds at no license cost, Eclipse Temurin, Amazon Corretto, Microsoft, Azul Zulu, Red Hat, and others, each with its own free update stream. Functionally equivalent: for the vast majority of workloads a free OpenJDK distribution runs identical bytecode with identical behavior, and applications generally don't know or care which JDK they run on. And support is available too: if you want paid support you can buy it from several of these vendors, often below Oracle's employee metric, so you can have support without buying Oracle's headcount priced subscription. Here's why this fact changes everything. The existence of free, equivalent OpenJDK builds is precisely what makes the Java subscription a choice rather than an obligation. It's the credible alternative from session thirty two, made real, and here it genuinely costs zero in license. The migration, next.
The migration path off Oracle Java, which for most estates is a well trodden, manageable project, not a rewrite. Four steps. Inventory first: find every Oracle JDK across servers, desktops, and applications, and note the version, because you can't migrate what you haven't located, and that inventory doubles as your audit defense. Match the version: pick an OpenJDK distribution and a version that match your current Java, so applications see the same platform, and same major version means minimal or no application change. Test and roll out: test applications on the chosen distribution, then roll it out in waves, per environment, and most applications pass without modification, while the few that need attention are found in test, before production. And remove Oracle Java: uninstall the Oracle JDK and stop downloading Oracle updates, which both eliminates the subscription need and closes the download record that feeds the audit. Here's the shape of it for the great majority of estates: migration is a bounded engineering task with a large, permanent payoff, the employee metric bill, gone, replaced by a zero license runtime that does the same job. The exceptions exist and they're specific and identifiable, which is the decision we turn to next. Stay, migrate, or subscribe.
Stay free, migrate, or subscribe, the paths laid side by side. Migrate to OpenJDK: the default for most estates, free, equivalent, and it removes the metric bill entirely, with the catch being a bounded migration project and version testing up front, a one time cost for a permanent saving. Free Oracle builds: there are specific no cost use cases Oracle still permits, but read the terms carefully, because the catch is they're narrow and easily overstepped, and commercial use usually is not free. Paid OpenJDK support: right when you want vendor support without Oracle's headcount metric, and the catch is only that you pay a support cost, but one decoupled from your total employee count. Oracle Java subscription: justified when you have a genuine need for Oracle's specific build, features, or certifications, with the catch being the employee metric, your whole headcount, every year. And do nothing: never a strategy, it's an unmanaged liability, and the catch is that the audit finds it, priced at headcount, with back maintenance on top. Here's the honest bottom line for most estates: the answer is migrate, because the employee metric makes the Oracle subscription poor value for a contained footprint. Subscribe only where a real, specific need justifies paying your entire headcount. Knowledge check three.
Knowledge check three. Facing a large Oracle Java employee metric quote, a firm confirms its applications run fine on a free OpenJDK build in testing. What is the strongest position? A, subscribe to Oracle Java, it's the safe, standard choice. B, migrate to the free OpenJDK distribution, remove Oracle Java, and eliminate the metric bill entirely, using the credible migration as leverage even if negotiating any past exposure. C, do nothing and hope the audit doesn't escalate. Or D, pay for one year of Oracle Java, then decide later. Pause here. If a free, equivalent build runs your applications, what exactly are you paying Oracle's headcount metric for?
The answer is B. Once testing confirms the applications run on a free, equivalent OpenJDK build, the Oracle subscription has lost its justification, and with it Oracle has lost its leverage. B is the strongest position on both fronts at once. Going forward, migrating and removing Oracle Java eliminates the employee metric bill entirely and permanently, replacing a headcount priced annual subscription with a zero license alternative that does the identical job. And on any past exposure Oracle raises from its download records, the credible, tested migration is exactly the leverage session thirty two described: you're not a captive buyer choosing between paying and non compliance, you're a customer who can and will leave, which turns the negotiation over historical use from a ransom into a modest, bounded settlement, if anything is owed at all. A subscribes to a headcount bill you've just proven you don't need, the worst value in the room. C ignores real download evidence and lets Oracle set the terms and the timing, forfeiting the very leverage the migration would have handed you. D pays a full year of the employee metric to defer a decision the testing has already made, spending heavily just for delay. The permanent lesson, and the reason module eight opens right here: in Java, the free equivalent is real, so the subscription is a choice, and a buyer with a tested migration in hand negotiates everything, the future bill and the past claim alike, from strength. One estate, decided, next.
One Java estate, decided, the session in six rows. The letter: Oracle writes, our records show your Java downloads, and the firm treats it as the audit it is, running an internal assessment before any call. The metric: the quote covers all five thousand employees, and the firm understands what that means, headcount, not the thirty servers actually running Java. The estate: Oracle JDK on thirty servers and a few dozen desktops, inventoried in full, every version located. The test: do the applications actually need Oracle's build, and the answer, from testing on a free OpenJDK distribution, is no, the applications ran unchanged. The decision: subscribe at headcount, or migrate, and the firm migrated to the free OpenJDK build and removed Oracle Java. And the outcome, the bottom row: what began as a large annual employee metric bill became zero license cost, with any past exposure settled from strength. Look at what the discipline achieved. The exposure was real and headcount sized, a genuine liability, not a false alarm. But audit discipline plus a tested migration converted a large recurring subscription into a one time engineering project and a zero license outcome, and turned a ransom style claim into a modest settlement. Same letter, entirely different ending. Recap, and module eight underway, next.
Session thirty six in three sentences, and module eight is underway. One, Java went from free to a paid subscription priced on an employee metric, your entire headcount regardless of how little Java you run, and many estates accrued exposure without ever noticing the terms had changed. Two, Oracle enforces it with a distinctive audit campaign built on download records and friendly outreach, so you treat it with full module five discipline: assess yourself first, control scope and channel, and never accept the opening number. Three, the decisive fact is that free, equivalent OpenJDK distributions exist, so for most estates the answer is migrate, which removes the metric bill entirely and gives you the leverage to settle any past claim from strength. Next session continues module eight with the on premises applications estate: E Business Suite, JD Edwards, PeopleSoft, and Siebel. The application metrics that price them, the customizations that complicate every upgrade and audit, and the support decisions facing mature estates, third party support, extended support, and the road to Fusion or a stable steady state. The big applications, the ones many organizations still run at their core. Homework first.
Homework, about an hour, and it's the fastest path from exposure to a plan. One, inventory Oracle Java: find every Oracle JDK across servers, desktops, and applications, with versions, because that inventory is both your migration map and your audit defense. Two, size the metric: multiply your employee count by a per employee Java rate, and that headcount number is what a subscription would actually cost you, usually a sobering figure. Three, check the alternatives: identify which free OpenJDK distribution matches your Java versions, and confirm it's free and supported for your use. Four, test one application: run one real application on a free OpenJDK build, and most run unchanged, so note any that need attention. And five, check for outreach: has Oracle contacted anyone in your organization about Java, and if so, route it through the module five audit discipline, not an open walkthrough. See you in session thirty seven, for the on premises applications estate.
Five reads, all free on redress compliance dot com. First, the Oracle Java licensing guide: the employee metric and the subscription model, at reference depth, the written companion to this session. Second, Oracle Java audits, what to expect: the download records, the outreach, and how to respond with discipline. Third, migrating from Oracle JDK to OpenJDK: the distributions, the version matching, and the rollout, the how to for the path most estates should take. Fourth, Azul Zulu versus Oracle Java: a supported OpenJDK alternative, compared on cost and support, for when you want support without the headcount metric. And fifth, alternative Java options, exploring OpenJDK and others: the full field of free and supported builds. That's session thirty six, and module eight is open. Java went free to fee on an employee metric, it's enforced like an audit, and the free equivalent is real, so for most estates the answer is migrate, and a tested migration is your leverage over the future bill and the past claim alike. You can now face a Java quote or a Java letter from a position of strength. Next session, the on premises applications estate. See you there.