Rocky Linux ha un piano per sopravvivere alle scelte di Red Hat sulla pubblicazione dei sorgenti di RHEL

27

Dopo l’annuncio da parte di Red Hat del termine della pubblicazione dei sorgenti dei pacchetti RHEL su git.centos.org, dopo l’indignazione della community e dopo la reazione di AlmaLinux (una delle principali vittime della scelta di Red Hat), ecco aggiungersi al dibattito Rocky Linux, la distribuzione creata dal fondatore di CentOS Linux proprio in seguito alla “chiusura” di CentOS.

Brave New World: The Path Forward for Rocky Linux, è così che si intitola il blog post apparso sul blog di Rocky Linux nel quale vengono esposte le strategie di sopravvivenza della distribuzione derivata di RHEL.

All’interno del post sono indicati gli instancabili sforzi compiuti dal team per far fronte allo stato delle cose e, ad oggi, è stata completata la composizione degli aggiornamenti sia per Rocky Linux 8 e 9, inclusi tutti gli aggiornamenti che erano mancanti e che sostanzialmente avevano fatto capire come qualcosa non stesse andando nel verso giusto all’interno del consolidato sistema di build (ovviamente era il fatto che i pacchetti SRPM non fossero presenti in git.centos.org).

Di fatto se avete Rocky Linux, digitando yum -y update oggi aggiornerete la distribuzione nella consueta modalità 1:1 con RHEL.

La maggioranza di questi iniziali allineamenti è però frutto di un lavoro manuale, ed è chiaro come sia nell’interesse del progetto Rocky strutturare un processo che continui a fornire gli aggiornamenti man mano che questi vengono rilasciati.

La soluzione a tutto questo pare risieda nel sistema di compilazione di Peridot che veniva già utilizzato da Rocky Linux per gestire le importazioni aggiuntive e automatizzarle. A compendio di questo il progetto sta lavorando ad un sistema di pubblicazione degli SRPM utilizzati, le patch applicate, i checksum applicabili e così via.

A detta dello stesso articolo ci sono netti margini di miglioramento, poiché il lavoro attuale è più manuale rispetto ai processi precedenti, ma, e questo è l’aspetto rilevante, questo rispetta gli accordi di licenza.

Perché, è bene continuare a ricordarlo, il problema principale delle derivate come Rocky Linux è che ora che i sorgenti sono disponibili solo per i clienti paganti di Red Hat, questi hanno un vincolo sul loro utilizzo, limitato sostanzialmente alla ricompilazione in proprio di RHEL e non verso altri utilizzi.

A quanto pare Rocky Linux con questi step manuali (che promette di automatizzare nel breve) ha quindi risolto il problema principale, verosimilmente andando ad incrociare le informazioni relative alle patch applicate e prendendo il codice direttamente alla fonte e non dai source RPM di Red Hat, ma non c’è una dichiarazione ufficiale in questo senso, quindi queste sono solo speculazioni.

Il post si chiude con un incoraggiante Rocky Linux continua a vivere, ed è quello che speriamo tutti.

Ad oggi manca ancora all’appello la terza delle vittime illustri designate, Oracle Linux, la quale da quel che ci risulta, non ha ancora espresso formalmente una posizione e non è detto che lo faccia. E tutto questo è molto curioso, se si considera come la principale responsabile di tutto il circo che si è scatenato sia proprio lei.

Ma questa vicenda non riguarda solamente AlmaLinux, Rocky Linux e soprattutto Oracle Linux. infatti come racconta The Register, ci sono altre distribuzioni come ad esempio l’accademica Springdale (fondata addirittura prima di CentOS!) che sono in crisi per via della decisione imposta da Red Hat.

Red Hat che nel frattempo estende a ben 240 sistemi la Free Developers Subscription (di cui avevamo già parlato) una mossa che, vista la concomitanza al momento topico, sa più di beffa.

Red Hat che nel frattempo a causa di un bug della UI ha fatto momentaneamente apparire ben 240 sistemi nella Free Developers Subscription (di cui avevamo già parlato) un problema che, vista la concomitanza con il momento topico, sa di beffa.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

