A JavaScript engedélyezve kell, hogy legyen a böngészőn, hogy az oldal minden funkciója megfelelően működjön.
SAM Tools and Services

Pod koniec 2017 roku firma Oracle ogłosiła znaczące zmiany dotyczące Java SE: przejście na półroczne cykle oprogramowania oraz wycofanie bezpłatnego wsparcia dla użytkowników biznesowych. Na co należy się przygotować? Artykuł Tamása Hegedüsa – prawnika, konsultanta ds. licencjonowania w firmie IPR-Insights.

Java logoPod koniec Oracle 2017 ogłosił, że zmodyfikuje zasady licencjonowania Javy SE. Ponieważ niektóre z zapowiadanych zmian wejdą w życie już w przyszłym miesiącu, warto przyjrzeć im się bliżej oraz ocenić ich wpływ. Użytkownicy komercyjni poczują różnicę w dwóch obszarach. Po pierwsze: Oracle przechodzi na półroczny cykl wydań oprogramowania. Po drugie (i co bardziej istotne): od końca stycznia 2019 roku wycofane zostane bezpłatne wsparcie Javy SE 8, a wersja Java SE 11 nie będzie już mogła być bezpłatnie wykorzystywana do celów komercyjnych.

Te informacje niosą za sobą duże zmiany, jako że w dzisiejszych czasach Java jest jednym z najpopularniejszych języków i platform programowania.

Java w skrócie

Swoją popularność zawdzięcza koncepcji „Write once, run anywhere”: wystarczy raz napisać kod, który następnie działać będzie na wszystkich urządzeniach z Javą.

Platforma od 2007 roku jest licencjonowana na podstawie GNU / GPLv2 + CE (GNU General Public License v2 z Classpath Exception). Licencja umożliwia między innymi swobodny dostęp do kodu źródłowego, jego używanie i modyfikowanie. Zmiany te powinny zostać opublikowane jako otwarte źródło. Jednak klauzula CE pozwala również na publikowanie aplikacji opartych na platformie jako zamknięte, więc w przeciwieństwie do „otwartego” GPL licencja nie jest wirusowa. Podobnie jak w przypadku platformy Linux, istnieje kilka dystrybucji, które mogą być licencjonowane nawet w sposób komercyjny. Wśród deweloperów platform znajdują się Oracle, IBM, Red Hat, SAP i Apple, ale także osoby prywatne.

Ważniejsze pojęcia użyte w artykule

JVM (Java Virtual Machine): jest podstawą działania każdego programu napisanego w Javie, tak aby aplikacja napisana w języku Java mogła być uruchomiona.
JRE (Java Runtime Environment): środowisko uruchomieniowe dla programów napisanych w języku Java, składa się z wirtualnej maszyny Javy oraz plików pomocniczych, niezbędnych do uruchomienia programu.
JDK (Java Development Kit): kompletne środowisko programistyczne, umożliwiające programowanie w języku Java; zawiera JRE (a więc także JVM), a także komponenty niezbędne do programowania.
Java SE (Standard Edition): zestaw specyfikacji podstawowych wchodzących w skład platformy Java.
Aktualizacja: pakiety naprawiające błędy w oprogramowaniu.
Wsparcie: oprócz dostarczania najnowszych aktualizacji, obejmuje także inne usługi, takie jak umowne zobowiązanie producenta do sprawdzania i naprawiania zgłaszanych błędów, dotyczących kompatybilności czy bezpieczeństwa.

Najbardziej rozpowszechniona jest dystrybucja Oracle Java SE, i to właśnie tej wersji dotyczą zmiany wspomniane na początku naszego artukułu. Przyjrzyjmy się im więc bliżej!

  1. Cykl wydawania programu

Począwszy od wersji Java 9 Oracle przestawił się z wcześniejszych wersji feature-driven na półroczne cykle wydawnicze. Obsługa takiego wydania trwa pół roku do czasu pojawienia się kolejnej wersji. W tym momencie więc ani wersja 9, ani 10 nie będą już wspierane. Raz na trzy lata Oracle wydaje natomiast także tzw. wersję LTS (Long Term Support) z obsługą przez pięć lat od jej daty pojawienia się na rynku. Obecnie najnowszą wersją jest Java SE 11.

  1. Aktualizacje

