JAVA – zmiany w modelu licencjonowania oraz dostarczania aktualizacji

POCZĄTEK, CZYLI DISCLAIMER

Zajmujemy się licencjami od lat, ale model licencyjny i utrzymaniowy ORACLE JAVA nadal nam imponuje. Ze względu na różnorodność i powszechność produktów, modeli dystrybucji, umów czy umieszczonych w nich kreacji prawnych jest to pole minowe dla każdego prawnika i license managera.

Na tę siatkę niejasności nakłada się jeszcze dotychczasowa praktyka, w dużej mierze, no cóż, optymistyczna, oparta na przekonaniu, że JAVA is free – co nie zawsze jest prawdą. Postaramy się omówić główny nurt zmian. Nie jest to pełna analiza – celowo odpuszczamy sobie wątki takie jak szczegóły JAVA Advanced. To raczej wskazanie kierunku, w którym poszedł Oracle, opis najważniejszych konsekwencji i kilka naszych przemyśleń dla użytkowników.

Materiał oparty został na naszej analizie, kopalni wiedzy z Google (różnej jakości), materiałach Gartnera i podobnych firm (z reguły przedniej jakości), a przede wszystkim pomocy kilku zespołów związanych z Oracle i JAVĄ oraz wielu rozmów z naszymi kolegami i koleżankami z firm audytorskich i doradczych z Europy i USA, którzy podzieli się swoimi doświadczeniami.

Za wszystkie te rozmowy serdecznie dziękujemy – ciekawe, że cały czas wzajemnie umiemy się zaskoczyć, co tylko pokazuje, z jak trudnym i niejednoznacznym modelem mamy do czynienia.

TELEGRAFICZNY SKRÓT DLA TYCH, KTÓRZY NIE MAJĄ CZASU CZYTAĆ CAŁOŚCI.

JAVA SE 8, czyli najpopularniejsze wydanie licencjonowane przez Oracle, była oprogramowaniem co do zasady darmowym. Każdy mógł ściągnąć i używać komponentów JAVA, a obowiązek zapłaty pojawiał się w przypadku użycia tzw. commercial features. Można też dywagować o konsekwencjach wykroczenia poza tzw. general purpose. Darmowe były także aktualizacje (choć już nie cały support).

Całość JAVA SE 8 była licencjonowania na licencji OBCL, którą zapewne mało kto czytał (taki los licencji „klikalnych”). Warto do tego tekstu wrócić, gdyby pojawiły się zarzuty licencyjne.

Tak było do stycznia tego roku. Ostatni patch w starym modelu nosi numer 202 i pochodzi właśnie ze stycznia. Po nim wszystko wymaga – w skrócie – opłaty.

W większości przypadków będzie to oznaczać konieczność zawarcia umowy z Oracle na nowych warunkach – zmienia się zarówno treść licencji (OBCL zamienia się w OTN, choć w grę wchodzi jeszcze stara, dobra OMA, nigdzie o tym ani słowa, ale jak przeszliśmy proces zakupu subskrypcji, pojawiła si e ona na końcu zamówienia), model licencji (z perpetual na subskrybcję, czyli taką prawniczą chmurę on premise), jak i model opłat.

Nowa licencja dla celu obliczenia opłat wykorzystuje całą paletę rozwiązań Oraclowych – per user, per procesor (wirtualizacja!) i rozwiązania unlimited. Trzeba dostosować najlepsze rozwiązanie do konkretnej architektury.

Subskrybcja (nowy model) nie jest jedynym wyjściem – prawa do JAVY mogą wynikać z innej umowy z Oracle (np. z WebLogic, jeżeli użycie java jest powiązane z z tym oprogramowaniem) lub umowy z innym producentem, który wcześniej porozumiał się z Oracle i zapewnia wsparcie.

W skali rynku są to jednak wyjątki, większość ma licencję OBCL i musi coś z tym zrobić.

Kluczem w rozumieniu nowej licencji OTN jest pojęcie „commercial use”.

JAVA jest nadal darmowa do użytku prywatnego, developmentu, testowania, prototypów i demo, ale wszystko inne – czyli ów commercial use – jest płatne. Dotyczy to te także rozwiązań JAVA „zaszytych” w innych aplikacjach – jeśli np. podpis elektroniczny ma komponent JAVA, może okazać się, że korzystając z niego, musimy zapłacić Oracle’owi. Sky is the limit.

