A processor license meters software by hardware capacity, and virtualisation or new servers after a deal can multiply the licensable count into a large inherited audit exposure.
What is processor license? A processor license meters software by the computing capacity it runs on, counting processor cores or sockets rather than the number of people using it. The model is common for database and middleware products from Oracle and IBM. In M&A it matters because capacity is easy to expand and hard to contain. Virtualisation, new servers and cloud migration can all enlarge the licensable footprint, and a target that has not tracked its cores carefully carries a processor license exposure that a publisher can price in an audit after close.
Capacity based licensing rewards publishers when hardware grows, and hardware grows constantly. Adding cores, moving a database onto a larger host, or spreading a workload across a virtual cluster can each increase the number of processors deemed to run the software. Oracle in particular applies a core factor table and strict rules on how virtualisation counts, so a single workload on a large virtual host can be treated as licensable across far more cores than it actually uses. The result is an exposure that scales with infrastructure, not with users.
Virtualisation is the sharpest edge. Where a database sits on a virtual cluster, a publisher may argue that every physical core the cluster can reach must be licensed, not just the cores the workload occupies. Buyers integrating two estates often consolidate workloads onto shared virtual infrastructure for efficiency, and in doing so unintentionally enlarge the licensable footprint. The saving on hardware becomes a liability on licensing.
In a deal the processor exposure is latent and rarely visible in financial diligence, because it lives in infrastructure configuration rather than in the accounts. It surfaces when the publisher audits and recounts the cores. IBM applies sub capacity rules that require continuous reporting to limit the count, and a target that has not reported correctly loses the benefit. Quantifying the processor position before close lets the buyer price the gap. This is commercial and licensing advisory, not legal advice.
A processor license behaves very differently from a named user or subscription model. It is indifferent to how many people use the software and sensitive to how much hardware runs it, which means integration decisions about consolidation and virtualisation drive the cost. Mapping which products are licensed by processor, and modelling how a planned integration changes the core count, is essential before the buyer commits to an infrastructure plan that quietly multiplies the exposure.
| Publisher | Capacity rule | Where exposure grows |
|---|---|---|
| Oracle | Core factor and virtualisation rules | Database on a large virtual cluster |
| IBM | PVU with sub capacity reporting | Missing or incomplete usage reports |
| Microsoft | Per core for some server products | Core counts after hardware refresh |
| Broadcom VMware | Per core subscription | Consolidation onto licensed hosts |
Related reading: see the M&A software glossary hub, plus named user license and indirect access.
Map and quantify the licensing exposure in your target or portfolio before it becomes a post close audit. Independent, buyer side, paid only by the acquirer.
Talk to a software M&A advisor