Od stycznia przyszłego roku użytkownicy biznesowi nie będą mieli dostępu do darmowych aktualizacji oprogramowania Java 8. Jest to zgodne z wcześniejszą praktyką Oracle. Na przykład do Javy 6 wydanej w 2006 roku bezpłatne aktualizacje przyznawane były do roku 2013, potem już za przedłużone wsparcie gwarantowane do grudnia 2018 rok trzeba było zapłacić. Z Javą 8 sytuacja jest podobna: publiczny cykl życia tej wersji dobiegł końca, żeby otrzymać przedłużone wsparcie niedługo będziemy musieli sięgnąć do portfela.

Począwszy od wersji Java 9, wersje otrzymują aktualizacje dwa razy w ciągu cyklu życia, wersje LTS natomiast kwartalnie. (Tabela poniżej przedstawia cykl wsparcia dla różnych wersji.)

Wersje Oracje Java SE

  1. Licencjonowanie

Oprogramowanie Oracle Java SE do wersji 11 jest dostępne na podstawie licencji BCL (Binary Code License). Ten typ licencji zasadniczo oznacza, że Java może być używana bezpłatnie (zarówno do celów prywatnych, jak i komercyjnych), o ile użytkownik nie instaluje płatnych aktualizacji lub nie używa dodatkowych funkcji (takich jak JavaFX, Jrockit, Mission Control itp.). Ten typ licencji obowiązuje również w przypadku obecnych wersji 6, 7 i 8.

Po wersji 11 Oracle Java SE nie będzie już licencją BCL, ale licencją komercyjną. W związku z tym Java może być używana bezpłatnie wyłącznie do celów programowania, testowania i prezentacji, zgodnie z zasadami licencyjnymi OTN (Oracle Technology Network). Każde inne użycie produktu wymaga płatnego zakupu. Innymi słowy, na przykład aplikacja „Hello world” bazująca na Oracle JDK 11, nie może zostać opublikowana bez zakupu licencji.

  1. JRE

Począwszy od wersji Java 11 JRE nie będzie już niezależny. Celem Oracle jest, aby programiści używali jlink do włączenia komponentów, których potrzebują do działania w swoim oprogramowaniu, a aktualizowanie środowiska Java nie było obowiązkiem użytkownika końcowego (lub Oracle). Pozostaje pytanie, czy Java zapakowana z aplikacją również wymagać będzie licencji.

  1. Ceny

Należy ponownie podkreślić, że Java już wcześniej była dostępna także w modelu płatnym. W przypadku Java SE Advanced i Advanced Desktop czy Suite Edition do tej pory należało uiścić opłatę licencyjną. Każdy, kto już posiada jedną z tych licencji oraz należacy do niej SULS (Software Update License & Support) – choć to raczej rzadki przypadek – nie będzie obciążony dodatkowymi zobowiązaniami płatniczymi.

Oprócz wyżej wymienionych konstrukcji pojawił się również model subskrypcji, subskrypcja Oracle Java SE Desktop bazująca na użytkownikach oraz subskrypcja Java SE oparta na liczbie procesorów (należy uwzględnić w niej również rdzenie procesora).

Spójrzmy zatem na ceny: Cena subskrypcji Oracle Java SE Desktop wynosi miesięcznie 2,5 dolara za użytkownika. Dzięki rabatom ilościowym można ją zredukować do 1,25 dolara.

Cena subskrypcji Oracle Java SE Subscription wynosi miesięcznie 25 dolarów za procesor (za rdzeń/dwa rdzenie). Tutaj również istnieje rabat ilościowy, który może obniżyć cenę do 12,5 USD.

W rezultacie w 200-procesorowym środowisku licencyjnym z 4000 użytkownikami łączna kwota obejmująca wszystkie zniżki wyniesie 11 750 dolarów miesięcznie, w skali roku 141 000 dolarów, czyli ponad 500 000 złotych.

Oczywiście tutaj także zastosowanie ma zasada Jednakowych Poziomów Wsparcia Oracle, więc nie jest możliwe zapewnienie i wykupienie wsparcia tylko dla części środowiska. W przypadku serwerów wirtualnych podstawę licencjonowania stanowi w zasadzie nie tyle liczba procesorów wirtualnych, ale liczba rdzeni działającego fizycznego serwera, którą w przypadku niektórych konfiguracji można zredukować.

W zamian za subskrypcję za pośrednictwem usługi My Oracle Support możemy uzyskać dostęp do środowiska Java SE 11 i jego aktualizacji oraz do niepublicznych (płatnych) aktualizacji Javy SE 8 i wcześniejszych wersji. Ponadto możemy korzystać z płatnych funkcji zawartych we wcześniejszych wersjach, włączając w to również funkcje enterprise management. Oracle także do nich zapewnia usługi wsparcia.

Potwierdza się więc, że Oracle przyszłość Java SE widzi w obsłudze krytycznych aplikacji biznesowych.

Licencjonowanie stało się prostsze

Oracle tym sprytnym posunięciem postanowił ułatwić licencjonowanie Javy SE. W przypadku wcześniejszych wersji problem pojawiał się wraz z kwestią, czy w danym środowisku występują płatne funkcje lub aktualizacje, a jeśli tak, to która płatna funkcja jest aktywna, a aktualizacja zainstalowana. Stwarzało to realne ryzyko, ponieważ użytkownicy innych produktów Oracle mogą uzyskać dostęp do My Oracle Support, gdzie znajdują się wszystkie starsze wersje oprogramowania Java, a wszelkie niepubliczne aktualizacje mogą zostać pobrane niezależnie od tego, czy użytkownik dysponuje odpowiednią licencją. Jednak w przypadku produktu Java SE 11 taki dylemat już nie istnieje, ponieważ nie możemy już w zasadzie mówić o jego darmowym użyciu.

Dla przeciętnych użytkowników stanowi to jednak dużą pułapkę, ponieważ zmiany nie zostały jeszcze zakorzenione w świadomości społeczeństwa. Jeżeli ktoś aktualizuje swoją wersję rutynowo w oparciu o wcześniejszą praktykę, w tym momencie podejmuje poważne ryzyko finansowe. Spodziewamy się bowiem, że Oracle w 2019 roku uruchomi falę audytów ukierunkowanych właśnie na użytkowanie Javy.

Niezbędne kroki możliwe do podjęcia

Na koniec rozważmy niezbędne i możliwe do wykonania rozwiązania, które należy podjąć, aby uniknąć pułapek związanych ze zmianami.

Przede wszystkim przydatne może być wyłączenie automatycznych aktualizacji, tak aby w przypadku użytkowników SE 8 nie zostały zainstalowane płatne pakiety naprawcze przeznaczone dla użytkowników biznesowych. Użytkownicy prywatni nadal bowiem otrzymują bezpłatne aktualizacje do końca 2020 roku, a techniczne rozwiązanie służące rozróżnieniu dwóch rodzajów użytkowników (komercyjnego i indywidualnego) nie jest jeszcze znane.

Następnie możemy przejść do zadań podstawowych. Po pierwsze konieczne jest sprawdzenie gdzie i w jakiej formie Oracle Java SE działa w naszym przedsiębiorstwie. W tej kwestii wskazana jest systematyczna kontrola. Ale uważajmy! Samo sprawdzanie można wykonać za pomocą Oracle Java Usage Tracker, który jest częścią bezpłatnej Javy SE, ale aby dowiedzieć się, czy nie musisz płacić, musisz już zapłacić, ponieważ jest to funkcja płatna (sprawdź punkt Licencjonowanie).

Można również używać niezależnego narzędzia SAM (Software Asset Management). Warto jednak wybrać taki system, który jest w stanie wykryć różne wersje i aktualizacje Javy używane w środowisku operacyjnym. W ten sposób możemy policzyć ilość subskrypcji Java i zobaczyć skąd  należy usunąć program, jeżeli nie został zainstalowany w komercyjnej dystrybucji Oracle.

