What Oracle EBS Actually Includes

Oracle E-Business Suite is not just an application — it is a stack. When an organisation licenses Oracle EBS, that licence includes restricted-use rights to several underlying technology components that EBS requires to function. These include Oracle Database Enterprise Edition (or Standard Edition, depending on the EBS version), Oracle WebLogic Server, Oracle Internet Application Server, and related middleware components.

The word "restricted-use" is critical. These are not full-use licences. They are licences to use the bundled technology solely for the purpose of running the licensed EBS applications. The database can store EBS data. WebLogic can run EBS application servers. The middleware can process EBS transactions. Everything within that scope is covered.

What is not covered: using the same Oracle Database instance to run other applications, storing non-EBS data in the EBS database, running non-EBS applications on the EBS WebLogic instance, or deploying custom applications that use the EBS database as their datastore. Any of these uses crosses from restricted-use into full-use territory — and Oracle requires a separate, full-use licence for each component involved.

A European manufacturing conglomerate deployed a third-party application on the WebLogic instance bundled with Oracle EBS. This triggered full-use WebLogic licensing obligations. The audit claim reached $2.8M. Our Oracle licensing advisory specialists confirmed the restricted-use boundary had been crossed but negotiated the final exposure to $410,000.

The Most Common Customisation That Triggers Full-Use Licensing

The most frequently observed trigger for full-use Database licensing in EBS environments is the creation of custom database schemas within the EBS Oracle Database instance. This happens more often than organisations realise, and the reasons are understandable: the EBS database is large, well-tuned, backed up regularly, and already managed by the DBA team. When a custom application needs a datastore, using the existing EBS database instance is the path of least resistance.

From a technical standpoint, creating a new schema in the EBS Oracle Database instance is simple. From a licensing standpoint, it is a compliance gap. Oracle's restricted-use licence for the EBS database does not permit storing non-EBS application data, even if it is a small reporting schema created by an internal developer with no connection to Oracle at all.

During an Oracle audit, LMS scripts examine the Oracle Database's data dictionary — specifically the DBA_USERS and related views — to identify all schemas present in the database. Any schema that does not correspond to a standard EBS schema (APP, GL, AR, AP, and so on) is flagged for investigation. The auditor's position is that non-EBS schemas indicate non-EBS use of the database, which requires a full-use Database licence.

"Creating a single reporting schema in your EBS Oracle Database for a non-EBS application is, in Oracle's view, sufficient grounds to require a full-use Database Enterprise Edition licence — at $25,000 per processor."

WebLogic Server Customisation and Full-Use Triggers

The same principle applies to Oracle WebLogic Server, the Java application server bundled with EBS. EBS ships with Oracle WebLogic as its application server infrastructure. The restricted-use WebLogic licence covers running EBS application code on that WebLogic instance. It does not cover deploying non-EBS custom applications.

Where organisations run into compliance problems is when custom Java applications — interfaces, middleware utilities, batch processing jobs, or mini-portals — are deployed on the EBS WebLogic instance for convenience. From a technical standpoint, WebLogic supports multiple deployments natively. From a licensing standpoint, each non-EBS deployment potentially triggers a requirement for a full-use WebLogic Server licence.

Full-use Oracle WebLogic Server Enterprise Edition is priced at approximately $15,000 per processor at list price. For the same EBS server environment, adding a non-EBS application to the WebLogic instance could expose the organisation to a full-use WebLogic obligation across all server processors — an exposure that may significantly exceed the business value of the custom application.

Database Schema Customisation vs. EBS Customisation

There is an important distinction between two types of customisation in EBS environments. The first is adding or modifying objects within existing EBS schemas — adding custom fields, creating custom tables in the APPS schema using standard EBS extension frameworks, or creating triggers and stored procedures within EBS schemas that extend EBS functionality. This type of customisation, when performed within Oracle's EBS customisation framework, is generally covered by the EBS application licence and does not trigger a full-use database licence.

The second type is creating entirely new schemas — independent of the EBS application — to support non-EBS functionality. It is this second type that creates the compliance risk. The distinction matters because both types of work are sometimes performed by the same DBA team as part of the same project. A developer building an EBS customisation might, in the same sprint, create a custom staging schema for data loads that technically falls outside the EBS boundary.

How Oracle Detects Custom Schemas During Audits

