Java im Unternehmen absichern

Oracle JDK oder OpenJDK: welche Java-Distribution ihr kostenfrei einsetzen dürft

Derselbe Quellcode, unterschiedliche Bedingungen. Wer im Haus welche Entscheidung trifft und woran das Ganze in der Praxis scheitert.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer
Worum es geht

Niemand hat etwas beschafft, und trotzdem steht plötzlich eine Rechnung im Raum

Java landet selten über den Einkauf im Haus. Es kommt mit einem Produkt mit, das eine Laufzeitumgebung mitbringt, es wird von einer Entwicklerin auf ihrem Rechner installiert, weil eine Anleitung es so sagt, oder es steckt in einem Container-Basisabbild, das jemand vor drei Jahren gewählt hat. Keiner dieser Vorgänge geht über eine Freigabe, und deshalb existiert auch keine Liste. Wenn dann eine Anfrage kommt, was im Haus läuft, beginnt eine Suche, die Wochen dauern kann.

Erschwert wird das durch eine Formulierung, die sich hartnäckig hält: Java sei nicht mehr kostenlos. Das ist in dieser Form falsch. Die Bedingungen betreffen ausschließlich die Builds, die Oracle unter eigenem Namen ausliefert, und auch dort nur bestimmte Versionen in bestimmten Zeitfenstern. Wer Eclipse Temurin, Amazon Corretto oder eine andere Distribution einsetzt, hat mit dieser Frage schlicht nichts zu tun. Solange im Haus aber niemand weiß, was wo installiert ist, lässt sich das nicht sagen, und diese Unsicherheit ist der eigentliche Aufwandstreiber.

Dazu kommt eine zeitliche Falle, die viele erst bemerken, wenn sie zuschnappt. Die kostenfreie Nutzung eines Oracle JDK ist nicht dauerhaft, sondern an ein Fenster gebunden, das etwa ein Jahr nach dem Erscheinen der nächsten Langzeitversion endet. Für Oracle JDK 17 ist dieses Fenster im September 2024 abgelaufen, für Oracle JDK 21 endet es im September 2026. Wer die Version einmal freigegeben und danach nicht mehr angesehen hat, wechselt in diesem Moment ohne eigenes Zutun die Lizenzgrundlage.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet was

Wer im Haus was entscheidet

Die meisten Probleme in diesem Bereich sind keine technischen, sondern Zuständigkeitsfragen. Die folgende Aufteilung hat sich bewährt, weil sie jede Entscheidung genau einer Stelle zuordnet und jedes Mal benennt, woran es in der Praxis scheitert.

Welche Java-Distribution im Haus Standard ist

Wer entscheidet
Die Architektur gemeinsam mit dem Betrieb, einmalig und schriftlich, mit Begründung und einem Datum für die Überprüfung
Wer setzt um
Der Betrieb, indem er die Distribution im internen Paketverzeichnis und in den Basisabbildern bereitstellt
Stolperfalle
Der Beschluss existiert, aber die Distribution ist intern schwerer zu bekommen als der Download bei Oracle. Dann gewinnt die Bequemlichkeit, und zwar jedes Mal.

Der Einsatz eines Oracle JDK in einem einzelnen Projekt

Wer entscheidet
Die Stelle, die für Lizenzen und Verträge zuständig ist, nicht das Projekt und nicht der Betrieb
Wer setzt um
Das Projekt, mit einem Eintrag im Bestandsverzeichnis und einer Begründung, warum die Standarddistribution nicht ausreicht
Stolperfalle
Der Fall wird als technische Kleinigkeit behandelt und läuft an der zuständigen Stelle vorbei, weil niemand ihn als Beschaffung erkennt.

Der Nachweis darüber, was auf Servern und Arbeitsplätzen läuft

Wer entscheidet
Die Stelle, die für die Inventarisierung ohnehin zuständig ist, entlang derselben Regeln wie bei anderer Software
Wer setzt um
Der Betrieb über die vorhandene Inventarisierung, ergänzt um die Herstellerzeile aus java -version und die Suche nach eingebetteten Laufzeitumgebungen
Stolperfalle
Erfasst wird nur die Versionsnummer. Damit lässt sich die eigentliche Frage nicht beantworten, denn sie hängt am Hersteller und nicht an der Zahl.

