Ma már minden érintett tisztában van a Java SE háza táján bekövetkezett legfőbb változásokkal, azaz a JRE, azaz a Java Runtime Environment megszűnésével, és az új Oracle Java licenceléssel (erről korábban itt írtam a Bitporton). Az is világos mindenkinek: valamit tenni kell, hogy továbbra is megfelelhessen a korábbi, és esetlegesen az új licencfeltételeknek. Atombiztos "best practice"  ilyen rövid idő alatt azonban értelemszerűen nem tudott kialakulni a környezet felmérésére és az egyes felhasználások kezelésére.

Ebben a képlékeny időszakban a licencelési területen dolgozó szakembereknek megkönnyebbülést jelentene, ha a lenne a kezükben egy olyan eszköz, ami automatizáltan felmérné és kiértékelné a felügyelt környezet Java használatát. Léteznek ilyen eszközök, de mielőtt felelőtlen keresésbe kezdenénk, nézzük meg, hogyan is néz ki egy ideális Java-felmérés, milyen pontokon kell végigmenni ahhoz, hogy valódi adatokon alapuló, üzleti (és nem utolsó sorban jogi) szempontból átgondolt döntést tudjunk hozni.

1. lépés: az összes Java-telepítés azonosítása

Evidens, hogy a felmérést a Java-telepítések felderítésével kezdjük. De nem elegendő az eszközökön platformtól függetlenül, távolról lekérdezni a java -version parancsot, hiszen ha hibaüzenetre utaló stringet kapunk vissza eredményként, az csupán annyit jelent, hogy az eszközön nincs Java környezeti változó beállítva, nem pedig azt, hogy az eszközön nincs Java telepítés.
 

Példa a fenti hibára: A lekérdezés a környezeti változót hozza, pedig az eszközön több mint húsz JRE/JDK telepítés van!

Windows esetén célravezetőbb lehet például minden eszközön a “java.exe” futtatható állományok keresése, Linux/Unix rendszereken szintén bináris állományokat kell összegyűjteni, lehetőség szerint elérési úttal és tulajdonságlistákkal együtt. MacOS-en elsőre csábító lehet az egyértelműnek tűnő /Library/Java/JavaVirtualMachines mappa, itt viszont csak a csomagfájlokból kifejezetten JRE/JDK-ként telepített környezeteket találjuk, nem pedig az esetlegesen más szoftverekkel együtt települt Javát, így a zártabbnak tartott macOS esetében is az Unix/Linuxnál használt módszert érdemes követni.

Ha megvan a teljes lista, akkor ki kell szűrni belőle az összes olyan környezetet, ami nem az Oracle-től származik, hiszen ezekre a telepítésekre nem az Oracle licencelési szabályai vonatkoznak, és jó eséllyel ezek használata ingyenes (kivéve persze, ha nem Oracle-től vásárolt támogatási szerződésünk van, például Azul Zing). Ugyancsak kiszűrhetők azok a felhasználások, ahol az Oracle Java csak fejlesztési, tesztelési, prototipizálási célt szolgál. (Itt tesztelés alatt nem egy harmadik fél által szállított szoftver megfelelőségi tesztelését értem, hanem a házon belül fejlesztett szoftverek tesztjeit!)

Ha az üzemeltetés során bármikor központilag terítettünk vagy teríteni tervezünk Oracle Java környezetet (értsd: MSI-ből, azaz Microsoft Windows Installerből), akkor az összes ilyen telepítéssel érintett felhasználást vonjuk be a licencelendők körébe, lévén az MSI telepítő használata nem ingyenes.

Jó ha tudjuk, hogy az így kapott listában nem szerepelnek azok a Java környezetek, amelyek beágyazva kerültek szállításra, de ettől nem kell tartanunk, mert a beágyazott Javára egyébként sem a BCL (Binary Code License) vagy az újabb licencelés, hanem egyedi, Fejlesztő és Oracle közötti szerződés vonatkozik. Ettől függetlenül proaktív szoftvergazdálkodásra utal, ha vezetünk nyilvántartást a beágyazott Java-t használó szoftvereinkről.

2. lépés Az összes egyéb Java-t használó alkalmazás azonosítása azokon az eszközökön, ahol Oracle Java környezet is megtalálható

