Red Hat wystawia społeczność linuksową na próbę [OPINIA]

Niedawno Red Hat podjął zaskakującą decyzję o ograniczeniu dostępu do swoich repozytoriów tylko do partnerów. Zablokowało to możliwość budowania własnych wariantów systemu, opartych o RHEL. Robiły tak zarówno otwarte projekty, jak i duże firmy (np. Oracle).

Decyzja o zamknięciu repozytoriów spotkała się z falą krytyki i wieloma emocjonalnymi odpowiedziami. Zaskakująco nerwowo, niemal nieprofesjonalnie, odpowiedziało Oracle. O wiele spokojniejsze oświadczenia wydały projekty Rocky Linux i AlmaLinux, których istnienie jest de facto uzależnione od dostępności Red Hata. Aby jednak zrozumieć sens (i ocenić zasadność) reakcji świata linuksowego na decyzję Red Hata (IBM-a?), należy przypomnieć, jaka jest relacja między Red Hatem, Fedorą, CentOSem i projektami "downstream", przebudowującymi źródła RHEL.

Obecnie, Red Hat wspiera dwa projekty związane z RHEL. Pierwszym z nich jest Fedora. To do Fedory są posyłane wszystkie adaptacje w oprogramowaniu open source, dokonywane przez Red Hata. Fedora jest całkowicie otwarta i taka pozostanie. Red Hat wywiązuje się z wielu swoich zobowiązań GPL właśnie poprzez rozwijanie Fedory. Nowości z Fedory prędzej czy później trafiają do RHEL-a, który okresowo dokonuje migawki i na jej podstawie buduje "zamrożoną" w czasie wersję Enterprise Linux.

Drugim z nich jest CentOS. Niegdyś był to system, który zachowywał binarną zgodność 1:1 z Enterprise Linuksem. Był to "odbrandowany RHEL", niezawierający żadnych składników obsługi klienta i dystrybucji oprogramowania. Zamiast tego stosował płaskie repozytoria, podobnie jak Fedora. RHEL stanowi branżowy standard i jest podstawą na której definiowanych jest wiele standardów i frameworków zabezpieczeń. Dużo projektów rozwijało więc swoje oprogramowanie na CentOSie, zakładając że w "dużych wdrożeniach", zostanie ono osadzone na RHEL-u i odbędzie się to bez niespodzianek.

Dziś CentOS nie zapewnia zgodności binarnej i celuje w funkcjonalną. Rozwija się szybciej niż RHEL, ale wolniej niż Fedora. Ponieważ jednak binarna zgodność ze standardem de facto, jakim jest RHEL, to cenna rzecz, a system ten musi podtrzymywać zgodność z GPL, pojawiły się inne projekty przebudowujące źródła Red Hata - jak Rocky Linux (RL). Jeżeli ktoś chce binarnej zgodności z RHEL-em, może wybrać RL. Red Hat nie narusza w ten sposób GPL - zmiany, których dokonuje, są publikowane w Fedorze.

Poza projektami budującymi się pod zgodność z Red Hatem, podobny proceder uskuteczniało Oracle. Dystrybucja była obsługiwana przez Oracle'a, a wszystkie oraclowe adaptacje były opcjonalne. Lekko przerysowując rzeczywistość, można powiedzieć, że Oracle sprzedawał pracę Red Hata. I ta druga firma właśnie tak zaczęła to widzieć. W zestawieniu ze spostrzeżeniem, że obecność binarnie zgodnych z RHEL-em Linuksów wcale nie przekłada się na wyższą sprzedaż subskrypcji, postanowiono ukrócić ten proceder.

O ile podszyta bezradnym żalem frustracja Oracle'a jest uroczym widokiem, to oddolne projekty jak Rocky Linux, pozwalające programistom budować produkty "dla RHEL-a" bez drenowania projektowego budżetu na licencje, ucierpią wraz z owymi programistami. To może być rynkowo niekorzystne. Co prawda dużo krytyki zaczynało się i kończyło na postulowaniu "sprzeczności z duchem GPL", ale istniały także głębsze argumenty. Jednym z nich jest właśnie utrudnianie życia twórcom niezwiązanego z Red Hatem oprogramowania, które docelowo miałoby pracować na RHEL-u. To bardzo dużo biznesów. Mniejszych i większych.

To jednak wcale nie dowodzi, że decyzja Red Hata jest jednoznacznie szkodliwa. Unaocznia bowiem, czego wiele osób nie chce zaakceptować, że Enterprise Linux stał się standardem - ale wiele społeczności i biznesów nie chce tego zaakceptować. Jeżeli binarna zgodność z RHEL-em jest taka ważna, to dlaczego nie postulować jej jako otwartego standardu? Opieranie się wyłącznie na tym, że jest to oprogramowanie open source, "standaryzuje" RHEL-a jedynie pośrednio. Ale jego powszechne wykorzystanie czyni do standardem de facto.

Red Hat rozwija świat open source, a jednocześnie wydaje górę pieniędzy na stworzenie systemu uznawanego za wyznacznik biznesowej stabilności. Sprzedawanie tak przygotowanego systemu przez inne firmy jednocześnie zwiększa zależność rynku od RHEL-a jako standardu oraz utrudnia dalsze, skuteczne rozwijanie go. Prowadzi to do degradacji jakości.

Poza tym owszem, oddolne projekty pozwalają tworzyć innym programy "dla RHEL-a bez RHEL-a", ale wobec tego oznacza to, że potrzebna jest w świecie linuksowym decyzja: czy standaryzować pod Red Hata niejawnie, pośrednio - czy może przyznać że jest standardem i przepchnąć tę standaryzację w sposób formalny? Uciąć domyślną nieskończoną różnorodność bez powodu. Nie wydaje się, by istniała wola właśnie takiej konfrontacji z rzeczywistością. Los LSB, o wiele bardziej ogólnego standardu niż empiryczna zgodność z RHEL-em, tylko to potwierdza.

A jest o tym trudno dyskutować. Wola zmniejszenia plagi forków i niezgodności, szczególnie motywowana chęcią ustandaryzowania na bazie komercyjnego produktu, jest uznawana za próbę monopolizacji, tłumienia rozwoju i utrudniania kompromisów technologicznych. Jednak brak jednoznacznej definicji platformy prędzej czy później kończy się standardami de facto.

Tak właśnie stało się z RHEL-em. Systemem, który korzysta z bazy open source, ale jego ujednolicenie bierze się z biznesu, a nie ze społeczności. Potrzebna jest więc biznesowa siła pędna, by mógł przetrwać. Red Hat próbuje zadbać właśnie o to. Przez kilka tygodni, które minęły od decyzji o zamknięciu repozytoriów, świat linuksowy jednak się nie zawalił. Teraz taki los powinien mu zagrażać mniej, wcale nie bardziej.