Oracle Proprietary Application Hosting (PAH) FAQs

Oracle Proprietary Application Hosting (PAH) FAQs

What is an Oracle PAH (Proprietary Application Hosting) license?

An Oracle Proprietary Application Hosting (PAH) license is a specialized Oracle licensing model that enables an ISV or service provider to use Oracle software as part of a hosted service or Software-as-a-Service (SaaS) offering. In simpler terms, a company with its own proprietary application can legally run that application on Oracle Database (or middleware like WebLogic) in their data center or cloud and serve multiple customers with it.

PAH licenses differ from normal Oracle licenses because they explicitly allow the use of Oracle software to host services for end customers, something standard licenses normally forbid.

This model evolved as Oracle’s answer for ISVs building SaaS solutions: instead of each end customer needing their own Oracle license, the ISV holds the Oracle license and provides a cloud or hosted solution to many clients on a single Oracle-backed platform.

It has effectively replaced older Oracle hosting licensing programs from the 2000s, formalizing how Oracle technology can power multi-tenant applications.

How does a PAH license differ from a standard full-use Oracle license?

A standard Oracle license (full-use) is meant for a customer’s internal use only—it cannot be used to process data or provide services for third parties as a commercial service.

Key differences:

• Allowed Use: Full-use licenses are for a company’s internal operations. PAH licenses, on the other hand, specifically allow the Oracle software to deliver a service to external end users. For example, with PAH, an ISV can run an Oracle database that hosts data for many customers in a SaaS model. A full-use license agreement would normally prohibit that scenario.
• Who Can License: End customers (businesses, organizations) buy full-use licenses for their own use. PAH licenses are only available to Oracle partner ISVs who offer a proprietary application as a service. End customers don’t buy PAH licenses but subscribe to the ISV’s service.
• Contract Terms: Full-use licensing terms are outlined in Oracle’s standard contracts (Oracle Master Agreement and ordering documents); typically, each customer signs those. PAH is governed by a partner agreement and an Application Registration Form (ARF/APRF) that describes the hosted application and its scope. The terms are more restrictive about what the Oracle software can be used for.
• Scope of Usage: Full-use has no application-specific restriction—you can use Oracle for any app. PAH is tied to a specific proprietary application owned by the ISV. The Oracle software under PAH can only be used to run that application.
• End User Agreements: In full use, each end user is an Oracle customer (directly or via a reseller). In PAH, the end user has no direct agreement with Oracle. The end user’s agreement is with the ISV for the service, and the ISV in turn has the agreement with Oracle.
• Pricing/Discount: PAH licenses often come with a different pricing structure or discount because of the restricted use (similar to ASFU’s discount). Typically, they can be cheaper per unit than full-use (which encourages ISVs to use Oracle). However, Oracle might ensure they still get a reasonable share since one PAH deployment might serve many customers.

In summary, full-use = internal use, any purpose, bought by the end customer; PAH = external/SaaS use, tied to one app’s service. Only ISVs can get PAH, which is like a special club that only solution providers join, whereas full-use is the general pool for everyone else.

Who can obtain and use Oracle PAH licenses?

Oracle PAH licenses are available only to ISVs, solution providers, or software companies that meet specific criteria:

• The company must provide a commercial service or application to multiple end customers (essentially acting as a hoster or SaaS provider). It needs to have a proprietary application, meaning it has developed and owns the intellectual property of the offered software.
• They must become an Oracle partner and typically enter into Oracle’s partner licensing agreements, including signing the Proprietary Application Hosting addendum and an application registration form (which details the application they’ll host on Oracle).
• Regular end-user companies (who only use software internally) cannot directly get PAH licenses. For instance, a bank or a manufacturer using Oracle for their own operations does not qualify, because they are not providing a SaaS or hosted application to others. Oracle wouldn’t sell them a PAH license to save costs if they’re not an ISV.
• Sometimes, even traditional outsourcing or managed service providers don’t qualify unless they have their distinct application. PAH is not meant for generic hosting of third-party apps; it’s for “proprietary” solutions.
• The ISV must own the application IP. If you’re hosting someone else’s application (like Oracle E-Business Suite for a client), that doesn’t fall under PAH. That would require full-use licenses with a special clause or not be allowed under PAH. PAH is about hosting your product.
• Oracle will vet the ISV’s application description to ensure it qualifies as a proprietary application and that it’s offered to multiple customers (not a one-off custom system).
• Once the ISV has the PAH license, they (and only they) can use it to run their service. End service customers do not get Oracle licenses; they just get user access to the ISV’s application.

In short, only ISVs/solution providers delivering a SaaS or hosted solution can obtain PAH licenses. If you are an end-user company, you’d generally not interact with PAH except as a client of such an ISV.

What kinds of applications or services typically use PAH licenses?

PAH licenses are used for scenarios where an ISV offers a hosted software solution to many customers. Typical examples:

• Software-as-a-Service (SaaS) Platforms: For instance, a CRM software company offering its CRM via the cloud to many businesses. They have one (or a few) Oracle databases running in their cloud that store data for all customers (in a multi-tenant schema or separate schemas). They’d use a PAH license to cover those databases powering the SaaS.
• Web-Based Services: An e-commerce platform provider might host online storefronts on a central Oracle-backed engine for multiple retail clients. The application is proprietary, but each client uses it via a web interface. The provider uses PAH to license the underlying Oracle DB and WebLogic, which handle all stores.
• Industry-Specific Hosted Solutions: A healthcare ISV has a cloud solution for clinics to manage patient records (their own proprietary application). They use Oracle Database in the backend. PAH licensing lets them have that single Oracle environment serve multiple clinics without each clinic needing Oracle licenses.
• Legacy Software Providers Moving to Hosted Model: Some traditional software vendors that used to sell on-premise licenses might move to a subscription cloud model. They then use PAH to license Oracle in their cloud instead of requiring each customer to license Oracle on-premise. For example, an ERP vendor decides to offer a cloud version; they host it for many clients and use PAH for the DB.
• Multi-Tenant Managed Services: If a company provides a managed service that involves running an application for multiple clients on one platform, and that application relies on Oracle, PAH is typically in play. For instance, a risk analytics service is one where the provider runs analytics for multiple banks on a single Oracle-based platform.
• Platform Providers: Some companies offer platforms (like marketing automation or supply chain hubs) that many organizations log into. The core application is proprietary. These fit PAH if Oracle is the underlying DB or middleware.

