Oracle PAH Licence Guide: Proprietary Application Hosting for ISVs and SaaS Providers

Understanding Proprietary Application Hosting and Its Strategic Importance for ISVs

Oracle's Proprietary Application Hosting (PAH) licence is one of Oracle's least-understood but commercially critical offerings for independent software vendors and SaaS providers who build applications on Oracle technology. The PAH licence exists to solve a fundamental problem: Oracle's standard software licences explicitly prohibit third-party hosting. A standard Oracle Database licence grants you the right to use Oracle Database for your own internal business operations. It explicitly prohibits you from installing Oracle Database on hardware you control and providing database services to your customers as part of your software offering.

The PAH licence provides a contractual carve-out to this restriction. Under a PAH agreement, you (as an ISV or SaaS provider) can install Oracle products inside your proprietary applications and deliver those applications to external customers via hosting, cloud delivery, or managed services. Your customers do not receive Oracle licences directly; you hold the Oracle licence, and your customers access Oracle technology as part of the value-added features of your application.

The commercial significance of PAH is substantial for software vendors who depend on Oracle technology. Many leading business applications—enterprise resource planning (ERP) platforms, human capital management systems, supply chain management solutions—are built on Oracle Database or other Oracle middleware. These vendors could not commercially deliver their products without a PAH licence that explicitly permits third-party customer hosting.

However, PAH agreements come with complex commercial terms, eligibility requirements, and audit risks that many ISVs navigate without full understanding. The agreement is negotiated case-by-case rather than offered as a standardised product. Pricing is not published; it is negotiated based on deployment volume, market position, and commercial leverage. Support obligations and escalation rights under PAH can diverge materially from standard Oracle licence terms. And the audit and compliance requirements for PAH are among the most stringent Oracle imposes on any customer.

What PAH Is and Why It Exists in Oracle's Licensing Framework

Oracle's standard software licence is limited in scope to internal use by the licensee. The Oracle Database Standard Edition licence agreement, for example, states that the software may be used for the licensee's internal business operations. This restriction is fundamental to Oracle's licensing model. Oracle's strategy is to license software based on the scope of who uses it and how it is deployed.

For internal use, the licensing scope is straightforward: count the processors in the server running the software, or count the users accessing the software, and that determines the licence count. For third-party hosting, the scope becomes ambiguous. If you are hosting Oracle Database on behalf of 100 external customers, how many Database licences do you need? Under the standard Oracle licence, the answer is effectively infinite, because standard licences do not permit third-party hosting at all.

The PAH licence solves this problem by creating a distinct licensing category for vendors who embed Oracle technology in proprietary applications and deliver them to external customers. Under PAH, the ISV holds the Oracle licence and is responsible for compliance; customers do not hold direct Oracle rights. The PAH licence grants the ISV the right to use Oracle technology for that specific purpose, under defined terms and conditions.

Oracle created PAH because it recognised a commercial opportunity: major software vendors were building applications on Oracle technology, and those vendors could be a channel for expanding Oracle's market reach. By offering PAH, Oracle enabled ISVs to build Oracle-backed solutions and deliver them to large customer bases. In exchange, Oracle negotiated pricing that was materially higher than the discount an ISV might receive on standard employee-named-user-plus licences, because PAH represents a qualitatively different and broader right.

PAH Eligibility Requirements: Who Can Use PAH

Not every software vendor can sign a PAH agreement. Oracle has specific eligibility criteria, and failing to meet those criteria means you cannot obtain PAH at any price.

Requirement 1: You Must Own the Intellectual Property of the Application. The application that will be hosted must be your proprietary software. You must own all intellectual property rights to the application's source code, functionality, user interface, and design. If you are reselling another vendor's application with Oracle technology embedded, you do not qualify for PAH. If you are a managed services provider offering hosting of third-party software that happens to use Oracle, you do not qualify for PAH.

Requirement 2: The Application Must Be Commercially Available and Offered to Multiple Customers. You cannot sign a PAH licence for a custom application built for a single customer or a limited set of customers. PAH applies only to products offered commercially for sale to multiple end customers. If you develop software that you deploy to 50 different organisations and charge them subscription fees, you qualify. If you develop custom software for one large customer and bill them for implementation and hosting, you do not.

