Oracle License Transfer and Assignment: What You Can Actually Move, Sell, or Reassign

Oracle's agreements ban transfer and assignment outright, yet buyers move licenses between servers, entities, clouds, and hosting providers every day, and most of it is legitimate if you know which door you walked through. This guide maps every transfer scenario against the actual contract language, the EU exhaustion case law, and the support repricing rules that decide whether a transfer saves money or costs you more.

The Baseline: Oracle's Contract Says No, and It Means It Selectively

Start with the sentence itself, because every argument in this article runs through it. The Oracle License and Services Agreement states that "you may not assign this agreement or give or transfer the programs and/or any services or an interest in them to another individual or entity" (OLSA v111003 and v122304). That language has not softened in twenty-plus years of contract generations. The renewals-era text (OLSA v053012) went the other direction and widened the ban to cover the programs, the operating system, integrated software, and any services, which is precisely the clause that stops a customer from putting a decommissioned Exadata rack on the open market with its stack intact. Read as a whole, this is a blanket prohibition with narrowly negotiated exceptions, not a flexible standard with room to argue. In 25 years of negotiating against Oracle, I have never once seen a customer talk their way past the clause on the merits. What works is identifying which of the five legitimate doors you actually walked through, then documenting it. Two traps deserve early flags. First, granting a security interest over licensed programs gives the secured party nothing: the OLSA states the secured party has no right to use or transfer the programs, and any financing must follow Oracle's published financing policies. That kills the naive sale-leaseback and asset-backed structures that finance teams occasionally propose. Second, learning credits are separately and expressly non-transferable and non-assignable (OLSA Ireland v122304), yet they appear on divestiture asset schedules constantly, listed as prepaid transferable value. When the buyer discovers post-close that the credits died with the seller's entity, the argument lands in the working capital true-up. Treat every mention of "transfer" in your Oracle estate as a question about which instrument governs, not whether the prohibition applies.

In 25 years, I have never seen a customer talk their way past the anti-transfer clause on the merits; they win by proving which legitimate door they walked through.

Five Transfer Scenarios and Which Rules Govern Each

Buyers get into trouble because they treat all five of these movements as one thing called "transfer." They are governed by different instruments, carry different consent requirements, and fail in different ways. Internal reassignment and cloud redeployment are day-to-day operational acts you control unilaterally, provided you stay inside the definitions. Entity change and secondary-market resale touch the anti-assignment clause head-on and require either Oracle's written consent or, in the EU, a statutory override. Hosting sits between them, governed by policy documents Oracle can reprice at will. Note carefully that only your master agreement and your ordering document are contractual. Oracle's cloud licensing policy is not, and Oracle can revise it, as it has repeatedly. Before you rely on any row below, verify your own contract text: agreements signed pre-2012 read differently from ULA amendments, and negotiated assignment carve-outs override the boilerplate. If you are considering resale routing through a channel partner, read our assessment of what an Oracle license reseller can and cannot do for you in 2026 before you sign anything.

Two structural points sit behind the table. Partial transfers, carving a subset of licenses out to a spun-off entity, are the hardest category and are generally not permitted without written Oracle agreement, which is also true of splitting a bundled order for EU resale. And support is the chokepoint on every row: reinstatement runs at 150% of the last annual fee paid, and Matching Service Levels prevents you from dropping support on the licenses you moved while keeping it on the rest of the license set. Model the support arithmetic against current Oracle cost benchmarks before you commit to any transfer, because the repricing rule routinely erases the entire saving.

Internal Reassignment: Who Counts as You Under the Contract

The only category of Oracle license movement that is genuinely free of charge, free of paperwork, and free of Oracle's consent is movement inside the contractual definition of the customer. Every Oracle agreement I have negotiated in the last two decades defines that customer as the signing legal entity plus its majority-owned subsidiaries, meaning greater than 50 percent ownership. Not affiliates. Not entities under common control. Not the joint venture where you hold exactly half. That threshold is the entire game, and it is a moving target because your legal entity register changes every quarter while your Oracle deployment inventory changes every week, and nobody in the business is comparing the two documents.

