Oracle Proprietary Application Hosting (PAH) License Model

What are Oracle Hosting Licenses?

• Definition: Licenses for Oracle technology software, as well as those for Independent Software Vendors (ISVs), are used to offer hosted solutions.
• Purpose: Enables ISVs to build and run their software as a service (SaaS).
• Includes Databases and middleware (e.g., WebLogic).
• Usage: Defined in the Application Package Registration Form (APRF).
• Restrictions: This offer does not apply to third-party applications or internal use only.

Oracle Hosting Licenses

The Oracle Proprietary Application Hosting (PAH) license model is a special Oracle licensing program designed for Independent Software Vendors (ISVs) that host their applications as services for multiple customers.

It allows an ISV to embed Oracle technology (e.g., Database, WebLogic) in a proprietary application and offer it as a SaaS or hosted solution to end clients, which is not permitted under standard Oracle licenses.

This model often offers significant cost advantages and flexibility compared to full-use licensing, but it comes with strict usage conditions.

Enterprise IT leaders must understand the benefits of PAH (such as lower aggregate costs and simplified customer onboarding) as well as its limitations and compliance risks to determine if it’s the right fit for their organization.

An enterprise licensing team reviews Oracle’s hosting license terms for a SaaS application. The PAH model enables ISVs to offer Oracle-powered software to multiple clients under a single license.

Read more about Oracle license models.

What Is the Oracle PAH License Model?

Oracle’s Proprietary Application Hosting (PAH) license is a contractual framework that grants an ISV the rights to use Oracle software to host its application for third parties.

In a traditional Oracle license (often called “Full Use”), the software can only be used for the customer’s internal business operations.

PAH, by contrast, explicitly permits use on behalf of external end users, making it essential for any company delivering Oracle-based software as a service.

• Designed for ISVs/Solution Providers: Only organizations that own and develop a proprietary application are eligible. The ISV’s application must incorporate Oracle technology and be the intellectual property of the ISV (not a third-party product).
• Multi-Customer Hosting Rights: PAH enables a one-to-many service model, allowing the ISV to host a single application instance (or multi-tenant environment) and serve multiple client organizations. End customers access the application via the ISV’s environment; they do not need to obtain Oracle licenses themselves.
• Replaces Older Hosting Agreements: Oracle introduced PAH to replace ambiguous hosting agreements from the past. It outlines how Oracle programs (such as databases and middleware) can be utilized in a commercial hosting scenario, establishing a legitimate path for SaaS vendors who choose Oracle as their platform.

In essence, the PAH model is Oracle’s answer to the cloud era: enabling ISVs to build Oracle-powered SaaS offerings without requiring each client to have a license.

If your company provides a cloud solution built on Oracle Database or middleware, PAH is likely the only licensing model that provides legal coverage for third-party use. However, it imposes specific requirements on who can use it and how.

PAH vs. Full Use Licensing: Key Differences

Understanding how PAH licenses differ from standard Full Use Oracle licenses is critical:

• Usage Scope: Full Use licenses are for internal use only, whereas PAH licenses explicitly allow hosting services for external customers. Under a Full Use license (bound by Oracle’s Master Agreement terms), you cannot provide services to third parties with your Oracle software. PAH grants that permission, but only for your proprietary solution.
• Eligibility: Full Use licenses can be purchased by any end-user organization. PAH licenses can only be purchased by qualifying Oracle partners (ISVs) who have enrolled in Oracle’s partner program and have an approved application. End-users (like banks, hospitals, etc,. that use Oracle for internal systems) cannot normally buy PAH licenses for their use – it’s meant for service providers.
• Scope of Application: A PAH license is tied to one specific application. Oracle requires the ISV to complete a Proprietary Application Registration Form (PARF/APRF), which describes the solution that will be hosted and the Oracle products it utilizes. The PAH license may only be used in the context of that registered application. Full Use licenses have no such restriction – they can be used for any purpose (but again, only internally).
• Third-Party Access: With PAH, the ISV’s end customers are allowed to indirectly use Oracle software (via the ISV’s app) without each having their own Oracle contract. Full Use licenses do not allow giving such access to external parties. PAH essentially extends limited Oracle usage rights to your customers as part of your service.
• Installation Location: Under PAH, Oracle software must run in the ISV’s environment (data center or cloud). You cannot install PAH-licensed Oracle software at a client’s site. By contrast, an end-user with a Full Use license can deploy Oracle anywhere for their internal use (including on a third-party cloud or hosted environment, provided they maintain control).
• Contractual Form: Full Use licenses are sold via an Oracle ordering document that references the Oracle Master Agreement, which includes standard terms. PAH deals also utilize Oracle order documents, but include specific hosting clauses that grant the extra rights, and are paired with the APRF, which becomes part of the contract. Essentially, PAH contracts add a “hosting services” clause that overrides the internal-use-only rule for that situation.

