Oracle proprietary hosting rights let you run your own application on Oracle programs and open it up to outside users — without licensing each of them. The grant is narrow, the conditions are strict, and the line between permitted hosting and a prohibited service bureau is exactly where Oracle audits land. Former Oracle insiders draw that line clearly.
Short answer: Oracle proprietary hosting, or Proprietary Application Hosting (PAH), is a contractual right that lets a licensee run its own proprietary application on Oracle programs and give third parties access to that application — without each third party needing its own Oracle license. The licensee must own the hosted application and must still fully license the underlying Oracle software.
Oracle proprietary hosting, formally Proprietary Application Hosting (PAH), is a contractual right that lets a licensee run its own proprietary application on Oracle programs and provide third parties with access to that application, without those third parties holding their own Oracle licenses. The right exists because Oracle's standard license is granted for the licensee's internal business operations — and hosting an application for external users is, by default, outside that grant.
PAH closes that gap for a specific scenario: you have built or own an application, it runs on an Oracle database or middleware program, and your customers or partners use your application over the web. Without proprietary hosting rights, every external user touching the Oracle-backed application could be argued to require licensing. With PAH, the external users access your application, you license the Oracle programs underneath, and Oracle does not separately license each end user.
The defining condition is ownership. Proprietary hosting rights apply only to an application that the licensee owns. A third-party packaged application, or one owned by a different entity, does not qualify for PAH even if you operate it. This ownership test is the first thing an Oracle auditor checks when reviewing a hosting claim, and it is where many arrangements that feel like "hosting" turn out not to qualify.
Definition that matters: A service bureau is an arrangement where you provide third parties access to the Oracle software's own functionality. Oracle's standard agreement prohibits service bureau use outright — so whether your platform is "proprietary hosting" or a "service bureau" is the difference between a permitted deployment and a license breach.
Proprietary hosting rights allow third parties to use your owned application that runs on Oracle programs, while keeping the Oracle licensing obligation entirely with you. The right governs who may access the application; it does not change how the Oracle software underneath must be licensed, and it does not extend to the Oracle software's own capabilities.
The grant is deliberately narrow. PAH permits external access to your application. It does not permit you to give third parties direct access to the Oracle database or middleware, to expose Oracle's native tools and utilities to those third parties, or to let third parties build or run their own workloads on your Oracle programs. The moment external parties are using Oracle functionality rather than your application, you have left the boundary of proprietary hosting.
| Scenario | Permitted under PAH? |
|---|---|
| Customers use your owned web application backed by Oracle Database | Yes — this is the core PAH use case |
| Customers log into Oracle's own tools or run their own SQL | No — that is access to Oracle functionality |
| You host a third-party packaged application you do not own | No — fails the ownership test |
| You provide Oracle database capacity as a service to clients | No — that is a prohibited service bureau use |
| Affiliates in your corporate group use your owned application | Usually yes, subject to entity restrictions |
Because the line is drawn around application ownership and the nature of the access, hosting arrangements that grow organically — a platform that adds a customer-facing reporting feature, or exposes an API that lets clients query data directly — can cross from permitted hosting into prohibited use without anyone signing a new contract. That drift is exactly what an Oracle audit is designed to surface.
Our Oracle Compliance Review maps your hosting architecture against your actual contract rights — before Oracle's LMS team maps it for you.
The difference between proprietary hosting and a service bureau is what the third party is actually using. Under proprietary hosting, third parties use your application, which happens to run on Oracle. Under a service bureau, third parties use the Oracle software's own functionality. Oracle's standard agreement prohibits service bureau use, so this distinction decides whether your arrangement is permitted or a breach.
In practice, three questions settle the classification. First, do you own the application the third parties are using? If not, PAH does not apply. Second, are the third parties interacting with your application's interface, or with Oracle's native capabilities? Direct Oracle access points toward a service bureau. Third, is the value you sell your own software, or is it effectively Oracle capacity and functionality dressed up as a service? If you are reselling Oracle, you need a different agreement entirely.
Oracle's auditors approach hosting platforms with these questions explicitly, because the service bureau prohibition is one of the most reliable ways to convert a hosting customer into a large compliance claim. The Oracle agreement types guide explains how the underlying grant in your master agreement frames all of this — the hosting right only matters within the broader license you already hold.
Proprietary hosting changes who can access the application, not how the underlying Oracle programs are licensed. You must fully license every processor or named user running the Oracle software, and for hosting deployments that almost always means the Processor metric, because external users cannot be identified and counted reliably under Named User Plus.
The Named User Plus metric counts every individual authorized to use the programs. For an internal deployment that is countable. For a hosting platform with thousands of external customers — many of them anonymous or transient — counting named users is impossible, and Oracle's minimums per processor would make it uneconomic even if you could. The Processor metric, which licenses the hardware the Oracle software runs on regardless of user count, is the standard approach for hosting. The Oracle Database Licensing Guide sets out how the Core Factor Table converts physical cores into licensable processors.
This has a direct cost consequence: a hosting platform is licensed on its full processing capacity, and any growth in the underlying infrastructure increases the license requirement. Architecting the hosting environment to contain Oracle to defined, fully-licensed hardware — rather than letting it spread across a virtualized estate — is one of the highest-value design decisions for any hosting deployment, and a core part of Oracle license optimization.
Sometimes, but not by default. A ULA (Unlimited License Agreement) is a fixed-term Oracle contract granting unlimited deployment of named products for a single upfront fee — but many ULAs restrict that unlimited grant to internal use, which means hosting third parties can fall outside the agreement entirely. Relying on a ULA to cover a hosting platform without reading its use restrictions is a common and expensive mistake.
The relevant ULA terms are the territory, entity, and use restrictions. A ULA that limits deployment to the licensee's internal business operations does not authorize external hosting, no matter how "unlimited" the headline grant sounds. Worse, a hosting deployment that runs during the ULA term but is not a permitted use may not count toward the certification at the end — leaving you having deployed Oracle for a purpose the contract never covered.
Before a hosting platform is built on ULA-covered Oracle programs, the ULA's use grant has to be confirmed to include external hosting, and the certification implications have to be modeled. Our Oracle ULA Advisory team reviews exactly this, and the Oracle ULA Guide explains how use restrictions interact with certification.
Hosting and shared-services arrangements generate audit exposure because they sit at the edge of the standard license grant, where small architectural or commercial changes can cross a contractual line. Across our engagements, roughly 1 in 4 hosting and shared-services arrangements is misclassified in a way that creates audit exposure (Oracle Licensing Experts, 2026). The recurring triggers are consistent.
The hosted application turns out to be a third-party package, or owned by a sister entity, rather than by the licensee. PAH does not apply, and every external user becomes a potential licensing claim.
An API, a reporting tool, or a data export feature lets external users query the Oracle database directly. That converts permitted application hosting into a service bureau use the standard agreement prohibits.
The platform scales onto additional cores or a virtualized cluster, but the Processor license count was sized for the original footprint. Oracle counts the full capacity the software can run on.
Central IT hosts an application for multiple group entities. Without a clear entity grant, Oracle argues the arrangement exceeds the internal-use license — a dispute covered in our work on subsidiaries and affiliates.
Each of these is recoverable if it is caught early. Reviewed before an audit, a hosting arrangement can be re-architected or re-papered. Discovered during an audit, the same facts become the basis for a back-license claim. A worked example is available in our Oracle case studies.
Protecting a hosting deployment means confirming your rights before you build, then keeping the architecture inside those rights as the platform grows. The steps are straightforward and, taken in order, remove most of the exposure.
These are the same controls an Oracle auditor will test, run in your favor and ahead of time. Our Oracle Compliance Review and Oracle Contract Negotiation services deliver both the classification work and the contract language needed to secure hosting rights cleanly.
Oracle Proprietary Application Hosting (PAH) is a contractual right that lets a licensee run its own proprietary application on Oracle programs and give third parties access to that application, without each third party needing its own Oracle license. The licensee must own the hosted application and remains responsible for full Oracle licensing of the underlying programs.
No. Proprietary hosting only covers access to your own application that runs on Oracle programs. It does not let you provide direct access to the Oracle software itself, resell Oracle functionality, or run a service bureau. Offering Oracle programs as a service to third parties requires a separate Oracle hosting or embedded license agreement.
Proprietary hosting means third parties use your own application, which happens to run on Oracle. A service bureau means you provide third parties with access to the Oracle software's own functionality. Oracle's standard agreement prohibits service bureau use, so the distinction determines whether your hosting arrangement is permitted or a license breach.
Yes. Proprietary hosting changes who can access the application, not how the underlying Oracle programs are licensed. You must fully license every processor or named user running the Oracle software, typically on the Processor metric because external users cannot be counted reliably under Named User Plus.
Sometimes, but ULAs frequently restrict or exclude hosting and external-user access. Many ULA agreements limit unlimited rights to internal use, which means hosting third parties can fall outside the grant. Review the ULA's territory, entity, and use restrictions before relying on it to cover a hosting platform.
No. Proprietary hosting rights apply only to an application the licensee owns. A third-party packaged application fails the ownership test, even if you operate and customize it. Hosting a vendor application on Oracle for external users requires a different licensing arrangement, often an embedded or application-specific license held by the application vendor.
Hosting rights, audit triggers and contract tactics — for Oracle stakeholders at 2,000+ enterprises globally.
Written by the Oracle Licensing Experts Team — former Oracle executives, LMS auditors, and contract managers with 25+ years of combined Oracle licensing experience. Not affiliated with Oracle Corporation. All advisory is independent and 100% buyer-side.