Restricted Use Database Licensing for the Acquired Suite

What restricted use database licensing means

JD Edwards, PeopleSoft, and Siebel all run on an Oracle database, and that database is very often acquired not as a standalone full use product but as a restricted grant bundled with the application. The most common form is Application Specific Full Use, usually abbreviated ASFU, which grants the full technical capability of the database but restricts its use to running the specific licensed application. The customer gets a complete database, but only for the purpose of running JD Edwards, PeopleSoft, or Siebel, not for general database workloads.

This distinction is one of the most consequential and least understood in the entire acquired applications estate. An organisation that treats its ASFU database as if it were full use, building reports, integrations, or unrelated applications on it, may believe it is fully licensed when it has in fact breached the restriction. The boundary between permitted application use and prohibited general use is where the exposure lives, and it connects directly to the broader Oracle database licensing model.

How is the database beneath these applications licensed?

The database beneath JD Edwards, PeopleSoft, and Siebel is licensed in one of two ways, and which one applies is the decisive question. Under Application Specific Full Use, the database may be used only to support the licensed application, and its metric and quantity are typically tied to the application's licensing. Under a full use licence, the database is licensed independently on the standard Processor or Named User Plus metrics and may be used for any purpose. The two grants can look identical in the technology installed but differ entirely in what the customer is permitted to do.

Reading the entitlement to determine which grant applies is therefore the foundation of any analysis. The contract or ordering document will specify whether the database was sold as application specific or full use, and the answer governs everything that follows. An organisation that cannot say with certainty which grant it holds cannot know whether its database use is compliant, which is a surprisingly common and dangerous position.

Where the restricted use boundary sits

The restricted use boundary is the line between using the database to run the licensed application and using it for anything else. Permitted use covers the application's own data, processing, and the reporting and integration that are genuinely part of the application. Prohibited use covers general purpose workloads: custom applications built on the same database, data warehouses fed from but extending beyond the application, third party tools querying the database for purposes unrelated to the application, and consolidation of other data into the application's database instance.

The grey area is reporting and integration, where the question is whether the activity genuinely serves the licensed application or extends beyond it. A report that summarises application data for application users is generally fine; a data warehouse that combines application data with unrelated sources to serve the wider organisation generally is not. The discipline is to test each use against the application boundary rather than assume that anything touching the database is covered, the same scrutiny the JD Edwards EnterpriseOne analysis applies to the technology foundation.

How a breach creates exposure

A breach of the restricted use boundary is expensive because it does not merely cost a small incremental fee; it can expose the organisation to full use licensing of the entire database, on the standard Processor metric, retroactively. An ASFU database that has been used for general purposes can be reclassified by Oracle as requiring a full use licence, and because full use database licensing on Processor terms is among the most expensive Oracle products, the gap between what was paid and what is then claimed can be very large.

This asymmetry is the heart of the risk. The restricted grant is inexpensive precisely because its use is constrained; remove the constraint, and the price reverts to the unconstrained product. An organisation that has quietly grown general purpose workloads on an ASFU database has accumulated an exposure measured against full use Processor pricing, which is the worst case outcome in the entire acquired applications estate and the one most worth pre empting.

How to manage restricted use exposure

Managing restricted use exposure is a boundary discipline. First, establish from the entitlement whether each application database is ASFU or full use. Second, inventory every workload, report, integration, and tool that touches each ASFU database, and test each against the application boundary. Third, remediate any prohibited use by moving it to a separately licensed full use database or eliminating it. Fourth, govern future change so that no new workload is added to an ASFU database without testing it against the restriction first.

The remediation choice, move the workload or license the database for full use, is a commercial decision that depends on the scale of the genuine general purpose need. The applications licensing practice conducts this boundary analysis as part of the estate review, establishing the grant type for each application database and testing the actual workloads against the permitted use, so the organisation knows precisely where it stands before Oracle asks.

The buyer side view

Restricted use database licensing rewards the customer who respects the boundary and knows exactly where it sits. The buyer side discipline is to establish the grant type for every application database, inventory every workload against the application boundary, and remediate prohibited use before it is discovered. Because a breach reverts the price to full use Processor terms, the boundary is the single highest value line to police in the acquired applications estate.

The leverage point is that the boundary is knowable and the exposure preventable. An organisation that maintains a clean ASFU database, used only for its application, carries no restricted use exposure at all; one that has let general purpose workloads accumulate carries a full use Processor liability it may not even be aware of. To establish where your application databases sit against the restricted use boundary, request a consultation.

Restricted use audit patterns

The restricted use boundary is a primary audit focus because the exposure, when found, is large and measured against full use pricing. Oracle examines what workloads run on each application database and tests them against the permitted use, and the organisations most exposed are those that have grown reporting, integration, and custom development on an ASFU database over years without considering the restriction. The audit logic connects to the broader trigger analysis in the acquired suite audit triggers article.

The defensive posture is to hold a current inventory of what runs on each application database and a clear position on its grant type, so that any audit begins from the customer's documented boundary analysis rather than Oracle's discovery of stray workloads. An organisation that can demonstrate its ASFU databases are used only for their applications converts a potentially severe full use exposure into a non issue.

Options, packs, and the restricted grant

A subtlety often missed is that the restricted grant covers the database edition the application requires but does not automatically include database options and management packs such as partitioning, advanced compression, or the diagnostics and tuning packs. Using such an option on an ASFU database, even within the application boundary, can require separate licensing of that option, because the ASFU grant is for the database to run the application, not for every option the database technically supports.

The discipline is to establish not only the grant type but which options and packs are licensed alongside it, and to confirm that any option in use is genuinely covered. This mirrors the options scrutiny applied across the Oracle database estate generally and is a frequent secondary finding when a restricted use database is examined, connecting to the wider database licensing model.

Consistency across the acquired estate

The restricted use question applies identically to JD Edwards, PeopleSoft, and Siebel, because all three are application products sold with bundled database rights. An organisation running more than one of them should establish the grant type and boundary position for each application database, because the answer can differ by product and by the era in which each was purchased. A clean position on one does not imply a clean position on the others.

The unifying principle, developed across the acquired applications pillar, is that the technology foundation carries exposure independent of the application layer above it. A complete position on any acquired application reconciles both the application metric and the database grant beneath it, because either alone leaves half the picture, and frequently the more expensive half, unexamined.