In summary, a Full Use license is akin to owning software for private use, whereas a PAH license is akin to a commercial use permit to operate a service for others. The table below compares these and other Oracle license models relevant to ISVs:

Table: Oracle licensing options for ISVs and hosting – comparing Full Use, ASFU, ESL, and PAH models. Each step down in cost comes with stricter usage limits.

Cost Structure and Pricing Considerations

One big reason ISVs pursue the PAH model is cost efficiency.

Oracle’s pricing for PAH licenses is generally more favorable when you’re serving many end users:

• Discounted License Fees: Oracle typically offers PAH licenses at a lower price than standard licenses, because the usage is restricted. In many cases, ISVs have negotiated deals at 50% or more off the equivalent full-use list price. For example, if Oracle Database Enterprise Edition costs approximately $47,500 per processor (list), a PAH agreement might effectively price it around $23,000 per processor or less. In some scenarios, Oracle even employs a royalty model – the ISV may pay Oracle a percentage (e.g., 5-10%) of their subscription revenue, rather than a per-processor fee, thereby aligning costs with business growth.
• Bundling and Unlimited Deals: Oracle may structure PAH agreements as an Unlimited License Agreement (ULA) for a fixed term (e.g., 3 years) specifically for the ISV’s application. This means the ISV can deploy unlimited Oracle software for that app during the term. Such PAH ULAs can significantly reduce unit costs as the ISV expands its customer base. However, they require a careful certification process at the end to quantify usage, and Oracle often imposes extra restrictions (narrow usage scope, complex exit audits) compared to a normal ULA.
• Support Fees Optimization: A common motivation is reducing annual support costs. Standard Oracle support renewals increase ~3-4% each year on full-use licenses – a pain point for customers. Under a PAH deal, an ISV might replace numerous customer-owned licenses (each with its support) with a single contract that has a lower support base. Over several years, this can result in significant savings. Oracle sales representatives often highlight scenarios where replacing, for example, $1 million of full-use licenses (with 22% yearly support) with a $ 500,000 PAH agreement could cut support fees by more than half. Important: These savings are real only if you legitimately qualify for PAH usage; otherwise, they’re a risky illusion.
• End Customer Savings: Perhaps the biggest economic benefit is on the end clients’ side. Without PAH, each client of the ISV would potentially have to purchase their own Oracle licenses (or the ISV would need to buy full-use licenses for each). That is usually cost-prohibitive and discourages clients. With PAH, one Oracle license investment by the ISV covers all clients, making the ISV’s solution more affordable and attractive. For instance, if 10 customers would have needed $100k each in Oracle licenses ($1M total), an ISV might instead license the environment for say $200k and serve all 10 – a win-win (Oracle gets a sale it might not have otherwise, the ISV grows user base, clients pay only for the solution not the pricey infrastructure software).

Real-World Example: A healthcare SaaS provider uses Oracle Database and WebLogic to host an electronic medical records application. Under standard licensing, each hospital client would need its own Oracle licenses, which would easily cost $ 300,000 or more each – a non-starter. Instead, the provider signs a PAH agreement for unlimited use of Oracle Database and 16 processor licenses of WebLogic in their cloud data center. They negotiate a 50% discount off list prices due to the restricted use. Now, the provider pays Oracle approximately $2 million upfront, plus 22% annual support, to cover the entire multi-tenant platform. This enables them to serve dozens of hospitals. Each new hospital incurs no additional Oracle license cost – just incremental support at most. The per-customer Oracle cost drops from approximately $300,000 to approximately $40,000, which is embedded in the subscription price.

