Oracle Proprietary Application Hosting. The grant that lets you host.

Proprietary Application Hosting is the Oracle grant that lets you run Oracle programs inside a service you sell to third parties. Standard full use licensing does not cover that, and most companies find out during an audit rather than during a product launch.

What does an Oracle Proprietary Application Hosting license actually permit?

It permits you to use Oracle programs to deliver your own proprietary application to third party end users, from your own environment, as a service those users access remotely. That is the whole grant, and every word of it carries weight.

The three load bearing conditions are that the application is yours, that it runs in your environment rather than theirs, and that end users get access to your application rather than to the Oracle programs underneath. Break any one and you are outside the grant.

• Your application: the intellectual property must be yours. Hosting someone else's software for them is a different arrangement and a different contract.
• Your environment: your data center, your colocation space or your cloud tenancy. Not an installation at the end user's site.
• Their access, not their license: end users consume your service. They gain no rights to the Oracle programs and you cannot assign or resell those programs to them.
• Commercially available: the grant is written for a service offered to a market, not for a single dedicated environment run for one client.

What does PAH not permit?

More than most people expect, which is why the registration form matters more than the price. The restrictions are not policy statements you can argue around later. They are the definition of what you bought.

• No installation at the end user site: the moment software lands on customer infrastructure you are distributing, not hosting, and you need an application specific full use or embedded arrangement instead.
• No resale or assignment: you cannot transfer the Oracle license to the end user, sublicense it, or sell it as part of a bundle.
• No internal business operations: a PAH grant covers the hosted service. Your own finance, HR and reporting systems still need full use licenses.
• No unregistered applications: a second product line, a spin out or an acquired platform is not covered by a form describing the first one.
• No single tenant workaround: dedicated environments run for one named customer sit uncomfortably against a grant written for a commercially available service.

What does the application registration form commit you to?

It fixes the scope of the grant to a written description of your product, and Oracle will hold you to that description. Depending on contract vintage the artifact is called a proprietary application registration form or an application package registration form, and it typically captures the application name, the architecture, the Oracle programs used and the intended end customers.

Treat it as a scoping document, not paperwork. Two rules apply.

1. Describe the product, not the release: a description tied to a specific version or a specific module set will need renegotiating the first time the roadmap moves.
2. Keep it current: if the product changes materially, update the form rather than hoping nobody reads it. The mismatch between the registered description and the delivered service is the standard audit finding on this grant type.

How does PAH differ from full use, ASFU and embedded?

By who holds the license, where the software runs, and who is allowed to touch it. Oracle has four practical answers to the question of how its technology reaches a third party, and picking the wrong one is expensive in both directions.

Our deep dives on the application specific full use license and the embedded software license cover those two grants properly, and the Oracle license types page maps the whole set.

Which grant fits which business model?

• You sell software that customers install: embedded software license if the Oracle programs are invisible to the user, application specific full use if the customer administers them.
• You sell a service customers log into: proprietary application hosting, registered against your product.
• You run a business and customers see a portal: usually full use, because you are selling insurance, logistics or banking, not software.
• You operate systems for one client under an outsourcing contract: usually the client's own full use licenses, with you named as a permitted operator, rather than any hosting grant of your own.

Do the normal metrics and counting rules still apply?

Yes. PAH changes what you may do with the programs, not how you count them. Processor and named user plus remain the metrics, the processor core factor table still converts cores to licenses, and support still runs at 22 percent of net license fees.

Two counting rules bite harder in a hosted design than in an internal one. Virtualized platforms are still measured under the Oracle partitioning policy, and named user plus is almost never workable because you cannot enumerate the end users of a commercial service.

Is your service permitted under the licenses you already hold?

Probably not, if the licenses were bought as standard full use and your customers log into software you built on them. The Oracle agreement grants use for your internal business operations, and a commercial software service is not that, no matter how many licenses you own.

This is the question worth answering before a product launch rather than after an audit letter. The definitions live in your own Oracle contract documents and in Oracle's published license definitions and rules, and they have changed across contract vintages.

Where does internal business operations end?

At the point where the software becomes the product rather than the tool. That line is clearer than most vendors admit, and it is worth writing down for your own business before Oracle writes it down for you.

The middle rows are where real businesses sit, and they are also where Oracle account teams push hardest. Get the classification into writing at the point of sale, in the ordering document rather than in an email from a sales representative.

Where the common advice on Proprietary Application Hosting is wrong

The common advice says that any external user access to an Oracle powered system means you need a hosting license. We disagree, and the cost of accepting that framing is high. The test is not whether third parties touch the system. It is whether the software is the product. A bank whose customers log into a portal is running its internal business operations, because it sells banking. A logistics company whose carriers update shipments is running its internal business operations, because it sells logistics. Neither needs a hosting grant. What needs one is a business whose customers pay for access to the application itself. In roughly 20 to 30 hosting and grant type engagements Fredrik Filipsson reviewed in 2024 and 2025, the wrong classification ran in both directions, and companies that bought hosting rights they did not need paid a premium for the privilege of being restricted. Classify the business model first, then buy the grant that matches it.

White Paper · Oracle

Oracle CIO Complete Playbook

The five year plan to control Oracle spend. Read it free.

Read the white paper

How do you buy PAH without handing over your roadmap?

By separating the commercial negotiation from the disclosure exercise, and by writing the registration form yourself. Oracle needs enough description to define the grant. It does not need your product strategy.

Remember what you are asking for. Oracle sells competing cloud applications, so a PAH deal is Oracle licensing the platform underneath a competitor. Expect scrutiny, expect questions, and expect the account team to counter with an Oracle cloud proposal.

