Embedded Java Licensing for IoT & OEM
Using Java in a product you sell is not the same as using it internally.
Oracle calls that embedded or OEM use, and it’s tightly controlled. Companies that embed Java into devices or third-party software must pay close attention to licensing rules – or risk compliance troubles.
Pro Tip: “If your product ships with Java inside, you’re no longer an end user.”
Read our guide to more scenarios where Java may or may not require a license, Oracle Java Technical Scenarios & Edge Cases.
When You Need an Oracle OEM Agreement
You need an Oracle OEM license when you do any of the following:
- Embed Java in a device or third-party product. For example, installing a Java runtime on an IoT device, appliance, or hardware controller.
- Distribute Java with your software installer. If your application’s installer bundles the JRE/JDK for customer convenience, that’s redistribution.
- Sell or lease systems running Oracle’s JRE/JDK. This includes any hardware or virtual appliance you deliver with Java pre-installed.
In these cases, Oracle’s standard free Java license does not apply. Oracle’s Binary Code License (BCL) only permits free use of Java on general-purpose computers (like PCs and servers under an end-user’s control).
Anything beyond that – such as a router, ATM, IoT gateway, industrial PLC, or any dedicated device – requires an OEM agreement. In Oracle’s eyes, once Java is part of a product you ship to others, it moves from “free internal use” to commercial distribution.
Examples of Embedded Java Scenarios
Not sure what counts as “embedded” Java? Here are some scenarios:
| Scenario | OEM Required? | Notes |
|---|---|---|
| Internal desktop app | No | Covered by standard use |
| Retail device sold to customers | Yes | Requires OEM license |
| IoT controller or PLC | Yes | Not a general-purpose computer |
| SaaS backend service | No | Treated as server runtime (internal use) |
If you only use Java on internal servers or user PCs, you typically don’t need an OEM deal. But the moment Java goes inside a product that leaves your building, the rules change.
Pro Tip: “If it’s shipped or sold, assume Oracle expects a license.”
Understanding Oracle’s OEM Java Licensing Model
Oracle’s OEM Java licensing isn’t a simple download agreement—it’s a negotiated contract. Here’s how the model generally works:
- Customized distribution rights: An OEM agreement grants you the right to redistribute Oracle’s Java in your product. The contract will specify where and how you can include Java (e.g., a specific device or application, Java version, etc.).
- Per unit pricing: OEM licenses are often priced per device or per software unit shipped. Oracle might charge a royalty for each unit you sell that contains Java. In some cases, they use a device-based model (a fixed fee per device) or a royalty model (a percentage or a fee per unit sold).
- Volume commitments: Expect Oracle to set minimum annual quantities or fees. For example, you might pay for at least X number of units upfront each year, regardless of actual sales, especially if you negotiate volume discounts.
- Support & update restrictions: The OEM contract may include specific terms for updates and support. You might be locked to a certain Java version or need to manage updates through Oracle. Unlike using Java internally, you can’t freely update the embedded Java without considering the terms of the agreement.
- Legal review required: An OEM Java agreement is a bespoke legal contract (not a click-through EULA). It will require review by your legal team and likely several rounds of negotiation. The agreement defines the product scope, your reporting obligations (e.g., quarterly reporting of units shipped), and liabilities for non-compliance.
In short, Oracle’s OEM program is tightly controlled and commercial.
It ensures Oracle is paid when Java is embedded in third-party devices or software. Any company pursuing this route should be prepared to enter into a formal contract and to manage the license terms on an ongoing basis.
How to Engage Oracle’s OEM Licensing Team
If you determine you need an OEM license, approach the process carefully:
- Identify and scope your usage. Document exactly how and where you use Java in your product. Be ready to explain your device or application, the Java version, and how Java is integrated (embedded in firmware? installed on a bundled OS? etc.).
- Prepare your data. Oracle will want to know your expected distribution volume (units per year), the regions you will ship to, and the device specifications. Gather this information beforehand. It shows that you understand your needs and lends you credibility in negotiations.
- Contact Oracle through official channels. Reach out via Oracle’s sales department or your Oracle account manager. Inquire specifically about “Java OEM licensing” or “Java SE embedded licensing.” This will likely route you to Oracle’s Java licensing specialists.
- Negotiate the terms. Don’t expect a standard price list. Oracle will propose terms after understanding your use case. Be ready to discuss royalty rates per unit or bulk pricing, technical support options, and any minimum fees. It’s wise to have a target budget and preferred terms in mind (and even a walk-away plan if it’s too costly).
- Involve legal and procurement early. Because this is a custom agreement, your legal team should review all terms (especially clauses about indemnity, audit rights, and terminations). Procurement experts can help ensure the pricing and commitments are reasonable.
Be cautious: The moment you signal to Oracle that you might be improperly embedding Java, it becomes a sales opportunity for them.
Oracle’s team may aggressively push to close a deal (or even hint at compliance audits). Make sure you’ve considered your alternatives before initiating contact.
Pro Tip: “Never start with Oracle before you’ve modeled your alternatives.”
Read what can trigger licensing, Java SE Commercial Features – Usage Rights.
Alternatives to Oracle’s OEM Licensing
The good news is you don’t have to use Oracle’s Java runtime in your embedded product. There are safe, legal alternatives that can eliminate the need for an Oracle OEM agreement:
- OpenJDK (Open Java Development Kit): OpenJDK is the open-source implementation of Java, available under the GPL license with the Classpath Exception. This means you can use it (and even bundle it in devices) without paying Oracle. Many companies use OpenJDK builds to avoid Oracle’s fees. However, you become responsible for delivering updates and fixes to your customers unless you rely on a third-party provider.
- Third-party JDK distributors: Companies like Azul Systems, Red Hat, Amazon (Corretto), IBM, and others provide their own builds of OpenJDK. Some of these vendors offer commercial support contracts for their Java distributions. For example, Azul’s Zulu and Red Hat’s OpenJDK are popular in embedded environments. They let you ship Java with your product royalty-free, while you can purchase support and update services as needed. This shifts the model from per-device payments to a support subscription.
- Custom Java runtimes: If your device has tight resource constraints, you can build a stripped-down Java runtime using tools like
jlink(available since Java 9). This lets you include only the Java modules you need, reducing the footprint. Using OpenJDK, you can create a custom minimal JVM for your device, entirely under open-source terms. - Migration to smaller Java profiles or other JVMs: In some cases, Java ME (Micro Edition) or other lightweight VMs could be alternatives for very constrained devices. These might have different licensing or be open-source (e.g., Eclipse’s Java ME implementations). Evaluate whether your use case truly requires the full Java SE platform, or whether an open-source JVM for embedded systems (e.g., MicroEJ) could suffice.
Choosing an alternative requires planning. You must ensure the non-Oracle JDK you use is well-supported and kept up-to-date (especially for security patches).
The engineering team will need to integrate and test the new Java runtime in your product. The trade-off is clear: you save on licensing fees, but you take on the engineering effort (or a smaller support cost) to manage Java yourself.
Pro Tip: “OpenJDK turns licensing cost into engineering cost — plan for both.”
General-Purpose vs Specialized Devices
A key concept in Java licensing is the difference between general-purpose computers and specialized devices.
Oracle historically allowed free Java use on general-purpose machines (PCs, laptops, servers) but not on devices with a specific, dedicated function.
General-purpose means a device meant for a wide range of tasks under user control (like a typical computer that can run arbitrary programs). Specialized (or embedded) means a device built for a specific purpose, often with Java embedded in its firmware or software stack.
Here’s how that distinction plays out:
| Device Type | Free Java Allowed? | Comment |
|---|---|---|
| Laptop or server | Yes | General purpose device |
| ATM (bank kiosk) | No | Dedicated function, not general use |
| IoT gateway/hub | No | Special-purpose embedded hardware |
| Mobile POS terminal | No | Not a general-purpose computer; requires OEM |
In essence, if the system can be repurposed by consumers or businesses (e.g., by installing other software), it’s likely general-purpose. If it’s a closed box doing one job (an ATM only runs the bank’s software, a smart fridge runs its built-in app, etc.), Oracle views Java on it as embedded use.
Free Oracle Java licenses (like the old BCL or the newer no-fee terms) explicitly exclude these specialized devices.
Always classify the devices using Java in your organization. If it’s not a PC, server, or smartphone/tablet, assume it’s embedded and double-check the licensing.
Compliance Checklist – Embedded Java Audit Steps
Worried about Java compliance for your devices? Use this checklist to audit and protect your organization:
✅ Identify every product or software package that embeds Java. Make an inventory. Include the JRE or JDK in any deliverable you ship to customers.
✅ Confirm whether each usage is distributed externally. Distinguish between Java used internally (on your own systems) and Java packaged for others. Internal use (even at scale) typically falls under standard licenses, whereas any external distribution is high-risk for OEM requirements.
✅ Review Oracle’s Java license terms and your contracts. Check the Oracle Binary Code License (if you were on Java 8 or earlier) or the Java SE subscription terms (for newer versions) for the definition of general-purpose use. Also, review any customer or supplier contracts that might involve Java – sometimes OEMs pass along restrictions to their buyers.
✅ Evaluate open-source or vendor-supported OpenJDK alternatives. Before agreeing to an Oracle OEM license, assess if you can switch the Java runtime in your product to an open-source JDK. Weigh the cost of re-testing and support against the potential savings and reduced compliance risk.
✅ Engage Oracle only after assessing your legal position. If you conclude that an Oracle license is truly needed, consult with your legal team to understand your exposure. When you approach Oracle, go in with a clear narrative (e.g., “We have 5,000 devices in the field running Java 8, and we need to legitimize that usage.”). Being informed reduces the chance of being blindsided by sales tactics.
✅ Document every runtime and distribution path. Auditors love clarity. Keep records of which Java version and distribution (Oracle JDK, OpenJDK, etc.) is used in each product, and how it’s delivered. For any Oracle-licensed usage, maintain proof of licenses. For open-source usage, keep track of the sources and versions (and ensure you comply with those open-source licenses, too).
Pro Tip: “Auditors love products that mix internal and embedded Java — keep them separated.” In practice, avoid using the same Java installation for both internal use and customer-shipped software. It’s better to have a clean separation (different builds or configurations) so you can clearly demonstrate what is and isn’t subject to OEM terms.
Common Mistakes Enterprises Make
Even large companies stumble on Java licensing. Here are common mistakes to avoid:
- Assuming Java is included in another Oracle product covers you. Example: You use Oracle Database (which includes a Java VM) and assume that entitles you to embed Java in your own tool. It doesn’t – Oracle’s inclusion of Java in its products is only for that product’s use.
- Shipping devices with Java without any review. Some teams go to market with a Java runtime in their appliance and involve legal/licensing only later. Always do a licensing check before release. It’s easier to address upfront (or swap to OpenJDK) than to negotiate under Oracle’s pressure after the fact.
- Mixing internal and external deployments. For instance, using Oracle’s JRE in both an internal server app and the firmware of a sold device. Teams might test internally and assume it’s fine to deploy the same package externally. This blur can lead to accidental breach of the license. Keep internal-use Java and redistributed Java separate.
- Treating OEM Java like standard Java. Buying a few Java SE subscriptions (for internal use) does not grant the right to redistribute Java on hardware. OEM agreements are a different animal. Don’t think that because you pay Oracle for some Java licenses, you can freely embed Java in products – it requires explicit OEM rights.
Each of these mistakes can trigger a costly compliance issue. Oracle’s auditors or sales reps may demand backdated royalties for unlicensed distribution, often covering multiple past years. Those bills can run into the six- or seven-figure range. It’s far better to catch and correct these mistakes proactively than to pay for them later.
Case Example – Embedded Java in an IoT Platform
Consider a real-world scenario: A logistics company deployed Oracle’s Java (JRE) on 10,000 smart IoT sensors in the field. They treated it like a free component and never signed an OEM agreement.
Two years later, Oracle became aware of this embedded use (likely through an audit or a licensing review). Oracle demanded a retroactive OEM license fee for all 10,000 devices, plus penalties for past unlicensed use. The compliance settlement was around $1.2 million – an unplanned hit to the business.
The outcome? The company learned its lesson. It immediately started a project to replace Oracle’s JRE with an OpenJDK alternative on those devices.
By switching to an open-source Java runtime, the IoT sensors could run Java without an Oracle fee, eliminating future royalty costs. The one-time engineering effort to transition saved them from ongoing payments (and removed the compliance risk).
This example shows how expensive it can be to ignore OEM licensing – and why exploring alternatives is crucial.
Final Take
Oracle’s OEM licensing for Java isn’t optional if you continue to use Oracle’s Java in your products. If Java is included in something you ship, you either pay Oracle or find a way not to use Oracle’s bits.
The good news is that you often can avoid it. With modern OpenJDK distributions and third-party support options, many companies sidestep Oracle’s fees entirely. The key is to do your homework early: understand Oracle’s rules, audit your Java use, and evaluate alternatives before Oracle comes knocking.
In summary, embedding Java is a powerful capability for IoT and OEM products, but it entails licensing responsibilities. Be strategic and clear-eyed about it. Sometimes the best negotiation with Oracle is not needing to negotiate at all.
Pro Tip: “Every device with Java inside is a license decision waiting to happen.” Keep that mindset, and you’ll stay ahead of compliance issues and surprise costs.
Read about our Java Advisory Services.