Die Basisabbilder für Container

Wer entscheidet
Die Plattformverantwortlichen, im Rahmen der ohnehin bestehenden Vorgaben für Images
Wer setzt um
Der Bauprozess, indem er nur Images aus der eigenen Registry zulässt und alles andere ablehnt
Stolperfalle
Die Regel gilt für neue Projekte, und der Bestand läuft weiter mit dem, was vor Jahren einmal kopiert wurde. Ohne eine Bestandsprüfung bleibt genau dort das Risiko.

Das Auslaufen einer kostenfreien Phase bei einem Oracle JDK

Wer entscheidet
Wer für das jeweilige Produkt im Betrieb geradesteht, nicht die Person, die den Hinweis zuerst liest
Wer setzt um
Das Team, entweder durch den Wechsel auf eine freie Distribution derselben Version oder durch den Sprung auf die nächste Langzeitversion
Stolperfalle
Der Termin verstreicht unbemerkt, weil weiterhin Updates verfügbar sind. Verändert hat sich nicht die Verfügbarkeit, sondern die Lizenz, unter der sie steht.

Eine Anfrage zur Prüfung des Java-Einsatzes

Wer entscheidet
Die Rechts- oder Vertragsabteilung, die auch sonst mit Herstelleranfragen umgeht
Wer setzt um
Der Betrieb, indem er den aktuellen Stand aus dem Inventar liefert, statt kurzfristig eine neue Erhebung zu starten
Stolperfalle
Die Antwort wird unter Zeitdruck aus verstreuten Quellen zusammengesucht. Ein gepflegtes Inventar verwandelt diesen Vorgang in eine Abfrage von wenigen Minuten.

Vom Bestand zur belastbaren Aussage

  1. 01 Was ist installiert? Version und Herstellerzeile erfassen, nicht nur die Zahl.
  2. 02 Ist ein Oracle-Build dabei? Nur dann stellt sich die Lizenzfrage überhaupt.
  3. 03 Welche Version, und liegt sie noch im kostenfreien Fenster?
  4. 04 Gibt es eine festgelegte Standarddistribution, die Projekte einfach nehmen können?
  5. 05 Stehen die Ablauftermine in einem Kalender, den jemand ansieht?
Was du mitnimmst

Was ihr im Haus tatsächlich klären müsst

Die Frage lässt sich in sechs Schritten dauerhaft beantworten. Vier davon sind einmalige Festlegungen, zwei sind laufende Vorgänge, die in bestehende Abläufe eingebaut werden können.

Version und Distribution auseinanderhalten

Java 21 ist eine Version, Eclipse Temurin 21 ist ein Build davon. Die Version bestimmt, was euer Code kann. Der Build bestimmt, unter welchen Bedingungen ihr Updates bekommt und wer haftet, wenn etwas nicht funktioniert. Trennt diese beiden Fragen in jedem Dokument und in jedem Gespräch, sonst führt ihr zwei Diskussionen gleichzeitig und beenden könnt ihr keine davon.

Eine Standarddistribution festlegen und begründen

Für die meisten Häuser ist die Antwort eine der frei verfügbaren Distributionen. Eclipse Temurin sagt für Langzeitversionen mindestens vier Jahre Builds zu und nennt konkrete Termine je Version. Amazon Corretto veröffentlicht ebenfalls eigene Zeitpläne, die für 17, 21 und 25 jeweils weit über Oracles kostenfreie Phase hinausreichen. Schreibt die Wahl mit Begründung auf, sonst wird sie in jedem Projekt neu verhandelt.

Ein Inventar aufbauen, das die Herstellerzeile mitnimmt