Two silent breach events catch buyers repeatedly, and neither generates an alert from Oracle until an audit lands. The first: an entity you acquire is not automatically covered by the parent's licenses. You bought the company, you consolidated its data center, you pointed its ERP at your existing Oracle Database estate, and you assumed the license followed the org chart. It did not. The acquired entity holds its own agreements or it holds nothing, and Oracle will price the shortfall at list. The second, and more expensive: a divested or diluted entity loses its usage rights the moment ownership drops to 50 percent or below. Redress Compliance's July 2025 analysis is blunt on this point, an entity that leaves via divestiture usually loses rights to use the parent's licenses once it is no longer majority-owned. Minority carve-outs and joint ventures are the classic trap because the ownership change is a board decision and the Oracle estate is never on the board agenda.

Two actions, both cheap relative to the exposure. First, run an annual ownership reconciliation: pull the legal entity register with ownership percentages as of a fixed date, pull the deployment inventory with the owning entity for each instance, and flag every instance where the deploying entity sits at 50 percent or below or does not appear in the register at all. Second, and this is where the negotiation leverage sits, push at your next renewal to replace the majority-ownership test with a common control definition. Oracle resists it, but it is winnable inside a large renewal or a cloud commitment where you have something Oracle wants, and it is materially cheaper than buying licenses twice. Benchmark what you are giving up against the Oracle license cost benchmarks for 2026 before you trade discount points for it.

Moving Licenses Between Servers and Data Centers Without Triggering an Audit Finding

Here is the good news buyers rarely hear stated plainly: Oracle Processor and Named User Plus metrics do not attach to a named machine. They attach to hardware where the program is installed and/or running. Nothing in the standard agreement prohibits you from decommissioning a server in Frankfurt and standing the same workload up in Dublin, provided the same legal entity operates both and the license quantity still covers what is deployed. Redeployment inside the customer definition is permitted. What changes, and what buyers consistently get wrong, is the counted quantity, because the count is a product of physical core count, the applicable core factor, and where the virtualization boundary is drawn on the new platform.

That last variable is where audit findings are manufactured. Moving from an eight-core x86 host at a 0.5 core factor to a sixteen-core host does not double your requirement, it doubles the core count and holds the factor, so the requirement moves from four processor licenses to eight. Move onto a SPARC or Power platform and the factor changes again. Move onto a shared virtualization cluster and Oracle's position is that every host in the cluster capable of running the workload counts, not just the one you deployed on. None of that is a transfer restriction. All of it is a quantity restriction, and it bites hardest on migrations sold internally as cost-neutral.

Three specific traps. The disaster recovery and failover allowance permitting up to 10 separate days per calendar year of unlicensed use on a failover node does not survive a permanent move. Once the standby becomes production, it is production, and the day count is irrelevant. Testing copies, development instances, and warm standby copies remain fully licensable unless a specific contract term says otherwise. And an undocumented migration looks, in an LMS review, exactly identical to unlicensed expansion: Oracle's scripts see the new install, they do not see the old one being switched off, and the burden of proving the decommission sits with you.

An undocumented migration and unlicensed expansion look identical in an LMS review, because Oracle's scripts see what you installed, not what you switched off.

Build a dated decommissioning record for every migration and treat it as audit evidence, not as IT housekeeping. Each entry needs the retired hostname, the physical core count, the processor model, the applied core factor, the resulting license quantity released, the date the Oracle software was removed or the host was powered down, and a named signatory. Attach the corresponding record for the new target with the same fields. In my experience this single artifact is the difference between a clean migration and a six-figure finding, because it converts a verbal explanation into a contemporaneous document. If your migration is heading toward a reseller-brokered hardware refresh, keep the same evidence discipline and read the real pros and cons of using an Oracle license reseller before you let a third party own that paper trail.

