Wszystkie teksty umieszczane na Linkedin lub naszych stronach internetowych są naszą opinią. Prosimy nie traktować ich jako porady prawnej w konkretnej sprawie, ponieważ konkretna sprawa zawsze wymaga indywidualnej analizy.
Równo dwa lata temu – 16 kwietnia 2019 roku został opublikowany przez Oracle update JAVA 8 SE o numerze 211 (8u211, 1.8.0_211-b12). Jeżeli ktoś go zainstalował, voilà – przeniósł się do nowego świata, gdzie słowo “bezpłatny” ma bardzo, bardzo ograniczone znaczenie. Kluczem staje się “subskrypcja” – Święty Graal producentów, źródło stałego dopływu gotówki, Jedi vendor lock-inu, finansowa chmura on-premise.
Przez te ostatnie dwa lata trochę się na rynku podziało, choć jak donoszą koleżanki i koledzy z firm konsultingowych, audyty JAVY dopiero ruszają. Zanim dojdą do nas, popatrzmy wspólnie na krajobraz JAVY z kwietnia 2021.
Rok 1995, Sun Microsystems opracowuję wersję beta JAVY, rok później wychodzi JDK 1.0. w modelu – uwaga – własnościowym, takim klasycznym, pod pełną kontrolą producenta. Open source, GNU GPL 2.0, uwolnienie JAVY to dopiero rok 2007. W 2010 Oracle przejmuje Sun Microsystems i z rynku znika ta kultowa marka (uwielbiałem ich logo i załogę polskiego biura). Na transakcję szybko zgadzają się amerykańskie organy do spraw ochrony konkurencji. Więcej uwagi poświęca jej Komisja Europejska, której niepokój wywołują m.in. konsekwencje przejęcia przez Oracle kontroli nad open source’owymi produktami Suna (przede wszystkim MySQL, ale też Java, czy OpenSolaris). Ostatecznie wydaje zgodę na przejęcie. Dla Komisji jednym z kluczowych czynników jest złożona przez Oracle obietnica utrzymania modelu open source otwartego oprogramowania Sun Microsystems, choć nie towarzyszą jej szczegółowe zobowiązania giganta.
W przypadku Javy oznacza to, że Oracle rozdziela linie produkcyjne JAVY na “czysty open source”, czyli Open JDK, nadal na licencji GPL v2 (z tzw. assembly exception i classpath exception, czyli z wyjątkami ograniczającymi “wirusowy” efekt GPL) oraz Oracle JDK, na licencji własnościowej BCL (nie-open source). Licencja BCL niekoniecznie jest darmowa, mimo powszechnej wiary w bezpłatność JAVY.
To nie koniec “linii produktowej”. Pojawiają się czysto komercyjne wersje – w 2011 JAVA SE Advanced i SE Suite, w 2014 SE Advanced Desktop. Co ważne, rozwijają się też tzw. commercial features, dodatkowe, płatne opcje/funkcjonalności (w tym Java Flight Recorder, Enterprise JRE Installer czy Java Usage Tracker). Działają z “darmową” wersją BCL, ale ich uruchomienie zawsze skutkuje obowiązkiem zapłaty (takie opcje, odnosząc się do świata baz danych).
Z prawnego punktu widzenia przeciekawy model – gdyby nie deklaracje towarzyszące przejęciu Sun, Oracle – jako podmiot mający prawa autorskie do JAVA, mógłby zdjąć z rynku wersję open source i powrócić do pierwowzoru z 1995 roku, czyli wersji czysto komercyjnej. Tego się nie dało zrobić, więc zaczął działać w strumieniu open source i rozwiązaniu “własnościowym” (BCL i Advanced). Piękne (prawnie) jest to, że takie rozwarstwienie wersji było możliwe wyłącznie w wypadku Oracle – inne podmioty są wciąż związane GPL v2. Nie mogą więc wziąć kodu na GPL i na jego podstawie wydać “swojej” JAVY na innej, mniej restrykcyjnej licencji. Sytuacja Oracle jest inna. Oracle po prostu ma prawo wydać ten sam kod na różnych licencjach.
Dla pełnego obrazu rynku musimy wspomnieć, że w oparciu o kod open source powstają wersje innych producentów – Red Hat, IBM, Azul etc. Co więcej, każdy może w oparciu o OpenJDK stworzyć własne wersje, nawet tylko do wewnętrznego użytku – zabawa dla dużych organizacji, ale znamy co najmniej jedną firmę w Polsce, która to uczyniła.
Dopóki obowiązywała wiara “JAVA is free” (OK, poza wersjami advanced) ten poplątany rynek był sterowany głównie potrzebami / preferencjami technologicznymi. Od kwietnia 2019 w grę weszli prawnicy (i CFO, i procurment).
Wiele było i jest przekłamań z JAVĄ – od najsłynniejszego hasła “3 billions devices run on JAVA”, które powstało bodajże pod koniec lat 90-tych, więc powtarzanie go jako slogan przez kolejnych 20 lat lat nie ma większego sensu (tak swoją drogą Oracle dziś inaczej to liczy, zgodnie z ich WWW to już “51 bilion JAVA Virtual Machine”). Oczywiście tylko w niewielkiej części przypadków ta JAVA wymagała płatności.
Płatności to właśnie największy mit, jaki się ukształtował. Poza wyraźnie wyodrębnioną wersją Advanced, Open JDK i Oracle JDK (ta na licencji BCL) w powszechnej świadomości się “zlały”. A Oracle JDK na licencji BCL (piszemy o wersji 8.0, jest najpopularniejsza – plus minus 75% rynku JAVY) nigdy nie była zupełnie bezpłatna. Bezpłatne było wyłącznie korzystanie w ramach tzw. “general purpose”. To mgliste pojęcie, jak to w warunkach licencyjnych, oznaczające w przybliżeniu typowe funkcje systemów informatycznych realizowane pod kontrolą użytkownika końcowego, takie jak poczta elektroniczna, przeglądarka WWW czy pakiet biurowy (ale nie funkcje “dedykowane” i nie systemy wbudowane). Ważny dla praktyki był fakt, że Oracle nigdy poważnie tego nie audytował, nie spierał się o interpretację z klientami, więc mało kto się kłopotał tą definicją. Piszemy o tym z kronikarskiego obowiązku, ale też ku przestrodze, bo jak Oracle będzie chciał wrócić do tematu, może to zrobić. Nie wiadomo, gdzie kończy się “ogólne przeznaczenie”, a zaczyna rozwiązanie dedykowane. W pokrętnej trochę interpretacji (ale nie bardzo pokrętnej, trochę pokrętnej) można nawet uznać, że serwery też były poza general purpose.
Większe znaczenie miały jednak wspomniane commercial features, które zawsze były płatne, jednoznacznie i bez wątpliwości (pomijamy indywidualne uzgodnienia, choć widzieliśmy takie). Jak pokazują doświadczenia nasze i zaprzyjaźnionego konsultingu – ten obowiązek zapłaty nie przyjął się powszechnie i wielu klientów używało lub używa tych opcji bez świadomości zobowiązania wobec producenta (lub wręcz bez świadomości, że coś takiego jak commercial features istnieje). Podsumowując – przekonanie o bezpłatności JAVY było w wielu przypadkach na wyrost. Ale jak ktoś konsekwentnie używał OpenJDK, była i jest to prawda.
Jakby zagłębić się w tekst obowiązującej wówczas licencji BCL, trochę przekłamana była także teza, że development był zawsze bezpłatny. O tyle ważny wątek, że akurat przy developmencie “bezpłatność” obejmowałaby także commercial features. W umowach nie jest jasno określone, czy development obejmuje rozwój/usuwanie błędów oprogramowania, które już jest na produkcji, czy obejmuje on jedynie czynności “czystego developmentu”, przed uruchomieniem produkcyjnym.
Do tego dość skomplikowanego krajobrazu faktycznego, kilku dystrybucji i licencji oraz powszechnych mitów dochodzi praktyka. Ponieważ JAVA “jest za darmo”, w organizacjach bywa i tak, że nie ma polityk kontrolujących update’y, definiujących general purpose, planów migracji na rozwiązania konkurencyjne. Kiedy na początku 2019 r. spada bomba w postaci komunikatu o przejściu Oracle na model subskrypcyjny, rynek jest, łagodnie ujmując, zadziwiony i nieprzygotowany.
Co się stało w tym dniu? Jeżeli używasz OracleJDK (cały czas się trzymamy wersji 8.0), pobranie i korzystanie z update’u 8u211 oznacza konieczność przejścia na nowy model licencji. W wielu publikacjach można znaleźć opinię, że ta nowa licencja to tzw. licencja OTN (Oracle Technology Network License) i pojawia się hasło “Java is still free”. I to kolejne uproszczenie w świecie wielu uproszczeń. Bo faktycznie licencję BCL zastąpiła licencja o nazwie Oracle Technology Network License Agreement for Oracle Java SE. I licencja ta rzeczywiście pozwala na bezpłatne korzystanie z Oracle JDK. Różni się jednak zakres, w jakim jest do możliwe. Jest on wyraźnie węższy niż w przypadku BCL. Ale wykroczenie poza te wąskie przypadki bezpłatności oznacza konieczność zawarcia licencji OMA.
Rzućmy okiem na OTN for JAVA SE. To – żeby było trudniej – inna licencja niż znana wcześniej “ogólna” licencja OTN, która pozwalała na komercyjne użycie objętego nią oprogramowania. OTN for Java SE obejmuje wyłącznie “Personal Use”, “Development Use” (trochę inaczej ujęte niż w BCL), “Oracle Approved Product Use” i “Oracle Cloud Infrastructure Use”. O tych dwóch ostatnich przypadkach dziś mniej (w uproszczeniu – załączniki wymieniają produkty, które mają “opłaconą” Javę w swojej licencji, podobnie infrastruktura chmurowa Oracle, czyli OCI), natomiast warto bliżej przyjrzeć się “Personal Use”.
“Personal Use” w OTN for Java SE zastępuje “general purpose” znane z BCL. Ma jednak znacznie węższy zakres, bo odnosi się wyłącznie do korzystania przez osobę fizyczną na komputerze stacjonarnym lub przenośnym będącym pod kontrolą takiej osoby, w celu uruchamiania aplikacji przeznaczonych tylko do użytku osobistego, takich jak na przykład gry. Jeżeli wychodzimy poza użytek prywatny, potrzebujemy licencji OMA i modelu subskrypcyjnego. A kiedy wychodzimy? Jeżeli wykorzystujemy JAVĘ (Oracle JDK oczywiście) na serwerze (już bez żadnych wątpliwości), na komputerach stacjonarnych lub przenośnych zarządzanych przez organizację (a nie przez osobę fizyczną korzystającą z Javy w ramach “personal use”), w jakiejkolwiek aplikacji która oferuje funkcje wykraczające poza ów użytek osobisty.
Licencja z pewnością nie posługuje się w 100% klarownym językiem. Niby cele komercyjne nie zostały wyraźnie wykluczone, ale praktycznie każde użycie Oracle JDK w organizacji czy w ramach działalności gospodarczej, to nie „Personal Use”. Czyli, użycie aplikacji Java do rozliczania podatków osobistych – tak, do prowadzenia księgowości – nie. To duża zmiana – BCL zezwalała na korzystanie z szeregu powszechnych aplikacji, jak e-mail czy “office suite productivity tools” (cytat z umowy BCL), nawet w ramach prowadzonej działalności. Teraz nie – musimy mieć opłaconą licencję albo przez nas, albo przez dostawców rozwiązania. Chyba jedyną zaletą zmiany modelu licencyjnego jest zniknięcie commercial features, które zostaną zastąpione “pełną” licencją komercyjną. Cały czas bezpłatny pozostaje development, trochę definicyjnie zmieniony, ale z podobnymi problemami interpretacyjnymi, jak w wersji BCL (kiedy się kończy, kiedy zaczyna).
W praktyce: jak masz firmę i zainstalowałeś update 211 – płać. I tu pojawia się złowieszcza cecha nowego modelu – nie ma już dobrych, wieczystych licencji, są tylko licencje okresowe, zasadniczo roczne. Kolejny mit, że płatne stały się “update’y”, serwis JAVY. Nic z tego. Płatna stała się możliwość korzystania z JAVA, która to możliwość jest “zespolona” z serwisem. Przestajesz płacić, to nie tylko tracisz prawo do patch’y, ale twoja komercyjna licencja wygasa i dalej z oprogramowania korzystać nie możesz. Jak wspomniałem – konstrukcyjnie dla producenta to ideał. Dla użytkowników – wady modelu chmurowego połączone z wadami on-premise (tak, wiemy, to też uproszczenie).
W modele i metryki licencyjne dziś głębiej nie wchodzimy – stosujemy tradycyjny model licencyjny Oracle. Jest więc NUP, są stare dobre procesory dokładnie z tymi samymi wyzwaniami wirtualizacji, jak bazy danych. Teoretycznie może być ULA. Żadnych specjalnych zasad, poza tym, że – jak wyjaśnia cennik Oracle – przy definicji NUP termin serwer odnosi się również do komputera typu desktop i (o ile dobrze to czytamy) nie ma obecnie minimalnych wartości NUP dla JAVA SE Desktop Edition. W praktyce policzenie tego czego potrzebujemy staje się wyzwaniem, zwłaszcza przy desktopach i konieczności pomieszania metryk procesorowych z użytkownikami nazwanymi. A ponieważ użytkownikiem nazwanym, zgodnie z OMA, jest także “non-human device” robi się gorąco. “Rekord” naszego klienta to roczne opłaty na sporo ponad 1 mln euro (oczywiście po tym wyliczeniu zoptymalizował infrastrukturę). A, jeszcze jedno – znikąd to nie wynika, ale już się spotkaliśmy z przypadkiem, gdy Oracle odmówił nam sprzedaży NUP na serwery.
Pierwsza – ucieczka (do dziś dominuje w komentarzach na LinkedIn). Niby jest prosta, z Oracle JDK do OpenJDK, ale jak weźmiemy pod uwagę sposób utrzymania, patch’owania, realną konieczność upgradu co pół roku pełnego OpenJDK, w wielu, w wielu przypadkach (np. duża część sektora regulowanego, jak finanse) nie jest to opłacalne. Można uciec jeszcze dalej, np. do IBM-a czy do Azula[1]. Ta dalsza ucieczka jest niejednokrotnie determinowana ograniczeniami technologicznymi i właściwoścami konkretnych aplikacji Java Javie nierówna. Wersje najdalej idące to opuszczenie świata Javy, a oferta alternatyw, zwłaszcza dostawców chmurowych, jest bogata.
Druga, o ironio, okazuje się dość popularna i nader skuteczna – likwidacja nadmiarowej JAVY. Plus wprowadzenie polityk co, kiedy, wolno patch’ować etc. Część rozwiązań nie wymaga aktualizacji, części można się pozbyć. Takie javowe porządki.
Trzecia, niedoceniana, ale chyba o największym znaczeniu i najbardziej korzystna – mapa produktów i dostawców, którzy opłacają JAVĘ. Od produktów Oracle (załącznik w OTN for Java SE – Oracle Approved Product Use – Forms, WebLogic, E-Business Suite, ale także zasadniczo bazy danych itd.) przez IBM (websphere), VMware, aż po dostawców lokalnych aplikacji. Oczywiście, trzeba sprawdzić i trzeba się upewnić, że taka JAVA jest wykorzystywana tylko na potrzeby tych produktów, w takiej wersji, jaką opłaca dostawca, ale to naprawdę sporo przypadków. U wielu klientów słychać było głośne “uff”, jak okazało się, że 75% ich JAVY już ma pokrycie właśnie w tym modelu. To wymaga dobrego self-audytu – o czym niżej.
Czwarta – negocjacje i zakup. Można przez Internet, można w teorii od partnerów. W teorii, bo jak jesteście dużą organizacją i jednocześnie chcecie kupić nie tak dużo tych licencji, jest szansa, że Oracle zaproponuje “pomoc” w określeniu “optymalnej liczby” licencji, odmawiając sprzedaży kanałem partnerskim. Właśnie przerabiamy takie przypadki. Ale oczywiście zakup może mieć sens, czasami nawet wielki. Bywa tak, że jak zaudytowaliśmy klienta, to skala użycia commercial features była tak wielka, że zakup subskrypcji, “w zamian” za odpuszczenie grzechów, był opłacalną opcją. Nie ściczyliśmy jeszcze ULA na Javie, gdyby ktoś miał taki przypadek, proszę dać znać.
Jest jeszcze kilka bardziej wyrafinowanych scenariuszy (zawsze mile widziana przez Oracle migracja do chmury OCI, rozwiązania “out of the box” jak niezależny support na starych licencjach), ale sensowna decyzja dotycząca tego, co dalej jest możliwa wyłącznie po self-audycie. To kilka kroków:
To wymaga czasu, plus minus 3 – 6 miesięcy, warto rozważyć te prace zanim zapuka audyt. Scenariusz najgorszy to niekontrolowana, powszechna, serwerowa i desktopowa migracja na wersje subskrypcyjne bez ich opłacenia. To nie tyle problem finansowy, jak w przypadku przekroczenia metryk licencyjnych czy sławnego indirect use, co dość poważne naruszenie prawa autorskiego. Mechanizm zmiany licencji został dobrze przemyślany przez Oracle. Przede wszystkim formalnie nikt nie zmienił żadnych zawartych umów (wersje starsze niż u211 nadal są dostępne na BCL). Po prostu od update 211 “klikane” warunki licencyjne pozwalają na mniej, niż w przypadku wcześniejszych wersji. Jeżeli organizacja nie mieści się w nowych zasadach, nie ma prawa korzystać z Oracle JDK chyba, że zawrze oddzielną umowę licencyjną, w której zezwolenie na takie korzystanie się znajdzie. Zapewne sposób komunikacji zmiany mógłby być bardziej czytelny, a dokumenty licencyjne bardziej klarowne, ale Oracle mógł taką zmianę wprowadzić i z możliwości tej skorzystał. A my pozostajemy z wrażeniem, że rozwiązanie komercyjne, za którym stoi wielka firma, okazało się mniej stabilne prawnie niż open source.
[1] Jedna ze znalezionych statystyk z maja 2020 https://sdtimes.com/java/report-80-of-oracle-jdk-users-considering-alternative-support-options/ – Oracle JDK w dół o 36%, Open JDK wzrost o 36%, Azul plus 3%.
ADDENDUM: JAVA i prawo to nie tylko problemy związane z operacją “16 kwietnia”. O przeciekawym i ważnym dla branży sporze pomiędzy Oracle a Google, dotyczącym Javy i Androida można poczytać w naszym poprzednim artykule.