java -version gibt zwei Zeilen aus, und die zweite ist die wichtigere: Dort steht, wessen Build läuft. Eine Bestandsaufnahme, die nur die Versionsnummer erfasst, beantwortet die Lizenzfrage nicht. Nehmt die Erhebung in eure bestehende Inventarisierung auf und lasst sie regelmäßig laufen, denn ein einmaliger Stand veraltet in dem Moment, in dem jemand ein Basisabbild aktualisiert.

Entwicklerrechner und Produkte von Drittanbietern mitzählen

Der häufigste Fund ist nicht der Server, sondern der Arbeitsplatz: Jemand hat sich ein JDK direkt bei Oracle heruntergeladen, weil das der erste Treffer war. Der zweithäufigste ist ein gekauftes Produkt, das eine eigene Laufzeitumgebung mitbringt. Für den ersten Fall braucht ihr eine bequeme Alternative im internen Paketverzeichnis, für den zweiten eine Klärung mit dem Hersteller darüber, wie dessen Laufzeitumgebung lizenziert ist.

Basisabbilder zentral festlegen statt pro Projekt

In Container-Landschaften entscheidet die erste Zeile einer Containerdatei über die Distribution, und diese Zeile wird kopiert, nicht gelesen. Legt geprüfte Basisabbilder in eurer eigenen Registry ab und lasst den Bauprozess ablehnen, was von woanders kommt. Damit ist die Frage für den größten Teil der Landschaft ein für alle Mal beantwortet, und Aktualisierungen laufen an einer Stelle.

Die Ausstiegstermine in den Kalender legen

Für jede eingesetzte Version gibt es zwei relevante Daten: das Ende des Supports bei eurer Distribution und, falls ein Oracle JDK im Spiel ist, das Ende der kostenfreien Phase. Beide gehören in denselben Kalender wie eure Zertifikatsabläufe. Ein Termin, der nur in einem Beschlussdokument steht, wird zuverlässig übersehen.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Drei Lizenzen, und woran ihr sie auseinanderhaltet

Der Quellcode von Java liegt im OpenJDK-Projekt und steht unter der GNU General Public License Version 2 mit Classpath-Ausnahme. Diese Ausnahme ist der Grund, warum eure eigene Anwendung dadurch nicht selbst unter diese Lizenz fällt. Alle verbreiteten Distributionen bauen aus diesem Quellcode, und die Builds, die Oracle unter dem Namen OpenJDK auf jdk.java.net veröffentlicht, stehen ebenfalls darunter. Sie werden allerdings nur bis zum Erscheinen der nächsten Version gepflegt, sind also kein Weg für den Dauerbetrieb.

Die zweite Lizenz ist die No-Fee Terms and Conditions License, kurz NFTC. Sie gilt seit September 2021 für die Oracle-JDK-Builds und erlaubt ausdrücklich die kostenfreie Nutzung für alle, auch kommerziell und im Produktivbetrieb. Ihre Einschränkung ist zeitlich: Eine Langzeitversion bleibt darunter bis etwa ein Jahr nach dem Erscheinen der nächsten Langzeitversion. Für Oracle JDK 21 ist das der September 2026, für Oracle JDK 25 nach heutiger Planung der September 2028. Nicht-Langzeitversionen bleiben für ihre gesamte, auf sechs Monate angelegte Lebensdauer darunter.

Die dritte ist die Oracle Technology Network License Agreement for Java SE, kurz OTN. Sie erlaubt die persönliche Nutzung sowie Entwicklung, Test, Prototypenbau und Vorführung, aber nicht den Produktivbetrieb. Unter ihr stehen heute die Updates für Oracle JDK 8, 11 und 17, und ab Oktober 2026 sollen die Updates für Oracle JDK 21 dazukommen. Der entscheidende Punkt für die Praxis: Der Wechsel von NFTC zu OTN passiert an einem Stichtag und ändert nichts an der Verfügbarkeit der Downloads. Es ändert sich nur, was ihr damit tun dürft.

Die Distributionen und was sie tatsächlich zusagen