In all these cases, a common theme is one Oracle environment with many end customers. Also, the service is the ISV’s product, not just hosting someone else’s software. PAH shines when an ISV needs to scale Oracle usage across a customer base in a service model.

What restrictions apply to Oracle PAH licenses?

Oracle PAH licenses have specific restrictions to ensure they’re used only for the intended scenario (hosting one’s proprietary app).

Key restrictions include:

• ISV-Owned Application Only: The Oracle software under PAH can only be used to run the application that the ISV has developed and registered with Oracle. It cannot be repurposed to run any third-party or off-the-shelf software. For example, a PAH license for “XYZ SaaS App” cannot be used to host a generic Oracle database for a different product or client project.
• No Direct End Customer Licensing: End customers do not get Oracle licenses and do not sign Oracle agreements. The ISV is the sole licensee. The ISV cannot transfer or resell the Oracle license to an end customer. If a customer leaves and wants a copy of the application on-prem, they’d need their own Oracle license; the ISV’s PAH license stays with the ISV.
• Not for Single-Customer Dedicated Use: PAH is meant for multi-customer (multi-tenant) environments, not one separate Oracle instance per customer in a way that mimics outsourcing. For instance, Oracle’s policy says PAH can’t be used to set up a dedicated environment just for one public sector client in your data center. The idea is that if you’re doing one-to-one hosting for a single customer, Oracle prefers that the customer have their own license or a different arrangement.
• Geared Toward Commercial Availability: The hosted application must be a solution you offer commercially to multiple customers. If you only have one customer, it doesn’t qualify. If it’s an internal tool or something not broadly offered, it doesn’t qualify. Oracle expects that the solution is marketed and sold to a market of customers.
• Specific Registration: The ISV must fill out a Proprietary Application Registration Form (often called PARF or APRF) describing the application, its functionality, architecture, etc. The PAH license then only covers usage as described in that form. If the ISV significantly changes the application’s nature, they need to update Oracle. The use of Oracle software is restricted to what’s in that form.
• No End-User Site Installation: The Oracle software under PAH should not be installed on the customer’s premises. It’s meant for the ISV’s own data center or cloud tenancy. The ISV is providing a hosted service, not delivering software for customer-managed installation (that would be an ASFU or full-use scenario).
• Oracle’s Standard Metrics and Terms Apply: Within the above boundaries, Oracle usage is still measured by standard metrics (Named User Plus, Processor, etc.), and the ISV must comply with those. Also, if the ISV wants to deploy in certain environments (like the cloud), they might need Oracle’s nod (for example, an amendment for public cloud usage, as noted by some PAH users).
• No Mixing with Full-Use for Same Deployment: An environment licensed under PAH should not be combined with standard licenses. For example, an ISV shouldn’t try to use some full-use licenses they have and some PAH licenses together to run the same application environment—that complicates compliance. Typically, you either license the hosted app under PAH or not.

Overall, the restrictions ensure PAH is only used by eligible providers, for their app, in a service model, and not abused as a backdoor cheap license for internal use or third-party app hosting.

How are Oracle PAH licenses priced compared to regular Oracle licenses?

The pricing of PAH licenses can differ from standard licenses, often with incentives, but it’s also subject to negotiation:

• Potentially Lower Cost per Unit: In many cases, ISVs can negotiate discounts on PAH licenses since their use is restricted. Oracle is interested in enabling SaaS providers (so they don’t choose a competitor’s database), so it might offer attractive pricing. Some sources note that PAH license costs are typically much lower than full-use licenses because of the usage restrictions.
• Negotiation and Volume: There isn’t a fixed “PAH price” globally; it’s negotiated case by case. If an ISV has a strong business case (many customers, potential large Oracle usage), Oracle might give a significant discount or favorable terms. Conversely, Oracle might give a smaller discount if the revenue potential is small.
• Metrics Still Apply: Pricing is usually still based on Oracle’s metrics—e.g., per processor or per user (Named User Plus). For example, an ISV might license X processors of Oracle Database Enterprise under PAH at some negotiated price per processor. So, the ISV’s cost will scale with the capacity they deploy for their service.
• Possibly Slight Premium for Hosting Rights: Some anecdotal experiences (like those referenced in compliance blogs) suggest Oracle sometimes even tries to charge more for hosting licenses or not discount them as much initially. Oracle’s logic might be that they want to preserve revenue since one license can service many customers. However, if they charge too much, the ISV might not adopt Oracle. So it’s a balance.
• Support Fees: PAH licenses come with support fees like normal (typically ~22% of the net license fee annually). However, Oracle sales might bundle deals (like lower support uplift or reduced price if switching from existing licenses). For instance, some Oracle reps have offered customers the opportunity to switch to PAH licenses to reduce their support costs over time by using a lower license base cost.
• Example Scenario: Suppose an ISV needs 10 Oracle processor licenses for a SaaS platform. The list price per processor for Oracle DB Enterprise might be $47,500. Ten of those is $475,000. If Oracle gives a 50% PAH discount, the ISV pays $237,500 plus support. That might be far less than if each of 50 customers had to buy a couple of processors themselves. So, collectively it’s cheaper. In some cases, Oracle could even do more aggressive deals if it’s competitive.
• Slightly More Expensive than Internal Use? The note in one FAQ said hosting licenses “may be slightly more expensive than internal use licenses”. This could mean Oracle sometimes adds a premium or doesn’t discount as deeply for certain deals. It depends on the negotiation context.

Ultimately, PAH pricing is tailored. The ISV should prepare a solid business projection to negotiate—Oracle will look at the total opportunity (number of end users, growth, etc.). The ISV then factors this cost into its own pricing to customers.

For end customers, ideally, the result is that the SaaS fee is reasonable, and they’re not paying more than they would if the ISV used a cheaper database (or the difference is justified by the Oracle performance).

How are support and maintenance handled for PAH-licensed environments?

In PAH scenarios, support works in a layered way:

• ISV Supports End Customers: The application’s end customers contact the ISV for any issues with the service. They don’t interact with Oracle at all. So, from an end user’s view, support is just like any cloud service—you call your provider (the ISV) if something’s wrong.
• ISV and Oracle Support: The ISV would typically maintain an Oracle support agreement on its PAH licenses. This is just like a normal Oracle support contract (with CSI numbers and the ability to open SRs—Service Requests—with Oracle). The difference is that the ISV holds it, not the end customer. Oracle expects the ISV to be technically capable, so the ISV will do a first-level diagnosis on any Oracle-related issue. Then, if it’s an Oracle bug or a complex question, the ISV can engage Oracle Support.
• End User Isolation: End users cannot go to Oracle for support or updates because they don’t own the licenses. If they tried, Oracle would likely refer them back to the provider. This means the ISV is responsible for keeping Oracle software updated (patches, upgrades) and troubleshooting performance issues, etc.
• Oracle Patches/Upgrades: Similar to OEM/ASFU, the ISV will receive patches from Oracle and apply them in their hosting environment. As part of their service management, they schedule maintenance windows, upgrade databases, etc. The cost of Oracle support (typically 22% of the license) is paid by the ISV to Oracle, and the ISV probably builds that into the subscription fees customers pay.
• Lower Support Fees Tactic: There have been cases where Oracle sales pitches PAH deals to reduce support fees for a customer with many expensive full-use licenses. In such a case, the company would effectively become the “ISV” and host their app under PAH. Then, the support is given to the smaller PAH license footprint. While it reduces Oracle’s support revenue, Oracle is presumably okay if it ensures the customer stays with Oracle long-term. However, if that company isn’t truly an ISV, this is misuse (discussed later).
• Scope of Support: The ISV’s Oracle support likely only covers the Oracle products they licensed (e.g., DB, WebLogic). If their solution involves other Oracle technologies (like Oracle Linux or third-party components), those are separate. However, the main ones in PAH are typically the database and sometimes the middleware.

From the end-customer perspective, you should ensure your contract with the provider includes adequate SLA and support commitments, since you can’t fall back on Oracle. From the ISV’s perspective, you need to maintain a good relationship with Oracle support – any lapse in Oracle support could leave you unable to get critical patches, violating.

SLAs with your clients. So, continuous Oracle support coverage is critical.

What are the compliance responsibilities and audit risks under PAH licensing?

Compliance and audit for PAH licensing have nuances:

• ISV’s Responsibility: The ISV (the PAH license holder) is responsible for ensuring that Oracle software is used within the agreed bounds (only for the specified app, appropriate number of licenses for the usage, etc.). Oracle can audit the ISV to check compliance, just like they audit end customers for normal licenses.
• Audit Focus: In an audit, Oracle will likely verify that:
  • The ISV uses the Oracle software only for the registered application, not for other purposes.
  • The ISV has not deployed Oracle in prohibited ways (e.g., not running other apps, not installing at customer sites).
  • The usage metrics (users, processors) align with what’s licensed. To ensure the ISV isn’t under-licensed, they might check server configurations, the number of customer tenants, etc.
  • The ISV’s end customers don’t have Oracle installed on-site for that service.
• End Customer Audits: End customers of a PAH-hosted service generally won’t be directly audited by Oracle for that service, because they aren’t the Oracle licensees. The customers have no Oracle license to audit. However, if an end customer also has their own Oracle licenses for other things, an Oracle audit would exclude the PAH service (aside from verifying it’s a third-party service). So end customers using a PAH-based service don’t face Oracle audits for that usage – the risk lies with the provider.
• Misuse Risks: The big compliance risk is if a company that is not truly an ISV (or not providing a service to others) somehow got PAH licenses. For example, if an Oracle rep convinced a regular company to buy PAH licenses to save money and they’re not hosting a proprietary app for others, then in an audit, Oracle would find they don’t meet the definition of a PAH provider. This could lead to Oracle declaring them out of compliance (essentially, they have the wrong license) and demanding they purchase full-use licenses retroactively. This can be a costly audit failure because all the discounts given for PAH might be revoked.
• Penalties: If an ISV is found non-compliant, Oracle could charge back-dated fees or require the purchase of additional licenses. For example, if the ISV ran double the processors they paid for, they’d need to pay for those plus possibly back support. If they used Oracle for an unapproved app, Oracle might force them to license that scenario properly or cease usage.
• Customer Contracts: ISVs usually include clauses in their customer contracts that the customer cannot use the service to do something that would put them (the ISV) out of compliance with Oracle. For instance, a clause might say the customer can’t extract and run the software themselves, etc. So, compliance is also a matter of ISVs ensuring their customers don’t pressure them into unsupported scenarios (like “can you deploy a separate instance just for us on our hardware,” which would violate PAH if done).
• Documentation: ISVs should document that multiple customers are using the service and that the application listed in the PARF is exactly what’s hosted. Oracle may ask for evidence of multi-customer usage (since single-customer use is not allowed under PAH unless it’s truly multi-tenant by design).

In short, the ISV carries the audit risk. End customers are mostly shielded, which is one reason some consider hosted services—it reduces their direct licensing headache. But the ISV must be diligent about adhering to the PAH terms; misuse can lead to an audit disaster, where suddenly, the ISV has to convert to full-use (potentially at a huge cost) or faces legal penalties.

Can an end customer use or be offered a PAH license for internal use?

No, end customers (organizations that do not provide software services to others) should not use PAH licenses for their internal deployments.

PAH is not intended for end-user consumption; it’s for service providers. If an Oracle sales representative offers a company PAH licenses to cover their internal systems, that’s a red flag:

• License Eligibility: If you’re not hosting a proprietary application for external customers, you simply don’t qualify for PAH in Oracle’s definition. Accepting such a license would mean you’re misrepresenting your usage to Oracle.
• Audit Risk: In the event of an audit, Oracle will check if you meet the criteria of a “Proprietary Application Hosting” company (do you have a commercially available application used by others?). If the answer is no, then Oracle will likely treat it as a compliance issue – essentially, you’ve been using licenses under the wrong terms. The outcome could be Oracle requiring you to purchase proper full-use licenses to cover all that usage (often immediately, and possibly with backdated support). This could be very costly, wiping out any initial savings and more.
• Examples: There have been cases, for example, where an Oracle rep sold PAH licenses to a financial institution, creatively defining the bank’s internal systems as a “proprietary application”—like calling their information system a proprietary app for hosting. Later, an audit found that these were really just internal systems (or maybe third-party software like SAP running on Oracle), and the bank had to pay up for proper licenses. This is precisely the scenario Oracle’s policies are meant to prevent.
• Public Sector Note: The clause in SoftwareOne’s summary disallows using PAH to set up dedicated environments for public sector end users. That suggests Oracle is particularly cautious of government or similar entities trying to use an ISV as a front to get cheaper licenses. It underscores that PAH isn’t for end users, period.
• Legitimate Alternative: If an end user wants a hosting-like license because they outsource their IT or something, Oracle has other mechanisms. For instance, an “Internet Hosting” clause (which basically allows an end user’s full-use license to be used for external-facing services) or letting an outsourcing provider use the end user’s licenses. There’s also Oracle’s Cloud (where the license is included), etc. But PAH should not be shoehorned into that scenario.

