Oracle Divestiture Licensing

What happens to Oracle licences in a divestiture?

In a divestiture, the seller separates a business unit and sells it, and the Oracle licences that unit relied on do not automatically go with it, because those licences were granted to the parent entity and remain with the parent. The divested unit can find itself on day one running Oracle software with no entitlement of its own, while the parent is left holding licences it no longer fully needs but cannot freely transfer. Resolving this gap is the central licensing problem of any divestiture, and it has to be solved before separation, not discovered after.

The difficulty is structural. The assignment clause prevents the seller from simply handing a slice of its entitlements to the buyer, so transferring licences to the divested unit requires Oracle's consent, which Oracle prices. Meanwhile the divested unit needs continuity of service from the moment it separates, which usually forces a transition arrangement under which it keeps using the parent's licences temporarily. This article sits under the license compliance pillar and complements the buy side view in the acquisition licensing guide.

The orphaned deployment problem

The defining risk in a divestiture is the orphaned deployment: software running in the divested unit that loses its licence at the moment of separation. While the unit was part of the parent, its use was covered because the parent held the licences and the unit was an affiliate. The instant the unit leaves the group, it stops being an affiliate, the affiliate based coverage ends, and every Oracle workload it runs becomes unlicensed unless a new arrangement is in place. Oracle is acutely aware of this dynamic and treats divestitures as reliable sources of new licensing revenue.

Avoiding the orphan requires mapping, before separation, exactly which Oracle deployments the divested unit depends on and tracing each to the entitlement that currently covers it. That mapping reveals which workloads will be orphaned and therefore which need a transition arrangement, a new licence, or a migration off Oracle. The exercise is the same dependency mapping that underpins any effective licence position, applied to the boundary of the divested unit, and it is the foundation for everything else in the separation. The reconciliation method is in the effective licence position guide.

Transition service agreements and interim use

The standard bridge across the gap is the transition service agreement, under which the parent continues to provide the divested unit access to Oracle systems for a defined period after separation. This keeps the unit operational while a permanent licensing solution is arranged, but it is not a free pass: the parent's licence must actually permit a now unaffiliated third party to use the software, and many Oracle agreements do not, which means the transition use itself can be a compliance breach unless Oracle has agreed to it.

A defensible transition arrangement therefore requires the parent to confirm that its licence terms permit the interim use, or to secure Oracle's agreement to it, before relying on it. The transition period also needs a hard end date with a concrete plan to reach a permanent state, because Oracle will treat an open ended transition as continued unlicensed use by the divested entity. The contractual question of who may use the software under whose licence is governed by the rules examined in the transfer rights analysis and the reassignment rules.

Three paths to a permanent state

Every orphaned deployment ultimately resolves down one of three paths. The first is licence transfer, where Oracle consents to assigning the relevant entitlements to the divested unit or its acquirer, usually conditioned on a true up or a move to current terms. The second is new licensing, where the divested unit buys its own Oracle entitlements, which gives it a clean position but at full cost and as a new customer with no negotiating history. The third is migration, where the unit moves the workload off Oracle entirely during the transition window, eliminating the entitlement question but requiring a technical project.

The right path differs per workload, which is why the dependency map matters: a large, stable database may justify a negotiated transfer, while a portable application may be cheaper to migrate. Deciding path by path, rather than treating the whole estate as one transaction, produces the lowest total cost. Where the divested unit sat under a ULA, the separation interacts with certification, covered in the ULA divestiture analysis.

The seller's residual position

Divestiture licensing is not only the buyer's problem; the seller is left with a residual position that needs attention too. After separation the parent may hold more Oracle licences than its reduced estate requires, having sized its entitlements and its support contract around a business that is now smaller. Those surplus licences continue to carry annual support fees, and Oracle's repricing rules make it difficult to simply drop a portion of support without penalty, so the seller can end up paying maintenance on entitlements it no longer uses.

The seller's discipline is to resize its position deliberately after the divestiture, reviewing its support renewal against its reduced deployment and using the divestiture as the occasion to renegotiate rather than passively renewing an oversized contract. This is a renewal and repricing exercise as much as a transaction one, and it is frequently the larger long term saving, because surplus support fees compound year after year. The standing capability to spot and manage this is software asset management, and the negotiation support sits in the licensing negotiation practice.

The buyer side view

A divestiture is a licensing event for both parties, and both lose if it is left to the lawyers papering the main transaction. The divested unit risks operating unlicensed from day one; the parent risks paying support on stranded entitlements for years. Both risks are entirely avoidable with planning that starts before separation, maps the dependencies, and resolves each orphaned deployment down a deliberate path while the parties still control the structure.

The buyer side discipline is to treat the Oracle separation as its own workstream, owned by someone who understands that affiliate coverage ends at separation and that the assignment clause governs everything that follows. Plan the transition, set its end date, choose a resolution path per workload, and resize the seller's residual position. To plan an Oracle divestiture separation before the deal closes, request a consultation, and read the carve out analysis for the closely related case of standing up a brand new entity.