BYOL to AWS, Azure, Google, and OCI: Redeployment, Not Transfer

Stop calling this a transfer. When you run Oracle Database Enterprise Edition on an EC2 instance, nothing has been assigned to Amazon, nothing has been sold, and the anti-transfer clause never engages. You remain the licensee, Amazon remains a landlord for compute, and the only question on the table is arithmetic: how many Processor licenses does a given instance shape consume. That distinction matters because it tells you which document to argue from. Three documents govern a BYOL deployment: your master agreement, your ordering document, and Oracle's cloud licensing policy. Only the first two are contractual. The third is a unilateral PDF that Oracle publishes, revises, and has rewritten more than once without customer consent. It is not incorporated by reference in most OMA and OLSA generations, which means it is a counting convention Oracle would like you to accept, not a term you signed. Treat it accordingly in an audit: comply with it operationally because fighting it burns goodwill you need elsewhere, but never concede in writing that it binds you.

The Authorized Cloud Environment list currently covers AWS EC2, Amazon RDS, Microsoft Azure, and Google Cloud Platform, with IBM Cloud and Alibaba Cloud recognized in some regions. Google's presence on that list contradicts older guidance still circulating in internal wikis, so purge stale copies. Two counting traps catch buyers repeatedly. First, the 0.5 x86 core factor does not travel with the license into an ACE. The vCPU rule replaces it; you cannot stack the multiplier on top and claim half again. Second, the hyper-threading direction in Oracle's own published material has been inconsistent across policy revisions, and the live source conflict is unresolved. The practical defense is documentary: download the policy PDF the day you deploy, record the effective date and version string, and store it with your deployment evidence. If Oracle audits you in 2029 against a 2028 policy, you produce the version that was live when you provisioned. Market experience says roughly nine in ten BYOL disputes we defend collapse the moment the customer produces a dated policy PDF the auditor did not expect them to have kept.

Only your master agreement and ordering document are contractual; Oracle's cloud licensing policy is a PDF the vendor can rewrite while you sleep.

The OCI column is the commercial point. Same workload, half the licenses, plus BYOL to PaaS which has no AWS or Azure equivalent. Oracle built that gap deliberately and will quote it at you during every renewal as a migration incentive. Price it honestly rather than emotionally: the license saving is real, but it is offset by OCI consumption commitments, egress costs, and the loss of negotiating leverage that comes from running on a competitor's infrastructure. Buyers who move Database EE to OCI purely for the 2:1 ratio typically find the saving absorbed by a Universal Credits commitment within two renewal cycles. Benchmark the whole package, not the license line, against what good pricing actually looks like in 2026 before you sign anything that names OCI.

Hosting Providers and Managed Service Providers: The Grey Zone Oracle Prices

Putting your licenses on hardware you do not own is not resale and not assignment. The transfer clause does not reach it. What changes is who must be counted and who bears the exposure when the count is wrong. Three arrangements sit under the same "hosting" label and they carry entirely different risk profiles. In the first, a hoster runs your licenses on dedicated hardware allocated to you: you remain the licensee, you count the physical cores in that dedicated estate, and this is generally acceptable without any Oracle involvement. In the second, the provider uses its own Oracle licenses to serve you as part of a managed service: this only works if the provider holds the correct Oracle partner rights, typically an OPN membership with hosting or embedded distribution entitlements. Ask for the agreement, not the badge on the website. In the third, you sit on shared multi-tenant infrastructure and cannot evidence isolation: this is where audits go badly, because Oracle's default position is that you must license every physical core in every host your workload could theoretically run on, and you have no way to disprove it.