So, if you are an end customer and someone suggests PAH to save money, be extremely cautious. It usually is “too good to be true” because it violates Oracle’s model. Always double-check with an independent licensing expert if a non-ISV company is being pointed toward PAH. The safe rule: PAH is for ISVs only – if you’re not one, you shouldn’t touch it.

How does a PAH license handle multi-customer or multi-tenant usage?

PAH licenses are specifically designed to handle multi-customer scenarios; indeed, that’s their raison d’être. Here’s how it works:

• One License, Many Customers: The ISV holds one set of Oracle licenses (or an aggregated metric count) that covers the entire hosted environment. This environment serves multiple end customers concurrently. For example, an ISV might license 8 processors of Oracle Database under PAH. On that database, they host data for 50 different client companies – each client’s data is isolated logically (by schema or tenant ID) but physically on the same database. The 8 8-processor license covers usage across all those customers collectively, not individually.
• Multi-Tenant Architecture: Most PAH-based solutions use a multi-tenant architecture (either multi-tenant at the database level or at least multi-instance with many customers per Oracle instance). Oracle’s license doesn’t enforce multi-tenancy, but the contract requires the solution to be for multiple end users. So, the ISV designs the app to serve many customers. Having multiple customers allows cost-sharing—the Oracle license cost is shared by the revenue from many clients.
• Not 1:1 Hosting: Oracle explicitly notes it’s not for 1:1 hosting. That means the ISV shouldn’t use a PAH license to run a separate dedicated copy of the app for each customer on separate Oracle installs, as that would resemble each customer having their own environment (which would blur the line with ASFU or full-use for each). Instead, Oracle expects consolidation—i.e., one instance or a cluster serving many, or at least economies of scale.
• Scaling Customers: As the ISV adds more customers, it monitors the usage. If their Oracle usage (like CPU or user counts) grows, they may need additional licenses to stay compliant. But they do that in aggregate. They don’t need to license each customer separately; they treat it like one big environment to manage.
• End Customer Isolation: Each customer is isolated by software, not by separate Oracle licensing. Oracle doesn’t require the ISV to attribute licenses per customer. So one customer might have heavy usage, another light; the ISV just has to have enough licenses for the total load.
• Single Application Focus: Multi-customer in PAH is always within the context of one proprietary application. It’s not like the ISV can use the same Oracle environment to host two completely different apps for different customer sets (unless both apps are registered in the agreement, which is usually separate deals). So it’s multi-customer on one application platform.

For an end customer, their data might sit alongside other customers’ data in the same Oracle system (separated logically).

They don’t have to worry about licensing—they’re just one tenant. For the ISV, this means they achieve economies of scale. Rather than one database per customer (which would be inefficient and expensive license-wise), they can maximize the utilization of a central Oracle deployment. Oracle allows this via PAH, whereas normal licenses would have restricted it.

What agreements or forms must an ISV complete to obtain a PAH license?

To enter a PAH arrangement, an ISV needs to go through Oracle’s partner contracting process:

• Oracle Partner Agreement: First, the ISV must be part of Oracle PartnerNetwork and sign up for the Oracle partner program that covers distributing Oracle software (formerly Oracle’s Embedded Software License (ESL)/Application Specific programs, now often referred to in partner agreements). They’ll sign something like the Oracle Master Distribution Agreement or an addendum for OEM/Hosting.
• Proprietary Hosting Addendum: There is usually a specific addendum or contract for Proprietary Application Hosting. It outlines the special terms for hosting (like the clauses cited about what you can do with the licenses). This might be an amendment to a broader OEM agreement or a standalone contract referencing the Oracle Master Agreement (OMA).
• Proprietary Application Registration Form (PARF/APRF): Crucially, the ISV must fill out a registration form for their application. In this form, they detail:
  • The name of the application/service.
  • A description of what it does (functional overview).
  • The Oracle products it will utilize (e.g., Oracle Database Enterprise, WebLogic, etc.).
  • The architecture in broad strokes (to ensure it matches multi-tenant usage).
  • Possibly the intended customer base or industry.
  • Sometimes the form also lists any third-party components or clarifies that the app is proprietary, not just Oracle Applications rebranded.
    Oracle reviews this form to approve that the application qualifies as a “proprietary application” and that using Oracle in this way is acceptable under PAH.
• Ordering Document: Once the agreements are in place, when the ISV actually purchases the Oracle licenses under PAH, they get an ordering document (just like a normal license order), but that document references the PAH terms. It might list the licenses as “Proprietary Hosting—Oracle Database Processor licenses: X units,” etc., and include the special clause or note that it’s for proprietary app hosting and subject to the PARF.
• Oracle Audit Clause: The agreements will include clauses about audit rights, similar to normal (Oracle can audit the ISV).
• Duration/Termination: The PAH agreement might be tied to the partnership’s status. If the ISV or Oracle terminates the partner agreement, the ISV likely loses the right to use those licenses in hosting, which could be dire for their service. Usually, that’s not common unless something goes wrong (like non-compliance or business decisions).
• Annual Reporting: In some cases, Oracle might require annual reports or certification of usage from the ISV under the agreement to gauge whether royalty models are used or whether more licenses are needed.

Working with Oracle’s licensing team is key to getting this right for an ISV. It might sound complex, but Oracle (and resellers) often assist in drafting these.

From a timeline perspective, finalizing the terms can take some negotiation, especially around how broad the application’s definition is. ISVs try to keep it broad to allow future features without renegotiating, while Oracle wants clarity to avoid abuse. Once done, the ISV is set to deploy and needs to remain within that framework.

Can Oracle PAH licenses be used in public cloud environments like AWS or Azure?

Yes, PAH licenses can be used in public cloud environments (like Amazon Web Services EC2, Microsoft Azure, etc.), but there are some important considerations and steps:

• Bring Your Own License (BYOL): PAH licenses are essentially a form of Oracle license owned by the ISV so that they can be brought to IaaS (Infrastructure-as-a-Service) clouds. The ISV can install Oracle software on cloud virtual machines and apply their PAH licenses like on their hardware.
• Oracle’s Approval/Amendment: Oracle often insists on an amendment to the PAH agreement if you plan to deploy in certain public cloud environments. Oracle has specific policies for recognized cloud vendors (AWS, Azure, Google). Typically, Oracle treats these similarly to on-prem in terms of licensing, but they want to ensure the ISV’s contract reflects that the deployment can be in third-party data centers. Some in the industry argue such amendments shouldn’t be needed if the license doesn’t prohibit it, but Oracle likes clarity. It’s wise for the ISV to inform Oracle of such plans and get any needed paperwork done to avoid disputes.
• Licensing Rules in Cloud: The ISV must follow Oracle’s cloud core factor policy. For example, Oracle has published rules for counting vCPUs on AWS/Azure to translate into Oracle processor licenses (e.g., usually two vCPUs = 1 Oracle proc license for those clouds, since they consider hyperthreading). The PAH licenses will be counted accordingly. User Plus is usually not used in multi-tenant anyway (it’d be hard to count all end users across tenants), so Processor licensing is common in the cloud.
• Not Allowed on License-Included Services: One thing to note: You cannot use PAH on a service where the cloud vendor provides the Oracle license (like Oracle on AWS RDS “license included” service). PAH means you’re using your own Oracle licenses. So you’d use AWS EC2 or Azure VM images (perhaps Oracle-provided ones, but with BYOL option) and apply your license. Suppose you accidentally used something like AWS RDS with a license included. In that case, you’d be paying AWS for Oracle licenses while also having PAH licenses – a mismatch and likely a violation because AWS’s license-included is full-use, not PAH.
• Cloud and Multi-Tenancy: Running in the cloud doesn’t change the multi-customer requirement. Whether the DB is on a physical server in your data center or a VM in AWS, it still must serve multiple customers and adhere to the same app usage.
• Network and Access: Ensure that just because it’s on the cloud, you’re not accidentally giving any customers access to the underlying DB. They should still only access it through the app. Cloud doesn’t change that, but if an ISV, for instance, allowed a big client direct DB access for reporting, that would violate PAH regardless of the environment.
• Oracle Cloud (OCI): If the ISV uses Oracle’s cloud (OCI), Oracle may have special programs or simpler terms since they encourage SaaS on OCI. However, on a third-party cloud, Oracle is a bit more formal. Oracle used to require an addendum for AWS/Azure explicitly because initially, they weren’t recognized in the licensing policy (which changed around 2017 when Oracle formalized BYOL to AWS/Azure). Still, being upfront with Oracle is best.

In summary, yes, you can deploy PAH in AWS/Azure; many SaaS providers do. Double-check licensing compliance and get Oracle to sign off in writing if needed. Some organizations have debated Oracle’s stance on requiring amendments, but from a risk perspective, getting it documented is safer for the ISV.

How do licensing metrics (e.g., user counts, processor counts) work under a PAH license?

Under PAH, the licensing metrics themselves are usually the same as standard Oracle metrics – the difference lies in usage rights, not how usage is measured:

• Named User Plus (NUP): If an ISV’s application is suitable for user-based licensing (perhaps a smaller-scale app with known users), Oracle could license the PAH environment by counting Named Users. However, counting all end users in a true SaaS with many subscribing organizations might be impractical or impossible for the ISV. So NUP under PAH is less common unless it’s a very controlled user count (some PAH deals might require a high minimum user count to ensure many small tenant users are covered).
• Processor (CPU) Licensing: This is more common for PAH. The ISV licenses Oracle by the number of processors (cores, considering Oracle’s core factor if on-prem, or cloud vCPU conversions). The ISV would estimate how many processor licenses they need based on the server capacity that runs the application. This metric scales with technical usage rather than the number of tenants, which is easier to manage as the user count can fluctuate widely.
• Concurrency or Other Metrics: Oracle’s standard metrics beyond NUP and Processor are rare, but if the application has a specific use case, other Oracle metrics (like “Application User” or something) could be considered. But likely not; Oracle sticks to the two main ones.
• Unlimited License Agreement (ULA) Option: Some ISVs use an Unlimited License Agreement specifically for PAH (covering their use for a couple of years, then certifying usage). That essentially suspends counting metrics for a period. Ultimately, they certify how many processors they have used to continue using beyond the ULA. Oracle may impose more restrictions on a PAH ULA than a normal one, but it’s an option if an ISV expects rapid growth and doesn’t want to constantly adjust license counts.
• Royalty Model: In some cases, Oracle might even allow a royalty model for PAH (similar to OEM). Instead of counting users or processors, the ISV could pay Oracle a percentage of its service revenue. This would need a custom negotiation. It simplifies metric counting, but Oracle tends to do royalties for embedded/OEM deals rather than hosting. However, a royalty could align better if the ISV’s value prop is far from technical (like they sell a service per transaction, etc.).
• Example of Metric Use: Suppose the ISV’s app runs on an Oracle DB with a web front-end. They decide to be licensed by the Processor. They deploy on a server cluster with 16 cores. With core factors (if applicable), they might need 8 Processor licenses. Those 8 cover any number of tenants/users until they need more hardware for more load. They buy more processor licenses if they add servers or CPUs for scaling. If

How do licensing metrics work under a PAH license model?

In a PAH license, Oracle still uses its standard license metrics – namely Named User Plus (NUP) and Processor – to quantify usage, just as with a normal license. The big difference is not in how you count licenses, but in the allowed use of those licenses (hosting your app for others).

Here’s how it typically plays out:

• Named User Plus: In theory, an ISV could license by Named Users, but in a multi-customer environment, it’s challenging to count all end users across clients. Oracle would require the ISV to license a sufficient number of Named Users to cover all individuals who access the system. This number can often grow, and Oracle might impose a high minimum user count to ensure adequate coverage. Many ISVs find user counting impractical for a SaaS, unless it’s a small, closed user base.
• Processor (CPU): This is more common. The ISV licenses Oracle per processor core on the servers powering the application (using Oracle’s core factor table as applicable, or vCPU counting rules in the cloud). For example, if the service runs on a cluster with 16 processor cores, the ISV might need 8 Oracle Processor licenses (after the core factor). Those cover all tenants using those servers. If demand grows and the ISV adds more server capacity, it would purchase additional processor licenses accordingly. Conversely, if the user count grows but fits on the same hardware, no new Oracle licenses are needed – it’s about capacity, not per-tenant counts.
• No “Per Tenant” License: The ISV does not need to license Oracle separately for each customer. One set of licenses covers the whole environment, which is far more efficient than each customer having their own database license. However, it also means the ISV must monitor overall usage (CPU load or total user counts) to remain compliant with the licenses they’ve purchased in aggregate.

In some cases, Oracle might allow a royalty model for PAH (similar to OEM agreements), but generally, they stick to the standard metric for hosting. The key point is that while you measure usage in familiar ways (users or processors), the contractual conditions (used for your app’s SaaS offering) make it a PAH license.