While pricing is negotiable and case-specific, Oracle’s goal is to make the economics compelling for ISVs so they choose Oracle over cheaper databases or middleware. Always model the 5-year total cost, including upfront fees, support uplifts, and any ULA certification outcomes.

Ensure that the discount or structure accounts for your expected growth (e.g., if you anticipate a doubling of user count or transactions, consider an unlimited plan or a price cap). Also, clarify what happens to support fees if you convert existing licenses to PAH. Oracle may offer to terminate and provide credit for some support, but ensure this is in writing.

Eligibility Requirements and Restrictions

Because the PAH license grants broad hosting rights, Oracle sets strict eligibility criteria and usage restrictions.

Before pursuing this model, ensure you meet these requirements:

• Independent Software Vendor Status: You must be an Oracle partner (Oracle PartnerNetwork member) that develops and sells its software. Typically, you’ll need to sign Oracle’s partner agreement and be authorized to license Oracle products through that channel. Pure end-user companies (those that only use third-party software) are not eligible to purchase PAH licenses.
• Ownership of Intellectual Property: The application you are hosting with Oracle must be your proprietary product. It can’t be a generic Oracle product or someone else’s software. Oracle defines a “Proprietary Application” as a commercially available solution that you developed and own (or have exclusive rights to). If you run an Oracle packaged app like E-Business Suite for clients, that doesn’t qualify – you’d need a different arrangement. Likewise, you cannot use PAH to host, for example, a SAP or Microsoft application on Oracle Database; it must be your application.
• Multi-Tenant or One-to-Many Service: PAH is designed to serve multiple customers from a single environment. Using it to provide a dedicated Oracle environment for a single, specific customer would likely violate the spirit (and possibly the letter) of the agreement. Oracle expects PAH solutions to be commercially available to the market. Suppose you have only one client and essentially act as their outsourced IT, running Oracle for them. In that case, PAH is not the correct model (that scenario is usually just a standard license with an outsourcing clause).
• Application Registration Form (APRF/PARF): A critical step is completing the APRF as part of your contract. This form names your application, describes its functionality, and lists the Oracle programs it utilizes. The license rights are limited to what’s described here. Tip: Keep the description broad and general. Suppose you lock it down too narrowly (e.g., specifying specific module versions or a narrow use case). In that case, any future change or expansion of your software might technically fall outside the license, requiring a contract update or a new license. For example, instead of “HR management app version 2.3 for the retail industry,” describe it as “a human resources management software platform” to allow flexibility.
• No Resale of Oracle Licenses: The ISV holds the Oracle license; end customers do not get Oracle licenses from this. You cannot “resell” Oracle licenses or give your customer a sublicense. The customers are simply using your application service. All Oracle software must remain under your control. Contracts typically even state that you cannot install the Oracle programs at the end-user’s site or allow them direct access to Oracle technology interfaces.
• Environment Control & Compliance: The ISV is responsible for ensuring all environments are licensed. During development and prototyping, Oracle’s partner program rules may let you use software without immediate licensing. But once the application goes live for customers, every instance (production, test, development) that runs Oracle must be properly licensed under the PAH agreement. The partner program usage only covers non-production work before paying customers are acquired. After go-live, you’ll likely include dev/test in your PAH counts or have separate non-production licenses via PAH (depending on how the deal is structured). Failing to license supportive environments is a common audit finding.
• Geography and Cloud Use: Confirm if your PAH license has any territorial restrictions or if it covers deployment in public clouds. Oracle generally allows you to deploy the software anywhere (on-prem data centers, Oracle Cloud, AWS, Azure, etc.) as long as it’s for the permitted use. However, Oracle often insists on contract amendments or notifications if you plan to run the workloads on third-party cloud infrastructure. Some PAH agreements explicitly mention allowed deployment platforms. Ensure your contract language doesn’t unintentionally bar you from using, for example, AWS or a specific region – negotiate this upfront.

