L’annuncio da parte di Red Hat relativo alla restrizione dell’accesso ai sorgenti di Red Hat Enterprise Linux (RHEL) ha causato notevoli mutamenti nel panorama di Linux. Tale annuncio ha portato a tre azioni diverse da parte di tre realtà di spicco: Rocky Linux ha annunciato che cercherà di rimanere un clone fedele di RHEL; AlmaLinux ha comunicato, invece, che prenderà una strada nuova e diventerà una distribuzione separata; SUSE, infine, si è unita al coro (un po’ a sorpresa) annunciando una propria distribuzione derivata di RHEL.
Rocky Linux continuerà a essere un clone di RHEL
“I termini di servizio e gli accordi di licenza all’utente finale di Red Hat impongono condizioni che cercano di impedire a clienti legittimi di esercitare i propri diritti come garantito dalla GPL. Mentre la comunità dibatte se ciò violi la GPL, noi crediamo fermamente che tali accordi violino lo spirito e lo scopo dell’open source. Di conseguenza, ci rifiutiamo di aderirvi, il che significa che dobbiamo ottenere gli SRPM [ovvero i sorgenti che consentono di ottenere i pacchetti software, NdR] tramite canali che aderiscano ai nostri principi e supportino i nostri diritti.” Così scrivono gli sviluppatori di Rocky Linux nel comunicare quale futuro vedono per la propria distribuzione.
Nell’articolo, gli sviluppatori scrivono come sia possibile aggirare le limitazioni imposte da Red Hat. Facciamo, però, un passo indietro: nel chiudere l’accesso ai sorgenti di RHEL, Red Hat ha di fatto reso impossibile (o molto difficile) ricreare distribuzioni cloni, poiché i suoi termini di servizio impediscono di condividere i sorgenti, pur open source, del software. Semplificando, i termini di servizio dicono: i nostri clienti possono condividere i sorgenti del software, ma noi ci riserviamo il diritto di sospendere i contratti in essere e, dunque, di non fornire più aggiornamenti e supporto. Taluni vedono questa limitazione come antitetica a licenze come la GPL e, più in generale, allo spirito stesso dell’open source; altri, inclusa la stessa Red Hat, ritengono che ciò sia legale e lecito.
Il problema principale è che, grazie a ciò, non è più possibile ottenere l’accesso ai sorgenti esatti usati per creare RHEL. L’escamotage trovato da Rocky Linux è semplice: usare le immagini dei container per Docker che Red Hat mette gratuitamente a disposizione di chiunque. L’uso di tali immagini non è subordinato all’accettazione dei termini di Red Hat, pertanto Rocky Linux ha campo libero nell’accedere ai sorgenti necessari. Tali immagini, però, non includono il kernel, pertanto Rocky Linux userà delle macchine virtuali disponibili presso i fornitori di cloud pubblico.
Sebbene più complesso rispetto al passato, questo meccanismo sembra poter garantire a Rocky Linux la possibilità di continuare a mantenere la compatibilità “bug for bug” con RHEL (ovvero, continuano a funzionare anche i programmi scritti per funzionare su RHEL e che si affidano, anche involontariamente, ai bug di quest’ultima per funzionare correttamente).
Ci sono, però, forti dubbi sulla longevità di questo approccio, come notano gli stessi sviluppatori di Rocky Linux. È plausibile, visto l’approccio tenuto fin qui, che Red Hat voglia limitare in futuro tali vie per aggirare i limiti imposti alla redistribuzione dei sorgenti. Resterà da vedere cosa succederà in questo gioco del gatto e del topo in cui non è poi così scontato chi vincerà.
AlmaLinux prende una propria direzione, con alcuni intoppi
Vista la direzione presa da Red Hat, AlmaLinux ha deciso di adottare un approccio diverso rispetto a Rocky Linux e ha annunciato di volersi distaccare dal modello del “semplice” clone per diventare una nuova distribuzione a sé stante. La distribuzione ha comunicato di voler diventare compatibile a livello di ABI con RHEL: in altri termini, il software scritto per funzionare con RHEL funzionerà anche su AlmaLinux, ma quest’ultima non sarà una riproduzione 1:1 di RHEL e diventerà invece una derivata di CentOS Stream.
Ciò porta ad alcuni svantaggi, ma anche ad alcuni vantaggi. Se AlmaLinux non sarà più un rimpiazzo assolutamente perfetto di RHEL, e ci potranno dunque essere alcuni casi limite in cui un programma può esibire un comportamento diverso su AlmaLinux rispetto a RHEL, nella stragrande maggioranza dei casi non ci saranno differenze. Al contrario, questo nuovo corso apre le porte al fatto che AlmaLinux potrà offrire patch e aggiornamenti indipendentemente da RHEL, i cui tempi sono notoriamente piuttosto lenti.
Proprio in quest’ambito, però, si sono già visti alcuni problemi legati al modo in cui Red Hat è organizzata e in cui si relaziona con la comunità. Uno sviluppatore di AlmaLinux ha infatti proposto negli scorsi giorni una patch per il pacchetto iperf3, usato per valutare le prestazioni di rete, solo per vederla inizialmente rifiutata. La motivazione espressa da Michal Ruprich di Red Hat è che “attualmente non abbiamo piani per risolvere questa [vulnerabilità] in RHEL ma terremo la patch per ulteriore valutazione in base al feedback dai clienti.”
Jonathan Wright, che ha proposto la patch ed è attivo nel progetto AlmaLinux, ha quindi chiesto: “davvero la domanda dai clienti è necessaria per risolvere dei CVE?”, aprendo così una lunga discussione su GitLab che è poi sfociata in un commento da parte di Mike McGrath, Vice President of Core Platforms Engineering in Red Hat, in cui è emerso come contribuire a CentOS Stream non sia compito semplice e Red Hat debba fare ancora molto lavoro per aprirsi maggiormente alla comunità e per comunicare meglio quali sono i giusti canali e le corrette modalità per dare il proprio contributo.
Ciò che si è reso chiaro è dunque come Red Hat non sia ancora pronta a gestire il rapporto con la comunità intorno a CentOS Stream e come sarà necessario ancora del tempo perché il meccanismo funzioni senza intoppi, in particolare relativamente alla comunicazione. Una parte consistente della comunità ha però reagito malamente alle risposte di Red Hat e ha puntato i riflettori su un’apparente contraddizione: perché Red Hat ha chiuso i sorgenti di RHEL affermando che la comunità debba collaborare lì dove è possibile, ovvero in CentOS Stream, quando poi non consente (apparentemente) di collaborare dato che rifiuta anche delle patch che correggono delle vulnerabilità?
La verità, come sempre, sta nel mezzo: CentOS Stream è, di fatto, un’anteprima di ciò che sarà RHEL ed è quindi soggetta alle regole e ai processi interni di Red Hat. L’azienda non ha finora dovuto lavorare con contributori esterni, se non in maniera organizzata molto specificamente (con i SIG, special interest group, organismi “ufficiali” che propongono cambiamenti in CentOS Stream e che si possono considerare né interni, né esterni, ma a metà) e non ha dunque dei processi che tengano conto di contribuzioni esterne. L’azienda dovrà necessariamente rivedere alcuni processi e cambiare il modo in cui comunica con i contributori esterni per avere maggiore successo nel gestire i rapporti con la comunità.
SUSE annuncia la propria distribuzione compatibile con RHEL
Ultimo, ma non per importanza, è l’annuncio di un concorrente diretto di Red Hat: l’europea SUSE. L’azienda ha infatti comunicato che investirà più di 10 milioni di dollari per “sviluppare e manutenere una distribuzione compatibile con RHEL e disponibile per tutti senza restrizioni”, aggiungendo che comunque “SUSE mantiene saldo il suo impegno a investire nelle sue soluzioni Linux altamente apprezzate come SLE e openSUSE”.
L’aspetto interessante di questo nuovo progetto è che SUSE sembra collaborare con CIQ, azienda fondata da Gregory Kurtzer, padre di CentOS prima e Rocky Linux dopo. CIQ fornisce servizi di supporto (a pagamento) per Rocky Linux ed è tra i principali sponsor della distribuzione. Ciò che è interessante è che la continuazione di Rocky Linux come distribuzione compatibile “bug for bug” di RHEL dipende dalla possibilità di ottenere i sorgenti del kernel; qualora ciò non dovesse più essere possibile, Rocky Linux potrebbe continuare a ottenere i sorgenti tramite le immagini pubbliche di RHEL, ma dovrebbe poi proporre un proprio kernel in sostituzione di quello di Red Hat.
L’accordo con SUSE potrebbe essere fondamentale in tale senso, perché SUSE ha l’esperienza necessaria per offrire un kernel stabile e con il supporto di livello enterprise che ci si aspetta da una derivata di RHEL. La distribuzione di SUSE, prodotta in collaborazione con CIQ, potrebbe dunque usare un proprio kernel sopra al quale andrebbe a risiedere il resto del sistema basato su RHEL. L’unico possibile ostacolo è rappresentato dai driver di terze parti certificati esclusivamente per RHEL, ma non è improbabile che sia possibile costruire kernel che risultino compatibili.
Nel complesso, dunque, la mossa di Red Hat di chiudere l’accesso ai sorgenti, che aveva l’obiettivo di ridurre la competizione delle alternative gratuite, sembra aver avuto poco successo per il momento. L’unico successo parziale (dal punto di vista di Red Hat) è quello di AlmaLinux, che è diventata una derivata a tutti gli effetti e che intraprenderà un proprio percorso basandosi su CentOS Stream. Rocky Linux continuerà a essere un clone e a lei si aggiunge anche SUSE, nome già molto noto e apprezzato in ambito enterprise. Come diceva Giorgio Galli, Manager Sales Specialist & Solution Architect in Red Hat Italia, durante un evento per la stampa al quale abbiamo partecipato, le conseguenze delle azioni di Red Hat si vedranno più chiaramente entro un anno; se questa è la direzione generale, però, sembra che non tutto stia procedendo secondo i piani. Il che non è necessariamente un male.