An ISV should choose the metric that best aligns with how their service scales. Many opt for processor licensing because it scales with infrastructure, not the unpredictable number of end-users coming and going.

(Example: Suppose an ISV runs a SaaS platform on an 8-core server with a PAH license for Oracle Database covering those eight cores. Those eight core licenses cover whether they have 10 or 100 customers on that platform (assuming performance is handled).

They’d need to license eight more cores if they expand to another 8-core server to onboard more clients. In contrast, counting every end user across 100 customers could be far more complex. )

Can an ISV sign an Unlimited License Agreement (ULA) for Oracle PAH licenses?

Yes, an ISV can negotiate an Unlimited License Agreement (ULA) specifically for their PAH deployment, but Oracle tends to attach extra strings to such deals.

A PAH ULA would allow the ISV unlimited use of certain Oracle products for a defined period (say, 2 or 3 years) to support their application hosting, after which the ISV certifies the usage. This can be attractive if the ISV expects rapid growth and doesn’t want to constantly true-up licenses.

However, there are important caveats:

• More Restrictions: Oracle usually imposes *tighter restrictions than a normal ULA. For example, the ULA might be confined strictly to one application environment and disallow any other usage (even more explicitly than standard PAH). It may also limit which Oracle products are covered or exclude things like cloud deployment without notice.
• Complex Exit: At the end of the ULA period, the ISV must count and declare their usage (number of processors, etc.) to Oracle, which becomes their fixed entitlement in the future. Oracle reportedly makes the exit certification process challenging in PAH ULA – likely to ensure the ISV isn’t claiming more usage than legitimately needed. If the ISV underestimates future growth at certification, they could outgrow their licenses post-ULA and need a new agreement.
• Audit and Compliance During ULA: Even in a ULA, Oracle may reserve rights to ensure the ISV is sticking to the application scope. They might not care about exact counts during the term (since it’s unlimited), but they do care that the usage is only for the intended SaaS service.
• Decision to Use ULA: For an ISV, a ULA offers cost predictability during the term and can accommodate surges in customer acquisition. On the flip side, it requires confidence in forecasting: you want to end the ULA with an entitlement that covers you long-term. ULAs also typically require the ISV to be a reasonably large Oracle partner (Oracle might not offer a ULA if the expected usage is small).

In summary, PAH ULAs are possible, and some large SaaS providers have taken that route, but they must be entered into carefully. You’d negotiate it much like any Oracle ULA, but with added attention to the specific hosting terms. Given the complexities, expert help in negotiating and exiting a PAH ULA is advisable so you don’t become constrained or over-committed.

Can a company transition from full-use Oracle licenses to PAH licenses?

A company (ISV) can transition from using full-use Oracle licenses to a PAH model, provided they meet the criteria of offering a proprietary hosted application. This is a common scenario as software companies evolve:

• Typical Scenario: An ISV may start by using full-use Oracle licenses internally or at individual client installations. Later, they offer their software as a hosted service (SaaS). At that point, switching to PAH licensing can align the costs and rights with the new business model. By moving to PAH, the ISV can consolidate licensing and potentially reduce costs because it no longer needs a separate Oracle license for each customer deployment.
• Cost and Compliance Benefits: Transitioning to PAH often reduces the number of licenses/support contracts needed, lowering maintenance overhead. It also ensures the ISV is compliant with Oracle’s policies (since full-use licenses technically wouldn’t allow serving external customers). One real-world example noted that a company could reduce costs and ensure compliance by switching to PAH when it moved to SaaS.
• Planning the Transition: This change isn’t simply flipping a switch; it requires *careful planning and negotiation with Oracle. The ISV would need to:
  • Sign the PAH agreements (partner contract and APRF for the app).
  • Potentially terminate or repurpose existing licenses. Oracle might allow some credit for existing licenses applied toward the new PAH licenses or require a fresh purchase – this is a negotiation point.
  • Coordinate timing so that PAH covers it when the SaaS service goes live, and any on-premises use of Oracle for that app is wound down.
• No Double Dipping: Once on PAH, the ISV should not continue using old full-use licenses for that application’s production service, which could confuse compliance. However, they might keep some full-use licenses for internal use or non-hosting purposes (like internal ERP systems or maybe development environments – though dev could be covered by partner licenses as discussed below).
• Customer Communication: End customers might need to be informed if anything changes on their side (usually, not much changes, except perhaps they no longer report Oracle usage if they were in some weird arrangement). Generally, the transition is an internal licensing change, with minimal disruption to the service itself if done right.

Moving from full-use to PAH is feasible and often beneficial for an ISV shifting to a cloud model. Just approach it systematically: align it with a business model shift, negotiate with Oracle for the best financial arrangement, and ensure no gaps in licensing during the switchover.

When executed well, it’s a win-win: the ISV cuts costs and compliance risk, and Oracle keeps the ISV’s business in a way that matches the ISV’s service delivery.

What are the risks if PAH licenses are used incorrectly or in the wrong situation?

Using PAH licenses outside of their intended scope (or by an organization that doesn’t qualify) can lead to serious compliance and financial risks:

• License Misalignment: If a company that is not truly an ISV or is not hosting a proprietary app uses PAH licenses, they are mislicensed. For example, if an Oracle sales rep convinces a regular business to buy PAH licenses to save money, but that business is just running third-party software or internal systems, those licenses are invalid for that us. The company might feel everything is fine until an audit occurs.
• Audit Consequences: In an Oracle audit, the first step will be verifying that the PAH license holder meets the definition of a “Proprietary Application Hosting” provider. If Oracle finds that the company uses PAH for internal operations (which should have been full-use licenses), it will declare a compliance breach. The company would then likely be forced to purchase proper full-use licenses for all the usage, often immediately and at list price, since the PAH licenses don’t cover that scenario. This can be extremely expensive, negating any initial savings and then some.
• Costly Example: One documented example (often cited by Oracle licensing experts) involves a company that was sold on switching to PAH for lower support fees. After the switch, they realized those licenses “were not suitable for their internal business operations,” resulting in a *costly audit finding. In that case, the company had to scramble to rectify their licenses – an expensive lesson in being mis-sold the wrong model.
• Service Disruption Risk: If an ISV misuses PAH (say, uses it for an app beyond what’s in the contract, or inadvertently uses it for a single-tenant deployment that isn’t allowed), Oracle could press them to cease the non-compliant usage. In extreme cases, Oracle could terminate the PAH agreement if compliance isn’t resolved. This is rare, but if it happened, the ISV’s ability to run their service could be jeopardized unless they quickly obtain alternative licenses. This scenario underscores that an ISV must strictly adhere to the agreed usage scope.
• Financial Penalties: Beyond simply buying new licenses, there could be back-support fees or penalties for the period of misuse. Oracle might charge for the period the improper usage occurred as if it were full use, possibly with penalties or interest (depending on the audit resolution).
• Reputational Impact: Being found in violation can strain the relationship with Oracle. For an ISV, that’s not ideal – it might affect their partner status or ability to negotiate good deals in the future. For an end-user company, it can mean being flagged for closer scrutiny in future audits.