Tudnunk kell azt is, hogy milyen szoftvereket használunk a környezetünkben, de esetünkben azok a legfontosabbak, amelyek Oracle Javát használnak. Erre vonatkozó információkat vagy a telepítési leírásokban, kézikönyvekben találhatunk –vagy a jó öreg “trial and error” metódussal élve egyszerűen kipróbáljuk a működést Java környezet nélkül. Természetesen az ilyen manuális munkát megelőzően ajánlott kiszűrni a teljes listából azokat az alkalmazásokat, amelyek olyan eszközökön is megtalálhatók voltak, ahol egyébként nem találtunk Java környezetet.

3. lépés: a szoftverek forrásának megállapítása

Az első két pontot követően van egy listánk azokról az eszközökről, ahol Oracle Java van használatban, illetve egy lista azokról a szoftverekről, melyek ezeken az eszközökön Javát használnak. A szoftvereket három további kategóriába kell besorolnunk:

– Belső fejlesztések: ilyen szoftver esetében értelemszerűen mi vagyunk a szoftver urai, így rajtunk áll az is, hogy azt hogyan írjuk meg. Mindenképpen vizsgáljuk meg, hogy ingyenes Java-környezet használata befolyásolja-e a szoftver működését, és ha igen, megéri-e ezt a szoftvert Open Java-kompatibilissé tenni. Ha nem éri meg a befektetést, de szükséges, hogy a szoftver a lehető legfrissebb Oracle Javát használja, akkor jelöljük meg az felhasználást licencelendőként.

– Harmadik féltől származó szoftverek: ha a szoftverrel együtt települ a környezet, érdemes lehet a szoftver forrásánál érdeklődni, hogy hogyan kívánja a jövőben ellátni a Java támogatását. Ha az együtt települő Oracle Java már eleve nem ingyenes, mindenképpen kérjünk licencigazolást a harmadik féltől, ami a végfelhasználókat is feljogosítja a Java használatra. Ha a Java licencek biztosításáért szerződés alapján mi vagyunk a felelősek, vagy a szoftver a végfelhasználótól igényli az Oracle Java telepítését, és az előző bekezdésben említett Open Java kiváltás nem megvalósítható, akkor jelöljük meg a felhasználást licencelendőként.
 

– Oracle-től származó szoftverek: az olyan Oracle-termék, melyekkel a Java együtt települ, vagy amelyek Javát igénylnek, az Oracle Java használata ingyenes mindaddig, amíg az Oracle termék maga ingyenes; vagy nem ingyenes, de megfelelően licencelt, valamint csak és kizárólag ez az Oracle termék képes elérni, használni ezt az Oracle Java telepítést.

A klasszikus példa az Oracle SQL Developer. A szoftver ingyenesen használható, és vele együtt települ az Oracle Java 8 legfrissebb verziója (jelenleg 8u242). Viszont ha csak egy helloworld.class fájlt is lefuttatunk ezzel a környezettel (hiába nincs beírva környezeti változóként, hiszen abszolút elérési utat használva bármely Java környezetet elérjük), onnantól a felhasználás már nem ingyenes. Hogy megfelelőségünket biztosítsuk, akár az is megfontolandó lehet, hogy azon az eszközön, amin ilyen Oracle terméket használunk Java-val, ne telepítsünk más, szintén Javát használó szoftvert, vagy más módon garantáljuk, hogy a Java környezet ne legyen elérhető más szoftver számára.

4. lépés: a lista véglegesítése

Már tudjuk, hol használunk Oracle Javát, milyen szoftverekkel, és azoknak mi a forrása. Most el kell dönteni, hogy mi legyen az egyes felhasználások sorsa. Általános igazság sajnos nincs a környezetek és igények sokfélesége miatt, de az alábbi pár sor támpontot nyújthat.

Kivonhatók a listából azok a felhasználások,
• amelyek verzió alapján ingyenesek, és nincs szükség a legfrissebb verzióra;
• amelyek önmagukban ugyan nem ingyenesek, de más szoftver nem tudja elérni ezeket a környezeteket, és nem mi vagyunk felelősek azoklicencelésért;
• amelyeket a meglévő Java licenceinkkel le tudunk fedni.

Végeredményként megkapjuk azokat a felhasználásokat, melyeket licencelelnünk kell, mert például kereskedelmi funkciót (lásd fenti MSI telepítős példát) használtunk, vagy Oracle-től származik a Java, amely felhasználás nem tehető igazolhatóvá a fent leírtak alapján, vagy egyszerűen szükségünk van valakire, aki segít, ha a JVM nem az elvártnak megfelelően működik.