The fix is contractual and it belongs in the hosting agreement, not in a side email. Insist on a right to audit the hoster or to direct an independent audit at your cost. Bind the provider to supply core, socket, and hypervisor configuration evidence within 15 business days of written request, in a format your own tooling can verify, because a 30-day Oracle response window collapses if your provider takes three weeks to answer. Require notice before any change to cluster membership, host affinity, DRS configuration, or physical capacity, and require indemnity for shortfalls caused by provider-side configuration changes you did not authorize. Without that indemnity, a hoster's routine capacity expansion becomes your seven-figure compliance gap and you have no recourse. Where a reseller sits between you and the hoster, understand that the reseller's incentives are not yours; the trade-offs are set out in our assessment of what an Oracle reseller does and does not do for you. Do this before signing the hosting contract. After signature you are asking for a favor, and hosters price favors.

Secondary-Market Resale in the EU: UsedSoft and What It Actually Permits

The single door Oracle cannot close is the one the Court of Justice of the European Union opened on 3 July 2012 in Case C-128/11, UsedSoft GmbH v Oracle International Corp. The ruling holds that the distribution right in a copy of software is exhausted under Article 4(2) of Directive 2009/24/EC when the rightsholder, or someone acting with its consent, puts that copy into circulation in the EU. Crucially, the court refused to distinguish between a copy on physical media and a copy delivered by download. Where the download and a perpetual, unlimited-duration use right form what the court called an indivisible transaction, at a price that remunerates Oracle for the economic value of that copy, Oracle has been paid once and has no further say in what happens to the copy. That is the entire legal architecture of the European secondary market, and it is the reason a perpetual Oracle Database Enterprise Edition processor license bought in Germany in 2014 can lawfully be sold to a different German company in 2026 despite an ordering document that says, in plain English, that you may not transfer the programs to another entity.

This is not an academic position that vendors quietly tolerate. It is litigated and enforced. In 2025 a Dutch court ruled directly against Oracle in a dispute with UWV, the Dutch employee insurance agency, holding that Oracle's contractual no-resale clauses were unenforceable because they contradicted superior EU law that had been settled for more than a decade. Read that outcome carefully: Oracle did not merely lose on the facts, the court struck the clause itself. In our negotiation experience, Oracle account teams still assert the contractual prohibition in writing when they learn a customer is exploring resale, and they will occasionally imply that a resale triggers a compliance review. Neither assertion changes the law in an EEA jurisdiction. What it does change is your workload, because you will be asked to prove the transaction was clean.

Oracle did not merely lose on the facts in the 2025 Dutch case, the court struck the no-resale clause itself.

Three conditions do the real work, and every failed resale we have reviewed failed on one of them. First, the seller must make its own copy unusable at the moment of resale. That means deleting every installed instance, not just stopping payment or archiving the binaries, and it means the same license cannot remain running in a disaster recovery site or a dormant test environment. Second, only perpetual licenses qualify. Subscriptions, SaaS entitlements, cloud credits, and support contracts are outside the doctrine entirely, which permanently removes Java SE Universal Subscription, Fusion SaaS, and OCI credits from the secondary market and is one reason Oracle has been migrating the estate toward subscription form. Third, bundles must be sold in their initial configuration. You cannot carve twenty spare processor licenses out of a hundred-license order and resell the remainder, which collides head-on with the most common commercial motive for resale. Before you engage a broker, price the alternative honestly against what a discounted new-license deal actually costs in 2026, because a compliant resale on a splittable-only estate often nets less than a well-run renewal negotiation.

Why the US Position Is Materially Weaker, and What That Means for Global Estates

Outside the EEA the analysis inverts. There is no US doctrine equivalent to UsedSoft for software delivered by download under a license rather than a sale, and most US state contract law enforces anti-assignment clauses as written. Oracle's prohibition on transferring the programs or assigning the agreement is therefore enforceable on its face in a US-law contract, and the only route to a lawful transfer is Oracle's written consent, which is a commercial negotiation rather than a legal right. This is the single most misunderstood point we encounter in multinational estates. Buyers assume geography of deployment governs, and it does not. Governing law and the contracting Oracle entity on the ordering document govern.

The practical consequence is blunt. A perpetual license purchased on a US ordering document under California law, from Oracle America, does not become resellable because the servers running it sit in Frankfurt and the deploying subsidiary is a German GmbH. Conversely, an Irish or German ordering document with Oracle EMEA as counterparty carries the exhaustion argument even if the workload later moves to Texas, subject to the copy being placed on the EU market with Oracle's consent in the first place. Most large estates we assess are mixed, with global agreements consolidated onto one paper in the 2010s and regional legacy orders underneath, and nobody has mapped which is which.

Do the mapping before you assume any resale route exists. Pull every ordering document, record the governing law clause, the contracting Oracle entity, whether the entitlement is perpetual or subscription, and whether it sits inside a bundle. Treat EU resale as a jurisdiction-specific tactic applied to a subset of line items, never as a global divestment strategy, and never as an assumption in a business case. If the mapping shows thin EEA coverage, the value is almost always in terminating and repricing rather than reselling, which is where the reseller channel and its limits deserve a hard, unsentimental look.

The Support Chokepoint: Where Transfer Savings Go to Die

Most buyers plan a transfer around the assignment clause and lose the money somewhere else entirely. The clause decides whether you may move a license. Oracle's Software Technical Support Policies decide whether moving it is worth anything, and in my experience that document has killed more resale and shed programs than the legal prohibition ever has. Two rules do the damage. First, Matching Service Levels: the policy states you may not support a subset of licenses within a license set, and that the license set must be reduced by terminating any unsupported licenses. So you cannot sell 200 processors out of a 500 processor CSI and keep paying support on 300 at the old rate. You either terminate the 200 formally, which surrenders them permanently, or you keep paying on all 500. Second, repricing: when the set is reduced, the remaining licenses are repriced at Oracle's list price for support minus the applicable standard discount, not the discount you actually negotiated. If you bought at 70 percent off list and Oracle's standard discount on that product line is 25 to 30 percent, the per unit support rate on what remains roughly doubles or triples. Advisory modelling published in 2025 and 2026 shows the arithmetic plainly: shedding 37.5 percent of an estate can cut the support bill by nothing at all, and dropping 50 percent can still leave the bill at 99 percent of the original. Third, if support ever lapses, reinstatement costs 150 percent of the last annual technical support fee paid, or 150 percent of the net fee that would have been charged had support been ordered originally. That is the penalty for guessing wrong.

The assignment clause decides whether you may move the license; the repricing rule decides whether moving it was worth doing.

What to do. Before you agree any resale price or any partial shed, model the post reduction support bill using Oracle's current list price for support minus the standard discount, not your historical net rate, and require your Oracle rep to confirm the repriced figure in writing on the renewal quote before you terminate anything. Two structural defences work. Split large purchases across separate CSIs and separate order documents at the time of purchase, so a future reduction only triggers repricing inside one small set rather than across the whole estate. And where you are shedding for genuine consolidation rather than resale, run the termination as part of a renewal negotiation where Oracle wants something from you, which is the pattern behind the documented cases where Costco removed 4.2 million dollars of Oracle support cost and where LVMH took out 10.5 million euros over three years. Never let support lapse in the belief you will pick it up later. The 150 percent reinstatement fee is applied consistently and is rarely waived outside a larger commercial event.

Entity Change: Divestiture, Merger, and the Transfer Letter

When the licensee itself changes shape, the licenses do not follow the corporate structure automatically. Oracle does not novate on divestiture. The contractual customer is your company plus its majority owned (greater than 50 percent) subsidiaries, so the moment a business unit drops below that threshold, its right to use the parent's licenses ends, whether or not anyone at Oracle notices that year. Acquisitions run the same rule in reverse: a newly bought entity is not automatically covered by your agreement, and its existing Oracle estate does not merge into your discount structure or your CSIs on its own. Partial and split transfers, carving a subset of licenses out to a spun off company, are the hardest category and are generally refused absent written agreement from Oracle. Even a clean full merger, where some agreements contemplate assignment on a merger or acquisition of assets, typically requires formal written notice to Oracle before it takes effect. And check the asset schedule: learning credits are separately and explicitly non transferable and non assignable, which means every deal that lists prepaid Oracle University credits as a transferable asset has a valuation error in it.

The decisive point is timing. Your leverage collapses on the day the deal closes, because from that moment Oracle knows you cannot unwind the transaction and the divested entity has no alternative source of the licenses it is already running. So the transfer letter, naming the new combined or standalone entity and expressly permitting continued use of all necessary licenses across it, must be negotiated and signed before signing the deal, not requested afterwards. In practice the letter is far easier to obtain when it rides alongside a renewal, a cloud commitment, or a new purchase that gives Oracle a commercial reason to say yes, and I have seen the same request refused flatly in isolation and granted in a week when attached to an order document. What to do: build the transfer letter into the SPA condition precedent list, define transition service period usage explicitly (how long the seller may run licenses on behalf of the buyer, and vice versa), get the CSI level license schedule attached to the letter rather than a vague reference to "all necessary licenses", and price the risk of refusal into the deal by benchmarking replacement cost against current Oracle license and support benchmarks. The divestiture carve out mechanics and the affiliate sharing rules are covered in depth on their own pages; treat those as the operating manual once the letter is signed.

Proving It: The Evidence File Every Legitimate Transfer Needs

In an Oracle audit, you carry the burden of proof. Oracle's LMS or GLAS team does not have to demonstrate that your reassignment was improper; it has to show a deployment, and you have to show the entitlement that covers it. A transfer that was perfectly legitimate under the contract but left no paper trail is, at the negotiation table, functionally identical to a breach, and it will be priced like one. I have watched customers lose seven-figure arguments they were legally entitled to win purely because nobody could produce a decommissioning record from four years earlier. Build the file at the moment of the transfer, not when the audit letter arrives, because reconstructing entity ownership percentages and server core counts retroactively is close to impossible and everything you assemble under audit pressure looks manufactured.

The file contents vary by scenario, and each one has a different failure mode. For internal reassignment, hold the ordering documents and CSI numbers that define the licensed customer, plus dated entity ownership evidence proving the receiving entity sat above the 50% majority-owned threshold on the transfer date, not today. For server or data center moves, keep decommissioning records naming the old hostname, processor model, core count, and shutdown date, because the whole defense rests on proving the source instance stopped running. For EU resale, retain a deletion certificate confirming every installed copy was made unusable at the time of sale, per the UsedSoft requirement, along with proof the original acquisition was a perpetual right sold at full economic value. For cloud redeployment, export instance configuration with vCPU counts and dates, since Oracle's cloud policy is not contractual and your evidence is the only version of history you control. For hosting, obtain a signed hoster attestation on isolation and installed instances. And for any entity change, the executed Oracle transfer letter or written consent is the only document that matters.

Put all of it in one controlled repository with a named owner in procurement or legal, not scattered across the infrastructure team's ticketing system. Set retention at the audit lookback period plus the remaining contract term, which in practice means keeping records for the life of the estate.

What to Do First: A 30-Day Transfer Readiness Plan

Sequence matters here, because the most common expensive mistake is executing a transfer or a shed before you have modeled what Oracle Support will do to the economics. Work through this in four weeks with a named owner and a fixed end date, and treat each week's output as a gate: do not start the next step until the prior one produced a document you would be willing to hand an auditor.

Week 1: establish what you actually signed. Pull every ordering document, the master agreement (OLSA, OMA, or OLA depending on vintage), and every amendment. Identify the governing law and contracting Oracle entity for each, because the EU versus US divide on resale rights turns entirely on this and multinationals routinely find three different jurisdictions across one estate. Extract the effective definition of licensed customer from each agreement generation and note the majority-owned threshold language.