PAH is a powerful licensing tool, but it must be used only in the right context. The risks of misuse are high: unexpected costs and compliance battles. Companies should ensure they clearly qualify for PAH and fully understand its limits.

When in doubt, consult a licensing expert before adopting an unfamiliar model. Doing it correctly up front is far easier than untangling a compliance mess later.

Do development and test environments need to be licensed under a PAH agreement?

It depends on the stage of your application, but once you have a production-hosted environment under PAH, all environments that relate to that production deployment must be properly licensed.

Here’s the breakdown:

• During Development (Pre-Production): If you are still developing your application (presumably an Oracle partner), you typically do not need to license Oracle for development and prototyping. As a member of the Oracle Partner Network, ISVs have the right to use Oracle software for development purposes. Oracle’s policy allows partners to develop and test internally using provided or trial licenses until the application is ready for production deployment. In other words, you don’t start paying while building your SaaS product; Oracle encourages innovation at this stage.
• After Go-Live (Production): Once your application goes into production and you’re using PAH licenses for the live service, you *must license all environments that support that production. This includes:
  • The production environment itself (obviously), any standby or disaster recovery environments, staging or UAT (User Acceptance Testing) environments that use production data or are essentially a mirror of prod for testing, and test and development environments, if they use the production data or are otherwise an extension of the production deployment.
  Essentially, after go-live, Oracle expects the ISV to license every instance of the Oracle software that is not strictly for development of new versions. A good rule is: if an environment is used to support the running application (like testing patches, training, etc., with real or full data), treat it as needing a license.
• Why License Dev/Test Post-Production: This is because those environments contribute to the service delivery. For example, if you have a QA environment that is a full copy of production for testing updates, that’s effectively another deployment of Oracle for the benefit of the service. Oracle’s stance is that it should be counted in your usage. Many ISVs handle this by licensing enough cores to cover a separate test system, or by using their partner/development licenses in a limited way (careful: partner licenses are typically only for pure development, not for staging with real data).
• Practical Approach: Often, ISVs include at least a small number of extra licenses in their PAH deal to cover non-prod needs. Alternatively, if the production is small, they might shut it down during testing and use the same licenses (not usually practical). But it’s safer to assume you need to license persistent non-prod environments.

To illustrate, Oracle’s guidance (via an ISV FAQ) notes that you can prototype and test without pre-production, *but once the application is in production, all associated environments must be licensed. Skipping this could lead to a licensing gap if Oracle audits the ISV and finds, say, an unlicensed DR server or an extra test instance running continuously.

In summary, before you go live, you can use Oracle freely under partner development rights. After you go live, account for every instance of Oracle that’s part of delivering or maintaining the service, production, or otherwise. Discussing this with Oracle when signing the PAH agreement is wise, so you’re clear on what needs to be licensed.

What are some common pitfalls or misunderstandings about PAH licensing?

Despite clear definitions, PAH licensing can be misunderstood. Some common pitfalls include:

• Thinking “Hosting = PAH always”: Not every hosting scenario needs a PAH license. For example, if an end customer hosts their Oracle-based system for external users (like a customer portal), they might just need an “Internet Hosting” clause on their license, not a PAH license. PAH is for providers offering a service to many customers. People sometimes mix up these concepts. As a rule, PAH is likely not for you if you are not selling a software service to others.
• Misidentifying the Proprietary Application: Companies have tried to shoehorn third-party apps into PAH by labeling them “proprietary.” For instance, claiming an implementation of SAP on Oracle is a proprietary application to try and get PAH pricing is not allowed (the company doesn’t own SAP). Oracle will see through a too-wide or artificial proprietary definition. A genuine proprietary app is one you built and own.
• Overlooking Multi-Tenancy Requirements: An ISV might assume that they qualify just because they are hosting customers. But if they end up deploying a separate Oracle instance per customer (single-tenant hosting), that can violate the spirit of PAH if those are essentially dedicated environments. Oracle expects a multi-tenant architecture, or at least that the service is truly shared. A pitfall is not designing the deployment optimally and risking that each environment looks “1:1”. (While Oracle might not explicitly forbid separate instances per customer, the agreement says the solution must be for multiple customers and not dedicated to one, especially in the public sector.)
• Not Amending Contracts for Cloud: As mentioned, if you move your hosting to AWS/Azure and don’t inform Oracle, you might be out of technical compliance. Some ISVs think, “We have licenses, we can deploy anywhere.” This is generally true, but Oracle likes documentation. The pitfall is deploying on a public cloud, and later, Oracle says, “You needed a clause for that.” The safe move is getting that amendment (even if one might argue it’s unnecessary, as some do).
• Forgetting to License DR or Test: We covered this above. An ISV might properly license production but forget that their standby database or full-size staging environment also consumes licenses. Oracle could count those as well in an audit. It’s an easy oversight, especially if those environments were set up by IT staff unaware of licensing implications.
• Believing PAH lowers Oracle Support Requirements Without Tradeoffs: Oracle reps might entice a switch to PAH by highlighting reduced support fees (since you’re licensing fewer total licenses). But a misunderstanding is thinking that support costs magically disappear. In reality, you trade one support contract (maybe larger) for another (smaller), and you must maintain support on the PAH licenses to get updates. Also, if you were an end user misusing PAH, those lower support fees would come at the cost of being non-compliant – a huge pitfall, as discussed.
• Neglecting the Contract Details: Some ISVs assume that they can grow and change their app once they have a PAH agreement. But if they significantly change the application’s scope beyond what’s in the APRF (say they add a major new module or start hosting a second application), they might fall outside the agreement. One should avoid overly narrow definitions in the contract (keep it slightly vague/flexible, as Oracle suggests). A pitfall is not planning for the future in the contract, then finding the need to renegotiate mid-stream, which could be costly or limiting.