27 risposte a “Rocky Linux ha un piano per sopravvivere alle scelte di Red Hat sulla pubblicazione dei sorgenti di RHEL”

  1. Avatar Black_Codec

    A parte che nel post linkato c’è scritto che hanno fatto attività manuali per ottenere il risultato ma non quali siano state… in un loro post parlavano di un container dal quale recuperare i srpms, illegale, o analizzare il delta per ricostruire i srpms loro… Ora questa è palesemente una supercazzola, leggi il file SPEC eventuali patch e li rinomini per evitare noie legali… Ma dubito che possa continuare a lungo una situazione che palesemente attira gli occhi di tutti su di se…

  2. Avatar Gianluca Gabrielli

    Red Hat che nel frattempo estende a ben 240 sistemi la una mossa che, vista la concomitanza al momento topico, sa più di beffa.

    Era un bug della webUI, i sistemi sono sempre 16.

  3. Avatar Raoul Scarazzini

    Vero! La fonte era questa https://linuxiac.com/red-hat-boosts-free-developers-subscription-to-240-systems/. Correggo l’articolo, grazie della segnalazione.

  4. Avatar Raoul Scarazzini

    No. L’utilizzo delle sub free tier è limitato al “personale” e non può formalmente essere utilizzato in contesti di produzione.

  5. Avatar Raoul Scarazzini

    Concordo sul fatto che tutto questo riserbo (mantenuto anche quando The Register ha chiesto direttamente chiarimenti) abbia dei risvolti fastidiosi. Se è di approccio open che stiamo parlando non pare certo la strada più promettente.
    L’aspetto su cui sono più curioso ad oggi è vedere come Red Hat giustificherà la tutela dei SRPM per i soli clienti ed il derivante obbligo di produrre unicamente ricompilazioni di RHEL. Questa parte pare aver aperto un vaso di Pandora di cui, ad oggi, nessuno sapeva l’esistenza, perché essendo tutto anche su git.centos.org era un non problema…

  6. Avatar Gianluca Gabrielli

    Trovo molto affascinante il blogpost del 29 dove illustrano due metodi per recuperare gli SRPM senza dover passare per il portale di RH e quindi senza accettare strani e limitanti agreements.

    One option is through the usage of UBI container images which are
    based on RHEL and available from multiple online sources (including
    Docker Hub). Using the UBI image, it is easily possible to obtain Red
    Hat sources reliably and unencumbered. We have validated this through
    OCI (Open Container Initiative) containers and it works exactly as
    expected.

    Another method that we will leverage is pay-per-use public cloud
    instances. With this, anyone can spin up RHEL images in the cloud and
    thus obtain the source code for all packages and errata. This is the
    easiest for us to scale as we can do all of this through CI pipelines,
    spinning up cloud images to obtain the sources via DNF, and post to our
    Git repositories automatically.

    These methods are possible because of the power of GPL. No one can prevent redistribution of GPL software.

  7. Avatar Alessandro Scarozza
    Alessandro Scarozza

    non ho mai comprato la subscription RHEL ma mi chiedevo una cosa, visto che la free include 16 installazioni, non basta fare più subscription con 2 o 3 mail ?

  8. Avatar Alessandro Scarozza
    Alessandro Scarozza

    quindi oltre al limite delle 16 installazioni, c’è anche un vincolo di utilizzo in ambienti di test?

  9. Avatar Raoul Scarazzini

    No, se il numero rimane al di sotto dei 16 puoi farci quello che vuoi, ma sopra mi son spiegato malissimo. Volevo dire, riferito al tuo esempio, come non fosse possibile registrare 3 account diversi in modo da usare 48 sub nello stesso ambiente.
    Quindi in contesti “small business” la cosa è fattibile, in contesti enterprise (che sopra ho nominato genericamente “produzione”) no.

  10. Avatar Alessandro Scarozza
    Alessandro Scarozza

    quindi non puoi avere piu subscription free legate alla stessa azienda ?

  11. Avatar Raoul Scarazzini

    Bisognerebbe leggersi tutto il contratto di utilizzo, ma a naso mi parrebbe logico che quel tipo di utilizzo non sia previsto.

  12. Avatar Simone
    Simone

    Ma non si può lasciar perdere RedHat e fare una solida distribuzione senza la pretesa di essere “bug for bug” compatibile?

  13. Avatar Black_Codec

    Beh tecnicamente nella gpl non c’è nulla che vieta l’azione eseguita da rhel, cioè rhel mantiene i sorgenti aperti, infatti ti fai un account free e vi accedi, ne vieta la ridistribuzione e l’uso improprio che è tra l’altro un diritto… Cioè non guardiamo a rhel solo come la stronza di turno, guardiamo a chi si appoggia al suo lavoro e si prende anche fetta del mercato… Ora rhel finanzia diversi sviluppatori nel panorama Linux non possiamo pensare che a questi basti uno stipendio ridicolo come quello ottenibile dalle sole donazioni…

  14. Avatar Simone
    Simone

    Ah senz’altro! Comunque in definitiva non credo che RedHat sia da condannare: questa mossa punta a rendere difficoltosa principalmente la concorrenza di Oracle, visto che lucrano su un rebranding di RHEL (cosa che osservavi tu in precedenti articoli sull’uscita dell’ultima release di Oracle Linux). E come poi – anche giustamente direi – Mike McGrath osserva sul blog di RedHat,

    In a healthy open source ecosystem, competition and innovation go
    hand-in-hand. Red Hat, SUSE, Canonical, AWS and Microsoft all create
    Linux distributions with associated branding and ecosystem development
    efforts. These variants all utilize and contribute Linux source code,
    but none claim to be “fully compatible” with the others.

    Tanto per dire, se non ricordo male, Amazon Linux è basato su Fedora… E la compatibilità “bug for bug” è davvero così rilevante? Io non credo, parliamo sempre di GNU/Linux, con systemd, praticamente cambia il gestore dei packages e poi sì, Debian non ha una policy SELinux impostata di default, ma un esperto sysadmin saprebbe ovviare.

    Certo da un punto di vista aziendale, usare progetti con licenza BSD sarebbe più conveniente, e non porterebbe grane di questo genere.

  15. Avatar Raoul Scarazzini

    Ma c’è già! Si chiama Debian 🙂

  16. Avatar Raoul Scarazzini

    Quasi tutto corretto. Il paywall siamo d’accordo possa rientrare nella GPL (anche se è una cosa che non fa praticamente nessuno), l’uso improprio andrebbe inquadrato (cosa si intende?), mentre sulla ridistribuzione proprio no: nella maggioranza delle licenze open-source quel limite non è mai previsto, anche perché annullerebbe di fatto il motivo stesso dell’esistenza delle licenze, che è quello di preservare la natura aperta del codice stesso.
    Red Hat finanzia tanti sviluppatori e progetti, certo (anche se la maggioranza sono suoi dipendenti, quindi anche lì è questione di interesse), ma per comporre RHEL usa anche una serie enorme di software sviluppati da altri e distribuiti con licenze open.

  17. Avatar Pietro Rewind
    Pietro Rewind

    Ma la domanda… Ha senso? Invece di contribuire alla frammentazione delle distribuzioni con distro la cui fonte dei pacchetti risulta anche avversa… Ma perché non chiudono baracca e burattini e non si uniscono al team di altre distribuzioni già esistenti?

  18. Avatar Black_Codec

    Attenzione attenzione, la licenza gpl si applica ai sorgenti del software non ai source dei file rpm eh… Infatti i sorgenti sono gpl e nell’eula di rhel c’è scritto chiaramente che è vietata la ridistribuzione dei source rpms non dei sorgenti dei software eh …
    Sul discorso questione di interesse non sono d’accordo, potrebbe tranquillamente sbattersene prendersi e farsi la sua *bsd perché avrebbe la forza lavoro e non credo che nessuno sviluppatore voglia non essere pagato, quindi l’interesse è di chi usa quel software più che di rhel eh…

  19. Avatar Raoul Scarazzini

    Per una questione di libertà. Il discorso che fai è applicabile nel caso delle distribuzioni un po’ a tutti (ne abbiamo parlato diverse volte, vedi https://www.miamammausalinux.org/2020/08/saturdays-talks-ubuntu-cinnamon-non-se-la-passa-bene-le-distribuzioni-remix-o-spin-hanno-ragione-di-esistere/ ) tranne le “big”, per assurdo anche Ubuntu a quel punto che è una derivata di Debian.
    Ma è una questione di libertà, non necessariamente, e non sempre, di buonsenso.

  20. Avatar Raoul Scarazzini

    Sì, ma quei SRPM sono riferiti anche a software che non ha sviluppato Red Hat, vedi il Kernel. Quindi siamo punto e a capo: basta che ci metto il file .spec e tutto diventa “mio”?
    Sull’interesse: avrebbe Red Hat la forza lavoro anche di crearsi e mantenersi un suo Kernel? Senza Torvalds? Non credo proprio, e non credo ci pensi minimamente…
    Per come la vedo quel che ha scritto SUSE è la sintesi migliore (https://www.miamammausalinux.org/2023/07/e-alla-fine-arriva-suse-che-si-pronuncia-in-merito-alle-scelte-di-red-hat-sui-sorgenti-rhel-e-sul-proprio-futuro-nellopen-source/ ) è una questione di interdipendenza che, al netto del comportarsi legalmente o no, andrebbe riconosciuta e rispettata.
    Di nuovo: legale? Presumibilmente sì. Etico? Certamente no.

  21. Avatar Black_Codec

    Ma perché dovrebbe scriversi il suo kernel quando gli basterebbe il bsd?
    Poi, i file spec e i file patch possono essere loro e fuori gpl, il punto è questo. Cioè se io creo il mio pkgbuild del kernel per dire un metodo piuttosto che un altro, non sono tenuto a rilasciarlo sotto gpl e non violo nessuna licenza.
    Che rhel ci abbia guadagnato dalla community è tutto da valutare, perché è stato un mutuo scambio di interessi spesso a sfavore di rhel che, ripeto, deve pagarli gli sviluppatori… Voglio vedere se domani tutti i vari dev kernel non prendessero più un euro che fine farebbe il kernel Linux… Eddai siamo onesti, lavori per la gloria o per portare la pagnotta a casa?

  22. Avatar Raoul Scarazzini

    Ma se è tutto come scrivi, perché la community Linux è letteralmente insorta ad ogni latitudine? Il problema non è pratico, ma etico. È dietro a questo che ruota l’indignazione generale. Che poi ci siano mille modi per ovviare alla limitazione siamo tutti d’accordo, ma a pesare è il tradimento dell’etica con cui spesso, anzi sempre, in passato Red Hat si è fatta scudo.

  23. Avatar Raoul Scarazzini

    Ti sbagli. Una patch applicata a un programma GPL è GPL per definizione. Se modifichi il Kernel Linux in qualsiasi modo, anche per i tuoi scopi personali, lo puoi rivendere, ci puoi far soldi, puoi creare meccanismi di subscription, ma DEVI rilasciare i sorgenti a loro volta sotto GPL.
    Tutti lavoriamo per i soldi, ed è proprio lì il punto: non sono stato io a costruire la narrazione di una dream company paladina dell’open-source, ma è Red Hat che da sempre si professa tale. L’indignazione della community ha origine da lì, fine.
    Tutti gli altri discorsi che citi hanno perfettamente senso, ma qui si valuta l’etica di una decisione incoerente con l’immagine che questa azienda ha sempre dato di sé.

  24. Avatar Simone
    Simone

    Effettivamente non sono stato equilibrato né esauriente: commercialmente ha fatto bene, capisco ovviamente però che la comunità si sia agitata: se fanno questo oggi, saranno capaci di andare oltre un domani… Oltre al fatto che come qualcuno ha già osservato, RedHat ha costruito la propria fortuna su una base di lavoro fatta da hobbisti dell’opensource.

  25. Avatar Black_Codec

    Ma le patch rhel le rilascia sotto gpl sui canali ufficiali, i file patch sono diversi, non sono le vere e proprie patch al software ma sono originati fondamentalmente da un comando diff e spesso riguardano variabili e path specifici per ciascuna distro che poco o nulla hanno a che vedere col software originale.
    In questo caso non sei tenuto a rilasciarle sotto gpl perché sono tue specifiche… Ma anche fosse puoi non riautorizzarne la distribuzione ed è infatti su questo che rhel si sta facendo forte e che tutti hanno dovuto fare pippa perché non puoi imporglielo a meno di modificate la gpl stessa … Ma attenzione al rovescio della medaglia che è sempre dietro l’angolo.

  26. Avatar Black_Codec

    Beh però almeno Oracle Linux ha dei suoi repository ad hoc per prodotti suoi, vedi kernel uek ad esempio… Le altre sono veramente rhel rebranded, soprattutto rocky linux.

  27. Avatar Simone
    Simone

    Anche il team di grsecurity rilascia il sorgente solo ai clienti paganti, credo stiano facendo la stessa identica cosa da RedHat

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *