Az Oracle 2017 végén jelentette be, hogy módosítja a Java SE licencelését. Mivel egyes változások egy hónap múlva hatályba is lépnek, érdemes áttekinteni a változásokat és hatásukat. A változást az üzleti felhasználók két területen fogják érzékelni. Az egyik az, hogy Oracle átáll féléves verziókiadási ciklusra. A másik már húsbavágóbb: 2019. január végétől megszűnik a Java SE 8 ingyenes frissítése, és a legújabb, Java SE 11 sem használható ingyenesen üzleti célra.

Ez komoly változást hoz, hiszen a Java napjaink egyik legnépszerűbb programozási nyelve, illetve platformja.

A Javáról röviden

Népszerűségének alapját a "Write once, run anywhere" koncepció adja: a kódot elég egyszer megírni, ugyanis utána az minden Javát futtató eszközön ugyanúgy fog működni.

A platform önmagában 2007. óta GNU/GPLv2+CE (GNU General Public License v2 with Classpath Exception) licencelésű. A licenc egyebek mellett lehetővé teszi, hogy a forráskódhoz bárki szabadon hozzáférjen, felhasználja és módosítsa. Ezeket a módosításokat nyílt forrásúként közzé kell tenni. A CE kitétel viszont lehetővé teszi, hogy a platformra épülő alkalmazások zártként is közzé tehetők, azaz ellentétben a "mezei" GPL-lel, a licenc nem virális. A Linux platformhoz hasonlóan több disztribúció is elérhető, amelyek licencelése akár kereskedelmi is lehet. A platform fejlesztői között szerepelnek többek között az Oracle, az IBM, a Red Hat, az SAP és az Apple, de átlagos magánszemélyek is.

A legelterjedtebb disztribúció az Oracle Java SE, és épp ezt a kiadást érintik a bevezetőben említett változások. Nézzük mik is ezek a változások!

1. Kiadási ciklus

A Java 9-es verziójától az Oracle a korábbi feature-driven kiadások helyett átállt a féléves kiadási ciklusokra. Egy ilyen kiadás támogatása fél évig, a következő verzió megjelenéséig tart. Így ma már nem támogatott sem a 9-es, sem a 10 verzió. Az Oracle azonban háromévente kiad ún. LTS (Long Term Support) verziót is, amelyhez a megjelenéstől számítva öt évig nyújt támogatást. Ebből a jelenleg legfrissebb verzió a Java SE 11.

2. Frissítések

Jövő év januárjától az üzleti felhasználók nem jutnak hozzá ingyenesen a Java 8 frissítéseihez. Ez megfelel az Oracle korábbi gyakorlatának. Például a 2006-ban megjelent Java 6-hoz 2013-ig adta ingyenesen a frissítéseket, utána viszont már fizetni kellett a kiterjesztett támogatásért, amit 2018 decemberéig biztosított. A Java 8-nál ugyanez történik: végéhez ért a verzió publikus életciklusa, a kiterjesztett támogatásért pedig hamarosan fizetni kell.

A Java 9-től kezdve a verziók életciklusuk alatt kétszer kapnak frissítést, az LTS verziók szintén negyedévente. (A különböző verziók támogatási ciklusát lásd a táblázatban.)

3. Licencelés

Az Oracle Java SE a 11 verzióig BCL (Binary Code License) alatt érhető el. Ez a licenc lényegében azt jelenti, hogy általános számítógépi felhasználásra (magán és üzleti célokra egyaránt) a Java ingyenesen használható egészen addig, amíg a felhasználó nem telepít fizetős frissítéseket, illetve nem használ extra funkciókat (pl. JavaFX, Jrockit, Mission Control stb.). Ez a licenctípus a jelenleg elterjedt 6-os, 7-es és 8-as verzióra továbbra is hatályban marad.

A 11-es verziót követően az Oracle Java SE már nem BCL, hanem kereskedelmi licencű. Ennek értelmében a Java csak fejlesztési, tesztelési és demonstrációs céllal használható ingyenesen – az OTN (Oracle Technology Network) licenc szabályainak megfelelően. Minden más jellegű felhasználás már fizetési kötelezettséget von maga után. Más szóval: például az Oracle JDK 11-gyel fordított futtatható “Helló világ” alkalmazás nem tehető közzé a licenc megvásárlása nélkül.

4. JRE

