If you ship MySQL inside a commercial product and cannot open-source your own code, the GPL forces you into a negotiated Oracle OEM agreement. This guide shows where Oracle sets the trap, how per-unit and revenue royalty models actually work, and the terms that decide your margin.
If you ship MySQL inside a commercial product and cannot open-source your own code, the GPL forces you into a negotiated Oracle OEM agreement. This guide shows where Oracle sets the trap, how per-unit and revenue royalty models actually work, and the terms that decide your margin.
The single fact that determines whether you owe Oracle money is whether you distribute MySQL as part of your product. Oracle dual-licenses the MySQL database server and client libraries under version 2 of the GPL and under a commercial license. Internal use, no matter how large the deployment, does not create a distribution event and carries no OEM obligation. The moment you ship a binary that combines your proprietary code with MySQL to a third party, the GPL's copyleft terms reach for your source code, and that is the pressure Oracle relies on to sell the commercial OEM license.
The mechanism is precise. If you distribute software that links to or incorporates MySQL, the copyleft requirement says your software must itself be released under a GPL-compatible license. For an ISV whose entire business is proprietary code, releasing source is a non-starter, so the OEM commercial agreement is the only path that keeps your intellectual property closed. This is a different question from the Community-versus-Enterprise decision that internal-use enterprises face, which we cover in MySQL Community vs Enterprise. OEM licensing is about redistribution rights, not support tiers.
One narrow escape hatch exists for open-source distributors. Oracle offers a FOSS Exception on the GPL-licensed MySQL Client Libraries that lets you use those libraries under certain non-GPL open-source licenses without pulling your whole derivative work under the GPL. If your product is itself open source under a FOSS license other than the GPL, read that exception carefully before assuming you need a commercial deal. If your product is proprietary, the exception does not help you.
Internal use of MySQL at any scale is free of OEM obligation. The obligation begins the instant a binary combining your code with MySQL leaves your control.
Oracle offers four editions for embedding: MySQL Classic Edition, MySQL Standard Edition, MySQL Enterprise Edition, and MySQL Cluster Carrier Grade Edition. Three of these overlap with the standard server catalog, but Classic Edition is different. It is available only to ISVs, OEMs, and VARs to license as an embedded database. You cannot buy it as a general server subscription.
Classic Edition targets read-intensive applications built on the MyISAM storage engine. The critical technical caveat: Classic no longer contains the InnoDB transactional storage engine. If your product needs ACID transactions, foreign keys, or crash recovery through InnoDB, Classic is the wrong edition and Oracle will steer you up to Standard or Enterprise, which is exactly where the price climbs. Verify your storage-engine dependency in your own codebase before you accept a Classic quote, because a mid-contract discovery that you need InnoDB gives Oracle the upgrade leverage.
| Edition | OEM availability | Storage engine fit | Server list reference (non-OEM) |
|---|---|---|---|
| Classic | OEM/ISV/VAR only | MyISAM, read-intensive, no InnoDB | Not published |
| Standard | OEM and server | InnoDB transactional | $2,140/yr (1-4 socket), $4,280/yr (5+ socket) |
| Enterprise | OEM and server | InnoDB plus enterprise tooling | $5,350/yr (1-4 socket), $10,700/yr (5+ socket) |
| Cluster CGE | OEM and server | Distributed HA, telecom grade | Above Enterprise (contact sales) |
The server list prices above are the public reference points from Oracle's catalog and are useful only as an anchor. OEM pricing is not published, and Oracle instructs ISVs, OEMs, and VARs to contact the MySQL Embedded Sales Team directly. Do not assume your per-unit royalty maps to these numbers. It does not. For how the per-server metric works when you are buying for internal use rather than embedding, see how Oracle prices MySQL Enterprise Edition.
OEM licenses cover the redistribution of MySQL binaries embedded in or shipped with proprietary applications, and they are priced entirely differently from standard server subscriptions. There is no published OEM price list, and in our experience negotiating these agreements the opacity is deliberate. Oracle's OEM team sets your number based on three variables: your distribution volume, the pricing model applied (per seat, per transaction, per server deployed, or per unit), and Oracle's read of how dependent your product is on MySQL.
That third variable is where buyers lose money. If MySQL is deeply embedded and hard to swap, Oracle knows your switching cost is high and prices accordingly. If you can credibly demonstrate a migration path to MariaDB, Percona, or PostgreSQL, your leverage improves materially. We cover that exit math in leaving MySQL Enterprise. Even a scoped, costed migration plan on paper changes the tone of an OEM negotiation.
Oracle prices your OEM deal on your switching cost, not your usage. A documented migration alternative is the single most effective discount lever you hold.
OEM royalty structures in the embedded-software market generally fall into two families, and you should decide which one favors your business before Oracle proposes one. Per-unit royalties charge a fixed dollar figure for each licensed system shipped. Revenue-share royalties charge a percentage of receipts derived from the product. Oracle frequently proposes a hybrid "greater of" formula. As an illustration of the structure seen across embedded OEM deals generally (not an Oracle-specific quote), a typical clause reads: the greater of thirty percent of gross receipts derived from products, or a fixed dollar figure per unit distributed.
OEM agreements routinely require a minimum quantity per year and a minimum number of units over the initial term. These minimums are where you carry risk if your product underperforms your forecast. Negotiate them against a conservative volume projection, not your sales team's optimistic one, because you owe the minimum whether or not you ship it. Ask for a carry-forward provision so unused minimums in a soft year offset future obligations rather than evaporating.
If your organization already holds an Oracle contract, whether an Oracle agreement, a ULA, or a live annual renewal, MySQL OEM or Enterprise terms can sometimes be folded into that broader negotiation at rates well below list. Oracle's sales team discounts MySQL more readily when it is part of a multi-product commitment than when it is negotiated in isolation. If you are already an Oracle customer elsewhere, do not let the OEM team treat this as a standalone deal. Route it through the account relationship that already has spend leverage. For the wider cloud-era context, see adapting your cloud licensing strategy.
The most contested territory in MySQL OEM licensing today is SaaS. Historically, distribution meant shipping a binary to a customer's machine. Oracle now argues that if MySQL runs in your infrastructure to serve customer data through your SaaS product, you need OEM coverage as well. The company will further argue that if you bundle MySQL with your application in any form, including as an optional component, a recommended dependency, or an auto-installed database, then every copy of your application that goes out the door needs coverage.
This is an aggressive read, and it is not settled law in every jurisdiction, but you should assume Oracle will assert it. If you run a SaaS product on MySQL Community and have never distributed a binary to a customer, you have a defensible internal-use position. The moment you offer a self-hosted or on-premises version, or auto-install MySQL as part of your product footprint, the distribution question reopens. Document your architecture precisely so you can show exactly where MySQL sits and who controls it. For how Oracle finds these deployments, read how Oracle checks commercial use.
MySQL is an active audit target. Oracle's LMS team runs specialized scripts that identify MySQL installations alongside your Oracle Database, Java, and middleware deployments, so a MySQL exposure often surfaces during an audit that started somewhere else. In our practice, clients working MySQL license disputes have consistently reduced Oracle's initial compliance claims by 40 to 70 percent, which tells you how inflated the opening claim typically is. Never accept a first-pass number.
Two metric traps recur. The first is the vCPU-as-socket inflation. Oracle's socket metric counts occupied physical sockets on the host, regardless of core count, but a virtual machine reports vCPUs, not sockets. We have seen a VM reporting eight vCPUs priced into the 5-plus-socket band at double the rate when the underlying physical host had only two sockets. Always map back to the physical host's socket count. The second is SE2 scope creep, where an application that started on a modest Standard Edition footprint scales into multi-node HA and lands in an unlicensed position that LMS scripts are specifically designed to detect. Related tooling triggers are covered in the MySQL Enterprise tools that quietly trigger a subscription.
Oracle's opening MySQL compliance claim is routinely 40 to 70 percent above what the facts support. Treat the first number as a negotiating position, never a bill.
Do not carry assumptions from Oracle Java OEM deals into MySQL. Java OEM licensing is driven by Oracle's Java SE subscription and processor-and-employee metrics that changed dramatically in 2023. MySQL OEM licensing is driven by the GPL copyleft trigger and negotiated per-unit or revenue royalties, with a database-specific edition ladder (Classic through Cluster CGE) that has no Java equivalent. The Classic Edition, restricted to OEM channels and stripped of InnoDB, is unique to the MySQL embedded story. Treat these as two separate negotiations with two separate Oracle teams, and do not let one team's concessions be quietly clawed back by the other.
For the full picture of Oracle's MySQL commercial strategy, including HeatWave and the open-source trap that pulls internal-use customers into paid subscriptions, start from the Oracle MySQL Enterprise licensing buyer guide. If your product roadmap touches cloud-hosted database service, the MySQL HeatWave OCI cost model is the companion read.
Bring the negotiation to Oracle's OEM team with these decisions already made. The single most expensive mistake in embedded MySQL licensing is accepting Oracle's proposed model and metric as fixed inputs. They are not. Volume, model, metric, minimums, and edition are all negotiable, and every one of them moves your unit economics for the life of the agreement.
Yes, if your product code is proprietary and you distribute a binary that combines it with MySQL. The GPL's copyleft would otherwise require you to release your source code under the GPL, so the commercial OEM license is the only path that keeps your IP closed. If your product is itself open source under a compatible license, check the FOSS Exception first.
Oracle argues yes when MySQL runs in your infrastructure to serve customer data, and it extends that argument to any bundled or auto-installed MySQL component. This is an aggressive position that is not fully settled, but you should assume Oracle will assert it. A pure internal-use SaaS architecture where you never distribute a binary is more defensible than a self-hosted or auto-installed model.
Classic Edition is available only to ISVs, OEMs, and VARs to license as an embedded database, so you cannot buy it as a general server subscription. It targets read-intensive applications on the MyISAM storage engine and no longer includes the InnoDB transactional engine. If your product needs transactions, foreign keys, or InnoDB crash recovery, Classic is the wrong edition.
There is no published OEM price list. Oracle sets your number based on distribution volume, the pricing model (per unit, per seat, per transaction, or per server), and its read of how dependent your product is on MySQL. Deals are negotiated directly with Oracle's MySQL Embedded Sales Team, and a credible migration alternative is the strongest lever to lower the price.
Per-unit charges a fixed dollar amount for each licensed system shipped and favors higher-priced products. Revenue-share charges a percentage of product receipts and favors low-price or freemium products. Oracle often proposes a 'greater of' hybrid that forces you to pay whichever is more expensive, which favors Oracle, so push to convert it to a single model.
In our practice, clients working MySQL license disputes have consistently reduced Oracle's opening compliance claims by 40 to 70 percent. Much of the inflation comes from vCPU-counted-as-socket errors and disputed distribution scope. Treat the first number as a negotiating position, and correct the physical socket count before agreeing to anything.
Oracle Cloud at Customer enterprise licensing framework. Buyer side framework across OCI Dedicated Region, Exadata Cloud at Customer, autonomous database.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
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. Renewal signals, audit moves, and the levers that work. No vendor spin.