Benefits of PAH for ISVs and Clients

When used in the right scenario (a genuine ISV with a multi-customer app), the PAH license model offers several advantages:

• Cost Savings & Competitive Pricing: As discussed, PAH can significantly reduce the Oracle licensing cost per customer. This allows ISVs to price their SaaS offerings more competitively. Instead of each client requiring a six-figure Oracle investment, the ISV spreads one investment across multiple clients. Lower costs can translate to lower subscription fees or higher margins. It also means huge incremental license costs for each new customer don’t hamper the ISV’s growth.
• Simplified Customer Onboarding: End customers don’t have to navigate Oracle licensing at all – they simply subscribe to the ISV’s service. This removes a significant adoption barrier. Clients can get started quickly without the need to procure their own Oracle licenses or worry about Oracle audits on their usage. All compliance responsibility lies with the ISV.
• Access to Oracle’s Technology Stack: PAH makes it feasible for ISVs to leverage Oracle’s robust database and middleware technology in their products without pricing themselves out of the market. Oracle Database, for example, offers high performance, security, and scalability. With PAH, an ISV can use these enterprise-grade features under a controlled cost, which can be a competitive differentiator for the ISV’s solution (compared to using open-source or less powerful alternatives).
• One Agreement Covers All: The ISV manages a single licensing agreement with Oracle, rather than maintaining dozens of separate licenses for each customer. This centralizes the compliance and relationship with Oracle. It can also streamline support – the ISV often becomes the first line of support for Oracle technology issues in their app (with the ability to escalate to Oracle if needed via their partner support channels). End users always call the ISV for any issues, providing a seamless support experience.
• Flexibility for SaaS Growth: PAH licensing can scale with your business. If you gain more customers and require additional Oracle capacity, you can simply acquire more licenses under your existing agreement (or plan for growth in an unlimited deal). There’s no need for each customer to individually scale their Oracle footprint – the ISV does it centrally. This elasticity is crucial for modern cloud services that must be able to onboard new users quickly. Many PAH agreements can be structured to allow for periodic true-ups, rather than requiring a license purchase for each minor increment of usage, making growth management easier.

In short, PAH enables ISVs to innovate and sell Oracle-based services without each sale triggering a licensing nightmare. It aligns Oracle’s commercial model with the SaaS delivery model.

Common Pitfalls and Risks

Despite its benefits, the PAH model can be misused or mis-sold, leading to serious compliance and financial risks.

• Misalignment (Using PAH When You Shouldn’t): Oracle’s sales teams have been known to pitch PAH deals to regular end-user customers as a way to cut costs. For example, an Oracle rep might tell a large company running third-party applications on Oracle, “We can replace your Full Use licenses with a PAH Unlimited deal and save you support money.” If that company is not an ISV and doesn’t own a unique application to host, they could end up in violation. If you are an end-user (not providing SaaS to others), PAH is generally not for you. Signing a PAH agreement when you don’t meet the criteria means you’re essentially out of compliance from day one. Oracle’s auditors will not accept “but the sales rep said we could” as an excuse.
• Overly Broad or Vague “Proprietary Application”: In some cases, organizations have defined their “proprietary application” in name only, simply to justify a PAH deal (e.g., referring to their collection of internal systems as the “Customer Information System” as the app). This is a risk – if audited, you must demonstrate that the application is genuine, owned by you, and commercially available. Creating a fictitious umbrella application to circumvent PAH can lead to license revocation or substantial penalties. Always be truthful and ensure you have a bona fide software product if you go the PAH route.
• License Scope Creep: Even genuine ISVs must be cautious about scope. If you start using Oracle for anything outside the registered application, those uses are unlicensed. For instance, if you have a PAH license for your HR SaaS product, you can’t suddenly also leverage that Oracle database for a different tool or a separate client-specific customization that isn’t covered. Similarly, if you develop a second product, you might need to get a separate PAH agreement. Using one PAH license for multiple distinct solutions is not allowed unless negotiated with Oracle (and each would need its registration form).
• Development/Testing Environments Not Covered: As mentioned, some ISVs forget to license non-production environments once their product goes live. If Oracle audits your PAH deployment, they will check all instances where Oracle software is installed. Every environment that’s supporting the service (prod, QA, dev, DR) must either be explicitly included under the PAH licenses or otherwise licensed. Non-production environments often have user minimums (Oracle’s Named User Plus metric requires a minimum number of users per processor, which applies to test servers, too). Ensure your contract covers these or that you purchase the necessary extra licenses.
• Audit Frequency and Scrutiny: Oracle tends to audit PAH customers more frequently and thoroughly than typical end users. Because hosting setups are complex and high-risk for Oracle, they will want to verify that you aren’t overstepping the agreed terms. Expect Oracle’s License Management Services (LMS) to require detailed evidence, including a demonstration that only your IP is being hosted, a review of your application’s functionality, verification of user counts or processors against what is licensed, and confirmation that no prohibited use is occurring (such as a client with direct database access). ISVs should implement regular self-audits and record-keeping to prepare for this. The risk of a failed audit includes the forced purchase of full-use licenses for any misuse (often at the list price backdated to the first use) and possibly back-support fees or other penalties.
• Complex ULA Exits: If your PAH agreement is an unlimited term that ends, be prepared for a potentially complicated process to certify usage. Oracle will want to ensure you only certify licenses for the allowed application. Any ambiguity in what’s covered can become a negotiation pain point at ULA exit. It’s vital to engage experts and start planning the exit early – sometimes a year in advance – to avoid getting trapped or paying for extensions. Mistakes during a PAH ULA exit could leave you either under-licensed (if you undercounted usage) or stuck with unnecessary licenses (if Oracle forces inclusion of things you don’t need outside the ULA).
• Cloud Deployment Ambiguities: If you host your app on a third-party cloud (e.g., AWS, Azure), Oracle’s contractual stance can be complex. While technically a processor is a processor anywhere, Oracle, in practice, might require you to sign an addendum specifying that you’re allowed to run the PAH environment on non-Oracle cloud infrastructure. Failing to do so ahead of time could create friction or attempted license pushback later. Some ISVs have reported that Oracle is attempting to mandate the use of Oracle Cloud for hosting, unless an amendment is signed – even if it is not legally enforceable, it can cause negotiation headaches. Ensure that your cloud usage is clearly and transparently discussed and agreed upon in the license terms.

Best Practices for Negotiating a PAH Agreement

To make the most of a PAH license while protecting your organization, consider these best practices during planning and negotiation:

• Validate Qualification: Double-check that your situation truly fits the PAH model. Are you an ISV with an application you’ll provide as a service? If yes, proceed. If you’re unsure, consult with a licensing expert before engaging with Oracle’s sales team.
• Engage Oracle Partner Programs: Work through Oracle’s partner channels. Often, the Oracle partner team (which handles ISVs) is separate from the direct sales team for end-users. Partner reps may better understand PAH specifics. Ensure your Oracle PartnerNetwork membership is up to date and that you have the necessary partner level to transact licenses.
• Negotiate Pricing and Metrics: Don’t accept the list price; Oracle expects to negotiate for PAH deals. Leverage the fact that Oracle wants to keep ISVs on their tech stack – mention alternative databases or cloud platforms to push for better discounts or a more favorable metric. For instance, if your user counts fluctuate, a processor metric might be safer than a Named User metric. If your processing load is variable, consider a term with no limit or a subscription model tied to your revenue. Get quotes for multiple licensing metric options.
• Include All Needed Components: Ensure the PAH agreement encompasses all Oracle products you will utilize for the solution. This can include database options (such as partitioning, Advanced Security, etc.), middleware, analytics, and more. It’s often structured as a bundle. If you leave something out and later need it, adding it mid-term could be costly. Also consider future roadmap: if you might incorporate an Oracle feature later (e.g., Oracle Machine Learning, or another DB option), try to have it pre-authorized or at least have pricing locked in.
• Define the Application Broadly: As noted earlier, keep the APRF description broad. It should encompass the general purpose of your application without overly detailed specifics that could change. For example, describe the business domain and general functionality (“a multi-tenant supply chain management platform”) rather than a narrow module list. This provides wiggle room for your product evolution.
• Secure Cloud and Outsourcing Rights: If you plan to run the service on AWS/Azure or use a third-party data center/outsourcer to operate it, ensure that this is explicitly documented in writing. Oracle’s standard hosting clause might allow it. Still, it’s wise to add a line such as “Customer may deploy the licensed programs on third-party cloud infrastructure or designate a third-party to manage the environment.” This avoids any later argument that only your company’s data center was permitted.
• Plan for Compliance & Audits: Establish internal processes to manage your license usage effectively. For example, if licensed by the processor, track where Oracle software is installed and the hardware configurations (cores, CPU type) to calculate usage against your entitlements. If licensed by Named Users, maintain lists of active named users across all tenants and update them regularly. Document everything that shows you’re adhering to the “proprietary application” requirement (product brochures, website pages of your solution, etc., to prove it exists as described). Being organized will make any Oracle audit far smoother. It also helps you avoid accidental non-compliance.
• Consider Expert Advice: Oracle licensing is complex, and PAH is an especially nuanced area. Engage an independent Oracle licensing advisor or legal counsel to review the contract before signing. They can identify any problematic clauses (for example, Oracle sometimes slips in wording that could restrict use in government sectors or limit support rights) and help negotiate improvements. The cost of advice is minor compared to potential non-compliance penalties or an overly restrictive contract.
• Understand ULA Exit Terms: If you do an unlimited PAH agreement, clarify the exit process in the contract. Know how long you have to certify, what constitutes included use, and if any products will convert to full-use licenses afterward. It might be worth negotiating a partial certification (maybe converting only what’s needed) or a follow-on support structure for anything certified. Don’t wait until the ULA is ending to figure this out.

By being proactive in these areas, you set up a PAH arrangement that truly delivers value without unwelcome surprises.

Recommendations

• Assess Fit Before Committing: Only pursue a PAH license if you genuinely develop and host a proprietary application for multiple customers. If you’re an end-user organization looking to save costs, do not force-fit into PAH – explore other negotiation tactics instead.
• Leverage Oracle’s Incentive: Use Oracle’s desire to win ISV business to your advantage. Negotiate aggressive discounts or flexible terms (such as an unlimited term or revenue-based fees) so that the deal aligns with your growth. Evaluate the long-term cost-benefit analysis in comparison to alternative databases or cloud services.
• Cover All Usage in Contract: Ensure the PAH agreement explicitly covers all scenarios: production, testing, DR environments, third-party cloud deployment, etc. No ambiguity should remain about where or how you can use the Oracle programs. This avoids conflicts and compliance gaps down the road.
• Keep Documentation and Stay Compliant: Implement strict internal tracking for Oracle usage under PAH. Document your application’s scope and ensure all Oracle use stays within that scope. Regularly audit yourself as if you were Oracle – check that you haven’t, for example, spun up an unlicensed instance or started using Oracle for something outside the agreement. Early detection allows you to correct course or seek an amendment proactively.
• Consult Experts for Complex Deals: For any enterprise-scale PAH deal or PAH Unlimited License Agreement, it is advisable to involve experts. They can help negotiate contract language, guide you on filling the APRF strategically, and prepare you for the end-of-term process. Given the financial stakes, an experienced licensing advisor can save you from costly mistakes and ensure you realize the full benefits of PAH.

A Checklist for Navigating Oracle PAH Licensing

1. Confirm ISV Eligibility: Verify that your organization is an Oracle partner and owns a unique application suitable for multi-customer hosting (the basic requirement for PAH).
2. Scope the Application Clearly: Draft a broad description of your proprietary application for the Oracle registration form. Include all necessary Oracle components and ensure they reflect a multi-tenant service offering.
3. Model the Economics: Calculate your 3-5 year Oracle licensing costs under PAH versus alternatives. Include expected growth, support fees, and potential ULA scenarios. Ensure the PAH model yields the anticipated financial benefits.
4. Negotiate the Contract Details: Work with Oracle to obtain favorable pricing and terms. Address deployment on any cloud platforms, coverage of test/dev environments, and any unique needs (e.g., government customer carve-outs or security requirements). Don’t sign until the contract fully suits your use case.
5. Implement Compliance Controls: Once signed, set up monitoring of Oracle usage (processors, users, etc.) tied to your PAH agreement. Train your engineering and ops teams on the boundaries of the license (e.g,. “we can’t use Oracle outside the XYZ app”). Schedule periodic internal reviews so you’re always audit-ready.

FAQ

Q1: Is the Oracle PAH license model right for my company?
A1: PAH is intended for software providers who sell a service or software solution to other companies using Oracle technology. If you are an ISV delivering a SaaS or hosted solution built on Oracle Database, Middleware, etc., then PAH is likely the appropriate model. If your company is simply an end user of Oracle software for its operations, PAH is not applicable (and attempting to use it would violate Oracle’s terms). Always assess whether you meet the “proprietary application for multiple customers” test. If not, stick to standard licensing or other models, such as ASFU/ESL.

Q2: How does PAH licensing save money compared to traditional Oracle licenses?
A2: PAH licenses are priced with volume and restricted use in mind. Instead of each of your customers buying full licenses (which sum up to a high cost), you, as the ISV, purchase a set of Oracle licenses to cover your entire hosted platform, often at a steep discount. You effectively share the cost of those licenses across all your clients. Additionally, Oracle support fees under a single contract are often significantly lower than those for dozens of separate support contracts for customers. The net result is a lower total cost of ownership, enabling you to offer your solution at a better price. For example, you might pay 50% of normal license costs and legally serve 100% of your customer base with that.

Q3: What are the risks if we incorrectly use a PAH license (or sign one mistakenly)?
A3: The risks are significant. If you sign a PAH agreement but your usage doesn’t qualify (for instance, you’re not hosting a proprietary app for others), you are essentially unlicensed in Oracle’s eyes. In an audit, Oracle can demand you purchase proper licenses (often at list price, plus back support) for all usage that falls outside the PAH terms. This could result in millions of unexpected fees. Additionally, violating contract terms can result in the termination of the agreement, potentially putting your deployed systems at legal jeopardy. There’s also reputational risk and potential legal disputes. In short, misusing PAH is viewed as non-compliance – the same as any other license breach – and Oracle aggressively enforces that.

Q4: What key contract terms should I focus on when negotiating a PAH deal?
A4: Pay attention to: Pricing structure and caps (ensure discounts are applied and future support increases are limited), the definition of your proprietary application (it should be broad enough for future needs), the hosting clause language (that it truly permits what you intend to do, including cloud deployment if relevant), and any special restrictions (sometimes Oracle disallows certain industries or uses – make sure none of these inhibit your business). Additionally, clarify the process for adding users or processors, as well as for terminating or renewing the agreement. If it’s an unlimited term license, detail how the end-of-term certification works. It’s wise to have a licensing expert or attorney review these clauses.

Q5: Can I convert existing Oracle licenses or use Oracle Cloud with a PAH model?
A5: It is possible to transition from standard Oracle licenses to a PAH agreement, but it requires Oracle’s approval and likely a contract amendment. Oracle may allow you to cancel some of your full-use licenses (and their support) when you sign a PAH deal, effectively “converting” those investments into the new model, typically by giving credit or discounts. However, approach this carefully and ensure the old usage is fully covered by the new agreement to avoid gaps. Regarding the use of Oracle Cloud (OCI) or other clouds under PAH, yes, you can deploy your solution on cloud infrastructure. Many ISVs run their Oracle-based SaaS in AWS, Azure, or OCI. Please ensure that you inform Oracle and have this reflected in the contract if necessary. Oracle occasionally proposes an amendment for clarity, but fundamentally, a processor license is valid on any server (on-premises or cloud) that you control. If Oracle’s terms seem to restrict that, negotiate an adjustment. The goal is to maintain architectural flexibility to host your app wherever it makes sense, while staying compliant.

Read about our Oracle Licensing Assessment Service.

Would you like to discuss our Oracle Advisory Services with us?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Message *

Submit