Primavera P6 restricted use licenses, and what they allow. What triggers full use, and what drift costs.

P6 EPPM includes WebLogic, WebCenter, Analytics Publisher and other Oracle products on restricted use terms. The software carries no marking, so drift goes unnoticed until an audit reprices it at full use.

What is a restricted use license in Primavera P6?

A restricted use license is a grant of the same Oracle software at a reduced price, on the condition that you use it only with or through the application, module or scope named in your ordering document. The binaries match the full use version exactly, and only the order limits what you may do with them.

Primavera P6 EPPM is a clear case. Your P6 license includes a set of Oracle middleware products, such as WebLogic Server, WebCenter Content and Analytics Publisher, that you may run only to support P6. Their price sits inside the P6 application fee rather than on separate lines, and the binding definitions sit in the contract documents that govern your order.

• Elsewhere in Oracle applications. The same pattern appears as a database restricted to a single repository, an analytics component restricted to one product's data, or a product restricted to a named integration.
• The database version. We cover it in our guide to application specific full use licenses.

Nothing in the installed software marks it

There is no flag, no license key difference and no warning. A WebLogic domain installed for P6 looks exactly like one bought at full use, and it will run a second application without complaint. The restriction lives only in the ordering document, so the people who could breach it are the people least likely to have seen it.

Which components come with P6 EPPM on a restricted use basis?

Oracle's P6 EPPM Licensing Information User Manual for version 25 lists more than a dozen restricted use grants that come with the P6 EPPM license. Each one carries its own condition, and most of them spell out the action that converts it to a full use requirement.

The remaining grants follow the same logic. Oracle Web Services Manager may only protect Primavera Web Services, and the Oracle ADF runtime gives you no right to build or deploy your own ADF applications.

Is the database under P6 part of the grant?

No. The P6 EPPM manual lists no database among its restricted grants, so the database that holds the P6 schema needs a license of its own.

Check where that license came from. If the database was bought as a restricted grant for another Oracle application, placing the P6 schema on it is the drift pattern this article describes. Our note on the P6 EPPM database license covers the common cases.

What about P6 Professional and integrations?

P6 Professional carries one restricted grant: Java SE, only for running P6 Professional. Integrations are the larger exposure. The manual requires users who are not licensed for P6 EPPM to hold P6 Peripheral Access licenses if they read P6 data or submit data into it through automated processes, including APIs, web services, ETL processes and database links.

That clause catches the third party reporting feed that someone points at P6 to fill a dashboard. The people consuming that data need P6 Peripheral Access, even though they never open the P6 client.

How does a restricted use license differ from full use?

They differ in scope, while the software and its capabilities stay the same. Full use allows any lawful purpose, while restricted use allows one named context. Every use outside that context is unlicensed, however natural it feels technically.

In practice the grant permits you to operate the named function and nothing else. Custom schemas, third party reporting feeds and reuse by another application all fall outside it. For P6 that means a second application on the WebLogic domain, a finance report written in Analytics Publisher, or a document library built directly in WebCenter Content.

What have we seen in recent Oracle license reviews?

Restricted use grants are among the most common failure points we find in Oracle applications. That view comes from roughly 30 to 40 Oracle license reviews and audit defenses we ran in 2024 and 2025. Three patterns came up again and again.

• Fast drift. In most of the companies we reviewed, restricted use components had moved into standalone use within 2 to 4 years of purchase, without anyone deciding to.
• A restriction no operator could see. The condition lived only in the ordering document, which the people running the software had never read.
• A large reprice. Audit repricing of drifted components ran 3 to 5 times the original restricted use spend.

Taken together, a short drift window and a large penalty multiple argue for a yearly review of every grant, rather than a check only when a renewal or audit letter arrives.

How does Oracle reprice restricted use drift in an audit?

Oracle treats use outside the permitted context as use that was never licensed at all. The remedy it asks for is full use licensing at list price for the whole deployment, often with back support for the period of unlicensed use.

That turns the original discount into the measure of your exposure. The deeper the restricted use saving, the larger the gap Oracle reprices when the drift is found, which is the opposite of how a discount normally behaves.

A worked example of the reprice

The figures below are hypothetical. Say a restricted use grant cost your company $120,000, against $400,000 for the same products at full use list. Three years later, a review finds the component serving a second application.

1. Oracle's starting claim. Full use at list for the whole deployment, $400,000.
2. Back support. Oracle's standard support fee of 22 percent a year on that list price, charged for one year of out of scope use, $88,000.
3. Total claim. $488,000, a little over 4 times the $120,000 you originally paid and inside the range we measured. A second year of back support would take it to $576,000, or 4.8 times.

The same conversation before any review is a different negotiation. You scope the upgrade to the component that outgrew its grant, you ask for the discount on your original order, and there is no back support to argue about.

Drift stays invisible until someone looks for it

No alert fires and no invoice changes. The first signal is usually a review, and by then the accumulated saving has already been spent several times over. Our audit practice sets out how to run that conversation once it has started.

What will Oracle say, and how should you answer?

Restricted use disputes on P6 tend to follow a few predictable lines. Here are the ones to prepare for, with the reply we would give.

• "The middleware is included with P6, so there is nothing to track." It is included on the conditions in the licensing manual, and those conditions are what an audit tests. Ask the account team to confirm in writing which of your current deployments the grants cover.
• "Clustering P6 is a standard configuration for availability." Oracle's own licensing manual says clustering triggers WebLogic Server Enterprise Edition. If you need the cluster, price that license now as a named line, before a review prices it for you.
• "Your planners built reports in Analytics Publisher, so they all need full use." Only users who customize or create reports need full use. Running and scheduling reports inside P6 is covered, so count the authors by name and no one else.
• "The finding is priced at list, with back support from first use." Ask for evidence of the date of first use outside scope, and offer to buy the upgrade as a forward purchase at the discount on your original order.

A restricted to full use upgrade costs far less before an audit than during one. Beforehand it is a negotiation, and afterwards it is a remedy.

How do you manage Primavera restricted use grants in practice?

Write the restriction down where the operators can see it. Map every restricted grant to its permitted context, record it against the system rather than in the contract file, and review the mapping every year.

How to check your own P6 deployment

You can test most of the conditions yourself with tools your team already has. Work through these checks for each P6 environment, including test and disaster recovery.

• WebLogic domain. In the WebLogic Administration Console, list the deployed applications and any clusters. Anything other than P6, or any cluster at all, needs a full use license.
• WebCenter Content. Compare the repositories and folders against those P6 created, and flag any your team made by hand.
• Analytics Publisher catalog. Find the custom or modified reports and record who wrote them. Those authors are your full use count.
• Workflows. List who has changed or created a workflow in the process management tools.
• Integrations. Inventory every API, web service, ETL job and database link that reads from or writes to P6, and the people who use the output.
• Database. List the schemas on the P6 database instance and confirm the license that instance runs under.

The annual review is the whole control

Product scope for the family is documented in the Primavera P6 product documentation, which is where the named context in an order usually points. Restrictions stay fixed, but the systems around them change.

The drift window we measured is short enough that a yearly check catches drift while it is still a configuration question and before it becomes a settlement.

• If P6 has outgrown the grant. Migrate to full use as a negotiation. Our clause negotiation guide has the contract language, and the technology price list guide shows how list prices behave.
• If you want to leave restrictions behind entirely. An unlimited agreement is the other route, with its own economics, which we set out in the unlimited agreement guide.

Why we do not tell clients to buy full use up front

A common recommendation is to avoid restricted grants altogether and license every Oracle component at full use from day one. We disagree. On P6, that means paying separately for middleware Oracle already includes, most of which will never leave its permitted context.

The restricted grant is worth taking when you pair it with a written record and a yearly check. Buy full use only for the component that has outgrown its grant, and buy it while you still choose the timing.

What contract terms should you ask for?

The order that grants P6 is also your best chance to limit the cost of drift later. Ask for these terms when you buy or renew.

1. A schedule of restricted grants. A list attached to the order naming each restricted component and its permitted context, so the condition is on your paper as well as in a manual that changes with each release.
2. A conversion price. The right to convert any restricted grant to full use at the discount on your current order, for a stated period. That caps the cost of growth in advance.
3. Audit findings at contract discount. Language that prices any restricted use finding at your negotiated discount rather than at list, with back support limited to a defined period.
4. Clarity on availability. Written confirmation of how a standby or failover P6 server is treated under the WebLogic grant, agreed before you design for high availability.

If you are weighing a move to Oracle's cloud service instead, the licensing model changes in other ways. Our comparison of Primavera Cloud and P6 EPPM licensing sets out the differences.

What to do next

1. Pull every ordering document. List which components carry a restriction, because the installed software will not tell you and the operators have never seen the paper.
2. Map each grant to its context. Write down the application, module or scope the order actually specifies, using the P6 licensing manual for the version you run.
3. Record the restriction against the system. Put it in the configuration record for each server, so the database administrator and the reporting team see it before they extend anything.
4. Run the checks every year. Repeat the six checks above for every P6 environment, and again before any upgrade, migration or infrastructure change.
5. Upgrade on your terms. Where the context has outgrown the grant, migrate to full use as a negotiation. Our Oracle practice prices the upgrade against the reprice exposure.

Frequently asked questions