Customising an Oracle E-Business Suite (EBS) environment can deliver significant business value — but it can also generate hidden licensing costs that dwarf the original development effort. Oracle includes database and middleware licences with EBS, but only for restricted use. Cross that line, and you may be required to purchase full-use licences for Oracle Database Enterprise Edition and Oracle WebLogic Server — at list prices that can reach hundreds of thousands of dollars.
This article explains how customised database technology in Oracle EBS can inadvertently violate licence rules, what to look out for, and how ITAM professionals can identify and mitigate these risks in global enterprises. For the complete EBS licensing overview, read our Oracle E-Business Suite (EBS) Licensing Guide.
1. Understanding Oracle EBS's Included Technology Stack
Oracle EBS is bundled with essential technology components — the Oracle Database and Oracle WebLogic Server (middleware) — under a restricted-use licence. When you purchase Oracle EBS application licences, you do not separately pay for a full Oracle Database or WebLogic licence to run them. Oracle provides these as part of the deal, but with strict conditions attached.
The included database and middleware licences can only be used to support the EBS applications you licensed. In practice, this is a significant cost benefit: you get the database engine and application server needed to run EBS without purchasing full-use licences upfront. However, the restriction is clear — using the database or middleware for anything beyond standard EBS is not permitted under the restricted-use grant.
Think of the included Oracle Database and middleware as EBS-only infrastructure. They are powerful tools given to you, but only to run standard EBS functionality. Any use beyond that scope — no matter how minor ("We already have an Oracle DB here, let's add another schema for a small app…") — can void the restricted-use benefit and trigger full-use licensing costs.
| Component | Included With EBS? | Restriction | Full-Use Licence Cost (List) |
|---|---|---|---|
| Oracle Database EE | ✅ Yes (restricted use) | EBS data only — no custom schemas or non-EBS applications | ~$47,500/processor |
| Oracle WebLogic Server | ✅ Yes (restricted use) | EBS application tier only — no custom apps or third-party deployments | ~$25,000–$50,000/processor |
| Oracle BI Publisher | ✅ Yes (limited) | Standard EBS reports against EBS data only | Varies (per user or per processor) |
| Oracle Forms / Reports | ✅ Yes (restricted use) | EBS-delivered forms and reports only | Included in WebLogic full-use licence |
Read: Oracle EBS Licensing Basics
2. Customisation Levels and Their Licence Impact
Oracle's EBS licensing policy defines three levels of customisation, each with increasing licence requirements. Understanding which category your organisation's changes fall into is critical for compliance.
| Customisation Level | Examples | Licensing Impact |
|---|---|---|
| Level 1: No Modifications (out-of-the-box) | Deploy EBS as delivered, with no custom code or schema changes. Use standard Oracle-provided configuration options. | ✅ No additional licences needed. The included restricted-use Oracle Database and middleware cover all EBS usage. |
| Level 2: UI/Logic Extensions (reports, forms, Java code within EBS) | Creating custom reports, altering forms, adding minor Java business logic using Oracle's provided extension tools (OAF, Forms Personalisation). | ⚠️ Full middleware licence required. You must licence Oracle WebLogic (or Oracle Internet Application Server) for all users or processors. The database remains under restricted use, but custom Java/reports beyond basics trigger a full-use app server licence. |
| Level 3: Database Customisations (schema changes) | Adding new tables, custom triggers, stored procedures, or an extra schema inside the EBS database for additional functionality. | 🔴 Full Oracle Database EE licence AND full middleware licence required. All users or processors must be covered by full-use DB and app server licences. The "free" benefit is entirely voided. |
Simply developing a custom workflow or report can force you to purchase an Oracle middleware licence (which was otherwise free under EBS). And if you go deeper and modify the database schema itself, the cost jumps dramatically — you effectively convert your "free" EBS database into a fully licensable Oracle Database instance. Oracle treats customised database technology in EBS as if you installed a separate Oracle product — and prices it accordingly.
Need help assessing whether your EBS customisations trigger full-use licensing?
Oracle License Management →3. Database Modifications: When a "Free" Database Becomes Costly
Many enterprises enhance Oracle EBS by adding fields, tables, or triggers to tailor the system to business needs. While this can deliver functional benefits, it crosses a licensing red line when done in the EBS database itself.
Oracle's policy is explicit: if you add or modify any objects in the Oracle EBS database schema — a table, column, stored procedure, or trigger — you are no longer just using EBS. You are altering Oracle's database structure. This triggers the requirement for a full-use Oracle Database Enterprise Edition licence, along with the associated middleware licence for the application tier.
A global enterprise developed a custom project management module, creating new tables and triggers in the EBS database to integrate with EBS Financials. The team assumed this was an efficient use of the existing system. During a routine Oracle audit, the custom tables were flagged. Oracle determined the company was using the database for custom applications beyond EBS. The result: a demand to purchase full-use database licences for the servers running EBS, plus backdated support fees.
Why the Cost Is So Significant
Oracle Database Enterprise Edition licences run ~$47,500 per processor at list price, and enterprises typically run EBS on multi-processor servers. An 8-core server (using Oracle's standard Core Factor of 0.5 for Intel/AMD) requires 4 processor licences: 4 × $47,500 = $190,000 just for the database. Add WebLogic full-use licensing and 22% annual support on both, and the total easily exceeds $380,000 — costs that had been entirely avoided under the restricted-use grant.
📊 Cost Comparison: Restricted Use vs Full Use
Server configuration: 2 sockets, 8 cores each (16 cores total), Intel Xeon. Core Factor 0.5 = 8 processor licences.
Under restricted use (no customisation): $0 for DB and middleware — included with EBS.
After Level 3 customisation: DB EE: 8 × $47,500 = $380,000. WebLogic: 8 × ~$25,000 = $200,000. Total: $580,000 + 22% support ($127,600/year).
Actionable Takeaways
Avoid embedding standalone apps in the EBS database. If your business needs custom database tables or applications, deploy them on a separate Oracle database instance (with its own licence) rather than piggybacking on the EBS database. This keeps the EBS restricted-use licence intact.
Assess schema changes upfront. Before adding any table or trigger in EBS, involve your licence management team. Weigh the cost of a full-use licence against the benefits of customisation. In many cases, alternative solutions exist that do not violate EBS licence terms.
Read: Licensing Oracle EBS Modules & Suites
4. Middleware Extensions: Hidden Triggers for Full-Use Licences
Oracle EBS relies on Oracle's middleware (Oracle WebLogic Server) to run forms, reports, and application logic. Oracle includes a limited-use licence of this middleware for EBS's own needs. But using the EBS application server for anything other than its intended purpose is another licensing landmine.
Common Middleware Violations
| Scenario | Risk Level | Why It Triggers Full-Use |
|---|---|---|
| Custom Java app on EBS WebLogic | 🔴 High | Deploying a custom .war/.ear application on the EBS WebLogic domain means the middleware is hosting non-EBS software. |
| Third-party integration on EBS app server | 🔴 High | Adding third-party applications (ETL tools, portals, connectors) to the EBS WebLogic for integration convenience. |
| BI Publisher accessing non-EBS data | ⚠️ Medium–High | Using EBS-included BI Publisher to pull data from non-EBS sources or heavily customised schemas beyond standard EBS data. |
| Custom web services on EBS middleware | ⚠️ Medium | Exposing custom REST/SOAP services from the EBS WebLogic that serve non-EBS consumers. |
| Custom reports using new DB objects | ⚠️ Medium | Reports built on custom tables (not standard EBS objects) may trigger both middleware and database full-use requirements. |
A large retailer using Oracle EBS decided to host a custom employee portal application on the same Oracle WebLogic Server that runs EBS, reasoning it would save infrastructure costs. Oracle's auditors discovered the shared deployment. The finding: the embedded WebLogic licence is only for EBS modules, not an employee portal. The retailer had to obtain a full WebLogic Suite licence for the environment and pay licence fees retroactively. The supposed savings of consolidating apps evaporated instantly.
Oracle BI Publisher is included with EBS in a limited capacity — to run standard EBS reports or slightly modified reports against the EBS schema. If you use BI Publisher on the EBS server to access any non-EBS data source or a heavily customised schema, Oracle requires a full-use BI Publisher licence. These smaller "middleware triggers" are easy to overlook but are equally subject to audit findings.
Actionable Takeaways
Keep EBS middleware dedicated. Treat the EBS application server like a silo: it should host only Oracle EBS-related applications and services. Set up a separate middleware server for custom apps, even if they could technically coexist.
Review integrations carefully. If you are integrating EBS with other systems, use supported integration points (interface tables, APIs) rather than deploying new components inside the EBS tech stack. This prevents accidentally turning a limited-use component into a full-use scenario.
Facing an Oracle audit that includes EBS technology licensing? Get expert defence before responding.
Oracle Audit Defense →5. Identifying Customisations and Compliance Risks
How can ITAM professionals proactively identify where customised database technology in Oracle EBS might be breaking the rules? Early identification is critical. Here is a step-by-step approach to find and address risky customisations in an enterprise EBS environment.
- 1Inventory the EBS Database Schemas. Work with your DBAs to list all schemas and custom objects in the EBS Oracle Database. Compare them against a vanilla EBS installation or Oracle's documentation. Red flag: Any schema or table that did not come with EBS (especially ones prefixed differently than standard EBS modules) indicates a custom extension that may trigger full-use licensing.
- 2Scan for Custom Triggers and Procedures. Check for custom triggers on EBS tables or stored procedures/packages that integrate with external systems. A trigger that writes to an external table or calls an external application indicates the EBS database is being used for non-EBS operations — a Level 3 customisation.
- 3Review WebLogic Deployments. Have your middleware administrator list all applications and services deployed on the Oracle WebLogic/Application Server that hosts EBS. Ensure every deployment is an Oracle-provided EBS component or officially supported add-on. Red flag: Custom .ear or .war applications in the EBS domain.
- 4Check for Unlicensed Modules or BI Tools. Run Oracle's LMS scripts or EBS usage reports to verify whether any modules are active without licences, or if BI Publisher is accessing non-EBS data. Sometimes enabling an unlicensed EBS module or using an included tool beyond its limits also violates terms.
- 5Interview Developers and Architects. Talk to the teams that built extensions or reports. It is common to find well-meaning developers who added a few tables or deployed a small integration in EBS without realising the licensing implications. Human intelligence complements your technical scans.
By conducting these checks, you can create a map of customisations in and around Oracle EBS. Each identified customisation should be evaluated against Oracle's three-tier policy. Not all custom work is non-compliant — Oracle provides some leeway for tailoring EBS within standard extension frameworks. The goal is to pinpoint those that go beyond allowed use.
During an audit, Oracle may request a dump of all database users/schemas on the EBS instance or inspect the WebLogic console for additional deployments. If ITAM has this information ready and has addressed any issues (either by licensing or removing the customisation), the organisation is in a far stronger position. It is always better to find and fix a potential compliance gap before Oracle does.
Read: Oracle EBS License Compliance Checklist
6. Recommendations for ITAM Professionals
| # | Recommendation | Why It Matters |
|---|---|---|
| 1 | Document your EBS environment. Keep an up-to-date record of all customisations, integrations, and extensions. | Enables quick compliance assessment and is invaluable during audits. |
| 2 | Educate your team. Train developers and system architects on Oracle's EBS licensing rules. | Even seemingly harmless changes (adding a trigger, deploying a small app on WebLogic) can have significant consequences. |
| 3 | Segregate custom applications. Deploy any non-EBS application or database schema on separate, fully licensed Oracle platforms. | Avoids commingling that voids the restricted-use benefit. |
| 4 | Leverage Oracle-provided tools. Use Oracle's LMS audit scripts regularly to check usage. | Shows extra schemas or unauthorised usage, giving you time to correct course before Oracle audits. |
| 5 | Review contracts and policies. Regularly revisit your Oracle EBS licensing agreement and Oracle's official policy documents. | Understanding the fine print (what "restricted use" entails) helps enforce internal compliance. |
| 6 | Plan before you customise. Involve ITAM before green-lighting significant EBS customisations. | A cost-benefit analysis that includes full-use licensing costs may change the decision entirely. |
| 7 | Consider Oracle's approval. If a customisation is critical, negotiate with Oracle for a special licence or amendment. | Getting terms in writing avoids ambiguity during future audits. |
| 8 | Archive audit trails. Maintain logs and evidence of how EBS is being used. If you remove a customisation, record that action. | Demonstrating a clean environment and historical diligence can lead to more favourable audit outcomes. |
| 9 | Use reporting instances carefully. If you create a read-only reporting database by copying EBS data, it likely needs its own licence. | Data warehouses or clones that are decoupled from EBS are not covered by restricted use. |
| 10 | Engage independent experts. Oracle licensing is complex — an objective review before an audit or major project can save huge fees. | A small advisory cost can prevent six- or seven-figure compliance penalties. |
Need an independent assessment of your Oracle EBS technology licensing position?
Oracle Contract Negotiation →7. Action Checklist — 5 Steps to Take Now
- 1Audit your EBS database now. Conduct an internal audit of the Oracle EBS database. List all non-standard schemas, custom tables, and database links. If you find objects that should not be there, decide whether to remove them or budget for proper licensing.
- 2Inspect the application server. Examine the Oracle EBS application server (WebLogic). Check what is deployed. Remove any unauthorised applications or move them to a separate server. Ensure only EBS-related services are running on the EBS middleware instance.
- 3Validate usage against entitlements. Cross-check enabled EBS modules and components against your Oracle licence entitlements. For each active module or feature (including BI Publisher and integrations), confirm that you have a licence or that it is included. If something is active without the necessary entitlement, deactivate it or obtain the required licence.
- 4Update policies and communicate. Update your internal IT policies to include Oracle EBS customisation guidelines. Clearly state that no changes to the EBS database or middleware should be made without a review of the potential licensing impact. Communicate this policy to all relevant IT staff and project managers.
- 5Schedule regular compliance reviews. Set a regular cadence (quarterly or biannually) to review Oracle EBS usage. This should include ITAM professionals, DBAs, and application owners. Regular reviews catch any drift in usage before it becomes a bigger issue.
🔍 Need Independent Oracle EBS Licensing Advisory?
Redress Compliance provides vendor-independent EBS licence assessments, customisation risk analysis, audit defence, and contract negotiation advisory. Our team includes former Oracle LMS auditors who understand exactly how Oracle evaluates EBS technology licensing compliance — and how to optimise your position before, during, and after an engagement with Oracle.
8. Frequently Asked Questions
Our Oracle Advisory Services
Vendor-independent. Fixed-fee. Proven results across hundreds of enterprise engagements.