Alle relevanten Distributionen bauen aus demselben Quellcode und bestehen dieselbe Konformitätsprüfung, das Technology Compatibility Kit. Ein Programm, das auf der einen läuft, läuft auf der anderen. Der Unterschied liegt in den Zusagen darüber, wie lange es Builds gibt, wie schnell Sicherheitsupdates erscheinen und ob es kommerziellen Support gibt.

Eclipse Temurin von der Adoptium-Arbeitsgruppe ist die verbreitete Antwort für Häuser, die keinen Support kaufen wollen. Adoptium sagt für Langzeitversionen mindestens vier Jahre Builds zu und veröffentlicht konkrete Termine je Version. Amazon Corretto veröffentlicht eigene Zeitpläne, die derzeit für Corretto 17 bis Oktober 2029, für Corretto 21 bis Oktober 2030 und für Corretto 25 bis Oktober 2032 reichen. Daneben stehen unter anderem Azul, Red Hat, Microsoft, BellSoft, SAP und IBM mit eigenen Builds, teils mit kostenpflichtigem Support, teils ohne.

Für die Entscheidung heißt das: Die Frage lautet nicht, welche Distribution technisch besser ist, denn dieser Unterschied ist gering. Sie lautet, wessen Zusagen zu eurem Betriebsmodell passen. Wer im Störfall jemanden anrufen können muss, braucht einen Vertrag, und dann ist Oracle nur eine von mehreren Möglichkeiten. Wer den Betrieb selbst trägt, nimmt eine der frei verfügbaren Distributionen und achtet auf deren veröffentlichte Termine.

Warum das Abrechnungsmodell die Diskussion verändert hat

Seit Januar 2023 verkauft Oracle die Java SE Universal Subscription nach einer Kennzahl, die auf der Zahl der Beschäftigten beruht und nicht auf der Zahl der Personen, die Java tatsächlich benutzen. Oracle nennt in seinen eigenen Angaben einen Einstiegspreis von 15 US-Dollar je Beschäftigtem und Monat, mit veröffentlichten Staffeln bis hinunter zu 5,25 US-Dollar. Wie der Begriff genau abgegrenzt ist, steht in Oracles Preisliste, und die Abgrenzung ist der Punkt, an dem sich die Summe entscheidet.

Die praktische Folge ist eine andere Rechnung als früher. Wenn ein einzelner Server oder ein einzelner Arbeitsplatz eine Verpflichtung für das gesamte Haus auslösen kann, dann ist ein aufgeräumter Bestand kein Verwaltungsthema mehr, sondern eine Kostenfrage. Genau deshalb lohnt sich die Arbeit am Inventar und an den Basisabbildern auch dann, wenn heute niemand vorhat, etwas zu kaufen.

Umgekehrt gilt: Wenn ihr Support wollt, ist ein Vertrag eine legitime und oft sinnvolle Entscheidung, und Oracle bietet dabei mehr als nur Updates. Die Frage ist dann nicht ob, sondern bei wem, denn mehrere Anbieter liefern kommerziellen Support für dieselben Java-Versionen zu anderen Kennzahlen. Ein Vergleich lohnt sich, und er ist deutlich einfacher zu führen, wenn ihr vorher wisst, was bei euch läuft.

Der Weg heraus, wenn ein Oracle JDK im Bestand steckt

Der Wechsel selbst ist technisch klein. Eine andere Distribution derselben Java-Version ist ein Austausch des Installationspakets oder eine geänderte Zeile im Basisabbild, danach läuft dieselbe Anwendung weiter. Was Zeit kostet, ist nicht der Wechsel, sondern die Feststellung, wo überall gewechselt werden muss, und die anschließende Prüfung, dass nichts Unerwartetes passiert ist. Plant den Test wie bei einem Versionswechsel, auch wenn die Versionsnummer gleich bleibt.

Zwei Stellen verdienen dabei besondere Aufmerksamkeit. Die erste sind Produkte von Drittanbietern, die eine eigene Laufzeitumgebung mitbringen: Dort dürft ihr oft gar nicht selbst wechseln, weil der Hersteller nur seine Zusammenstellung unterstützt. Klärt in diesen Fällen schriftlich, wie die mitgelieferte Laufzeitumgebung lizenziert ist, denn im Regelfall trägt der Hersteller das. Die zweite sind Anwendungen mit eigenen Startskripten, in denen der Pfad zu einem JDK fest verdrahtet ist. Diese Skripte findet ihr nur, indem ihr danach sucht.

Für die Zukunft hilft eine einfache Regel mehr als jede Richtlinie: Es muss leichter sein, die richtige Distribution zu bekommen als die falsche. Solange der Download bei Oracle drei Klicks kostet und das interne Paket eine Anfrage per Ticket, wird der Bestand immer wieder durchmischt. Ein internes Paketverzeichnis, ein geprüftes Basisabbild und ein Eintrag in der Einrichtungsanleitung für neue Arbeitsplätze erledigen mehr als jede Erinnerung im Intranet.

Dazu passende Kurse

Wenn Betrieb, Architektur und Einkauf bei dieser Frage aneinander vorbeireden, schaffen Java-Kurse für technische und entscheidende Rollen die gemeinsame Sprache dafür.

Wissen prüfen

Wie sicher bist du beim Thema wirklich?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Einführung in die Programmierung für Programmiereinsteiger
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Groovy Grundkurs
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Unreal Engine Kurs für Einsteiger

Häufige Fragen

Ist Java jetzt kostenpflichtig?
Nein. Der Quellcode steht unter offener Lizenz, und Distributionen wie Eclipse Temurin oder Amazon Corretto liefern daraus fertige Builds ohne Kosten und mit eigenen Support-Zeitplänen. Kosten entstehen nur bei den Builds, die Oracle unter eigenem Namen ausliefert, und auch dort nur außerhalb der jeweiligen kostenfreien Phase.
Wir haben Oracle JDK 21 im Einsatz. Was passiert im September 2026?
Die Updates bleiben verfügbar, aber sie stehen ab dann unter der OTN-Lizenz, die den Produktivbetrieb nicht abdeckt. Ihr habt zwei Wege: entweder auf eine freie Distribution derselben Version 21 wechseln, was technisch ein Austausch des Pakets ist, oder auf Java 25 gehen, das nach heutiger Planung bis September 2028 unter der kostenfreien Lizenz bleibt.
Zählt ein JDK auf einem Entwicklerrechner mit?
Für die OTN-Lizenz sind Entwicklung, Test, Prototypenbau und Vorführung ausdrücklich erlaubt, ein JDK für diese Zwecke ist also unproblematisch. Heikel wird es, wenn dieselbe Installation für etwas anderes verwendet wird, etwa als Laufzeitumgebung für ein internes Werkzeug, das andere Leute benutzen. Deshalb gehören Arbeitsplätze trotzdem ins Inventar.
Unterscheiden sich die Distributionen technisch voneinander?
Kaum. Sie bauen aus demselben OpenJDK-Quellcode und bestehen dieselbe Konformitätsprüfung. Unterschiede gibt es bei Zusatzbestandteilen, bei den unterstützten Betriebssystemen und Prozessorarchitekturen und beim Zeitpunkt, zu dem Sicherheitsupdates erscheinen. Für eine gewöhnliche Anwendung ist der Wechsel zwischen zwei Distributionen derselben Version unauffällig.
Was ist mit Java in gekaufter Software?
Bringt ein Produkt seine eigene Laufzeitumgebung mit, ist im Regelfall der Hersteller dafür zuständig, und ihr dürft dort meist auch nichts austauschen, ohne den Support zu verlieren. Lasst euch das trotzdem schriftlich bestätigen und nehmt diese Produkte in euer Verzeichnis auf, denn bei einer Anfrage müsst ihr sie benennen und zuordnen können.
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

Die Java-Landschaft im Haus einmal sauber aufstellen

Bei cmt bekommen technische und entscheidende Rollen in den Java-Kursen dieselbe Grundlage, damit die Diskussion über Versionen und Distributionen nicht jedes Mal von vorn beginnt.