Oracle is one of the most expensive software vendors in any enterprise technology portfolio. That statement is not controversial. The Oracle database platform, the range of options and packs that extend it, the application suite across E-Business Suite, JD Edwards, PeopleSoft, Siebel, and Fusion Cloud, the middleware products, and the Java licensing obligations collectively represent a commercial commitment that for most large enterprises runs into the millions annually. The question that does not get asked often enough, and the one this blog addresses directly, is how much of that commitment reflects software that is genuinely being used versus software that is licensed, maintained, and renewed year after year because nobody has done the work to establish whether it needs to be.
Oracle shelfware is a specific and commercially costly version of the broader enterprise software waste problem. It is specific because Oracle’s licensing model creates forms of unused entitlement that are structurally different from unused SaaS seats. The Oracle Database options and management packs that were enabled years ago but are no longer actively used. The excess processor licences that cover servers which were decommissioned or reduced in capacity without a corresponding licence rationalisation. The ULA-certified licence counts that reflect the maximum deployment reached during the certification period rather than current and ongoing deployment. Each of these is a form of Oracle shelfware, and each has a support cost that is accruing regardless of whether the underlying capability is delivering value.
The Oracle Options and Packs Problem
Oracle Database Enterprise Edition is a powerful platform that is made significantly more expensive by the ecosystem of options and management packs that Oracle sells as extensions to the base database licence. Options including Partitioning, Advanced Security, Real Application Clusters, Multitenant, Active Data Guard, In-Memory Database, and Diagnostic and Tuning Pack are each separately licensed and add meaningfully to the cost of an Oracle database deployment.
The specific commercial risk of Oracle options and packs is that they can be enabled in a database environment without a deliberate purchase decision. Database administrators using Oracle Enterprise Manager to view certain types of performance data are activating the Diagnostic and Tuning Pack whether or not they know it. Features that are enabled by default in some Oracle database configurations may constitute option usage that triggers a licensing obligation. And options that were purchased for a specific project years ago may still be enabled in the database configuration even though the project concluded and the capability is no longer in active use.
Oracle auditors look specifically for these scenarios. The Diagnostic and Tuning Pack activation through Enterprise Manager is one of the most consistently cited findings in Oracle audit reports, precisely because it occurs through routine DBA activity without any intent to use a licensed feature. Organisations that have not specifically audited their Oracle database environments for enabled features and compared that against licensed entitlements are almost certainly running with either unlicensed options, in which case they face compliance exposure, or licensed options that are not being used, in which case they are paying annual support on entitlements they do not need.
InfoWorld covers Oracle database management and the commercial governance practices that enterprise organisations use to manage Oracle options and packs compliance and cost. Their InfoWorld Oracle database commercial management and options governance coverage provide technical and commercial analysis of how Oracle options and management pack licensing works in practice, including the specific enterprise management and database administration activities that create licensing obligations and the audit risk profiles associated with different Oracle database management approaches.
Excess Processor Licences and the Infrastructure Change Gap
Oracle processor licence counts are tied to the hardware on which Oracle software runs, and hardware changes over time in ways that should affect the Oracle licence position but frequently do not because nobody manages the two in conjunction. Server consolidations that reduce the physical server count, migrations from Intel to AMD processors that change the Oracle core factor and therefore the licence count, decommissions of physical servers as workloads move to cloud environments, and virtual environment changes that alter the sub-capacity licence requirement all create opportunities to reduce the Oracle processor licence count. In most organisations, these infrastructure changes happen without a corresponding Oracle licence review, and the excess licences carry on generating annual support costs at twenty-two percent of their net licence value.
The commercial opportunity in excess processor licence management is significant. For a large enterprise with a mature Oracle database estate that has undergone substantial infrastructure change over the past several years, the reduction in annual support costs achievable through a processor licence right-sizing exercise is often a meaningful percentage of the total Oracle support spend. The challenge is that Oracle’s support model does not permit unilateral licence count reductions without a commercial negotiation, and the timing and leverage mechanics of that negotiation need to be managed carefully to achieve the desired outcome.
Oracle Application Shelfware: EBS, JD Edwards, and the Installed Module Problem
Oracle application suites including E-Business Suite, JD Edwards, and PeopleSoft are modular platforms where individual functional modules are separately licensed. Over the years since these platforms were originally deployed, organisational needs change, processes evolve, and some modules that were licensed at the time of original deployment are now either not used at all or used by a much smaller user population than the original named user or processor licence assumes.
The shelfware problem in Oracle application licensing manifests as either modules that are licensed but not deployed, named user counts that reflect the maximum historical population rather than the current active user base, or processor licences that cover servers running application components that are no longer actively used. A systematic application module audit, mapping licensed modules against actual deployment and active usage, typically reveals optimisation opportunities that reduce the renewal cost of Oracle application licensing without affecting the organisation’s ability to use the platform for its active business processes.
The complicating factor is that Oracle’s application licence model includes minimum user requirements and interdependencies between modules that limit how far licence rationalisation can go. Understanding the specific contractual constraints that apply to a given Oracle application licence before entering a rationalisation conversation with Oracle is essential to avoid negotiating a reduction that turns out to violate a minimum user term and creates a different compliance problem.
The ITAM Forum publishes research on Oracle application and database licence management, including the specific audit and optimisation methodologies that enterprise organisations use to identify and address Oracle shelfware across complex, long-lived Oracle estates. Their ITAM Forum Oracle licence management and shelfware optimisation resources provide practitioner-level guidance on the Oracle licence review process, covering the data collection approach, the Oracle contractual constraints that affect rationalisation scope, and the commercial negotiation approaches that produce the best outcomes in Oracle support cost reduction discussions.
Java: The Silent Cost in Every Oracle Estate
Since Oracle changed its Java SE licensing model to an employee-based subscription in January 2023, Java has become one of the most commercially significant Oracle licensing topics for organisations that are not primarily Oracle database customers. The employee-based model charges based on the total number of employees in the organisation, not the number of Java users or the number of JVM instances. This means that an organisation using Java in a limited number of backend processes, with the majority of its employees having no interaction with Java whatsoever, pays the same per-employee rate as an organisation where Java is pervasively deployed.
Java shelfware in this context takes a different form. It is not unused Java licences in the traditional sense. It is the payment of an employee-based subscription rate that significantly overvalues the actual scope of Java usage in the organisation. The commercial response is to conduct a thorough Java deployment audit that documents exactly where Java SE is being used, at what version level, in what deployment contexts, and by what processes. This audit often reveals that some Java deployments can be migrated to OpenJDK or other freely available Java distributions that do not require an Oracle Java SE subscription, reducing the scope of the Oracle Java commercial obligation without affecting functionality.
The Sourcing Industry Group publishes research on enterprise software licence optimisation, including guidance on the Java SE commercial assessment and the migration strategies that allow organisations to reduce their Oracle Java exposure while maintaining technical continuity. Their SIG Oracle Java licensing and enterprise software optimisation research provide commercial frameworks for evaluating the Oracle Java SE subscription cost against the specific deployment profile of each organisation and the alternative licensing options that may reduce unnecessary spend.
Building an Oracle Shelfware Audit
A practical Oracle shelfware audit has four components that should be conducted before the next Oracle renewal or support renewal conversation. First, an Oracle Database options and management pack audit that identifies every option enabled in every Oracle database instance and compares that against the options included in current licence entitlements. Second, a processor and named user licence right-sizing review that reconciles current licence counts against current server configurations and active user populations. Third, an application module usage assessment that maps licensed application modules against current deployment and identifies any modules that are licensed but inactive. Fourth, a Java SE deployment inventory that documents where Oracle Java SE is in use and assesses which deployments could be migrated to OpenJDK.
The findings from this audit become the commercial foundation for renewal negotiations and support cost reduction conversations. Oracle is a sophisticated commercial counterpart that will not volunteer information about over-licensing or accept unsupported claims about unused capability. But well-prepared buyers who arrive at renewal conversations with accurate, independently verified data on their actual Oracle usage position have consistently achieved better commercial outcomes than those who renew without that evidence base.
KPMG’s software asset management practice publishes guidance on Oracle commercial strategy and the licence optimisation approaches that enterprise Oracle customers use to manage one of the most commercially significant vendor relationships in the enterprise software portfolio. Their KPMG Oracle commercial management and licence optimisation resources provide advisory frameworks for building the Oracle shelfware audit programme and using its findings to structure commercially effective renewal negotiations.
Conclusion
Oracle is too expensive a vendor to manage passively. The combination of processor-based database licensing, options and packs that can be activated without deliberate commercial decisions, application module licensing across large modular suites, and an employee-based Java subscription model creates multiple dimensions of potential shelfware that most organisations have not audited systematically. The organisations that build the discipline to ask the question that this blog started with, whether they are actually using everything they are paying for, and to answer it with evidence rather than assumption, will find meaningful commercial recovery within their existing Oracle estate.
