As many have heard, Oracle recently announced a change in the way Java SE is licensed. The Processor and Named User subscription models, not even four years old, have been sent packing, in favor of a new “Employee” metric. Oracle has changed the definition of a new “Employee” as follows:
Employee for Java SE Universal Subscription is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employees, part-time employees, and temporary employees of your agents, contractors, outsourcers, and consultants that support internal business operations. The required number of licenses is now determined by the number of employees and not just the actual number of employees using the programs.
How can you ensure this new system does not increase the price of your current Oracle contract?
Oracle had begun quietly introducing this model to select customers in the latter half of 2022, presenting it as a much “simpler” way of licensing Java, cutting past all of the report-pulling and number-crunching present under the “old” model, especially for customers with highly-virtualized on-premise environments. While this is true, it, unfortunately, preserves the age-old problem that was/is present in Processor licensing: the requirement to license infrastructure/personnel that are not even using the product, and likely would never utilize it, simply because of the realities of modern virtualization technology. Instead of requiring what is effectively an enterprise-wide licensure of the hardware, Oracle has converted to an enterprise-wide licensure of people. If you have one employee out of 10,000 that downloads Oracle Java SE onto a server, laptop, or another device in your environment, you are now liable for $990,000 in annual subscription fees ($99 per year x 10,000 employees).
Here are a few things we at ISAM would look at when evaluating this change in licensing from Oracle:
Know Your Rights
Make no mistake, Oracle is going to leverage this change to try and bully customers into giving them all sorts of information. They will likely request things like AD lists, department headcounts, etc., in the supposed spirit of trying to accurately determine usage. It can be easy in the rush of trying to satiate a salesperson or analyst to simply pull a report and hand it over. However, it’s very likely that your Oracle rep has zero right to ask for any of these reports or documents. Be sure to consult the most recent version of your Oracle contract or MSA to determine what documentation (if any) you are required to provide them outside of an audit situation. State this very clearly to them, or ask them to show you where you’re required to furnish the requested data. You can give Oracle what you believe to be your employee count; if they don’t want to believe you, they can send an audit letter if they want to explore further. This can be a scary tactic for some, but you must show Oracle that you’re not going to be pushed around or let them snoop through your books unabated.
Limit Communication
Like any software vendor, there are likely many points of contact between Oracle and your organization. This is certainly helpful from a technical standpoint, as it allows problems to be addressed more efficiently. However, in this situation, we would recommend taking an “audit stance” and to communicate with Oracle viz-a-viz a single point of contact. This helps ensure that Oracle’s representatives are not wandering around your organization (virtually speaking) and asking questions that they shouldn’t be asking. Any information that Oracle does receive should travel out only through this single point of contact. It could be a director or procurement officer, and whoever it is, Oracle stakeholders should be aware of this person’s name and contact info and direct all correspondence with Oracle through this individual for the time being.
Use Current Contract As Precedent
If you’ve already signed a Java subscription agreement, be sure to make Oracle aware that you consider the change to the licensing model an Oracle change and not a change for the way you use or budget for Oracle. If you’re paying $500,000 per year now under the “old” model, you expect to be paying around $500,000 under the new metric as well. In addition, comb your contract for anything relating to price uplifts or price caps, and use these as guardrails against potential uplifts. If you agreed to a 5% price uplift under the old model, we would argue that you should see no more than a 5% overall uplift under the new model as well. Again, just because Oracle has changed how they sell the product does not mean you’ve changed how you use the product.
COMMENTS