Oracle's LMS collection scripts are comprehensive in their discovery of database schemas. The scripts query system views to enumerate all database users and their associated objects. A standard EBS database has a predictable set of schemas — the Oracle-supplied EBS module schemas, technical schemas like APPLSYS and PORTAL, and infrastructure schemas. Any deviation from this expected pattern is flagged.

A particularly common scenario: an organisation has used the EBS database instance for a legacy integration schema that predates current compliance awareness. The schema contains a few thousand rows of data and is rarely accessed. Oracle's LMS scripts find it, the auditor classifies it as evidence of non-EBS use, and the audit claim includes full-use Database Enterprise Edition licensing for the entire server infrastructure — potentially millions of dollars for what began as a trivial data staging exercise.

Concerned about EBS customisation compliance?

Our EBS compliance reviews identify custom schema and WebLogic deployment risks before Oracle's LMS team finds them.
Request a Compliance Review

What to Do If You Have Custom Schemas in the EBS Database

The practical remediation approach depends on the current state of the custom schemas and the organisation's timeline relative to any Oracle engagement.

  • Conduct a schema inventory before any Oracle engagement. List every schema in the EBS database, identify its owner and purpose, and classify it as EBS-standard, EBS-custom-framework (extensions), or non-EBS (independent data). This inventory is the foundation of any compliance review.
  • Migrate non-EBS schemas to a separate database instance. The cleanest remediation is to move non-EBS data out of the EBS database and into a separately licensed or licence-exempt database. If the non-EBS data is small, migrating it to an open-source database such as PostgreSQL eliminates the Oracle licensing obligation entirely.
  • Drop empty or abandoned schemas. Legacy schemas that contain no data and serve no function should be dropped from the database. This eliminates the audit finding at no cost, provided the schemas are genuinely unused.
  • Negotiate retrospective coverage if migration is not feasible. If non-EBS schemas have been in the EBS database for years and migration is not immediately feasible, organisations with pending Oracle renewals have an opportunity to negotiate retrospective coverage as part of a broader commercial agreement — often at a significant discount from Oracle's initial audit claim.

Non-EBS Applications on EBS WebLogic: Practical Steps

For WebLogic exposure, the remediation principles mirror the database approach. Map every application deployed on the EBS WebLogic instance, identify which are EBS applications versus independent custom deployments, and either migrate non-EBS deployments to a separate, appropriately licensed server or negotiate coverage for their current use.

The migration path for WebLogic is often simpler than for database schemas. Modern container-based infrastructure makes it straightforward to move a custom Java application to a separately managed Tomcat, Jetty, or open-source WildFly instance at minimal cost, eliminating the Oracle WebLogic licence obligation entirely. The key is to ensure the migration is complete and documented before any Oracle audit engagement begins.

The Annual Cost Dimension

One aspect of EBS technology customisation compliance that is often underestimated is the annual cost trajectory. Oracle's support fees increase at 8% per year. A full-use Database Enterprise Edition licence claim that starts at $200,000 in licence cost carries a 22% annual support fee of $44,000 in year one. After five years of 8% annual increases, the annual support on that claim would be approximately $64,700 per year — and that is before the back-support obligation for the years of unlicensed use prior to the audit.

This annual escalation makes early remediation significantly more cost-effective than deferred action. Every year that a non-EBS schema remains in the EBS database without appropriate licensing is a year of compounding potential back-support liability.

Frequently Asked Questions

Can I use EBS's Oracle Database for my own reporting database?

No. The Oracle Database bundled with EBS is licensed under restricted-use terms that limit its use to supporting EBS applications. A separate reporting schema used for non-EBS data requires a full-use Oracle Database licence or migration to a non-Oracle database platform.

What is the difference between an EBS extension schema and a non-EBS schema?

An EBS extension schema is one that exists within Oracle's documented EBS customisation framework — for example, custom objects in the APPS schema or custom tables created using the EBS naming conventions and registered in the EBS Application Object Library. A non-EBS schema is an independently created schema that stores data unrelated to EBS applications. The former is generally permitted; the latter requires a full-use licence.

Does Oracle always find custom schemas during audits?

Oracle's LMS collection scripts query system-level database views that enumerate all schemas regardless of whether they are EBS-related. Custom schemas are consistently identified during LMS audits. Their presence does not guarantee an audit claim, but it invariably triggers an inquiry that shifts the compliance burden to the customer to explain why the schema exists and whether a full-use licence is required.