Requirement 3: Oracle Technology Must Be Embedded and Integral to Your Application. The Oracle technology—typically Oracle Database, Oracle WebLogic, or Oracle middleware—must be an integral component of your proprietary application, not a separate service you offer alongside your application. This distinction is important. If your application provides business logic and functionality, and you happen to use Oracle Database as the underlying data store, that qualifies as embedded and integral. If you offer your application plus a separate "optional Oracle Database hosting service," that may not qualify as PAH because the Oracle technology is offered separately rather than embedded in the application.

Requirement 4: You Must Be a Member of Oracle PartnerNetwork (OPN) in Good Standing. PAH is available only to Oracle PartnerNetwork members. You must be an active OPN member with a current certification status. Termination of OPN membership terminates all PAH rights. This creates an ongoing dependency: if Oracle votes to terminate your OPN membership for any reason (violation of partner agreement, compliance issues, policy changes), your PAH rights terminate with it.

Requirement 5: Each PAH Licence Is Tied to a Specific Named Application. A PAH agreement covers one specific named application and the version lineage of that application. If you own a customer relationship management (CRM) application and you want to offer both a standard edition and an enterprise edition, those might be covered under a single PAH, or they might require separate PAH agreements. If you develop a second, unrelated application, you need a separate PAH agreement for that application. You cannot sign one broad PAH and use it across multiple products.

What PAH Covers: Rights and Limitations

A PAH licence authorises you to install and run specified Oracle products as part of your proprietary application and to deliver that application to multiple end customers via hosting, cloud deployment, or managed services. The PAH licence grants you (the ISV or hosting provider) the right; end customers do not receive Oracle licences.

Practically, a PAH agreement specifies which Oracle products are covered. Typically, this includes Oracle Database Enterprise Edition, Oracle WebLogic, Oracle Application Server, or other Oracle middleware components. The PAH agreement defines the scope of use: you can use the covered Oracle products as an integral component of your named application and no other purpose.

The critical limitation: you cannot extend PAH rights to end customers. Your customers do not have the right to use the Oracle technology outside the context of your application. They cannot access Oracle directly, extract Oracle libraries, or use Oracle functionality independently of your application. If a customer wants to use Oracle Database separately from your application, they must obtain their own direct Oracle licence.

Another limitation: PAH rights are tied to your OPN membership. If Oracle terminates your OPN status for any reason, PAH rights terminate immediately. This creates a significant dependency and audit risk that many ISVs do not fully account for in their strategic planning.

PAH Licence Metrics and Capacity Measurement

PAH agreements are typically structured using the same licence metrics as standard Oracle licences: Processor-based or Named User Plus (NUP). The difference is the right of use, not the measurement mechanism.

For processor-based PAH, you measure the number of processors in the infrastructure you use to run Oracle as part of your application delivery. If you host your application on a 32-core server, your licence metric is 32 processors. The x86 core factor of 0.5 still applies, so 32 cores require 16 Oracle processor licences. This measurement does not scale with the number of customers you serve; it scales with the infrastructure you provision for Oracle.

For Named User Plus (NUP) PAH, you measure the number of named users who access Oracle through your application. If 1,000 customers access your application and each of them is a named user for Oracle Database purposes, you require 1,000 NUP licences (with a minimum purchase requirement; Oracle typically requires a minimum of 25 NUP per licence).

The licence count is determined by your infrastructure and customer base, not by the number of end-customer organisations using your application. This is a critical distinction. If you host one customer's entire enterprise on a PAH-covered application, and that customer has 5,000 employees, all 5,000 are named users for Oracle purposes (if using NUP licensing), and you must license 5,000 NUP (200 minimum packs of 25).

PAH Pricing and Negotiation Strategy

There is no published price list for PAH. Oracle negotiates each PAH deal individually based on the ISV's deployment volume, market position, product strategic importance, and Oracle's competitive interest in the vendor's market.

Typical PAH discount ranges from 40 to 60 percent or more off standard Oracle list price for processor licences. The discount reflects Oracle's interest in embedding its technology in the ISV's product and benefiting from the distribution channel the ISV represents. An ISV with a large customer base, significant projected Oracle usage, and strategic market positioning attracts deeper discounts than an early-stage vendor with limited deployment volumes.