What will Oracle ask for, and what should you give?

• Asked: the application name and description. Give: a product level description that survives three years of roadmap, not a module list.
• Asked: the architecture and the Oracle programs used. Give: the programs and editions you will actually deploy, with headroom for growth.
• Asked: the end customer profile. Give: the market segment. Named customer lists date instantly and invite renegotiation.
• Asked: forecast volumes. Give: what you will commit to buy, not what your board deck projects.
• Never volunteer: historical deployment detail before you understand your own position. That is an audit conversation, not a purchase conversation.

What changes if you host on AWS, Azure or OCI?

The counting rules change, the grant does not. Running the hosted service in a public cloud brings you under Oracle's cloud licensing policy for how virtual cores are counted, but it does nothing to give you hosting rights you did not already hold.

• Counting: authorized cloud environments are licensed on virtual processor counts under Oracle's published policy, which is a different arithmetic from physical core counting.
• Rights: a cloud provider gives you infrastructure. Only your Oracle contract gives you the right to deliver a service on it.
• Bring your own license: moving PAH licenses to a cloud tenancy keeps the restriction with them. The registered application still bounds what you may run.
• Oracle cloud incentives: expect an Oracle proposal to move the workload to OCI. Price it, but negotiate the grant separately from the infrastructure.

Does a ULA cover hosted deployments?

Usually not, and this is the trap that costs the most. An unlimited license agreement grants unlimited deployment for your internal business operations, and hosting rights have to be negotiated into the agreement explicitly.

• During the term: hosted deployments made under a ULA that lacks hosting language are unlicensed, however unlimited the agreement felt.
• At certification: those deployments can be excluded from the certified quantity, which removes them from the perpetual position you thought you were building.
• The fix: get hosting rights written into the ULA at signature, with the registered application named, or keep the hosted estate on separate PAH licenses entirely.
• The test: read the ULA definition of internal business operations and check whether it mentions third party access at all. If it does not, assume no.

A ULA that feels unlimited is still bounded by the words internal business operations. Hosting lives outside those words unless somebody negotiated it in.

What if you are already hosting without the rights?

Fix it deliberately and quietly, in that order, before anyone contacts Oracle. Discovering a grant type problem is uncomfortable but it is not an emergency, and the worst outcomes we see come from teams that self report before they understand their own numbers.

1. Establish the facts internally. Which programs, which editions, which environments, and since when.
2. Read the actual contract set, including amendments and any partner agreements, rather than a summary spreadsheet.
3. Classify the business model honestly against the internal business operations test above.
4. Quantify the exposure at list and at realistic discount using the technology price list, so the number is yours and not Oracle's.
5. Decide the target position: PAH for the hosted service, full use for internal systems, and a clean boundary between them.
6. Bring the purchase forward as a commercial conversation about future capability, not as a confession about the past.

Involve counsel before any written statement to Oracle. A grant type problem is a contract question, and the first written characterization of your usage tends to become the frame for everything that follows.

What should a buyer do next?

Six steps. The first three are internal and cost nothing, and they determine whether the rest is a small purchase or a large one.

1. Write one paragraph describing what your customers actually pay for, and decide whether it is software or a business service.
2. Pull every Oracle ordering document and search it for hosting, service bureau, third party access and internal business operations.
3. Map every Oracle program in the customer facing environment, with editions, options and core counts.
4. If you hold PAH, compare the registered application description against what you sell today and update it if it has drifted.
5. If you need PAH, draft the registration form yourself before Oracle drafts it, and keep the description at product level.
6. Separate the hosted estate from the internal estate physically and contractually, so one grant type never has to cover both.

Do this before a funding round, an acquisition or a renewal, not during one. Grant type problems surface in diligence, and they price very differently when the buyer has a deadline.

Frequently asked questions

What is an Oracle PAH license?

PAH stands for Proprietary Application Hosting. It is an Oracle grant type that lets you use Oracle programs to deliver your own proprietary application to third party end users as a hosted service, from your own environment, under a registered application description.

Can I use my existing Oracle licenses to run a SaaS product?

No, if they are standard full use licenses. Full use grants the right to use the programs for your internal business operations, and selling access to software built on them is outside that grant. You need hosting rights written into the contract.

How is PAH different from ASFU?

ASFU licenses are sold to an end customer for use with a specific partner application installed at the customer site, and the customer holds the license. PAH stays with the hosting company, runs in the hosting company's environment, and the end customer receives a service rather than a license.

Is PAH cheaper than a full use license?

Not reliably. PAH uses the same processor and named user plus metrics and the same 22 percent support rate, and the effective price often lands at or above full use because Oracle is pricing the right to monetize its software inside your product. Treat it as a rights change, not a discount.

Does a ULA give me hosting rights?

Usually not. A standard unlimited license agreement grants unlimited deployment for internal business operations only, so hosted deployments can be unlicensed during the term and excluded at certification. Hosting rights must be negotiated into the ULA explicitly.

Can I use PAH licenses for my own internal systems?

No. The grant covers the registered hosted application, so your own finance, HR and reporting systems still need full use licenses. Keeping the two estates physically separate is the cleanest way to prove it.

Does PAH allow dedicated single customer environments?

Rarely without a specific negotiation. PAH is written around a commercially available service delivered to multiple end customers, so a dedicated environment run for one named client sits awkwardly against the grant and should be agreed with Oracle in writing first.

What happens if my hosted application changes?

Update the registration form. The grant is scoped to the application Oracle registered, so a new product line, a rebuild or an acquired platform is not automatically covered, and a mismatch between the registered description and what you deliver is the most common audit finding on this license type.