A JAVA 11-es verziótól kezdve nem lesz többé önálló a JRE. Az Oracle célja ezzel az, hogy a fejlesztők a jlink segítségével maguk fordítsák be a szoftverükbe a futtatáshoz szükséges komponenseket, és ne a végfelhasználó (vagy az Oracle) felelőssége legyen a Java futtatási környezet naprakészen tartása. Más kérdés, hogy az alkalmazással csomagolt Java szintén licencigénnyel bír.

5. Árazás

Ismételten hangsúlyoznám: a Java korábban is rendelkezett fizetős modellel. A Java SE Advanced és Advanced Desktop, illetve a Suite kiadásokért eddig is licencdíjat kellett fizetni. Aki már rendelkezik előbbiek valamelyikével és hozzá tartozó SULS-sal (Software Update License & Support) – bár ez ritka eset –, annak nem keletkezik további fizetési kötelezettsége.

Fentiek mellett pedig megjelent egy előfizetéses modell is, a felhasználónként licencelendő Oracle Java SE Desktop Subscription, illetve processzoronként lefedendő Java SE Subscription. (A processzormagokat itt is faktorálni kell.)

És akkor nézzük az árakat. Az Oracle Java SE Desktop Subscription ára havi 2,5 dollár felhasználónként. Ez sávos mennyiségi kedvezményekkel 1,25 dollárig csökkenthető.

Az Oracle Java SE Subscription ára havi 25 dollár processzoronként (magonként/kétmagonként), Itt is van mennyiségi kedvezmény, amivel sávosan legfeljebb 12,5 dollárig csökkenthető az ár.

Ebből következően egy 4000 felhasználós, 200 processzor licencigényű környezetben a már mennyiségi kedvezményeket is magába foglaló végösszeg havi 11.750 dollár, éves szinten 141.000 dollár, azaz majdnem 40 millió forint.

Természetesen az Oracle Egyező Támogatási Szintek szabálya itt is érvényes, azaz nem lehet a környezet csak egy részére támogatást biztosítani. Virtualizált szerverek esetében a licencelés alapja alapvetően nem a virtuális processzorok száma, hanem a futtató fizikai szerver magszáma, amely bizonyos konfigurációk esetében csökkenthető a teljes fizikai kapacitás alá is.

Az előfizetésért cserébe a My Oracle Support-on keresztül elérhetjük a Java SE 11-et és frissítéseit, hozzáférünk a Java SE 8 és korábbi verziók nem publikus (nem ingyenes) frissítéseihez. Emellett használhatjuk a korábbi verziókban benne lévő, de nem ingyenes funkciókat, beleértve az enterprise management funkciókat is. Az Oracle ehhez támogatási szolgáltatást is nyújt.

Ez utóbbi mutatja legjobban, hogy az Oracle a Java SE jövőbeni feladatát a kritikus üzleti alkalmazások kiszolgálásában látja.

Egyszerűbb lett a licencelés

Az Oracle egy huszárvágással megoldotta, hogy egyszerűbb legyen az Oracle Java SE licencelése. A korábbi verzióknál problémát jelent, hogy egy környezetben van-e fizetős funkció vagy frissítés telepítve, és ha igen milyen fizetős funkció aktiválva, illetve van-e fizetős frissítés telepítve. Ennek megvolt a reális kockázata, mert a más Oracle terméket licencelők be tudnak lépni a My Oracle Support portálra, ahol az összes korábbi Java verzióhoz az összes nem publikus frissítés letölthető függetlenül attól, hogy van-e rá licencük. A Java SE 11-től viszont nincs ilyen dilemma, hiszen ingyenes használatról lényegében nem beszélhetünk.

Átlagos felhasználók számára ugyanakkor ez komoly csapdát is jelent,  a változás ugyanis nincs eléggé a köztudatban. Ha valaki a korábbi gyakorlata alapján rutinból hajt végre verziófrissítést, azzal komoly anyagi kockázatot vállal. Várható  ugyanis, hogy az Oracle 2019-től célzott Java-auditokat is indít.

Szükséges és lehetséges teendők

Végül vegyük sorra tételesen a szükséges és lehetséges tennivalókat.

Mindenekelőtt érdemes lehet kikapcsolni az automatikus frissítést, hogy az SE 8 esetén nehogy telepítésre kerüljön üzleti felhasználóknak már díjköteles javítócsomag, hiszen a magánfelhasználók még 2020 végéig kapnak ingyenes frissítéseket, a két felhasználótípus megkülönböztetését szolgáló műszaki megoldás pedig még nem ismert

Utána jöhetnek az alapfeladatok. Mihamarabb fel kell mérni, hogy a vállalatnál hol és milyen Oracle Java SE fut. Emellett érdemes rendszeressé tenni az önellenőrzést is. Itt van egy kis csavar. Az önellenőrzés ugyanis elvégezhető az Oracle Java Usage Trackerrel, amely benne van az ingyen letöltött Oracle Java SE-ben, azonban azért, hogy megállapítsuk, hogy egyébként nem kellett volna fizetni, már kell fizetni, mivel ez fizetős funkció (lásd fentebb a Licencelés pontot).

Használhatunk független SAM (Software Asset Management) eszközt is is. Olyat érdemes választani, ami képes verziónként és frissítésenként felismerni az üzemeltetett környezetben jelenlévő Javákat. Így ki tudjuk számolni a Java-előfizetések összegét, és azt is láthatjuk, honnan kell eltávolítani, ha nem az Oracle kereskedelmi disztribúcióját választjuk.

És most jöjjenek a lehetséges teendők.

Mindenekelőtt ismét hangsúlyozzuk: a változások csak az Oracle Java SE-re vonatkoznak. Vannak azonban más disztribúciók is. Az alábbiakban felvázolunk pár lehetséges forgatókönyvet , hogy mire számíthatnak azok 2019 januárja után, akik nem az Oracle kereskedelmi disztribúcióját választják.

1. Oracle Java SE 8 vagy korábbi verziót használ: ha valakinek elég, és nem is kíván frissíteni, akkor egytelen teendője van: kapcsolja ki az automatikus frissítéseket. Ilyenkor természetesen Elegendő a legutóbbi ingyenesen elérhető verziót meghagyni, de vállalni kell az ezzel járó biztonsági és kompatibilitási kockázatokat.

2. OpenJDK 11+-t használ: ezzel sem lesz problémamentes az élet. Érthető, hogy az Oracle fizetőssé tette a Java SE 11-et, hiszen köré épített egy nagy szolgáltatáscsomagot. A Java SE és az Open JDK esetében hasonló helyzet alakult ki, mint a RHEL és a CentOS viszonyában. Mint a cikk első felében írtuk,a Java platform GPL, azaz nyílt forráskódú. Ugyanakkor annak funkcionalitása eddig nem egyezett meg az Oracle Java SE-vel. Csakhogy az Oracle, hogy lökést adjon a nyílt forráskódú közösségnek, elérhetővé tette saját disztribúciójának ingyenes változatát GPL2+CE alatt. Ez a megjelenésétől fél évig kód szintjén és funkcionalitásában is megegyezik a fizetős változattal, még a kereskedelmi funkciók – például a Mission Control vagy a Flight Recorder – is részei az OpenJDK-nak.

Fél év után azonban, amikor megjelenik egy új OpenJDK, az Oracle nem ad frissítést a régebbi verzióhoz. A felhasználó előtt három út marad, ha ragaszkodik az ingyenes megoldáshoz. Minden alkalommal átáll az új OpenJDK verzióra, azaz lényegében bevállalja a folyamatos biztonsági tesztelést és migrálást a rövid életciklus miatt. Esetleg kockáztat, és abban reménykedik, hogy a közösség majd foltozgatja a verziót. Vagy más szolgáltatóktól vásárol hosszútávú támogatást. Egy biztos: a féléves ciklus lejártát követően az Oracle Java SE és az OpenJDK már nem lesz azonos kódszinten.

3. Más disztribúciót használ: Egyéb gyártók, illetve szolgáltatók is rendelkeznek OpenJDK-kiadással, például az IBM, Red Hat, Azul vagy az SAP. Ezek a disztribúciók eltérhetnek egymástól például abban, hogy milyen operációs rendszereket támogatnak, vagy például a Java mellé milyen modulokat, kiegészítő eszközöket adnak. Csakhogy ezeknek a kiegészítőknek a támogatása ugyanúgy fizetős, mint az Oracle-nél. Más kérdés, hogy az ilyen szolgáltatók által nyújtott frissítések a GPL licenc miatt nyílt forráskódúak kell legyenek, azaz előbb-utóbb visszajutnak az OpenJDK főágába. Egyes szolgáltatók, például az Azul vagy a Red Hat ezt a visszatöltést maguk elvégzik a frissítések megjelenésével egy időben és utóbbiak ingyenes, tesztelt JDK-kat is elérhetővé tettek.

Az OpenJDK-ból a végfelhasználó készíthet saját JDK csomagot is. Ez azonban a kódbázis folyamatos ellenőrzését igényli, azaz nézni kell, hogy mikor, ki és milyen típusú módosítást tett közzé. Összességében tehát nem túl felhasználóbarát megoldás. Másrészt azzal is számolni kell, hogy a frissítések, módosítások nem esnek át tesztelésen, azt a felhasználónak magának kell elvégeznie. És ha valamilyen kompatibilitási vagy működési hiba lép fel, nincs kinél reklamálni.

Lehetséges út még az AdoptOpenJDK mozgalom is. Ez több operációs rendszerre ad OpenJDK disztribúciókat, és folyamatosan újracsomagolja a legújabb változásokat az adott Java-verzión, tehát azok tartalmazzák a legfrissebb közösségi biztonsági frissítéseket is. Emellett tesztparkot üzemeltetnek, ahol az egyes frissítéseket tesztelik. Ezzel az AdoptOpenJDK azoknak a korábbi felhasználóknak az igényeit ki tudja elégíteni, akik eddig sem igényeltek valódi támogatást, csak frissítéseket.

A különböző disztribúciók (beleértve az Oracle-ét is)  közötti kompatibilitás elméletileg akkor biztosított, ha az adott disztribúció átmegy a TCK (Technology Compatibility Kit) teszten. Ez igazolja, hogy a kiadás megfelel az SE specifikációnak. A disztribúciók nevében ezt jogi okokból nem tüntethetik fel, legfeljebb egy “SE compatible” kitétel utal rá.

Az OpenJDK egyik nagy hátránya az, hogy csak a közösség megegyezésén múlik, kap-e egy-egy verzió LTS-t, azaz hosszú távú támogatást, és ha igen, meddig. A 8-as verzióhoz például (ahol az OpenJDK még nem egyezik meg az Oracle Java SE-vel) a Red Hat 2023-ig vállalta frissítések készítését és a támogatást, a Java 11-nél pedig 2024-ig.

Dr. Hegedüs Tamás

A szerző jogász, idén csatlakozott az IPR-Insights Hungaryhez, ahol licencelési tanácsadóként dolgozik.

4. Amazon Corretto: a közelmúltban az Amazon is beszállt az OpenJDK fejlesztésébe, és saját Java-disztribúciót is fejleszt Corretto néven. A Corretto 8 kiadását jövő év első negyedévére ígérték (a megjelenés előtti változata már elérhető, és az AWS-en is ez fut). Használata a GPL licenc miatt ingyenes lesz magán és üzleti célra egyaránt, és az Amazon 2023 júniusáig negyedévenkénti frissítést is ígér hozzá (teljesítményjavító és biztonsági frissítések), a kritikus hibák javítását pedig soron kívül elvégzi.

Az első negyedévben a Corretto 11 (az Open JDK 11 alapján) is megjelenik, aminek frissítését az Amazon 2024 augusztusáig vállalta. A vállat állítása szerint a Corretto teljesen kompatibilis lesz az egyéb OpenJDK és az Oracle JDK disztribúciókkal. Linux kiadások közül csak a sajátját, az Amazon Linux 2-t támogatja, tehát inkább desktop oldalon ígéretes, de a Linux disztribúciók készítői többnyire egyébként is gondoskodnak a legfrissebb OpenJDK csomagokról. Így a cikkben részletezett változások a Linux (kivéve az Oracle Linux) felhasználókat nem érinti, az ő gépükön eddig is OpenJDK futott.

Nehéz ígéretekre építeni, de ha nem kívánunk támogatást vásárolni, akkor a Corretto mellett szól, hogy egy nagyvállalat áll mögötte, aki maga is használja. Ennek ellenére a felhasználó részéről odafigyelést igényel, hiszen az OpenJDK 8 és az Oracle Java SE 8 kódbázisa nem teljesen azonos, bár a kettő kompatibilitását a TCK megfelelés is igazolja. Az eltérés ebben az esetben is kiterjedt tesztelést igényel a felhasználó részéről.

Bármelyik forgatókönyvet is választja valaki, a felkészülést és az esetleges átállást minél hamarabb meg kell kezdeni, hiszen a változás hatályba lépéséig mindössze két hónap van. Utána viszont súlyos összegek foroghatnak kockán.