5. lépés: a licencelési szabályok alkalmazása

Mielőtt hátradőlnénk: még mindig csak a licencelendő felhasználásokat hordozó eszközöket ismerjük! Azokat ismét két vagy inkább három alkategóriába kell sorolnunk: szerverek, desktopok, valamint a szerverként és desktopként is működő eszközök.

Szerverként működő eszközökről beszélünk, ha a Java-alapú szolgáltatás távoli felhasználásokat szolgál ki. Ide értendők tehát a Java-alapú felhőszolgáltatások is. Ezekben az esetekben a kiszolgáló hardverkörnyezet processzormagjait kell (on-premise felhasználás esetén faktoráltan) figyelembe venni a licencigény meghatározásánál.

Desktopról beszélünk akkor, ha a Javát használó szoftver közvetlenül az eszköz közvetlen felhasználóját szolgálja ki (értsd: az eszköz előtt ülő embert). Ebben az esetben az összes olyan felhasználót kell összeszámolni, akik a fent meghatározott desktopokat használják, hiszen az Oracle Java desktop oldalon felhasználónként licencelődik.

Találkozhatunk olyan esetekkel is, ahol egy eszköz szerverként és desktopként is viselkedik. Ebben az esetben mindkét típusú licenccel számolnunk kell, hiszen nem szoftvert, hanem felhasználási jogot vásárlunk, egyszer a szerverkénti felhasználásra, egyszer a desktopkénti felhasználásra.

Ha még a virtualizáció is képbe kerül, tovább bonyolódik a kép. Ezzel kapcsolatban most csak az ún. a worst-case scenario-t vázoljuk fel, és figyelmen kívül hagyjuk a felhasználási szerződések világában a szerződéseken kívüli Oracle belső virtualizációs vagy felhőszolgáltatási irányelvek alkalmazhatóságának (és kikényszeríthetőségének) vizsgálatát Az összes olyan, licencelendő Javát futtató virtuális gép alapjául szolgáló fizikai eszköz (on-premise felhasználás esetén faktorált) processzormagját figyelembe kell venni, ahova a virtuális gép mozoghat. Ez olyan, mintha egy parkolóházban az összes helyre jegyet kellene váltanunk, arra való hivatkozással, hogy elméletileg bármely helyre beállhatunk.

Ha virtualizációval kapcsolatos körülmény merül fel, érdemes mozgósítani a más Oracle-termékek használatával megszerzett tudásunkat, és az azoknál alkalmazott belső szabályozásunkat alkalmazni a Javára is. Ha pedig nem vagyunk biztosak ezekben, akkor inkább forduljunk megfelelő szakértelemmel bíró külső tanácsadóhoz.

6. lépés: a végeredmény, de ezzel még nincs vége

Ha jól dolgoztunk, végül megkapjuk azt a valós felhasználó-, illetve processzorlicenc-igényt, amelyet be kell szereznünk az Oracle-től, hogy megfeleljünk a felhasználási feltételeknek.

És akkor térjünk vissza a kiindulóponthoz.Amikor egy Java felmérő eszköz beszerzésén gondolkozunk, mindenképpen érdemes meggyőződnünk arról, hogy a végeredményként megjelenítendő szám megfelelhet-e a valóságnak. Például figyelembe veszi-e a meglévő szerződéseinket, a fejlesztői környezeteinket, és nem csupán az összes fellelt, nem ingyenes Oracle Java telepítésen alapul.

A fent leírt metódus meglehetősen szigorú, de ennek oka van. Mivel az Oracle gyakorlata még nem ismert, érdemes inkább elővigyázatos kalkulációval dolgozni.

Ha a terméktámogatás nem létszükség, megfontolandó megoldás lehet, hogy a jövőbeni Java-alapú felhasználásokat, harmadik féltől származó, Javát használó szoftverfejlesztéseket Open Java alapokon tervezzük/terveztetjük meg. Ez azért is megfontolandó, mert a 11-es verzió óta az Open Java lett a Java platform referenciaimplementációja, és a még mindig népszerű nyolcas (Open Javával nem teljesen kompatibilis) verzió sem lesz örökké támogatott – még akkor sem, ha fizetünk érte.

Másfél év múlva pedig érkezik a platform következő LTS (Long-Term Support), 17. verziója, amikor pedig már nem a 8-11-es, hanem 11-17-es kiadások közötti átállással kell foglalkozni.