Podsumowując – badamy nasze środowisko. sprawdzamy, czy wchodzimy w zakres „commercial use”. Jeśli tak, a chcemy korzystać z aktualizacji, musimy podjąć decyzję.

Rozwiązań jest kilka:

Pierwsze to nie robić nic i zostać przy aktualizacji 202, nie korzystając z dalszych wydań.

Drugie – kupić subskrypcję (OTN + OMA) lub zawrzeć inną umowę, która zapewni prawo do aktualizacji.

Trzecie – przemigrować na OpenJDK od Oracle lub innych dostawców, przy okazji oglądając ich warunki licencyjne, bo nawet open source może być wymagający (na pewno chcecie zarazić swoje rozwiązanie wirusem GPL?). Przy rozwiązaniu trzecim warto uważnie przyjrzeć się polityce update’ów, bo może okazać się – tak jest przy wersji open od Oracle – że wymusza to określony cykl migracji do nowych wersji (np. co pół roku).

Czwarte rozwiązanie to zrezygnować z JAVY (nie, to nie jest dowcip – wielu klientów odkryło niepotrzebne instalacje, które najprościej usunąć).

Co się stanie? Zapewne prędzej czy później przyjdzie audyt. Najgorsze rozwiązanie to ściągać kolejne wersje bez strategii i modelu zarządzania. Jednym słowem – zakaz aktualizacji Javy bez opracowanej strategii.

Przewidujemy trzy obszary sporów:

  • oczywiste naruszenia, które będą częste – ściąganie nowych wersji w celu komercyjnego wykorzystania i niedoczytanie nowego modelu licencyjnego, czyli działanie „na pamięć”. Szczególnie groźne przy licznych pracownikach, z których każdy może sobie JAVĘ sam aktualizować. Tu mogą się też znaleźć tysiące klientów, którzy nawet nie wiedzą, że korzystają z rozwiązań Oracle – głównie w związku z innymi aplikacjami (na marginesie, warto ten element opisać w umowie z dostawcą aplikacji i np. przerzucić na niego ciężar opłat).
  • szara strefa, czyli działania na granicy „commercial use” czy też korzystanie z rozwiązań JAVA zaszytych w innych aplikacjach. To każdorazowo będzie wymagało namysłu.
  • bardzo szara strefa, czyli dobrze znany problem wirtualizacji, teraz z udziałem JAVA, a nie tylko baz. W wielu przypadkach do obrony.

Co robić?

Po pierwsze, wiedzieć, czy się JAVĘ ma, w jakiej wersji i na jakiej postawie prawnej (mapa umów).

Po drugie, zdecydować, która zostaje, która migruje do open source’a, która jest zbędna i idzie do odinstalowania.

Po trzecie, zdecydować, czy JAVA od Oracle, która została, potrzebuje nowych wersji i aktualizacji.

Po czwarte, rzucić okiem na całą architekturę, w tym wirtualizację. Po piąte, raz jeszcze porównać to z mapą uprawnień i w razie potrzeby dokupić co trzeba – lub cofnąć się do kroku numer dwa.

NASZA TROCHĘ DŁUŻSZA ANALIZA

Co się stało?

Po długich latach bezstresowego korzystania z produktów Java SE, które powszechnie (choć niekoniecznie poprawnie) postrzegane były jako darmowe, a co za tym idzie niegenerujące ryzyka audytowego, komfortowa dla użytkowników sytuacja uległa zmianie. W największym skrócie: korzystanie z Javy SE 8 i aktualizacji (update’ów oraz aktualizacji bezpieczeństwa) będzie wymagało comiesięcznych opłat subskrypcyjnych. Najnowsza wersja typu LTS (Java SE 11) dostępna jest od początku (co do zasady – patrz disclaimer) wyłącznie w modelu subskrypcyjnym.

Zmiany dotyczą dwóch kluczowych obszarów: modelu licencjonowania oraz modelu dostarczania aktualizacji.

Dotykają one bardzo szerokiego grona podmiotów, wśród których znajdują się m.in. developerzy, vendorzy rozwiązań IT oraz użytkownicy aplikacji dostarczanych przez osoby trzecie. Poniżej przedstawiamy wysokopoziomowe podsumowanie najistotniejszych kwestii, na które podmioty z wyżej wymienionych grup powinny zwrócić uwagę w ramach działań związanych z zarządzaniem licencjami.

Perspektywa licencyjna:

Dotychczas produkty Java dostarczane przez Oracle licencjonowane były w ramach licencji wieczystej (perpetual), a patche i update’y zapewniano nieodpłatnie (z wyjątkiem specyficznych produktów, w tym tzw. commercial features, np. Java Flight Recorder, Java Mission Control). Warunki licencyjne zawarte były w Oracle Binary Code License Agreement (OBCL).

Wraz z wprowadzeniem modelu subskrypcyjnego OBCL zastąpiono nową umową licencyjną – Oracle Technology Network License Agreement (OTN). Wersja SE 8 do stycznia br. działała na licencji OBCL i jeżeli ktoś korzysta z wersji sprzed stycznia, nadal jest związany tą licencją. Warto nadmienić, że w procesie składania zamówienia na JAVĘ zostaniemy także zmuszeni do zaakceptowania umowy OMA (acz wygląda na to, że bez Price Listy, czyli bez definicji procesora, co może mieć kluczowe znaczenie przy określaniu ilości licencji potrzebnych na maszynach wirtualnych).

Chcąc skorzystać z kolejnych edycji SE 8 (tych po patchu 202), nowi użytkownicy nie mają już możliwości zawarcia umowy OBCL. Jedynym modelem, z którego mogą skorzystać, jest model subskrypcyjny (tak jak dla wersji 11), w ramach którego mają zapewnione uprawnienia licencyjne na podstawie umowy OTN, aktualizacje oraz support dla wszystkich produktów Java SE. W konsekwencji zniesiono rozróżnienie na komponenty komercyjne (commercial features) oraz niekomercyjne, co nastręczało użytkownikom sporo problemów i było częstym zarzutem audytowym. Subskrypcja jest płatna miesięcznie, według metryk NUP lub procesora (możliwy jest model unlimited), przy czym umowa zawierana jest na co najmniej jeden rok. Wybór metryki to już decyzja architektoniczna i biznesowa.

Poniżej krótkie porównanie starych i nowych warunków licencyjnych:

  • Korzystanie z komponentów Java SE (w tym z commercial features) w celach developerskich, testowych, demonstracyjnych oraz w celu prototypowania jest w obu licencjach bezpłatne. Zastosowanie szersze, w tym jak to opisuje OTN „w celach przetwarzania danych, działaniach komercyjnych, produkcyjnych lub wewnętrznych działaniach biznesowych innych niż cele developerskie (itd.)” (jak widać przestrzeń do interpretacji jest tutaj szeroka), wykracza poza zakres uprawnień (ergo – wymaga odrębnego, odpłatnego licencjonowania);
  • Umowa OTN nie rozróżnia (tak jak robiła to OBCL) korzystania w ramach general purpose computing oraz non-general purpose computing (stanowiących zresztą jedne z trudniejszych do interpretacji pojęć w ramach umowy OBCL). Kluczowy staje się cel korzystania (komercyjny albo niekomercyjny) – nadal nie jest to jasna definicja, ale wydaje się, że cel komercyjny ma szerszy zakres niż „general purpose”;
  • W ramach licencji OTN „dystrybucja, przekazanie lub transfer” (tu znowu pojęcia niedookreślone) nie są dozwolone, podczas gdy były one zgodne z warunkami OBCL przy spełnieniu odpowiednich warunków;
  • Obie licencje nie zezwalają na „modyfikowanie programów Java”.

W skrócie – jeśli chcemy korzystać z Java by Oracle w celach innych niż wprost dopuszczone umową OTN, musimy :

  • wykupić subskrypcję,
  • być uprawnieni do tego w ramach innej, odrębnej umowy z Oracle (samoistnej, jak model Advanced, lub zawartej w celu korzystania z innego produktu Oracle, jak np. WebLogic),
  • posiadać uprawnienie wynikające z umowy z innym dostawcą, który w ramach swego produktu dostarcza Oraclową Javę (np. w części produktów VMware).

Oczywiście innym rozwiązaniem jest przejście na open source, w tym produkty firm trzecich (np. IBM, SAP, Azul etc.).

Aktualizacje:

Od stycznia 2019 r. aktualizacje do SE 8 oraz kolejnych wersji zaczynają być płatne w ramach modelu subskrypcyjnego (łącznie z licencją, podobnie do modeli chmurowych). Erę darmowych aktualizacji JDK 8 zamknął opublikowany 15 stycznia 2019 r. Critical Patch Update 8u201 oraz związany z nim Patch Set Update 8u202, natomiast update zapowiadany na 16 kwietnia 2019 r. (8u211 oraz 8u212) będzie dostępny jedynie dla uprawnionych użytkowników w ramach nowej licencji OTN1.

Tutaj sprawa jest prosta – jeżeli kolejne wersje nie są potrzebne, można zostać przy wersji 202. Jeżeli ktoś ściągnie cokolwiek wydanego po styczniu 2019, zmaterializuje się ryzyko opłat subskrypcyjnych (chyba że – jak opisano powyżej – ma inną podstawę prawną do JAVY, np. w ramach WebLogic czy innej umowy).

Kto nadal może korzystać z Javy bezpłatnie?

Mając na uwadze zmiany w modelu licencjonowania oraz dużą niepewność w zakresie interpretacji poszczególnych zapisów oraz informacji publikowanych przez Oracle, należy przyjąć, że jedynymi użytkownikami, co do których nie ma wątpliwości, że mogą korzystać z Oracle Java SE bezpłatnie, są tzw. teamal users (Oracle deklaruje darmowe wsparcie Javy 8 dla podmiotów korzystających z aplikacji typu B2C co najmniej do 2020) oraz podmioty korzystające z Javy w celach developerskich, testowych, demonstracyjnych lub w ramach prototypowania na podstawie licencji OBCL lub OTN.

Podmioty wykorzystujące Javę (w wersjach po 202) na szeroko pojętych środowiskach komercyjnych powinny liczyć się z koniecznością wykupienia określonych licencji (user/procesor), których liczba musi zostać oszacowana w ramach szczegółowej inwentaryzacji.

Co dalej?

Aby zabezpieczyć się przed ryzykiem związanym z korzystaniem z oprogramowania Oracle w sposób nieuprawniony oraz wypracować optymalny dla organizacji model korzystania z Javy w przyszłości, należy odpowiedzieć sobie na szereg pytań, w tym m.in.:

  • Czy korzystam z produktów Oracle Java (tu do rozważenia dostępne narzędzia do wykrywania Javy w systemach; uwaga na narzędzie Oracle Usage Tracker – samo w sobie zawiera ono komponenty płatne)?
  • Z której wersji Javy korzystam, w jakim celu i w jakim zakresie (inwentaryzacja)?
  • Czy używane są tzw. commercial features (w przypadku wersji 8 odrębnie płatne także przed styczniem 2019 – jak ktoś nie płacił, może to wyjść przy audycie)?
  • Co jest podstawą prawną do używania oprogramowania – licencja OBCL, OTN, GPL, uprawnienia związane z korzystaniem z innego produktu Oracle, jak np. WebLogic, lub z korzystaniem z rozwiązań innych dostawców, takich jak IBM, Azul, SAP etc.?
  • Czy niezbędne są aktualizacje (w tym konieczność zbadania ryzyk związanych z brakiem aktualizacji bezpieczeństwa)?

W zależności od udzielonych odpowiedzi (a pełna lista pytań jest jeszcze dłuższa) możliwe będzie określenie potencjalnych braków licencji i podjęcie decyzji co do dalszych kroków.

Obecnie dostępne podstawowe scenariusze działania to:

  • Korzystanie z aktualizacji Oracle – odpłatnie w celach komercyjnych;
  • Korzystanie z Oracle OpenJDK – bezpłatnie na licencji GPLv2+CE, jednak z (realną) koniecznością dokonywania samodzielnych update’ów co sześć miesięcy;
  • Korzystanie z usług dostawców zewnętrznych (Independent Software Providers) – na warunkach uzależnionych od dostawcy; przy migracji do innego dostawcy uwaga na certyfikaty TCK/JCK oraz na ograniczony czas świadczenia wparcia dla takich rozwiązań;
  • Utrzymywanie Javy samodzielnie – bezpłatnie, jednak dla większości organizacji to mało realna opcja.

Zobacz inne artykuły autorów