During PAH negotiation, ISVs should provide Oracle with detailed information on:

Deployment Forecast: Year-by-year projections of Oracle processor or NUP requirements for the next three to five years. Include assumptions about customer growth, compute scaling, and feature adoption. More detailed and credible forecasts provide Oracle visibility and support better pricing.

Competitive Context: Information about alternative technologies the ISV considered or could consider. If the ISV has evaluated PostgreSQL, MySQL, or Microsoft SQL Server and determined that Oracle was the appropriate choice, that context is valuable. Oracle wants to know what it is competing against and why you chose Oracle.

Market Position: Information about your market size, customer base, and growth trajectory. Vendors with large customer bases and strong market positions attract better terms because Oracle sees the potential for substantial Oracle licence volume.

Strategic Importance: Information about the importance of Oracle to your product roadmap and technology strategy. If Oracle is core to your product's value proposition, that provides leverage in negotiations. If Oracle is one of several database options you offer to customers, that reduces your negotiating leverage.

Strategic approach: engage Oracle's ISV sales team early and provide detailed business context. Request multiple pricing scenarios: processor-based vs. NUP-based, different support levels, and multi-year pricing. Allow Oracle time to construct a business case internally for the discount you are seeking. Rushed PAH negotiations typically result in less favourable terms than negotiations conducted with adequate lead time for Oracle's internal evaluation.

Support Fees and Annual Escalation Under PAH

PAH support fees are structured identically to standard Oracle support: 22 percent of the net PAH licence fee annually, with automatic 8 percent annual escalation. If your PAH licence fee is $2 million in Year 1, your annual support fee is $440,000 in Year 1, increasing to $475,200 in Year 2 (8 percent increase), $513,216 in Year 3, and so on.

Over a five-year period, support fees under the standard OMA escalation increase total support cost by approximately 47 percent compared to flat support fees. Over ten years, support cost doubles relative to Year 1 levels. This escalation compounds significantly and should be factored into long-term financial planning.

The negotiable element: support fee caps are often negotiable as part of PAH deal terms. Rather than accepting the OMA's standard 8 percent annual escalation, request a cap at 4 or 5 percent. Some ISVs negotiate multi-year fixed support pricing as an alternative, locking in support costs for the entire contract term and removing escalation uncertainty.

Support cap negotiation should be part of your initial PAH deal structure, not deferred to a future conversation at renewal. Once a PAH agreement is signed with uncapped support escalation, the escalation applies to all future support anniversaries, and renegotiating becomes difficult without providing Oracle commercial incentive (such as committing to larger deployment volumes).

PAH ULA: Unlimited Licence Agreements for ISVs with High-Growth Needs

For ISVs with high-growth deployment trajectories and significant Oracle usage scaling, Oracle offers a PAH variant called PAH ULA (Proprietary Application Hosting Unlimited License Agreement). This structures the same PAH rights under an unlimited licence model rather than a fixed licence count model.

Under a PAH ULA, you pay a fixed annual fee for unlimited deployment of covered Oracle products within the PAH context during the ULA term (typically two to three years). You do not count processor licences or NUP during the ULA term; instead, you deploy Oracle as needed to support customer growth, and all deployments are covered by the fixed annual fee.

The commercial advantage is substantial for vendors experiencing rapid growth. Suppose you anticipate scaling from 10 processors of Oracle to 100 processors over two years. Purchasing PAH licences incrementally would cost increasingly more as you add processors. Under a PAH ULA, you pay a fixed amount annually (negotiated upfront based on your deployment forecast), and every additional processor deployed during the ULA term is free.

At the end of the PAH ULA term, you conduct a certification audit where you declare all deployments of covered Oracle products during the ULA period. Those declared quantities become your perpetual PAH licence entitlement, purchased at market price on the certification date. From that point forward, you own the perpetual PAH licences and pay support fees on the certified quantity (with 8 percent annual escalation unless a cap was negotiated).

Strategic implication: maximise your Oracle deployment before your PAH ULA certification date. Every additional processor deployed before certification is effectively free (cost already paid in the fixed ULA fee). After certification, licences for deployments above the certified quantity must be purchased at prevailing market rates. If you anticipate significant growth during a PAH ULA period, plan to deploy aggressively before certification to lock in the largest perpetual entitlement at the lowest cost.

