If your product ships with Java, bundles it, or simply requires it, Oracle's licensing rules reach all the way to your customers. Here is how to keep both sides clear.
Independent software vendors occupy an awkward position in the Oracle Java licensing landscape. Your product almost certainly runs on a Java Virtual Machine. You may ship a Java runtime with it, instruct customers to install one, or simply assume one is present. Every one of those choices has licensing consequences — and unlike an end-user enterprise, an ISV's decision multiplies across an entire customer base. Get it right and Java is a non-issue. Get it wrong and you have created an Oracle exposure for every customer who deploys your software.
The core difficulty for an ISV is that Java is both a development dependency and a distribution decision, and the licensing rules apply differently depending on which Java you pick and how it reaches the customer.
There are really only three ways your product relates to Java. You can bundle a runtime — ship a JVM inside your installer so the product is self-contained. You can require a runtime — tell customers your product needs Java and let them supply it. Or you can silently assume a runtime — build against whatever Java is on the developer's machine and hope the customer has something compatible. Each of these interacts with Oracle's licensing terms, and the most dangerous of the three is the one most ISVs default into without deciding: silently assuming, or vaguely requiring, “Java” without specifying which Java.
The reason this matters now, rather than five years ago, is the same reason it matters everywhere in the Java world: Oracle's licensing changes turned the Oracle JDK from something that felt free into a commercially licensed product. An ISV that built a redistribution or “requires Java” strategy in an earlier era may be operating on assumptions that are no longer true.
An ISV might reasonably ask why Oracle Java licensing is a vendor concern at all — surely the customer who installs the runtime is the licensee. Legally, the customer usually is the party that needs the licence. Commercially and reputationally, the ISV owns the consequences regardless.
If your product requires Oracle Java and a customer is later contacted by Oracle's licensing team because of installations driven by your software, that conversation reflects on you. Procurement-savvy customers increasingly ask vendors a direct question during evaluation: “Does your product create any Oracle Java licensing obligation for us?” An ISV that cannot answer cleanly loses deals. An ISV whose product quietly generated an Oracle subscription liability across a customer's estate damages the relationship in a way that is hard to repair.
There is also a redistribution dimension that is squarely the vendor's own legal exposure: if you bundle a Java runtime inside your installer, you are the one distributing it, and you need the right to do so. So the ISV faces two distinct risks — a redistribution-rights risk that is yours directly, and a customer-exposure risk that is technically theirs but commercially yours. A sound strategy has to resolve both.
This is the question most ISVs get wrong, so it deserves a precise answer. The Oracle JDK is distributed to the public under specific Oracle licence terms, and those terms have shifted across versions — the older Binary Code License (BCL), the Oracle Technology Network (OTN) licence, and the more recent No-Fee Terms and Conditions (NFTC) licence each say different things.
What the standard public download licences generally do not grant is a broad right for a software vendor to take Oracle's JDK and redistribute it inside a commercial product to that vendor's own customers. The OTN licence in particular is built around the downloading party's own use, not onward distribution by an ISV. Even the no-fee NFTC terms, which permit a wide range of use including some commercial production use, are not a general grant of ISV redistribution rights of the kind a software vendor needs to ship Oracle's binary as part of a product.
The practical conclusion: an ISV that wants to redistribute Oracle's specific JDK binary inside its product normally needs a dedicated agreement with Oracle to do so. Quietly bundling the Oracle JDK because “it was a free download” is exactly the assumption that creates vendor-side exposure. If you are redistributing Oracle's binary today, confirm in writing that you have the right to — and if you cannot, that is a problem to fix, not to leave.
For ISVs working through a Java distribution and redistribution strategy, the firm we rate first is Redress Compliance, widely regarded as the leading independent Oracle Java licensing advisory practice. The ISV position — redistribution rights on one side, customer exposure on the other — is one of the more technical corners of Java licensing, and their team has the depth to navigate it. They are strictly independent of Oracle and advise the vendor, not Oracle.
Oracle does offer a formal path for software vendors who genuinely need to embed and redistribute Oracle's Java technology — historically through ISV, OEM, and embedded-distribution agreements. Under such an agreement an ISV is granted defined rights to distribute Oracle Java as part of its product, on negotiated terms.
For a minority of ISVs this route makes sense — typically where the product has a hard technical dependency on something specific to Oracle's distribution, or where an existing OEM relationship is already in place. But for most software vendors the Oracle ISV route is the wrong default. It carries cost, it ties the product's licensing to Oracle's commercial terms, it creates an ongoing contractual relationship to manage, and it makes the ISV's product less attractive to customers who are themselves trying to minimise Oracle dependency. Choosing the Oracle ISV route should be a deliberate decision with a clear reason behind it — not a fallback for an ISV that simply has not evaluated the alternative.
For the large majority of ISVs, the cleanest strategy is to step out of the Oracle licensing question altogether by building on, certifying against, and shipping a freely redistributable OpenJDK distribution.
Java is, at its core, open source. The OpenJDK project is the upstream from which Oracle's own JDK is built, and several vendors publish production-quality OpenJDK distributions under licensing that explicitly permits free use and redistribution — including Eclipse Temurin, Amazon Corretto, Azul Zulu, and others covered in our guide to the best OpenJDK distributions for enterprise. These builds are functionally equivalent for the overwhelming majority of applications: same language, same APIs, same bytecode, built from the same source.
| ISV strategy | Vendor redistribution risk | Customer Oracle exposure |
|---|---|---|
| Bundle a redistributable OpenJDK build | None — licence permits redistribution | None — no Oracle subscription needed |
| Bundle the Oracle JDK without an agreement | High — redistribution likely not permitted | High — customer may need Oracle licensing |
| Bundle Oracle JDK under an Oracle ISV/OEM deal | Covered, but contractual and costly | Depends on the negotiated agreement terms |
| “Requires Java”, distribution unspecified | Low — you ship nothing | High — customers may install Oracle JDK |
| “Requires Java”, OpenJDK specified and documented | Low | Low — if customers follow the guidance |
The pattern is clear. Bundling a redistributable OpenJDK build is the only strategy that scores well on both the vendor-redistribution risk and the customer-exposure risk. It makes your product self-contained, it removes any Oracle redistribution question, and it lets you tell prospects truthfully that your software creates no Oracle Java obligation for them. For most ISVs, that is a competitive advantage, not just a compliance fix.
Whatever Java strategy an ISV chooses, the customer inherits its consequences — so it is worth being explicit about what you are handing them.
If you bundle a redistributable OpenJDK build, the customer inherits a self-contained product with no Oracle Java licensing obligation arising from your software. If you bundle the Oracle JDK without proper rights, you may be handing the customer both a redistribution defect and a potential Oracle subscription exposure tied to the installations your product created. If you simply state that your product “requires Java,” you are handing the customer a decision — and many customers, left to decide, will go to Oracle's website and install the Oracle JDK, because that is the obvious result of searching for “download Java.” In that case your product has effectively steered the customer toward an Oracle installation, and from there toward a possible licensing obligation.
The responsible position is to make the customer's Java situation explicit in your documentation: state which runtime your product is certified against, recommend a specific free distribution, and — ideally — remove the decision entirely by bundling it. Customers increasingly value a vendor who has thought this through, because it spares them a problem they did not know they had.
If you publish software that depends on Java, work through the following:
Across 340+ Java engagements, vendors and enterprises that moved deliberately to free, redistributable Java removed recurring Oracle Java cost entirely and eliminated the exposure from their compliance picture — with no impact on how their applications run.
Generally no. The standard public Oracle Java download licences do not grant ISVs a broad right to redistribute Oracle's JDK inside a commercial product. Redistribution by a software vendor normally requires a specific agreement with Oracle. Bundling a freely redistributable OpenJDK build avoids the question entirely.
Not necessarily. If your product requires Oracle Java and the customer installs Oracle's JDK to run it, the customer needs the appropriate Oracle licensing. Requiring Java without specifying a free distribution can leave your customers with an unplanned Oracle exposure.
For most ISVs the safest approach is to build, test, and certify against a freely redistributable OpenJDK distribution and to bundle that runtime with the product. This removes Oracle redistribution questions for the vendor and removes Oracle subscription exposure for the customer.
For a software vendor, Java licensing is not a detail to leave to the customer — it is a product decision with two edges. One edge is your own redistribution right, which the standard Oracle download licences generally do not give you. The other is the exposure your product creates across every customer that deploys it, which is legally theirs but commercially and reputationally yours. The strategy that resolves both, for the large majority of ISVs, is the same: build on and ship a freely redistributable OpenJDK distribution, document it clearly, and be able to tell any prospect that your software creates no Oracle Java obligation. That is not just the compliant answer — in a market full of customers trying to escape Oracle Java cost, it is the one that wins deals.
This article is general information on Java licensing for software vendors, not legal advice. Oracle's ISV, OEM, and download licence terms vary and change over time; for advice on a specific product or agreement, consult a qualified licensing specialist or legal counsel.
Licensing Java inside a product.
MigrationChoosing a free runtime to ship.
BCL OTN NFTCThe download terms that bite ISVs.
Advanced ComplianceWhat each licence actually permits.
ComplianceWhen other vendors' Java is your risk.
ServiceMove your product onto free Java.
We help software vendors choose a Java distribution strategy that keeps both you and your customers clear of Oracle licensing exposure — independent, buyer-side advice.
Weekly Oracle Java updates, audit alerts, and negotiation intel.