A teraz omówmy konkretne kroki do podjęcia

Podkreślmy ponownie: zmiany dotyczą tylko Oracle Java SE. Poniżej przedstawimy kilka możliwych scenariuszy dla tych, którzy po styczniu 2019 roku nie zdecydowali się na komercyjną dystrybucję Oracle Java.

  1. Użycie Oracle Java SE 8 lub wcześniejszych wersji: jeśli używasz tej wersji, jest dla Ciebie wystarczająca i nie masz potrzeby jej aktualizować, musisz jedynie wyłączyć automatyczne aktualizacje. W tym wypadku oczywiście należy pozostawić ostatnią wersję dostępną bezpłatnie, należy wziąć jednak pod uwagę możliwe ryzyko związane z bezpieczeństwem i kompatybilnością.
  2. Użycie OpenJDK 11+: tutaj także nie obejdziemy się bez problemów. Zrozumiałe, że Oracle zrobił Javę SE 11 produktem płatnym, ponieważ zbudował wokół tej wersji duży pakiet usług. W przypadku Javy SE i Open JDK wykształciła się więc podobna sytuacja jak pomiędzy RHEL i CentOS. Jak wspomnieliśmy w pierwszej części artykułu platforma Java to GPL, czyli open source. Jednocześnie jej funkcjonalność do tej pory nie była zgodna z Oracle Java SE. Tymczasem firma Oracle, aby pobudzić społeczność open source, dokonała dystrybucji bezpłatnej wersji w ramach GPL2 + CE. Przez pół roku od momentu wydania w poziomie kodu i funkcjonalności jest to odpowiednik płatnej wersji, nawet funkcje komercyjne (jak Mission Control lub Flight Recorder) są częścią OpenJDK.

Jednak po upływie pół roku w momencie pojawienia się nowego OpenJDK, Oracle nie zapewni aktualizacji dla starszej wersji. Istnieją trzy sposoby w przypadku, gdy użytkownik obstaje przy darmowym rozwiązaniu. Za każdym razem może przechodzić do nowej wersji OpenJDK, co w istocie pociąga za sobą ciągłe testy bezpieczeństwa i migrację z powodu krótkiego cyklu życia danej wersji. Może również zaryzykować z nadzieją, że społeczność poprawi wersję. Lub zakupi długoterminowe wsparcie od innych dostawców. Jedno jest pewne: po upływie półrocza Oracle Java SE i OpenJDK nie będą już miały tego samego poziomu kodu.

  1. Użycie innych dystrybucji: Inni producenci i dostawcy usług (np. IBM, Red Hat, Azul lub SAP) również posiadają wersje OpenJDK. Dystrybucje te mogą jednak różnić się w zależności od obsługiwanych systemów operacyjnych lub modułów czy dodatkowych narzędzi, które oferują obok Javy. Mimo wszystko wsparcie dla tych dodatków jest tak samo płatne, jak w przypadku Oracle. Inną kwestią jest to, że aktualizacje dostarczane przez takich dostawców powinny być otwarte ze względu na licencje GPL, to znaczy wcześniej czy później powrócą do głównej rodziny OpenJDK. Niektórzy dostawcy, tacy jak Azul lub Red Hat dokonują tego sami w czasie pojawienia się aktualizacji i udostępnili wolne, przetestowane JDK.

Z OpenJDK użytkownik końcowy może również utworzyć własny pakiet JDK. Wymaga to jednak stałej weryfikacji kodu źródłowego, należy bowiem sprawdzać, kiedy, kto i jaki rodzaj zmiany opublikował. Ogólnie rzecz biorąc nie jest to więc rozwiązanie przyjazne dla użytkownika. Z drugiej strony należy także liczyć się z tym, że aktualizacje i modyfikacje nie przechodzą testów, użytkownik więc musi je przeprowadzać sam. A gdy w działaniu czy kompatybilności pojawi się jakaś usterka- nie mamy u kogo złożyć reklamacji.

