The discount is real and the perimeter is invisible. What the restricted grant permits, how it differs from full use, and the audit trap that catches teams who treat it as standalone.
Restricted use licenses in Primavera P6 grant the software at a lower price, but only inside a defined application context. The discount is real, and so is the audit trap waiting for teams who treat it as full use.
A restricted use license grants Primavera P6 components at a reduced price, on the condition that they are used only with or through a defined application, module, or scope named in the ordering document. The software is identical. The contract is not.
Oracle uses restricted use grants across its applications portfolio, and Primavera bundles commonly include them: a database restricted to the P6 repository, an analytics component restricted to P6 data, or P6 itself restricted to a named integration.
Restricted use differs from full use in scope, not capability. Full use allows any lawful purpose. Restricted use allows one named context, and every use outside it is unlicensed regardless of how technically natural that use feels.
Restricted use versus full use in practice
| Dimension | Full use | Restricted use |
|---|---|---|
| Permitted scope | Any lawful purpose | Only the named application context |
| Price | Full list, standard discounting | Substantially below full use |
| Visible in software | No marking needed | No marking at all; contract only |
| Audit treatment of drift | Not applicable | Repriced as unlicensed full use at list |
| Upgrade path | Not applicable | Negotiable migration to full use |
It typically permits operating the named P6 function and nothing else. A restricted repository database may hold P6 schemas only. Restricted analytics may read P6 data only. Custom schemas, third party reporting feeds, or reuse by another application all fall outside the grant.
Because the people running the software never saw the ordering document. A DBA adds a schema to a convenient database. A reporting team points a BI tool at the repository. Each step is operationally sensible and contractually a breach.
The audit trap is repricing. When an audit finds a restricted component used outside its context, Oracle's position is that the use was never licensed, and the remedy is full use licensing at list for the whole deployment, often with back support.
The original discount becomes the measure of the exposure. The cheaper the restricted grant was, the larger the gap to the full use reprice.
Through schema inventories, connection logs, and integration maps. Auditors ask what reads from the restricted database and what writes to it, and the answers expose every consumer the grant never covered.
Manage them as contractual perimeter, not as software. The Primavera P6 documentation describes what the software can do; only the ordering document says what yours may do. The control is a register that maps every restricted grant to its permitted context, reviewed annually against actual connections and schemas.
The standard advice treats restricted use as a bargain to maximize: buy restricted wherever possible and save. We disagree with the unqualified version. In roughly 30 to 40 Oracle license reviews Fredrik Filipsson ran in 2024 to 2025, restricted grants drifted out of scope within 2 to 4 years in most estates, and the audit reprice consumed the accumulated savings 3 to 5 times over. Restricted use is a bargain only for organizations with the contract governance to hold the perimeter. The buyer side move is to buy restricted where the context is genuinely stable, document the perimeter, and budget the full use upgrade the moment the roadmap threatens it.
Three cuts of our advisory engagement file frame the size of the risk.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Six moves close the restricted use gap before an auditor finds it.
It permits use of the component only with or through the application context named in the ordering document, such as the P6 repository or a named integration.
Yes, substantially. The restriction is the price of the discount, which is why drifting outside it converts the saving into a multiple of the original spend.
Oracle treats it as unlicensed use. The audit remedy is full use licensing at list for the deployed footprint, often with back support added.
Read the ordering documents, not the software. Restrictions appear only in contract language, so extract every clause into a register mapped to permitted contexts.
Yes, and proactively is the time to do it. A negotiated migration before an audit costs a fraction of a compliance reprice after a finding.
Oracle ULA exit moves, audit defense posture, certification framework, and the buyer side moves across the Oracle estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
The software never tells you it is restricted. The ordering document does, once, on the day everyone reads it for the last time.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Pricing moves, audit signals, and the levers that work. No vendor spin.
