A corporate event is a licensing event. Oracle licenses are bound to a legal entity and are non transferable without consent, so every acquisition, divestiture, and restructure quietly reopens the Oracle agreements, and the outcome is decided in advance by clauses signed years earlier, the assignment clause, the change of control clause, the affiliate definitions, and the ULA merger language. This session covers both sides: when you acquire you inherit the target's whole Oracle position including its gaps and audit exposure, and when you divest the licenses do not follow the unit, so the carve out needs its own agreement while the parent right sizes. The discipline is diligence before close, when every Oracle cost is still a line item you can price and allocate.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the outright acquisition whose change of control clause the deal team wrongly assumes away; the target found under licensed in diligence, priced into the deal before close while the seller still shares the bill; and the divestiture that needs both a new agreement for the unit and right sizing for the parent, planned before the carve out. It closes with one deal licensed correctly, every Oracle cost known and allocated before signing.
The full narration of this session, section by section, for reading and reference.
Welcome back, session thirty eight of forty, module eight continuing. Last session was the on premises applications estate. Today, what happens to all of it, to every Oracle agreement you hold, when the company itself changes: mergers, acquisitions, and divestitures. Here's the core idea, and it surprises almost everyone the first time. A corporate event is a licensing event. When you buy a company, sell a division, or restructure, you're not just moving people and assets, you're moving, or trying to move, Oracle licenses between legal entities, and Oracle licenses are bound to entities and terms. So the corporate deal quietly reopens every Oracle agreement in scope, and it does so on Oracle's terms unless you got ahead of it. And the single most important thing about these events is when they're decided: in advance. The outcome is set by clauses signed years earlier, the assignment clause, the change of control clause, and by diligence done before the deal closes. After the deal, the leverage is gone and the terms are fixed. Today: why licenses don't travel freely between entities. The clauses that decide the outcome in advance. What changes when you acquire a company, and when you carve one out. How M and A interacts with a ULA. And the diligence that prices it all before close. Let's get ahead of the event.
Five takeaways. One, you'll see the event: recognize acquisitions, divestitures, and restructures as Oracle licensing events, not merely corporate ones. Two, you'll know the transfer rule: understand that Oracle licenses don't move freely between legal entities without consent. Three, you'll read the deciding clauses: find the assignment, change of control, affiliate, and territory clauses that decide the outcome in advance. Four, you'll handle both sides: know what changes when you acquire a company and when you carve one out or sell it, because they're mirror problems. And five, you'll do the diligence: assess Oracle exposure before the deal closes, when you still have the leverage to price it in. One sentence to carry through the session: M and A outcomes are decided before the event, by the clauses in the agreement and the diligence before close, not improvised after, so you read the paper early. The corporate event, next.
Four words that frame the M and A event. Entity: what an Oracle license is bound to, a specific legal entity, on specific terms, in a defined territory, so change the entity and you've changed the license's entire world. Consent: what transferring licenses usually requires, Oracle's, because licenses are generally non transferable without approval, so the corporate deal needs Oracle's yes to move them, which is a negotiation, not a formality. Audit: what frequently follows M and A, an Oracle audit, because a merger or carve out is a visible trigger, and combined or split estates are exactly where compliance gaps surface, per module five. And before: when it's all decided, in advance, by clauses signed years ago and by diligence done before close, because after the deal the leverage is gone and the terms are fixed. Here's the theme of the whole session, stated plainly: M and A outcomes are decided before the event. The clauses in the agreement and the diligence before close determine what happens, not anything improvised afterward. So the entire discipline is to read the paper early, before the deal if you can, and certainly before it closes. Licenses don't travel freely, first.
Oracle licenses do not travel freely, the single most important fact in M and A licensing: a license belongs to a legal entity and cannot simply move to another one. Four points. Bound to the entity: an Oracle license is granted to a named legal entity, not to a brand or a corporate group, so it doesn't automatically follow assets, people, or a business unit into a new owner. Non transferable by default: most Oracle agreements make licenses non transferable and non assignable without Oracle's prior written consent, so moving them between entities is a request you make, not a right you hold. Change of control matters: even keeping the same entity, a change in who controls it can trigger contract provisions, so an acquisition of the whole company is itself a licensing event, even though the entity survives. And territory and use limits travel too: any territory, affiliate, or use restrictions in the original deal apply to the new structure, so a license that's perfectly fine in one entity may be out of scope in another. Here's the consequence that drives the rest of the session. Because licenses are entity bound and non transferable, every corporate event that moves software between entities is an Oracle event that needs planning and, usually, Oracle's consent. There's no such thing as a corporate reorganization that's invisible to Oracle. The clauses, next.
The clauses that decide in advance, because the outcome of an M and A event is written into the agreement long before the deal appears. Four clauses decide most of it. The assignment clause: whether, and how, licenses can be assigned to another entity, stating whether consent is required and on what terms, and it's the master clause for any transfer. The change of control clause: what happens when control of the licensed entity changes hands, and some agreements treat a change of control as an assignment requiring consent, or even as a termination trigger, so it matters enormously in a whole company acquisition. The affiliate and territory definitions: who counts as an affiliate entitled to use the license, and where, because a divested unit that leaves the affiliate group can lose its right to use the software the day it leaves. And the ULA merger language: for a ULA, specific clauses govern acquisitions and divestitures during the term, per session fourteen, and they can make or break the certification. Here's why these clauses are the heart of the session: they're negotiated years before any M and A, which is exactly why they matter, the deal you did then decides the outcome now. So you read them at signature, and you read them again the moment a transaction appears on the horizon, because by the time the deal is closing, they are simply facts. Knowledge check one.
Knowledge check one. A company is acquired outright. Its Oracle agreement has a change of control clause requiring Oracle's consent for a change in ownership. The deal team assumes the licenses just carry over. Correct? A, yes, the company still exists, so its licenses are unaffected. B, no: the change of control clause is triggered, so Oracle's consent is required and the transfer is a negotiation, best addressed before close, not assumed. C, yes, Oracle licenses always transfer automatically on acquisition. Or D, no, the licenses are simply void and must be repurchased. Pause here. The entity survives, but who now controls it, and what does the clause say about that?
The answer is B. The deal team's assumption, the entity survives so nothing changes, is exactly the trap the change of control clause is written to catch. The licensed entity does continue to exist, but its ownership has changed, and the clause makes that change itself the event: a change of control requiring Oracle's consent. So the licenses don't simply carry over, their continuation is subject to Oracle's approval, and that approval is a negotiation Oracle can attach conditions to, true ups, repricing, new terms, or a demand to move onto its current agreement. B is correct and, crucially, names the timing: this is addressed before close, when the acquirer still has leverage and the transaction can be structured or priced to account for it, not after, when Oracle holds a consent the deal now depends on. A misreads the clause by focusing on the entity's survival rather than its control. C is the dangerous optimism this whole session refutes, Oracle licenses don't transfer automatically, that's precisely the default that produces post close surprises. D overstates it in the other direction, the licenses aren't void, they're subject to consent, which is a negotiation, not an extinction. The rule: in any acquisition, read the change of control and assignment clauses first, because whether the licenses carry, and at what cost, is decided by those clauses and by whether you raised it before or after the deal closed. When you acquire, next.
When you acquire a company, you inherit its Oracle estate in full, its entitlements, its gaps, and its audit exposure, so handle it as diligence, not an afterthought. Four points. Inherit the whole position: you acquire the target's licenses and its liabilities, any non compliance, any shelfware, any ULA obligations, the estate comes as it is, good and bad, so you assess it before you own it, not after. Consent and transfer: moving or combining the target's licenses into your entity usually needs Oracle's consent per the clauses, so you plan the transfer and its cost as part of the deal, not as a post close chore. Combining estates raises exposure: merging two Oracle estates can breach territory or entity limits, or push combined usage past entitlements, so the combined position must be counted, never assumed to simply add up cleanly. And M and A invites the audit: Oracle watches for acquisitions and often audits around them, per module five, so the combined estate should be reconciled to entitlements before Oracle asks, not after it does. Here's the frame: acquiring a company is acquiring its Oracle position in full. The diligence that prices the deal must include the Oracle estate, or the cost surfaces later, as a consent demand or an audit finding, at full price and with no leverage. Knowledge check two makes the timing concrete.
Knowledge check two. During due diligence on an acquisition target, you find it has been under licensed on Oracle Database for years. When is the best time to deal with this? A, after close, sort it out once the company is yours. B, before close: price the exposure into the deal or make the seller resolve it, because after close the liability is entirely yours and Oracle may audit the new structure. C, never, under licensing on a target is not the acquirer's problem. Or D, after close, and hope Oracle doesn't notice the acquisition. Pause here. Who owns the target's compliance gap the day after close, and who owned it the day before?
The answer is B. Compliance liability follows the entity, so the day before close the under licensing is the seller's problem, and the day after close it's entirely yours, with no recourse unless you created some. That single shift in ownership is why timing is everything. B is the disciplined move: while the exposure is still the seller's, during diligence and before close, you have leverage to act on it, either price the estimated liability into the purchase price as a reduction, or make the seller resolve it or indemnify you against it as a condition of the deal. Do that, and the gap is handled by the party that created it. A forfeits exactly that leverage, after close you own the liability outright and can only pay to fix it, and Oracle, which watches for acquisitions, may well audit the new structure and find precisely what diligence would have found, only now on your account. C is simply wrong on the mechanics, an acquired entity's non compliance becomes the acquirer's the moment the deal closes, that's what buying the entity means. D compounds the error with a hope, betting Oracle will miss a corporate transaction it actively monitors, which is not a plan. The rule, and it's one of the highest value lessons in the module: an acquisition target's Oracle position is part of what you're buying, so assess it in diligence and settle it before close, because after close there's no seller left to share the bill. When you divest, next.
When you carve out or sell, the mirror problem: the licenses don't automatically go with the divested unit, and both sides have exposure to manage. Four points. Licenses don't follow the unit: a divested business cannot simply take its share of the parent's Oracle licenses, so splitting entitlements between the retained and divested entities needs Oracle's involvement, it isn't a private matter between buyer and seller. The transition service period: a carve out usually runs on the parent's systems under a transition service agreement for a time, and that shared use has to fit the license terms, or the interim arrangement is itself out of scope and a compliance gap. The divested unit needs its own deal: to run Oracle independently, the carved out entity generally needs its own Oracle agreement, which Oracle prices as a new customer, often a significant and unplanned cost that someone in the deal has to bear. And the parent must right size: after the divestiture the parent's estate is smaller, so support and licenses should be reduced to the retained footprint, per module four, or the parent keeps paying for a business it no longer owns. Here's the summary: a divestiture is two licensing problems at once, the divested unit needs a new Oracle position, and the parent must shrink to its retained one. Both are planned before the carve out, or both cost more after it. M and A and the ULA, next.
M and A during a ULA, where a ULA and a corporate event interact in ways that can hand you a windfall or a trap, and the contract language decides which. Four points. Acquisitions during a ULA: deploying the ULA's unlimited product into a newly acquired business can be a genuine benefit, potentially a large one, but only if the ULA's language permits it, so the merger and acquisition clause governs, per session twelve. The certification trap: at certification, per session fourteen, only deployments the ULA actually covers count, so acquired entity usage may be excluded, or the acquisition may cap the countable estate, which means an acquisition you thought expanded your position could quietly shrink what you can certify. Divesting under a ULA: a divested unit generally cannot take ULA rights with it, and the parent's certification counts only what it retains, so timing the divestiture against the ULA term genuinely matters to the outcome. And read it before the deal: the ULA's M and A provisions are the difference between an acquisition that expands your certified position and one that excludes itself, so they're read before both the ULA and the deal are signed. Here's the through line to module three: a ULA turns an acquisition into either a deployment opportunity or a certification exclusion, and which one you get is decided entirely by the contract language from session twelve and the certification rules from session fourteen, not by hope. The diligence, next.
Licensing due diligence, before close, five steps. Inventory the target's estate: every Oracle product, entitlement, and deployment, on both sides of the deal, because you cannot price what you haven't counted, per module one. Reconcile to entitlements: deployment against license on the target, to find under licensing before it becomes yours, and that gap is a number for the deal, a price reduction or an indemnity. Read the transfer clauses: assignment, change of control, affiliate, and ULA language, on both the target's agreements and your own, because they decide what's even possible. Model the combined position: how the two estates fit together, and whether combining them breaches territory, entity, or entitlement limits, so the merged footprint is understood before it exists. And price it into the deal: consent costs, true ups, new agreements for a carve out, all quantified and put on the deal table while you still have leverage. Notice what this checklist does. It converts a set of hidden Oracle risks into a set of known numbers, before close, when those numbers can still change the price or the terms. That's the whole art of M and A licensing, moving the Oracle costs from after the deal, where they're surprises at full price, to before it, where they're line items you negotiate. Knowledge check three.
Knowledge check three. A company plans to divest a division that runs heavily on the parent's Oracle estate. What must be planned before the carve out, not after? A, nothing, the division takes its Oracle licenses with it automatically. B, both sides: the divested unit's own Oracle agreement and TSA terms, and the parent's right sizing to its retained estate, because neither happens automatically and both cost more if left to after. C, only the parent's side, the buyer of the division handles Oracle later. Or D, nothing, Oracle isn't involved in divestitures. Pause here. After the split, who is licensed to run the division's Oracle software, and who is paying support for a division they no longer own?
The answer is B. A divestiture splits one company into two, and it splits the Oracle problem into two as well, both of which have to be planned before the carve out because neither resolves itself. On the divested side, the unit can't take the parent's licenses automatically, so it needs its own Oracle agreement to run independently, priced by Oracle as a new customer, and it needs the transition service agreement terms to keep running on the parent's systems in the interim without breaching the parent's license scope. On the parent side, the retained estate is now smaller, so support and licenses should be right sized down to what it actually keeps, per module four, or the parent keeps paying maintenance on a division it no longer owns, pure shelfware created by the split. B captures both, and the timing point: planned before the carve out, when the deal can allocate these costs and the TSA can be scoped, they're manageable; left to after, the divested unit faces an unplanned new agreement under time pressure and the parent bleeds support on a departed business. A is the automatic transfer myth this whole session dismantles, licenses don't follow a business unit out the door. C handles only half the problem and abandons the divested unit's licensing to a scramble after close, and the transition period exposure with it. D is simply false, Oracle is very much involved in divestitures, and often audits around them. The rule: plan both sides of a divestiture's Oracle position before the carve out, the new agreement and TSA for the unit, the right sizing for the parent, because a corporate split is two licensing events, and both are cheaper handled early. One deal, licensed, next.
One deal, licensed correctly, the session as a before and after. The acquisition itself: the risk if ignored is that the change of control clause triggers a consent demand later, after close, when Oracle holds the leverage; handled before close, consent is negotiated as a deal condition with the cost known upfront. The target's compliance gap: ignored, the inherited under licensing surfaces in a post close audit on your account; handled, it's reconciled in diligence and priced into the purchase price. The combined estate: ignored, merged usage breaches territory or entitlement limits unnoticed; handled, the combined position is counted and any true up sized and negotiated. A ULA in play: ignored, acquired usage is excluded at certification; handled, the M and A clause is read and certification planned around the deal. A later divestiture: ignored, the unit is stranded without licenses and the parent is over supported; handled, a new agreement and TSA are scoped and the parent right sized. And the deal as a whole, the bottom row: ignored, the Oracle costs surface after close at full price with no leverage; handled, every Oracle cost is known, priced, and allocated before signing. Same transaction, two completely different outcomes, and the only variable is when the Oracle work was done. Diligence before close turns every one of these surprises into a line item. Recap, next.
Session thirty eight in three sentences. One, Oracle licenses are bound to a legal entity and are non transferable without consent, so every acquisition, divestiture, and restructure is a licensing event, decided in advance by the assignment, change of control, affiliate, and ULA clauses signed years earlier. Two, when you acquire, you inherit the target's entire Oracle position, entitlements, gaps, and audit exposure, so you assess and price it in diligence and settle it before close, because after close the liability and the consent leverage are entirely yours. Three, when you divest, the licenses don't follow the unit, so the carve out needs its own Oracle agreement and TSA terms while the parent right sizes to its retained estate, and both, like everything in M and A licensing, cost less handled before the event than after. Next session is the second to last, and it steps back to the relationship itself: the Oracle relationship, run deliberately. Account team dynamics, quarter and year end behavior, escalation paths, and an annual Oracle calendar for the buyer, everything the course has taught, organized into a standing way of dealing with Oracle across the whole year, not just at renewal or audit. Homework first.
Homework, about an hour, and it prepares you for the next corporate event before it happens. One, find the transfer clauses: in your main Oracle agreement, locate the assignment and change of control clauses and note what each requires, because most buyers have genuinely never read them until a deal forces it. Two, check the affiliate definition: who counts as an affiliate entitled to use your licenses, and what happens to an entity that leaves the group. Three, map any live events: any acquisition, divestiture, or restructure underway or planned, and list the Oracle exposure for each. Four, read the ULA M and A language: if a ULA is live, find its acquisition and divestiture provisions, per sessions twelve and fourteen, because they decide the certification. And five, draft a diligence checklist: the Oracle questions to ask of any acquisition target or carve out, so the licensing position is priced into every future deal by default. See you in session thirty nine, the second to last, on running the Oracle relationship deliberately.
Five reads, all free on redress compliance dot com. First, Oracle licensing in mergers and acquisitions: the transfer rules and deal treatment, at reference depth, the written companion to this session. Second, Oracle license transfer and assignment: the assignment and change of control clauses, explained clause by clause. Third, Oracle divestiture and carve out licensing: the new agreement, the transition service agreement, and the parent right sizing, the divestiture side in full. Fourth, Oracle ULAs and M and A: the ULA merger language and certification, tying back to sessions twelve and fourteen. And fifth, Oracle software audits: why M and A invites an audit, and how to be ready, per module five. That's session thirty eight. A corporate event is a licensing event; licenses are entity bound and non transferable, the outcome is decided by clauses signed years earlier, and diligence before close turns every Oracle surprise into a priced line item. You can now walk into any merger, acquisition, or divestiture and handle the Oracle position deliberately, from ahead of the deal rather than behind it. Next session, running the whole Oracle relationship on purpose, across the year. See you there.