PAH Restrictions: What You Cannot Do

PAH has explicit restrictions that must be understood and enforced operationally:

You Cannot Transfer PAH Rights to End Customers. PAH licences are non-transferable. You cannot convey Oracle rights to your customers or allow customers to assume Oracle licensing obligations. Your customers access Oracle technology solely through your application, and they have no direct rights to the Oracle software or to use Oracle outside your application context.

PAH Rights Are Tied to the Specific Named Application. A PAH for your CRM application cannot be used for your ERP platform or any other application. Each distinct application requires a separate PAH agreement. This is an important constraint: if you develop related products or extensions, verify with Oracle whether they qualify as the same application or require separate PAH agreements.

You Cannot Sublicense Oracle to Other ISVs or Hosting Partners. PAH rights are not sublicensable. If you partner with another vendor or integrate with another ISV's platform, you cannot extend your PAH rights to them. They must obtain their own PAH agreements with Oracle.

You Cannot Offer Oracle Products Directly to Customers Outside Your Application. PAH covers Oracle as an embedded component of your application. You cannot offer standalone Oracle Database services or other Oracle products separately, even to customers who use your application. If a customer wants direct Oracle access or standalone Oracle services, they must purchase direct Oracle licences.

You Must Maintain OPN Membership in Good Standing. PAH rights are contingent on OPN membership. Termination, suspension, or downgrade of OPN status terminates PAH rights. You cannot maintain PAH rights independently of OPN status.

PAH vs. ASFU: Alternative ISV Licensing Models

Oracle also offers Alternative Service Fulfillment Use (ASFU) licences as an option for some ISV scenarios. ASFU differs from PAH in a critical way: ASFU licences are granted to end customers rather than to the ISV.

Under ASFU, your customers receive direct Oracle rights as part of your service delivery. Your customers own or control the Oracle licences, and you provide hosting and operational management. ASFU is appropriate when customers want direct Oracle ownership or when you are a pure hosting provider (rather than an embedded software vendor) offering Oracle as a service.

PAH is appropriate when you (the ISV) hold all Oracle rights, operate all Oracle infrastructure, and customers access only through your proprietary application. If customers want independent Oracle access or separate Oracle rights, ASFU may be more appropriate than PAH.

The distinction has significant liability and operational implications. Under PAH, you bear all responsibility for Oracle compliance, audit responses, and licensing obligations. Under ASFU, customers own the Oracle licences and bear those responsibilities. Your choice of PAH vs. ASFU should align with your operational model and your appetite for direct Oracle compliance responsibility.

PAH Audit Risk and Compliance Exposure

Oracle audits PAH deployments with particular intensity. Oracle LMS considers PAH deployments high-risk for non-compliance because PAH gives ISVs substantial discretion in how they deploy Oracle, and the audit scope is broad.

During a PAH audit, Oracle LMS will request:

Deployment Inventory: A complete list of all Oracle deployments covered under PAH, including processor counts, customer counts, and customer identities.

Customer Configuration: Information about how many customers each Oracle deployment serves and whether Oracle instances are shared across customers or isolated per-customer.

Scope Verification: Evidence that the deployment is indeed for the named application covered under the PAH agreement, not for other applications or purposes.

Oracle Version and Feature Usage: Information about which Oracle versions are deployed, which features are used, and whether additional option licences are required.

The audit risk areas: deploying Oracle under a PAH for applications or purposes not explicitly named in the PAH agreement; failing to document that deployments are for the covered application; exceeding the licensed processor or NUP count without timely purchase of additional licences; or allowing deployments to continue after OPN membership is suspended or terminated.

Many ISVs encounter audit findings because they did not maintain clear documentation of which deployments were PAH-covered and which required alternative licensing. If Oracle LMS cannot verify that a specific Oracle deployment was part of the covered PAH application, LMS will assume it was not PAH-covered and demand that the ISV purchase direct licences for that deployment retroactively.

Negotiation Strategy and Key Contract Elements

When negotiating a PAH agreement, prioritise these contract elements:

Define the Covered Application Broadly. Rather than naming one specific application version, negotiate language that covers the application, all versions, related extensions, and modules. Language such as "Oracle [Product] and all versions, updates, and derivative products of [Product]" provides flexibility for product evolution without requiring PAH renegotiation.

Negotiate Support Fee Caps. Request a cap on annual support increases. Standard OMA language provides 8 percent escalation; negotiate for 4, 5, or 6 percent, or negotiate multi-year fixed support pricing. This is one of the highest-impact negotiating points in PAH terms.

Extend Audit Notice Period. Oracle's standard PAH audit notice period is 45 days. Negotiate for 60, 75, or even 90 days. Extra notice period allows you to engage advisors, gather documentation, and assess whether proactive true-up payments or licence purchases might resolve issues before the formal audit begins.

Address OPN Membership Dependency Explicitly. Negotiate language requiring Oracle to provide advance notice (typically 90 days) before any OPN status change that would affect PAH rights. This protects you from sudden OPN termination that would kill PAH rights without opportunity to remediate.

Clarify Deployment Scenarios. Ensure the PAH agreement covers your intended deployment model. If you plan shared Oracle instances across multiple customers, that should be explicitly covered. If you intend per-customer dedicated instances, that should be specified. Ambiguity in deployment scenarios leads to audit disputes.

Build in Renewal Terms. Negotiate multi-year PAH pricing with clear renewal terms for subsequent periods. Avoid leaving renewal pricing to Oracle's discretion at the end of your PAH term. Upfront commitment to renewal terms protects you from dramatic price increases at renewal.

Seven Key Questions to Ask Oracle Before Signing a PAH Agreement

1. How Broadly Can the Covered Application Be Defined? Will the definition cover future versions and related extensions, or does each version require a separate PAH agreement?

2. What Is the Support Fee Cap? Will you accept the standard OMA 8 percent escalation, or can you negotiate a lower cap or fixed multi-year support pricing?

3. What Are the Audit Notice and Preparation Timelines? Can you extend the standard 45-day audit notice period to 60, 75, or 90 days?

4. What Happens if OPN Membership Changes? If Oracle suspends or terminates your OPN status, what notice and remediation period are you provided before PAH rights terminate?

5. Are Shared Oracle Instances Across Customers Permitted? Can multiple customers share the same Oracle instance and database, or must each customer have dedicated Oracle infrastructure?

6. What Reporting and Documentation Requirements Apply? How frequently must you report Oracle deployment data to Oracle? What documentation must you maintain to prove PAH compliance?

7. What Happens at PAH Renewal? What is the process for renewal? Is pricing locked in upfront, or is it subject to market rates at renewal time?

These questions should be clarified before signature, not discovered during the first audit or renewal negotiation.

Practical Recommendations for PAH-Licensed ISVs

For ISVs operating under PAH agreements, here are the most effective compliance and risk management practices:

1. Maintain a Deployment Inventory. Create and maintain a current inventory of all Oracle deployments under PAH, including deployment dates, processor/NUP counts, customer assignments, and application versions. Update this inventory monthly or quarterly.

2. Document Audit Preparation Process. When you receive an Oracle audit notice, immediately engage your advisors. Use the entire notice period (45 or negotiated longer) to gather documentation, verify deployment counts, and assess whether proactive licence purchases or true-up payments are warranted.

3. Monitor OPN Membership Status. Track your OPN membership status continuously. Ensure your OPN contact information is current so you receive notifications of any status changes. Establish internal processes to prevent inadvertent OPN termination due to non-payment or missed compliance requirements.

4. Clarify Application Boundaries. Ensure your development, product management, and operations teams understand clearly which applications and versions are PAH-covered. Prevent accidental use of Oracle outside the covered application scope.

5. Plan PAH ULA Strategically if Pursuing High Growth. If your deployment volumes are scaling rapidly, evaluate PAH ULA for the next contract period. Plan strategically to maximise deployment before your ULA certification date to lock in the largest perpetual licence entitlement.

6. Negotiate Multi-Year Renewals with Fixed Pricing. Before your current PAH agreement expires, begin renewal discussions and negotiate multi-year pricing with fixed costs. This provides budget certainty and typically achieves better pricing than annual renewals subject to market rates.