In essence, misunderstandings usually result from overestimating PAH’s flexibility or trying to use it as a loophole. The best defense is a thorough understanding: know the exact terms of your PAH agreement, stick within them, and don’t try to game the system.

And if Oracle or a reseller pitches something that sounds too good (like a cheap PAH deal that doesn’t quite fit your business), get a second opinion to avoid stumbling into a trap.

What are the best practices for ISVs to effectively manage PAH licenses?

To successfully manage PAH licenses and stay compliant while getting the most value, ISVs should consider the following best practices:

1. Thoroughly Review and Understand Your Agreements: Make sure you (and your legal/compliance team) fully understand the PAH contract and the Application Registration (APRF) form content. Know exactly what application is covered, what “hosting” means in your context, and any special provisions (e.g., cloud usage, region restrictions, etc.). Keep a copy of these terms handy for reference when making business changes.
2. Keep the APRF Scope Broad (but Accurate): When defining your application in the contract, *avoid overly specific or narrow descriptions. Oracle advises keeping details vague (yet truthful) to allow flexibility. For example, instead of listing each module of your software in the APRF, describe it generally (“a financial services platform”) so that adding a new module doesn’t force a contract update. This prevents constant renegotiation as your product evolves.
3. Monitor Your Usage and Customers: Implement a process to regularly review how many users or how much capacity you’re using relative to your licenses. Although Oracle doesn’t audit end customers, you should internally audit your usage. If system usage grows, plan to true-up licenses before Oracle comes knocking. Also, ensure you have multiple customers active; if you ever end up with a scenario with only one customer on the service (even temporarily), be mindful that you don’t inadvertently slip outside the “multi-customer” requirement.
4. Engage Licensing Experts: Consider consulting with Oracle licensing experts or firms (especially at the onset and whenever you have a major change). They can provide guidance on tricky areas (like virtualization, cloud deployments, or expansion to new regions). The PAH terms can be complex, so getting expert advice helps avoid missteps.
5. Communicate with Oracle Proactively: Maintain a good channel with Oracle’s partner management. If you plan a significant change – e.g., deploying in a new cloud provider, or launching a new product that might also use the PAH licenses – discuss it with them. It’s better to proactively clarify or amend the agreement than to assume and risk non-compliance.
6. Stay Current with Support: Always renew your Oracle support on the PAH licenses (unless you’ve arranged something else). This ensures you get security patches and can ask Oracle for help. Lapsing on support risks technical issues and could also breach contract (Oracle requires supported environments for active partners in many cases).
7. Audit-Readiness: Even though Oracle audits are aimed at you (the ISV), not your customers, be prepared. Keep documentation on: the nature of your app, a list of customers using it, how you segregate customer data, and your license counts. If Oracle initiates an audit, you want to demonstrate quickly that you are in control and compliant. This can shorten or even defuse an audit.
8. Plan for Growth: If you anticipate rapid growth or a new big client dramatically increasing usage, talk to Oracle early about scaling up licenses or even a PAH ULA if appropriate. Sudden, unplanned growth is a good problem business-wise, but you don’t want to outgrow your license grant overnight. Oracle might be amenable to structuring a flexible arrangement if they see your success coming (they like successful ISVs on Oracle).

By following these practices, ISVs can treat Oracle PAH licensing not as a headache but as a stable platform for their SaaS business.

Essentially, treat license management as an ongoing part of operations, just like monitoring uptime or performance, and you will avoid surprises.

As one expert summarized, ensure continuous compliance and plan so that your focus stays on growing your service, not fighting licensing fires.

How does PAH licensing impact end customers of the ISV’s service?

For end customers (the businesses subscribing to the ISV’s application service), PAH licensing is mostly invisible and has a few key implications:

• Simplicity: The end customer does not need to acquire Oracle licenses for the hosted application. This is a big relief for many clients – they don’t have to deal directly with Oracle’s license complexity or cost. The customer simply pays the ISV, usually via subscription fees, and the ISV handles all Oracle licensing in the background.
• No Direct Relationship with Oracle: In this scenario, the end user typically has no contractual relationship with Oracle. Their contract is with the ISV or service provider. This means the end customer won’t interact with Oracle sales or Oracle auditors regarding this service. They also cannot call Oracle for support on the application, nor would they need to, since they don’t run Oracle themselves.
• Reliance on the Provider: Because customers aren’t dealing with Oracle, they rely on the ISV to manage compliance and support. If Oracle licensing issues arise, the ISV must sort them out without disrupting the service. From a customer’s perspective, ensuring the contract with the ISV has provisions that shield the customer from any fallout is worth it. (For example, the contract might state the provider will indemnify the customer for any third-party IP/license claims, including Oracle licenses.)
• Costs: The ISV’s costs for Oracle licenses (and support) are generally baked into the subscription price. The customer might indirectly pay for Oracle, but it’s usually a better deal because the ISV obtained discounted PAH licenses and can spread the cost across many clients. In other words, customers benefit from Oracle’s performance without the full Oracle price tag individually. However, customers should be aware that if they demand something like a dedicated environment outside the normal service (say, a custom separate instance just for them), it may change the cost model or even licensing model.
• Limited Control: Since the customer doesn’t have an Oracle license, they can’t easily take the Oracle-based system in-house. For instance, if they ever decide to leave the ISV’s service and deploy a similar solution internally, they would have to procure their own Oracle licenses at that time. Additionally, the customer can’t ask for direct access to the database “just because”—contractually and technically, that’s not part of the deal. They get the application functionality, not a database license.
• Data Portability: One thing to consider is data export. Customers should ensure the service agreement allows them to retrieve their data in a usable format upon termination. While this isn’t an Oracle license issue per se, it’s related. If a customer wants to move to another solution, they might need the data to be imported elsewhere, which could involve getting an Oracle dump or CSV export. The process should be agreed upon since the customer can’t run Oracle to extract the data. Many providers will assist with data export or offer APIs to get all your data.
• Audit Shield: As noted, Oracle won’t audit the end customer for this service’s usage. That’s a positive – one less vendor audit to worry about. The customer should, however, confirm that the ISV indeed has valid licensing, as part of due diligence, especially for critical services. It’s rare, but you wouldn’t want to use a service that suddenly shuts down because the provider violated Oracle licensing and got caught.

In summary, PAH licensing means the end customer gets a turn-key service with Oracle under the hood but without Oracle licensing burdens.

The trade-off is a loss of control over the database platform – but that’s the essence of SaaS: you trade control for convenience.

Most business users see this as a benefit if they trust the provider. It allows them to focus on using the application to drive business value rather than on caring for and feeding the underlying database.