Im September 2024 endet der kostenlose Support für Oracle Java 17 und kommerzielle Nutzer benötigen ein kostenpflichtiges Abo von Oracle. Das dürfte teuer werden, da Oracle die Lizenzgebühren nach der Zahl der Mitarbeiter im Unternehmen berechnet. Firmen müssen reagieren und entweder auf JAVA 21 oder ein kostenloses JDK von anderen Anbietern wechseln, wenn sie die Lizenzgebühren vermeiden möchten.
Anzeige
User-basierende Oracle Java SE-Lizenzen
Ich greife erneut das Thema Java-Lizenzierung im kommerziellen Umfeld auf, weil sich ab Oktober 2024 ggf. eine Änderung ergibt. Die mal von Sun entwickelte Programmiersprache
JAVA war seinerzeit kostenlos. Aber seit der Übernahme durch Oracle ist JAVA (begann mit der Version 8) inzwischen für kommerzielle Einsätze kostenpflichtig – das gilt selbst für Bildungseinrichtungen. Auf der JAVA-Seite findet sich diese Information zu den Oracle JAVA-Lizenzen.
JAVA 17 als NFTC-Lizenz
Im September 2021 wurde Java 17 veröffentlicht, und viele Unternehmen wechselten auf die neue Version. Am 13.09.2021 gab es wohl eine Ankündigung für das neue Java LTS-Release 17, welches wieder kostenfrei genutzt werden könne (siehe). Nach dem Download von Oracle Java 17 LTS und Annahme der "No Fee Terms and Conditions"-Agreements (NFTC) bekam der Nutzer kostenfreie Updates bis September 2024.
Bei Java 17 handelt es sich zudem um eine Long Term Support Version (LTS), für die Oracle fünf Jahre kostenpflichtigen Premium-Support und weitere drei Jahre Extended Support anbietet. Das qualifiziert sie als stabile Lösung für den Unternehmenseinsatz.
Aber wir sind nun am genannten Termin angelangt und die kostenlose NFTC-Lizenz wandelt sich automatisch zur kostenpflichtigen OTNLA-Lizenz. Sprich: Ab Oktober 2024 schlägt die Oracle-Falle zu, Firmen, die JAVA weiter verwenden und Updates haben wollen, müssen eine kostenpflichtige Lizenz erwerben.
Anzeige
Das wird aber teuer, wie ich 2023 im Artikel Am Lizenzhaken: 3 fach höhere Lizenzkosten für MS SQL-Server, User-basierende Oracle Java SE-Lizenzen angesprochen hatte. Ein neues Preismodell von Oracle basiert nicht mehr auf der Anzahl der verwendeten JAVA-Einsätze sondern auf der Anzahl der Mitarbeiter. Es gibt zwar verschiedene Preisstufen für unterschiedliche Mitarbeiterzahlen, aber es führt dazu, dass jeder Mitarbeiter im Unternehmen für die Lizenzierung gezählt wird, auch wenn er keine Java-Software verwendet.
Dies hat zur Folge, dass Unternehmen, die Java SE einsetzen, von erheblichen Preissteigerungen betroffen sind. Ich hatte im Juni 2024 im Beitrag Oracle spielt die JAVA-Lizenzkarte; Audits in Firmen; Jagd auf nicht lizenzierte Nutzer berichtet, dass Oracle nun Jagd auf nicht lizenzierte Nutzer macht und in Firmen Audits durchführt. Das endet oft in gepfefferten Rechnungen für Lizenzkosten durch die Nutzung von JAVA SE. Im verlinkten Beitrag hatte ich thematisiert, dass Unternehmen, die durch Oracle per Brief zu ihrer JAVA-Verwendung befragt werden, nicht zu viel verraten würden.
Wechsel zu Alternativen
Simon Ritter von Azul meint, wer ein teures JAVA-Abo vermeiden möchte, hat zwei Möglichkeiten: Er könnte zu JAVA 21 wechseln und dort eine NFTC-Lizenz beantragen. Oder die Firma entschließt sich, gleich die JAVA-Laufzeitumgebung eines anderen Herstellers zu verwenden.
Wechsel zu JAVA 21 als NFTC-Lizenz
Eine Möglichkeit besteht darin, zur nächsten JAVA LTS-Version zu wechseln – das wäre der JDK 21. Sie fällt derzeit noch unter die NFTC-Lizenz und erfordert daher keine Java SE Universal Subscription. Allerdings müssen Unternehmen dann spätestens in zwei Jahren auf JDK 25 migrieren, weil JDK 21 in die OTNLA-Lizenz übergeht. Abgesehen davon kann es passieren, dass bestehende Anwendungen unter JDK 21 nicht wie erwartet funktionieren, schreibt Simon Ritter von Azul. Bisher sei Java zwar stets gut abwärtskompatibel gewesen. Doch seit JDK 9 wurden nicht nur neue Funktionen hinzugefügt, sondern auch ältere entfernt. Das kann zu Problemen führen.
Wechsel zu einem alternativen JDK
Ich hatte bereits im Artikel Oracles Java-Preise: Abonnenten wechseln auf OpenJDK erwähnt, dass man nicht auf Oracles JAVA angewiesen sei. Es gibt alternative Anbieter für die JAVA-Laufzeitumgebung, wie Amazons Corretto oder IBM Semeru Runtimes oder Eclipse Temurin,
Simon Ritter von Azul weist in einer Mitteilung darauf hin, dass es auch ein Support-Modell wie Azul Platform Core (kostenpflichtig) gäbe. Mit diesem Modell erhielten Unternehmen Sicherheit und Komfort beim Einsatz von JAVA und würden im Vergleich zu Oracle in der Regel mindestens 70 Prozent Kosten sparen.
Ähnliche Artikel:
Am Lizenzhaken: 3 fach höhere Lizenzkosten für MS SQL-Server, User-basierende Oracle Java SE-Lizenzen
Oracle spielt die JAVA-Lizenzkarte; Audits in Firmen; Jagd auf nicht lizenzierte Nutzer
Oracles Java-Preise: Abonnenten wechseln auf OpenJDK
Anzeige
Hier aus der Lizenz-Praxis in der Oracle Datenbank-Umgebung:
Da werden z.B. Out-Of-Box bei Standard-Software hundert+ "Enterprise-Features" mitinstalliert. z.B. Sowas wie Backup-Kompression, oder Backup-Verschlüsselung. Solche Features sind selbst kostenpflichtige Addons je Core die zusätzlich eine Enterprise-Lizenz voraussetzen. Standard-Software war per Socket Lizensiert, Enterprise muss auch per Core.
Das rauskopieren der Installations-Umgebung auf einen Backup-Server macht den Backup-Server z.B. lizenzpflichtig, weil die Binaries gestartet werden könnten.
Da werden z.B. bei Virtualisierungen Annahmen getroffen die Laien nicht auf dem Radar haben: Jeder Core im Host wird betrachtet weil die Software auf jedem laufen .
Bei VMware könnten VMs clusterübergreifend verschoben werden? Tja, dann halt den Custer lizensieren. Ein einzelner ESX Host hat mehr als 2 Sockets, dann brauchst Du grundsätzlich Enterprise, und musst folglich je Core lizesieren.
Virtualisierungs-Lösungen:
* ESX-Host in eigenen Subnetz (VLAN), am besten ganz ohne VCenter-Bindung.
* oder: Oracle-VM mit CPU-Pinning
Da können bei unbedachter Nutzung die Kosten schnell in die hundertausenden bis Mio explodieren selbst eigentlich kleinen Umgebungen.
Folgende Empfehlungen für Oracle-Datenbanken:
* DOAG Lizenzguide (Mitgliedschaft erforderlich)
Und zusätzlich:
* https://frankgerasch.de/2016/12/scriptbasierter-license-violation-check/
Fazit:
Den Einsatz von Oracle sollte man sich wirklich gut überlegen.
Lizenzverstöße werden nicht aufgezeigt, es liegt beim Admin all das zu wissen, und darauf zu achten.
Virtualisierungslösungen in mittleren Umgebungen bedingen bei Oracle einen sogenannten VLAN-Audit, d.h. es wird entschieden, auf welchen der vorhandenen Hosts und welchen CPU-Core eine Oracle-Lösung (z.B. Datenbank) _theoretisch_ umziehen könnte.
Sind nicht klar erkennbare Sperren (z.B. getrenntes Storage und eben getrennte Netze) vorhanden, sind das eben alle vorgefundenen CPU-Cores mit Virtualisierungslösungen – das kann sehr schnell sehr teuer werden.
Fluchtweg ab einer bestimmten Unternehmensgröße sind dann nur physische Rechnerknoten. Oracle selbst hat die sogenannte "Oracle Database Appliance" ODA, welche sogar einen von Oracle gebauten und damit auch akzeptierten Weg enthält, nur einzelne CPU-Cores für die Datenbank freizugeben.
Natürlich nicht billig, dann muß man eben dafür einen Tesla weniger anschaffen (oder zwei, wenn das System redundant sein soll). 😀
Ansonsten sind eigentlich alle separat lizenzpflichtigen Features mit Countern und Zeitstempeln versehen, wenn man beispielsweise versehentlich mal eine Analyse aus dem Diagnostic- und Tuning-Pack aufgerufen hat, dann reicht es, das Oracle rechtzeitig zu melden. Wenn der Aufrufzächler wirklich nur eins oder zwei zeigt und der letzte Aufruf lange zurückliegt, kommt man ggf. darum herum, das noch lizensieren zu müssen.
Wichtig ist es, möglichst bei allen Architekturentscheidungen einen kompetenten Oracle-Partner (möglichst ein Mitglied der DOAG) an seiner Seite zu haben.
In Sachen Datenbank würde ich einen Umstieg auf eine Alternative empfehlen – wie z.B. Postgres
MsSql-Server hat ja ähnliche Lizenzkosten oder passt diese langsam aber stetig an Oracle an, also schiebt man da das Problem nur auf.
MySql bzw. MariaDb wäre auch eine Möglichkeit, aber ich habe den Eindruck, das Postgres diese in den letzten Jahren überholt hat. Aber das kommt natürlich auf die Anwendungsfälle an.
Natürlich ist so ein Umstieg alles andere als einfach, auch bietet Postgres nicht alle Möglichkeiten die ORACLE auch hat, aber auch bei ORACLE muss man frickeln – besonders bei den Installationen und Clients in Windows – das kann schon mal PostGres besser…
Es dauert sicher seine Zeit bis man alle Sql Befehle migriert hat. Bei Software Fremdlösungen (die nur auf ORACLE setzen) ist es dann aber fast unmöglich.
Genau diese Fremdlösungen (bei uns das seit 20 Jahren genutzte ERP-System) sind halt die Crux. "Unseren" Anbieter mußten wir schon mit leichtem Druck dazu bringen, statt Oracle unter Windows auch Linux (für die ODA) zu unterstützen. Eine andere Datenbank – ausgeschlossen. Und ein ERP-System mit tausenden kundenspezifischer Anpassungen wechselt man eben auch nicht von heute auf morgen.
>> In Sachen Datenbank würde ich einen Umstieg auf eine Alternative empfehlen – wie z.B. Postgres <<
Das spricht sich einfach.
Wenn Du jedoch 10-Mannjahre Entwicklung in Sachen Desktop-Applikationen, APEX und Drucklayouts gesetzt hast, die auf Oracle-Spezifische APIs setzen, ist Umstieg keine realistische Option mehr.
Oder willst du den Core-Entwickler 3-5Jahre abziehen, und auf irgendwas neues ohne garantierten Erfolg setzen, während die Bestands-Lizenzen zur Upgrade Fähigkeit inkl. technischem Oracle-Support vielleicht noch 12k im Jahr kosten?
Ich wollte das Thema nicht zu weit auffächern.
Wir haben sind ohne offizielles "VLAN-Approval" seitens Oracle erfolgreich durch ein Audit gekommen, indem die Host-Netze via VLAN getrennt waren, und je nach Lizenzen unterschiedliche Virtualisierer genommen wurden: HyperV, ESX ohne VCenter. Storage sind lokal, RAID6, via VEEAM gesichert, und zusätzlich laufen die nackten Backup-Files auf verschiedene NFS-Shares extern raus.
Der DOAG Lizenzguide war hier tatsächlich Gold Wert.
Du hast vollkommen recht, einzelne Feature-Verstöße sind kein Problem, aber sobald eine Regelmäßigkeit erkennbar ist, muss gezahlt werden.
Das Problem ist ja, das der normalsterbliche keine 100+ Verstoßmöglichkeiten ahnt – insbesondere nicht beim aktivieren bei sowas wie Backup-Kompression etc. Auch ahnt keiner das er bei einer Default-Installation schon Verstöße auslöst.
Also wer da noch in die Falle tappt ist selber schuld.
Wir haben unsere Produkte schon von Jahren alle umgestellt und auch unsere Kunden sind das Thema systematisch angegangen.
Alternativen gibt es fast immer und wer eine Oracle Java Umgebung benötigende Software hat stehen lassen hat richtig gepatzt.
Oracle (wie Broadcom) interessieren Kunden nicht die wechseln können. Deren Umgebung sind mindestens um den Faktor 1000x zu klein.
Meist wird Java ja bei Serverlösungen eingesetzt, auf dem Desktop sicher weniger oft. Daher verstehe ich schon das Bestreben per User zu lizenzieren. Aber wie man auch bei den anderen Kommentaren lesen kann, sind die Lösungen meist auf Geldmacherei ausgelegt.
Auch bei der Datenbank, kann es passieren, dass man bei dem kostenlosen Klient auf ein Analysetool klickt und damit aber dann bei der Datenbank in eine andere Lizenzklasse fällt, bei der man plötzlich wesentlich mehr zahlen muss. So war es zumindest vor 10 Jahren.
Wie erwähnt wird – sind die Lösungen aber nur hingebastelt. Man sieht keinen Überblick, es gibt kaum Warnungen, es ist ein gefrickel – mit dem sich die Admins herumquälen müssen.Aber da kann man dann noch gerne eigene teure Kurse anbieten und Zertifizierungen. Außerdem hat man einen Grund diese Audits durchzuführen. So lässt man sich die eigene Inkompetenz durch den Kunden extra zahlen.
Zu Java .. wäre man doch besser bei Oak geblieben ;-)
aber der Umstieg auf OpenJDK ist jedenfalls zu empfehlen..
Es gab eine Zeit (die gottseidank halbwegs vorbei ist), in der einem viele zu Hardware gehörende Tools mal eben ihre eigene JRE auf die Festplatte klatschten.
Switche, Telefonanlagen, KVM-Lösungen und auch Solar-Wechselrichter. Alles Produkte mit langer Lebensdauer, die man ggf. auch heute noch betreibt und gelegentlich "anfassen" muß. Viel läuft mit alternativen JREs, aber manchmal sind die Aufrufe hartcodiert und nicht trivial "umzubiegen".
Meine Vermutung: dass diese Java Versionen dann aber auch nicht upgedatet werden und man somit "nur" (!!!) Sicherheitslücken hat, aber noch so alte Versionen – die noch nicht mit Lizenzgebühren verbunden sind. Oder sehe ich das falsch?
Etwas neuere Versionen (gerade in der Zeit des Lizenzwechsels) brachten schon einen Auto-Updater mit. Ob der genutzt wurde hängt aber natürlich von vielen Faktoren ab.
Danke für den Hinweis!
Im privaten habe ich hier nur noch zwei Programme (jDownloader2 & TV-Browser), die unbedingt eine Laufzeitumgebung benötigen. Ich habe mich jetzt dazu entschlossen auf die Version 21 umzusteigen, da diese auch bei meinen LINUX-Installationen mittlerweile bei dieser Version ist und ich das Ganze dann doch noch etwas einheitlich halten möchte. Das mit OpenJDK behalte ich mal als Ausweichmöglichkeit im Hinterkopf – gerade beim TV-Browser probiert, funktioniert das (dort) auch ganz gut.
Wirf Oracle Java raus, installiere Coretto (Amazon) oder eine andere freie Runtime. Die von dir erwähnten Programme laufen damit einwandfrei. Wenn Du Jawa Webstart benötigst (ältere KVM von Supermicro als Beispiel) kannst Du zusätzlich IcedTea installieren. Achtung, ältere Version verwenden, die neuen haben das Feature nicht mehr.
Fast jeder unserer Kunden nutzt die Java Runtime auf irgendeinem Rechner im Unternehmen. Hat das dort irgendwelche Auswirkungen?