Week 2: reconcile legal entities against deployment reality. Map your current legal entity register to your Oracle deployment inventory, hostname by hostname. Flag every entity below 50% ownership, every joint venture, and every divested business still running software under a parent CSI. Each flag is either a remediation item or a consent conversation, and neither gets cheaper by waiting.

Week 3: model support repricing before you commit to anything. This is the step buyers skip and regret. Under Matching Service Levels you cannot support a subset of licenses within a license set, and remaining licenses get repriced at list minus your standard discount, which is why dropping half an estate can leave the support bill at roughly 99% of the original. Model the post-transfer support number first. If the saving does not survive repricing, the transfer is not worth executing. Our Oracle license cost benchmarks give you a reference point for what the repriced number should look like against market.

Week 4: build the evidence file and time the consent ask. Assemble the repository described above. If an entity change or resale is planned, open the consent conversation only when a renewal, a cloud commitment, or new license spend is on the table. Oracle grants transfer letters far more readily when it wants something from you, and asking cold, mid-term, with no pending purchase, is how customers end up paying a fee for a right they arguably already had. If you are considering a resale route, weigh the reseller channel realities in our Oracle license reseller analysis before approaching Oracle at all.

Related reading: Can You Buy or Sell Used Oracle Licenses? The Secondary-Market Reality.

Frequently asked questions

Can I legally sell unused Oracle licenses?

Inside the EEA, yes for perpetual licenses first sold in the EU, based on CJEU Case C-128/11 (UsedSoft) and Article 4(2) of Directive 2009/24/EC, and a 2025 Dutch ruling held Oracle's contractual no-resale clauses unenforceable against that principle. You must make your own copy unusable, sell the bundle in its original configuration rather than splitting it, and accept that subscriptions, SaaS, and support contracts cannot be resold. In the US, most state contract law upholds Oracle's anti-assignment clause, so the resale route is generally not available.

Do my Oracle licenses still belong to me after I move them to AWS or Azure with BYOL?

Yes. BYOL is a redeployment, not a transfer, and you remain the licensee under your master agreement and ordering document. What changes is the counting method: Oracle's cloud licensing policy governs vCPU-to-Processor conversion in Authorized Cloud Environments, the 0.5 x86 core factor does not apply there, and that policy is unilateral and can be rewritten. Save a dated copy of the policy version in force when you deploy.

Can I share Oracle licenses with a subsidiary or affiliate?

Only if that entity falls inside the contractual definition of licensed customer, which Oracle typically limits to your company and its majority-owned (greater than 50%) subsidiaries. An entity that drops to 50% ownership or below, including most joint ventures, loses the right to use the parent's licenses, and an acquired company is not automatically covered. Reconcile your entity register against deployments annually and negotiate a broader affiliate definition at renewal.

Does Oracle transfer licenses automatically when I sell a business unit?

No. Oracle does not novate on divestiture, and partial transfers carving out a subset of licenses to the spun-off entity are generally refused unless Oracle agrees in writing. Even a full merger typically requires formal notice. Negotiate the transfer letter naming the new entity before the deal closes, because your leverage disappears on closing day.

Why did dropping Oracle licenses not reduce my support bill?

Two policies. Matching Service Levels means you cannot support a subset of licenses within a license set, so the set must be reduced by terminating the unsupported licenses entirely. Repricing then recalculates the surviving licenses at list price minus the applicable standard discount, which can leave a 37.5% to 50% reduction in license count producing close to zero saving. Model the repricing outcome before you commit to any shed, resale, or transfer.

Can a hosting provider run my Oracle licenses on its hardware?

Generally yes, provided you remain the licensee and the arrangement is not a disguised transfer. The risk shifts to evidence: you must be able to prove core counts, socket counts, and hypervisor configuration on infrastructure you do not control. Put contractual obligations on the hoster to supply that evidence within a fixed window and to indemnify you for shortfalls caused by provider-side changes.