Kolejna możliwość to ruch AdoptOpenJDK. Zapewnia on dystrybucje OpenJDK do wielu systemów operacyjnych i stale “przepakowuje” najnowsze zmiany w wersji Java, w tym także najnowsze wspólne aktualizacje zabezpieczeń. Oprócz tego prowadzi także park testowy, w którym testowane są aktualizacje. Dzięki temu AdoptOpenJDK może zaspokoić potrzeby tych użytkowników, którzy do tej pory nie potrzebowali prawdziwego wsparcia, a jedynie aktualizacje produktu.

Zgodność między różnymi dystrybucjami (w tym Oracle) jest teoretycznie zapewniona, jeśli dana dystrybucja przejdzie przez test TCK (Technology Compatibility Kit). Potwierdza on, że wydanie jest zgodne ze specyfikacją SE. Z przyczyn prawnych dystrybutorzy nie mogą zamieszczać tej informacji, używając co najwyżej określenia “SE compatible które sugeruje kompatybilność.

Jedną z głównych wad OpenJDK jest zależność od zgody społeczności, czy dana wersja otrzyma LTS, tj. wsparcie długoterminowe, a jeśli tak, to na jak długo. Na przykład dla wersji 8 (gdzie

OpenJDK nie jest jeszcze zgodny z Oracle Java SE), Red Hat zobowiązał się do aktualizacji i obsługi do 2023 roku, w przypadku Javy 11 do roku 2024.

  1. Amazon Corretto: Amazon również niedawno dołączył do rozwoju OpenJDK i tworzy własną dystrybucję Javy pod nazwą Corretto. Producent zapowiada premierę Corretto 8 w pierwszym kwartale przyszłego roku (wersja przedpremierowa jest już dostępna i działa na AWS). Korzystanie z Coretto na podstawie licencji GPL będzie bezpłatne zarówno w celach prywatnych, jak i komercyjnych. Amazon obiecuje kwartalne aktualizacje (obejmujące ulepszenia wydajności i aktualizacje zabezpieczeń) do czerwca 2023 roku, krytyczne błędy naprawi natomiast “poza kolejką”.

W pierwszym kwartale wydany zostać ma także Corretto 11 (oparty na Open JDK 11), do którego Amazon gwarantuje aktualizacje do sierpnia 2024. Producent zapewnia, że Corretto będzie w pełni kompatybilny z innymi dystrybucjami OpenJDK i Oracle JDK. Spośród wersji Linuxa obsługiwać będzie jedynie własny Amazon Linux 2, tak więc sam produkt jest obiecujący raczej w środowisku desktopowym, ale dystrybutorzy Linuxa sami często dbają o najnowsze pakiety OpenJDK. Zmiany wyszczególnione w tym artykule nie dotyczą użytkowników Linuxa (z wyjątkiem Oracle Linux), na ich komputerach już do tej pory działał OpenJDK.

Trudno opierać się na obietnicach, ale jeśli rzeczywiście nie chcemy dokonywać zakupu wsparcia, za Corretto przemawia fakt, że stoi za nim duża firma, która również sama go używa. Niemniej jednak produkt wymaga uwagi ze strony użytkownika, ponieważ bazy kodu OpenJDK 8 i Oracle Java SE 8 nie są dokładnie takie same, mimo że ich zgodność potwierdzona została przez TCK. W tym przypadku wszelkie odchylenia również wymagają obszernych testów przeprowadzonych przez użytkownika.

Niezależnie od wyboru scenariusza, przygotowanie do ewentualnych zmian w użytkowaniu musimy rozpocząć jak najwcześniej, ponieważ wchodzą one w życie już za niecałe dwa miesiące. Później niestety mogą okazać się kosztowne w skutkach.

Dr. Tamás Hegedüs

Prawnik, w tym roku dołączył do zespołu IPR-Insights Hungary, pracuje jako konsultant ds. licencjonowania.

Dr. Hegedüs Tamás

Dr. Hegedüs Tamás

Your Turn To Talk

This site uses Akismet to reduce spam. Learn how your comment data is processed.