Fin 2020, Red Hat secouait le monde Linux en annonçant la fin de CentOS, au profit d’un nouveau fonctionnement pour les participations des développeurs tiers. La société franchit un autre cap en limitant l’accès à son code source, provoquant la colère d’Oracle et diverses réactions, dont celle de SUSE.
Il y a deux ans et demi, l’annonce de Red Hat – qui appartient à IBM depuis 2018 – n’était pas passée inaperçue : l’arrêt de la version classique de CentOS au profit d’une version Stream destinée à concentrer les améliorations à venir pour RHEL (Red Hat Enterprise Linux).
Une décision très peu appréciée de la communauté, qui y voyait une forme d’avarice, CentOS étant une reconstruction gratuite de RHEL d’après les sources, avec une compatibilité totale. Pour certains, Red Hat ne faisait que se débarrasser d’un concurrent provenant de sa propre écurie.
Fin juin, la société est cependant passée à l’étape suivante.
Les sources de CentOS Stream plus difficiles d'accès
Dans un billet de blog daté du 21 juin, Mike McGrath, vice-président chez Red Hat, annonce un autre changement de taille pour CentOS Stream : ce dernier sera maintenant « l’épine dorsale » de l’innovation Linux au sein de l’entreprise et constituera « désormais le seul dépôt pour les versions publiques du code source liées à RHEL ».
McGrath précise dans la foulée que rien ne change pour les clients et partenaires, le code source étant disponible via Red Hat Customer Portal. À la question du « pourquoi », le vice-président répond :
« Avant CentOS Stream, Red Hat poussait les sources publiques pour RHEL vers git.centos.org. Lorsque le projet CentOS s'est recentré sur CentOS Stream, nous avons maintenu ces dépôts même si CentOS Linux n'était plus construit en aval de RHEL. L'engagement autour de CentOS Stream, les niveaux d'investissement en ingénierie et les nouvelles priorités dont nous nous occupons pour les clients et aux partenaires rendent maintenant inefficace le maintien de référentiels séparés et redondants. Le code source le plus récent sera toujours disponible via CentOS Stream ».
Une attaque contre les clones de RHEL ?
Très vite, l’annonce fait beaucoup de bruit. Beaucoup s’en prennent violemment à Red Hat, qui semble vouloir encore une fois réduire le champ de la concurrence en verrouillant un peu plus CentOS Stream. Car si l’ancien CentOS n’existe plus, d’autres ont pris sa relève, notamment Rocky Linux (créé par le fondateur de CentOS) et Alma Linux.
Il fallait en effet lire entre les lignes : l’accès aux sources n’était plus direct ni gratuit sans licence RHEL. Plus précisément, il faut cette licence pour accéder à tout ce qui est reversé par Red Hat dans le code de CentOS Stream, y compris les mises à jour de sécurité, à partir desquelles ces deux distributions (entre autres) reconstruisaient de nouveau paquets RPM. Licence encadrée par des règles, stipulant par exemple qu’il est interdit de redistribuer les logiciels Red Hat.
Les réactions de Rocky Linux et Alma Linux sont arrivées dans la foulée. Sans surprise, les équipes de développement regrettent toutes la décision de Red Hat. Cependant, il n’y a aucun changement à prévoir pour l’instant. Dans les deux cas, les développeurs ont trouvé ou vont trouver des solutions, notamment en empruntant à Oracle Linux, autre reconstruction de Red Hat Enterprise Linux totalement compatible (nous y reviendrons).
Chez Rocky Linux comme chez Alma Linux, une partie du discours est très axée sur les apports permis par cette émulation autour de RHEL, et ce que cela signifie pour la communauté comme pour l’esprit de l’open source, que Red Hat est accusée d’avoir enfreint.
Red Hat tente une explication au ton aigre
Le 26 juin, Mike McGrath publie un nouveau billet. Il y exprime une certaine amertume face au torrent de commentaires négatifs, souvent violents, reçus depuis le premier billet. Il indique notamment avoir été qualifié de « diabolique ».
Il se dit surtout peiné par un certain nombre de « déclarations fausses » au sujet de Red Hat : « Red Hat utilise et utilisera toujours un modèle de développement open source. Lorsque nous trouvons un bogue ou écrivons une fonctionnalité, nous contribuons à notre code en amont. Cela profite à tous les membres de la communauté, et pas seulement à Red Hat et à ses clients ».
Il insiste en particulier sur « les heures et les nuits que nous passons à rétroporter un correctif à un code qui a maintenant 5 à 10 ans ou plus ; à tout moment, nous prenons en charge 3 à 4 versions majeures, tout en appliquant des correctifs et des rétroportages à toutes ces versions. En outre, lorsque nous développons des correctifs pour des problèmes dans RHEL, nous ne les appliquons pas seulement à RHEL - ils sont d'abord appliqués en amont, à des projets tels que Fedora, CentOS Stream ou le projet de noyau lui-même, et nous les rétroportons ensuite. Maintenir et soutenir un système d'exploitation pendant 10 ans est une tâche herculéenne - le travail que nous effectuons est d'une grande valeur ». Il ajoute : « Nous devons payer les gens qui font ce travail ».
L’aigreur devient palpable quand il déclare avoir le « le sentiment qu'une grande partie de la colère suscitée par notre récente décision concernant les sources en aval provient de ceux qui ne veulent pas payer pour le temps, les efforts et les ressources consacrés à RHEL ou de ceux qui veulent le reconditionner à leur propre profit. Cette demande de code RHEL est fallacieuse ».
Selon le vice-président, Red Hat trouvait une certaine valeur dans le travail des « rebuilders » tels que CentOS. Mais l’entreprise a changé d’avis. Elle s’érige désormais contre la vision « généralement acceptée » que ces distributions sont des « entonnoirs produisant des experts RHEL », fournissant une première approche de cette dernière, ce qui concrétise ensuite des ventes pour Red Hat : « ce n’est tout simplement pas la réalité ».
McGrath indique par exemple que Red Hat, SUSE, Canonical, AWS et Microsoft possèdent toutes des distributions Linux utilisant et contribuant au code source de Linux, « mais aucune ne prétend être totalement compatible avec les autres ».
Le jugement du vice-président finit par tomber, comme un couperet : « Le simple fait de reconstruire le code, sans y ajouter de valeur ou le modifier de quelque manière que ce soit, représente une véritable menace pour les entreprises de logiciels libres du monde entier. Il s'agit d'une menace réelle pour l'open source, qui risque de faire de l'open source une activité réservée aux amateurs et aux pirates ».
En clair, les distributions telles que Rocky Linux et Alma Linux sont décrites en parasites. On peut se demander d’ailleurs s’il s’agit d’un authentique sentiment chez Red Hat, pourquoi cette vision n’a pas été partagée plus tôt.
Oracle s’en mêle
Alors que les propos de McGrath ont fait sensation, faisant se poser la question de possibles violations de la GPL, Oracle a décidé de s’en mêler. Sa distribution Oracle Linux est justement l’une de ces reconstructions de RHEL, avec laquelle elle est pleinement compatible.
Dans la première partie de son billet de blog, l’expression est sobre : Oracle est impliquée depuis 25 ans dans la communauté Linux, l’objectif a toujours été de faire de Linux le meilleur système pour les serveurs, les contributions au noyau, systèmes de fichiers et outils sont nombreuses, etc.
Dans la deuxième partie, le ton devient plus sarcastique : « IBM ne veut pas continuer à libérer publiquement le code source de RHEL parce qu'il doit payer ses ingénieurs ? Cela semble étrange, étant donné que Red Hat, en tant que société open source indépendante prospère, a choisi de publier le code source de RHEL et de payer ses ingénieurs pendant de nombreuses années avant qu'IBM n'acquière Red Hat en 2019 pour 34 milliards de dollars ».
Échange de douceurs
Concrètement, quelles conséquences pour Oracle Linux ? Selon Oracle, sa distribution Linux restera compatible avec RHEL 9.2. Au-delà, aucune garantie, mais l’entreprise précise qu’en cas de problème avec un client, elle travaillera à le corriger.
Qu’en est-il du code source de Linux ? « Oracle fait la promesse suivante : tant qu'Oracle distribuera Linux, Oracle rendra les binaires et le code source de cette distribution publiquement et librement disponibles. En outre, Oracle accueille les distributions en aval de toutes sortes, communautaires ou commerciales. Nous sommes heureux de collaborer avec les distributeurs pour faciliter ce processus, travailler ensemble sur le contenu d'Oracle Linux et veiller à ce que les produits logiciels Oracle soient certifiés sur votre distribution ».
Oracle se positionne donc en alternative, dans un domaine où elle est un outsider. Et la société « trolle » IBM avec deux suggestions : « Si vous êtes un développeur Linux en désaccord avec les actions d'IBM et que vous croyez à la liberté de Linux comme nous, nous embauchons. ... Enfin, pour IBM, voici une grande idée pour vous. Vous dites que vous ne voulez pas payer tous ces développeurs RHEL ? Voici comment vous pouvez économiser de l'argent : inspirez-vous de nous. Devenez un distributeur en aval d'Oracle Linux. Nous nous ferons un plaisir d'assumer le fardeau ».
Les propos d’Oracle ne sont pas passés inaperçus, d’autant que l’entreprise a un passé compliqué avec l’open source, comme on a pu le voir il y a longtemps avec Java. Chez Red Hat, pas de réaction officielle, mais certains employés ont répondu de manière acerbe. « Où IBM (ou Red Hat) dit-elle qu’elle ne veut pas payer ses développeurs ? Et on parle d’hommes de paille et de mensonges ! », s’insurge Paolo Bonzini, ingénieur. « Non-sens typique et opportuniste de la part d’Oracle », tacle Paul Frields, directeur de l’ingénierie chez Red Hat.
SUSE va développer sa propre distribution compatible RHEL
Alors que la situation était déjà complexe, SUSE a décidé de s’en mêler avec une annonce de poids : au moins 10 millions de dollars seront affectés à la création d’une distribution totalement compatible avec RHEL, dont elle sera un fork.
« Depuis des décennies, la collaboration et le succès partagé sont les fondements de notre communauté open-source. Nous avons la responsabilité de défendre ces valeurs. Cet investissement préservera le flux d'innovation pour les années à venir et garantira que les clients et la communauté ne seront pas soumis à un verrouillage des fournisseurs et auront un véritable choix demain comme aujourd'hui », a ainsi expliqué Dirk-Peter van Leeuwen, PDG de SUSE.
Les actuels systèmes SUSE Linux Enterprise et openSUSE continueront à être développés, mais le nouveau venu sera là pour les entreprises et les membres de la communauté qui préfèrent avoir le choix.
L’annonce a été globalement bien accueillie. Le communiqué intègre d’ailleurs la réaction de Gregory Kurtzer, fondateur de Rocky Linux et PDG de CIQ : « SUSE incarne les principes fondamentaux et l'esprit de l'open source ; CIQ est ravie de collaborer avec SUSE pour faire progresser un standard ouvert pour Linux en entreprise ».
Commentaires (63)
#1
Pour ALMA Linux, normalement plébiscité par l’ANSSI, vient de passer dans la case «à éviter, pas de pérennité»
(avis perso: est-ce que s’appuyer sur une société américaine cotée en bourse donc ayant des intérêts économiques était la meilleure idée, plutôt que Debian ou Gentoo ?)
#1.1
Ce troll d’Oracle est d’un croustillant, ils n’ont honte de rien.
A 34 milliards l’achat, il devait y avoir des répercussions à un moment donné.
Ah tiens j’ai loupé le document, un lien ?
Pour des décideurs en DSI, ce qui est recherché c’est le support commercial derrière.
Il y a des exceptions politiques récentes: Kaspersky, Pegasus
#1.2
Pas de document à ma connaissance, c’est une consigne qui circule y compris au campus cyber (j’y étais la semaine dernière, les formateurs de l’ANSSI ont mentionné la difficulté à propos de Alma Linux).
Du coup, effectivement pour le support commercial, RHEL est du coup un peu seul en liste.
#2
Et encore une fois, on observe la confrontation entre l’ “open-source” et le “tout gratuit”.
Ouin, ouin, Je veux mon clone gratuit de RHEL ! C’est open-source alors j’y ai droit…
#2.1
J’ai commencé à faire des dons récurrents (principalement LineageOS et microG, j’ai toujours grâce à eux des mises à jours tout les mois sur mon smartphone vieux de 5 ans avec la dernière version d’Android).
Le problème c’est que j’utilise tellement l’Open-Source que je ne peux pas faire de dons partout
Mais oui, c’est toujours le même problème, les grosses entreprises qui se reposent dessus, ont les moyens et ne font jamais de dons sont un gros problème.
#2.2
Plutôt la confusion entre Logiciel Libre (distribuable dès qu’un tiers signe la GPL) et Open source (consultable par les tiers).
#2.3
Si RedHat mettait sa RHEL (version desktop, sans support) à disposition des particuliers pour moins d’une centaine d’€uros (puis 50€ le changement de version) avec uniquement accès aux mises à jour.
Quant à Debian pour les particuliers béotiens, ce n’est peut-être pas si simple… Les OpenSuSE, CentOS étaient plus abordable… Sinon, il y a les versions LTS d’Ubuntu proche de Debian.
#2.4
Rien n’empêche un particulier d’utiliser Red Hat gratuitement via une inscription au programme Red Hat Developer, si je ne me trompe pas ça permet l’installation de 5 machines, et c’est renouvelable annuellement gratuitement.
#2.5
Oui, mais si l’on désire une certaine stabilité (type LTS d’Ubuntu) se tourner ver une distribution «pro» peut être intéressant moyennant un petit investissement mais sans abonnement.
Perso je ne cherche pas nécessairement le tout gratos, c’est d’ailleurs très dommage que Eset ait abandonné les particuliers pour la version Linux de son antivirus (Cela dit, beaucoup disent que c’est inutile… ¿car peu d’intérêt pour les brancouilleurs de virus il n’y a pas assez d’utilisateurs à polluer sous Linux ?)
#2.6
Déjà évoqué, mais un compte user permet déjà d’avoir des subs “developper” qui donnent jusqu’à 16 systèmes possibles.
(et de facto, en mettant en place un reposync, à un nombre que ne suivra pas le subs-manager de redhat)
https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux#general
#3
Dans tout ça, c’est Debian et dérivés qui ont tout à gagner …
Une distribution en danger avec ces histoires est clairement VSPhere. Et ce n’est pas une bonne nouvelle pour ses nombreux utilisateurs …
#4
Moi j’avoue que je comprends pas trop toute cette polémique:
Ce que recherchent les DSI quand ils achètent RHEL, c’est justement la ligne budgétaire et le support long terme.
Sinon, autant prendre une debian, ou même n’importe quelle distro basé sur RPM… voire même dans les cas extrêmes fabriquer la sienne spécialisé !
Donc les compétiteurs de RHEL c’est bien oracle & Suse.
Alors oui, bien sur, il y a des gens qui utilisaient CentOS : Un excellent exemple de ça ce sont les dev, parfois sous-traitants, de programmes spécifiques à destination de ces grosses DSI. Ces devs sont fait sur n’importe quelle distro et sont testés (et adaptés) ensuite sur centos dans un 1er temps, avant d’être déployé en réel sur RHEL in fine.
Mais de toute façon, on parle de quelques licences, c’est pas significatif et aller grater ça c’est prendre le risque de perdre les grosses DSI…
J’avoue que je pige pas la stratégie, là.
#5
Suse est pas dans le coup ?
Ils sont pas aussi gros que redhat et plutôt EU, mais c’est pas non plus la distro de la boutique de réparateur de téléphone du coin !
#6
Non, dans la plupart des cas lorsque les DSI vont vers RHEL ou compatible, c’est pour y déployer un produit qui n’est certifié que sur ces environnements (et pour lequel il est explicitement dit qu’aucune garantie de bon fonctionnement n’est faite avec un autre environnement Linux).
Partout où je suis passé, les serveurs étaient sous Debian, Ubuntu Server (ou, plus rarement openSUSE ; et fut un temps où il y avait du Mandriva Server), sauf pour les quelques produits dont le déploiement sur autre chose que RHEL ou CentOS entraînait une suspension de la maintenance et de l’assistance.
#6.1
perso full centos7/rhel7 au boulot, on doit tout basculer en RHEL8 (voir 9 maintenant vu le retard qu’on à)
et le gros plus c’est le support RHEL quand tu as des comportement à la con !
ils m’ont sortie plusieurs fois du pétrin, y compris sur centos car on arrivais presque toujours à reproduire sur nos RHEL.
aujourd’hui ont est passer sur des licences par hosts vmware (avec négoce du tarif par le groupe) du coup avec l’arrêt de centos autant passer en full rhel de partout.
#7
J’ai du mal à comprendre comment RHEL va pouvoir maintenir les sources fermées. Il suffit qu’un seul client achète RHEL pour avoir accès aux sources et avoir le droit de les republier, GPL oblige …
Ou alors, il y a quelque chose qui m’échappe.
#7.1
“Il fallait en effet lire entre les lignes : l’accès aux sources n’était plus direct ni gratuit sans licence RHEL. Plus précisément, il faut cette licence pour accéder à tout ce qui est reversé par Red Hat dans le code de CentOS Stream, y compris les mises à jour de sécurité, à partir desquelles ces deux distributions (entre autres) reconstruisaient de nouveau paquets RPM. Licence encadrée par des règles, stipulant par exemple qu’il est interdit de redistribuer les logiciels Red Hat.”
#7.2
A confirmer, car je n’ai regardé l’histoire que de loin, mais RedHat n’interdit pas la diffusion des sources. RedHat dit, qu’en cas de diffusion, votre licence sera invalidée (avec toutes les conséquences que cela a).
Cela peut être vu comme une “faille” de la GPL :
C’est discutable, cela va à l’encontre de l’esprit de la GPL (comme la tivoïsation qui est à la base de la GPLv3), mais cela reste a priori dans les clous de la GPL en l’état actuel des choses.
#7.4
Petites corrections et ajouts:
Donc si RedHat imposait une interdiction de redistribution des sources, il serait en violation des licences GPL, par contre il peut jouer sur les marques et logos, mais face à ça il y a déjà des méthodes correctrices.
Euh, non, tu mélanges tout, et tu ferais mieux de relire la définition de l’opensource de l’Opensource Initiative: https://opensource.org/osd/ et du libre de la FSF: https://www.gnu.org/philosophy/free-sw.fr.html
Reste qu’au final, tout ça était à prévoir. Depuis que Jim Whitehurst s’est fait évincer, il était évident qu’IBM ne tarderait pas à casser RedHat… Cette neutralisation systématique de la communauté autour de RedHat Enterprise Linux n’est pas du tout de bonne augure.
IBM a racheté RedHat pour éviter de couler à pic après les années Rometty et la stratégie désastreuse que l’entreprise a essayé de suivre (autant essayer d’apprendre à un singe à faire des claquettes) … Ils ont à l’époque acheté pour 34 milliards une entreprise dont les bénéfices annuels étaient inférieurs à 500 millions de dollars… Ce n’était qu’une question de temps avant qu’IBM n’essaye de rentrer dans ses frais plus agressivement, ils n’allaient pas attendre 60 ans pour rentrer dans leurs frais.
Mais comme c’est IBM, il ne faut pas s’attendre à des manœuvres de génie pour accroître les bénéfices, mais plutôt à de l’agressivité, du mépris et des dégâts irréparables à la réputation, ce qui risque d’entraîner une nouvelle série de départs et de casser les dynamiques avec la communauté et les partenaires.
“First they ignore you,
then they laugh at you,
then they fight you,
then they buy you”
#7.5
Bon, je prends mon doliprane et je vais faire une sieste (j’ai relu les définitions, par précision ainsi que les autres textes détaillant les ambiguïtés dans lesquels j’ai mis mes grosses godasses bien crades)
#7.6
Merci pour les précisions
#7.3
Ben non justement, l’article précise que la licence qui permet d’accéder aux sources est “encadrée par des règles, stipulant par exemple qu’il est interdit de redistribuer les logiciels Red Hat.”
EDIT : désolé, c’est vrai que si le code source est sous GPL, la question se pose
#8
C’est quand même un peu fort de la part de RedHat de dire qu’Alma et Rocky Linux ne sont que des parasites qui ne contribuent en rien à l’écosystème autour de REHL.
Je serais curieux de connaitre la proportion d’utilisateurs de Alma/Rocky qui feront le pas vers RHEL maintenant, pas sûr que ça soit significatif.
#9
Sauf qu’un logiciel sous licence GPL modifié reste sous licence GPL, donc le paquet RPM est lui aussi sous licence GPL. Donc comme indiqué précédemment, si je paie pour avoir accès aux paquets RPM, la licence GPL m’autorise bien à demander les sources du paquet et à les republier à côté, gratuitement ou non. Bref, quand RedHat écrit qu’il est interdit de redistributer des logiciels RedHat, ce n’est pas possible que si ces logiciels ne sont pas sous licence GPL.
#10
Logiciel Open source / Libre, sont synonymes en terme de droit accordés aux utilisateurs (si on fait abstraction de l’aspect philosophique).
Je trouve aussi le terme open source mal défini, et devrait correspondre, à mon sens, à “source available”. Mais ce n’est pas le cas.
#10.1
Je ne suis pas d’accord. Logiciel Open Source et Logiciel Libre ne sont pas synonymes.
Le premier est l’accessibilité/visibilité accordée à l’acquéreur de la licence mais n’autorise pas forcément la possibilité de le modifier, le redistribuer, ni même de le recompiler.
Un société qui fournit de l’open source n’est pas implicitement obligée de fournir le source code suite à l’acquisition de la licence; elle peut le faire suite à une demande de l’acquéreur et dans les délai qui lui conviennent.
La recompilation à des fins de comparaisons, de vérifications, des binaires est une option. Ce n’a pas toujours été autorisé.
L’Open Source est toujours un copyright et le Libre un copyleft.
Une licence Libre définit, force, justement cette différence.
#11
Non, même pas. C’est la confusion entre ce qui est écrit noir sur blanc dans la GPL et l’idée que les gens se font de la GPL (ce que certains appellent la “philosophie” du libre).
Ce qui est écrit noir sur blanc c’est que la GPL accorde des libertés et impose des obligations aux utilisateurs à qui on distribue le logiciel. En particulier, la GPL impose de redistribuer le logiciel à l’identique en terme de libertés et obligations. La partie “obligations” n’est pas négociable.
L’idée que les gens se font de la GPL c’est que ca impose seulement de redistribuer avec les mêmes libertés. Et donc que ca enlèverait magiquement toutes les contraintes légales ou commerciales liées à la distribution d’origine.
#12
Voilà un post qui résume beaucoup mieux les changements fait par redhat, que toutes les interprétations qu’on a pu lire ici et là: https://lists.fedoraproject.org/archives/list/[email protected]/message/XM6BNUHKI3EKTDEXAAVE3JBPCG3BPUJC/
tl;dr: ce que ça change vraiment pour les rebuilders? c’est qu’ils vont devoir rebuild from source (ou trouver des alternatives) plutôt que simplement récupérer les SRPM jusque-là gentiment fournis par les ingénieurs redhat uniquement pour eux. Est-ce que les sources restent librement accessibles? Oui: c’est centos stream, qui reste 100% libre. C’est là: https://gitlab.com/redhat/centos-stream
#12.1
Centos Stream <> RedHat enterprise linux … c’est proche mais ce n’est pas pareil. Rien que le noyau tel que fourni dans RHEL incorpore déjà un nombre élevé de patches non-documentés par rapport à Centos Stream, redhat ayant décidé de rendre ses mises à jour les moins lisibles possibles pour ses concurrents (et accessoirement ses utilisateurs)
#12.2
Tu as des sources de ce que tu avances?
Le workflow pour patcher RHEL, c’est de patcher centos stream et attendre que ça “redescende” vers RHEL. À ma connaissance, les seules exceptions sont les CVE sous embargo (où, pour des raisons de sécurité, les patchs sont faits en secret donc pas sur un repo public - il sont reversé sur le public dès que l’embargo prend fin) - et des éléments cosmétiques genre logo de redhat etc.
#12.3
Quoi, tu vas me dire qu’ils ont mis fin à cette tradition?
https://www.computerworld.com/article/2748700/red-hat-defends-kernel-code-obfuscation.html
#12.4
C’est assez drôle, de sortir un article datant de 2011 dans lequel il est reproché à redhat de fournir les sources dans un gros tarball plutôt que dans git … alors que c’est précisément le contraire aujourd’hui (et ce qu’on lui reproche, il faut croire qu’on aime reprocher tout et son contraire) : maintenant avec centos stream toutes les sources sont dispo en mode “upstream first”, bien au propre dans git, avec l’historique qui va bien.
#12.5
Sachant que la GPL 2.0 ne spécifie rien qu’autre que “machine readable source code (…) on a medium customarily used for software interchange”.
Même si Red Hat a un passif de mesures borderline avec la GPL, ça sert à rien de pinailler sur des détails comme celui-ci.
#12.7
Oui si on s’en tient strictement au respect de la GPL, mais ce qui me chagrine c’est le ressentiment qu’on voit ici, alors qu’en définitive je trouve que c’est un mauvais procès qui est fait dans la mesure où les sources utilisées pour builder RHEL restent bel et bien 100% open.
Je pense surtout qu’il y a eu des maladresses de com dans la façon de considérer les rebuilds (et je vais glisser un petit disclaimer ici: je bosse pour redhat (pas dans cette branche, pas dans les linux - et je ne sais rien de plus là dessus que ce que je lis dans la presse) mais je reste très attaché aux questions sur l’open-source - et d’autant plus regardant sur les changements de politiques de la boite).
Quand on s’en tient à regarder les process de build, honnêtement, cette décision a du sens: on supprime un repo qui n’avait a priori plus d’utilité pour redhat, et qui était juste gracieusement maintenu pour les rebuilds. La question d’un point de vue entreprise était bel est bien de savoir si ces rebuilds aident ou desservent redhat. J’imagine, pas simple à répondre. Évidemment d’un point de vue communauté, la question ne se pose pas dans ces termes, et la fermeture des repos apparaît forcément défavorable. Sauf que: redhat veut pousser la communauté vers centos stream. Non pas que les utilisateurs, mais les rebuilds également: ça signifie que les rebuilders doivent (selon redhat) prendre stream comme source, et avec un peu de chance, du fait d’en être plus proche, y contribuer. Je ne sais pas si ça en prendra le chemin …. pas sûr vu les déclarations des uns et des autres. Mais toujours est-il que ces questions sont finalement assez loin des procès en “closed-source” faits à redhat.
#12.8
Sur le plan purement juridique, je rejoins en fait le commentaire #20 sur le fait que le GPL est un peu trop fantasmée.
Sur le plan purement personnel, je considère que Red Hat fait une erreur. Surtout au niveau communication en considérant les rebuilds comme du pillage sans valeur ajoutée. Ce qui en soit est mensonger, insultant, et opposé au principe même du logiciel libre. Quand j’ai lu ce post de blog chez Red Hat, je me suis demandé s’ils ne découvraient ce qu’est le logiciel libre.
Et ça c’est une grosse erreur de mon point de vue car ça braque aussi les clients. Comme je disais dans mon précédent message, je connais des gros comptes qui ne veulent pas RHEL car ils ne veulent pas payer de license. Quand CentOS 8 a été flinguée et transformée en CentOS Stream, l’étude d’un remplaçant a été faite. Et la confiance en Red Hat était déjà très fragilisée. Cette confiance est encore plus fragilisée aujourd’hui et toute la famille Red Hat est désormais, sauf exception, absente des catalogues IT dans les secteurs où je preste.
Tu me diras que ça ne changera pas grand chose vu qu’ils se limitaient au strict nécessaire pour le besoin de RHEL. Ben y’a des décisions considérant ne plus vouloir utiliser leurs produits et ça devient désormais une clause bloquante pour un choix de solution si l’éditeur dit ne supporter que RHEL. A la suite de l’arrêt de CentOS, on a passé du temps à tester et qualifier les rebuilds pour s’assurer que le standard OS soit poursuivi avec tout le socle technique de la DSI. Ces travaux sont de nouveau à refaire.
Ce qui amène à un autre résultat : la stratégie de plusieurs DSI où je travaille est de s’orienter en priorité sur du Cloud-native application, donc du PaaS, et garder la VM pour du legacy. Ce changement imposé par Red Hat n’a fait qu’accélérer la volonté d’arrêter de faire de la VM pour ne plus avoir à maintenir un socle OS. Et le socle OS, bah maintenant c’est Ubuntu uniquement.
Et ça je trouve que c’est dommage car malgré quelques pieds dans le tapis dans son histoire, Red Hat a toujours eu de ma fenêtre une réputation positive. Depuis peu, c’est l’inverse que je constate et elle est rangée dans la même catégorie que Oracle ou IBM. Des entreprises avec qui on ne veut généralement pas travailler.
#12.9
Je suis d’accord sur l’erreur de com et la mauvaise appréciation de la valeur des rebuilds. C’est certainement impossible de déterminer quelle est cette valeur pour redhat: est-ce que ça détourne de RHEL ou au contraire amène vers RHEL - et dans quelles proportions? Va savoir… J’ai vu passer des argumentaires sur reddit où la valeur était mesurée en fonction du nombre de contributions sur l’upstream (code, doc, …), et de ce point de vue elle était quasi nulle. Évidemment ce n’est qu’une partie de l’équation, sûrement négligeable même, comparé au fait d’habituer les utilisateurs à l’écosystème redhat. Donc on ne peut pas dire qu’il n’y a pas de valeur dans les rebuilds du point de vue de redhat, et à ce titre je n’ai pas bcp aimé non plus cette com. Qu’il y ait de la frustration de la part de certains de voir leur travail repris / réétiqueté pour peut-être en plus perdre des parts de marché, ça peut se comprendre occasionnellement (c’est humain), mais c’est le jeu de l’open-source et redhat n’est pas un nouveau venu dans ce domaine, c’est juste un sentiment qu’on doit savoir réprimer en tant que contributeur.
Maintenant, comme je disais, les rebuilds ne sont pas morts pour autant et sont encouragés à utiliser les “vraies” sources, celles de centos stream. RHEL est buildé via ces sources, donc n’importe quel linux peut faire de même, à partir des mêmes commits. D’ailleurs je serais curieux de savoir si c’est ce que Suse compte faire, ce serait une bonne nouvelle.
Pour l’autre point que tu soulèves, la stabilité : je connais mieux la théorie que la pratique, mais l’idée à la base de Stream est justement d’améliorer la stabilité et limiter les mauvaises surprises, notamment lors des upgrades : plutôt que de faire un saut dans l’inconnu à chaque major/minor, on est capable de tester via Stream plus ou moins en permanence et donc mieux anticiper les problèmes et remonter du feedback plus vite. J’imagine pour ça de déployer du rhel ou rocky/alma en prod, et stream sur certains environnements de test. Après, je fais ni de la prod ni du linux, j’ai sûrement une vue incomplète des choses…
#12.10
Concernant CentOS Stream, pour l’avoir eue pendant un an sur un VPS à titre perso, c’est inadapté pour héberger une solution. Même sur de la non production.
Le but de la non prod est justement d’être au plus proche de la prod en terme de configuration et versions, à l’exception qu’elle peut être en avance car elle qualifie les nouveautés, mais ces nouveautés doivent finir en prod de la même façon. Et à l’inverse, un problème rencontré en production doit être reproductible en non prod si nécessaire.
Stream, j’ai eu plusieurs fois des pertes de service lors de mise à jour à cause de libs qui devenaient subitement incompatibles entre elles (surtout celles liées à podman, un peu relou quand tu fais du container…).
Quand au point sur les contributions à l’upstream, ce n’est que pure spéculation de ma part, mais à titre perso j’aurais pas envie de contribuer à un projet pour lequel on me dit que je suis un voleur sans valeur ajoutée si j’ose le recompiler depuis ses sources. Je ne sais pas quelle était le niveau de contribution à CentOS de la part de Oracle Linux par exemple (vu que Alma et Rocky sont nées après et que les autres rebuilds comme Scientific Linux - créée par le CERN et arrêtée en 2019 - et Springdale étaient un peu plus confidentielles), mais un changement aussi brutal n’inspire pas confiance quant à l’idée de collaborer avec l’entreprise de mon point de vue.
Je ne saurais pas dire si c’est là une erreur stratégique, mais c’est clairement une erreur de posture et de communication pour moi.
C’est pas des backport de la version N+1 une fois la version parallèle EOL ? Il me semble que c’est ce qui se fait usuellement lors qu’un produit passe en support étendu.
#12.6
Upstream first c’est bien, mais “upstream first” n’empèche pas re remouliner des choses en aval. Le problème ici est en fait que l’on endommage la lisibilité.
Si on ne peut que saluer le fait que Centos soit effectivement devenu l’upstream de RHEL, ce qui est reproché ici est que RHEL lui-même est devenu plus opaque, les modifs entre les paquets version centos stream et RHEL n’étant plus accessibles au grand public.
On est bien d’accord. Oracle a vraiment joué le jeu du cannibalisme avec l’Open Source, en mode “pourquoi je ferais un partenariat avec RedHat alors que je peux juste lui prendre son travail pour rien” … et pour en rajouter , ils ont commencé à ne plus certifier que “Unbreakable Linux” + “Unbreakable kernel” pour certains produits, obligeant de fait les entreprises à passer à Oracle Linux.
Pour le moment, je revois de temps à autres des commerciaux d’Oracle car l’entreprise essaye maintenant de s’implanter sur le marché kubernetes, mais pour le moment, c’est d’une médiocrité fantastique et ça se voit qu’ils comptent plus sur le nom Oracle que sur leur expertise.
#13
Le vrai parasite dans l’histoire, c’est bien Oracle Linux amha.
Contrairement à ce qui est indiqué, ce n’est pas Alma ou Rocky qui sont en réalité ciblés par cette évolution de RHEL.
La frustration de RHEL était de voir tout le commerce fait par Oracle pour inciter les clients à venir chez lui, pour moins cher (alors que j’aimerai bien savoir/voir la quantité des équipes Oracle qui travaillent sur Oracle Linux).
On était donc dans une situation où un “parasite” venait faire son marché sur le dos du premier. Et en repiochant allègrement dans le travail fait par celui-ci, et sans reverser quoi que ça soit à son niveau.
Facile dans ces cas de faire une distrib “apacher” quand on ne paye en réalité aucun dev…
Donc c’est pas très valorisant pour Red Hat, mais à mon avis largement justifé !
#14
y’a que moi qui pense que le sous-titre aurait dû être :
“l’attaque des clones”
#14.1
#14.2
#15
La communication d’Oracle m’a tellement fait marrer n’empêche… Quand la fosse à septique dit à l’égout qu’il pue.
Genre le changement de license de Java, à tout hasard.
#15.1
Mais carrément ! Oracle, c’est l’hôpital qui se fout de la charité. L’exemple le plus récent, c’est ce qu’ils ont fait avec la licence Java, mais là, on peut encore se rabattre sur un truc comme Eclipse Temurin si on n’a pas envie de se fatiguer avec du OpenJDK à la main.
Non, le meilleur parallèle qu’on puisse faire est ce qu’Oracle a fait à OpenSolaris et Solaris 11 lors du rachat de Sun : arrêt pur et simple d’OpenSolaris à la sortie commerciale de Solaris 11 (en mode « merci d’avoir testé ça pour nous les mecs, maintenant vous pouvez aller tous faire foutre ! »), et alors que Solaris 11 était prévu pour tourner sur à peu près tout ce que Sun supportait encore, une fois à sa sortie, ça ne fonctionnait que sur les dernières générations de matériel…
Sur ce coup là, IBM / Red Hat a raté une belle opportunité de souligner l’hypocrisie d’Oracle. Maintenant, le nouvel upstream des distros basées sur les cendres d’OpenSolaris est Illumos. C’est quelque chose qui pend au nez d’IBM, et Oracle a une carte à jouer et les moyens de devenir le nouvel upstream à la place de Red Hat (mais ce sont tellement des boulets qu’ils n’y arriveront pas, et n’auront jamais la confiance des contributeurs Open Source).
Même combat avec tout ce qui était Open Source chez Sun : OpenOffice.org (et le coup de génie à la Microsoft d’avoir renommé StarOffice 9 ou 10 en Oracle Open Office 3.0, histoire que les gens aient aient du mal à distinguer les 2 produits - on sait jamais, sur un malentendu, quelqu’un va peut être payer pour Open Office) qui a été supplanté par LibreOffice, MySQL dont le nouveau « standard » libre est MariaDB, et OpenZFS qui n’est plus compatible avec le ZFS d’Oracle…
#16
J’ai jamais croisé de Centos en production dans les domaines ou j’ai travaillés, qui étaient plutôt des grosses structures. Et de ce que j’ai vu dans mes derniers changement de systèmes, c’était plutôt pour y installer du RHEL à a place de Suse ou HP-UX.
Est ce que l’un d’entre vous ont déjà vu du Centos voir du Rocky linux en prod ?
#16.1
Dans le monde du HPC oui. Alors, peut-être pas dans les gros centres de calcul où ils n’ont aucun problème à sortir plusieurs centaines de milliers d’euros pour des licences, mais dans des structures plus modestes, c’est pas rare d’avoir les nœuds de service et quelques nœuds de calcul sous RHEL pour avoir du support en cas de problème (autant le support Red Hat, que le support d’éditeurs tiers dont les logiciels ne sont souvent officiellement supportés que sous RHEL ou SLE), et à côté de ça une flopée de nœuds de calcul anciennement sous CentOS, maintenant sous Rocky Linux.
#17
CentOS jusqu’à 7 oui, principalement parce que le client ne voulait pas payer de licence RHEL. Et pas de la petite entreprise, mais bien du grand groupe international. Les seules RHEL en place le sont par contrainte éditeur.
#18
Ce que ça sent, pour moi qui est toujours un béotien, c’est qu’IBM veut faire du Libre… moins libre, et de l’open source… moins open.
En deux mots : ça pue.
N’oubliez jamais qu’IBM, ca veut dire International Business Machines. Et ils ajoutent, au cas où t’aurais pas pigé : Corporation.
…Dire que Linus bosse pour eux ! C’est comme la bergerie qui dirait au loup : STP, mange-moi !
.
…
…. D’un autre côté, question puanteur, s’il veulent vraiment jouer à ce petit jeu, j’ai de quoi répliquer en force : j’ai un de ces stock de poissons… de quoi faire exploser leurs narines ! Ça leur changera de ce qu’ils y mettent habituellement !
#19
Dommage que personne ne lise attentivement le post #21.
Ca éviterait d’inventer des problèmes la où il n’y en a pas.
Car le problème qui fait gueuler tout le monde n’est ni légal, ni idéologique.
Non, il est bassement pragmatique. On peut le résumer en deux phrases:
Mais en fait c’est la situation actuelle qui est anormale, avec des distro qui sont des forks “nettoyés” de RHEL au lieu d’être des downstream de CentOS.
Prenez les navigateur web edge/opera/etc: ils sont construits en downstream de Chromium, et pas en forkant Chrome.
#19.1
Anormal est peut-être un grand mot… disons plutôt ‘pas ce que redhat souhaite’ … car il n’y a pas franchement de règle ou de standard sur ce point, et pendant des années c’était la situation par défaut. Ce n’est en outre pas en changeant régulièrement les règles unilatéralement que les ’re’distributions vont avoir confiance en RedHat.
#20
Je t’invite sérieusement à relire la définition d’une licence open-source
Oui, le lien, c’est wikipédia. Mais tu trouveras le même type de réponse sur le site de l”OSI ou de la FSF.
Ce point est identique pour les licences libre/open-source. La source doit être fourni à tout utilisateur qui en fait la demande. Il est d’usage dans beaucoup de cas de mettre à disposition la source à tout le monde (et pas seulement aux utilisateurs). C’est beaucoup plus commode que de devoir gérer la diffusion des sources au cas par cas.
Cf la définition de l’open-source
Absolument pas. La GPL est une licence libre et open-source. Du coup, elle est quoi, copyright ou copyleft ?
Tu confonds clairement open source et source available.
Et pour information, ce ne sont pas mes définitions, mais celles de l’Open Source Initiative et de la Free Software Foundation, les deux organismes à l’origine des appellations concurrentes.
Richard Stallman lui-même, quand il parle de la différence entre les deux, dit que la différence fondamentale entre les deux concepts se situent au niveau de leur philosophie :
#20.1
Merci pour la piqûre de rappel ;)
#21
Je vois plus dernière cette histoire de code source la pate d’IBM que celle RedHat. Et malheuresement depuis le rachat, ce genre de chose était plus ou moins à prévoire.
La réponse d’Oracle est elle, juste hallucinante au vu de la réputation de la boite.
Par contre je ne comprends ce que gagne Suse dans son fork.
Quel intérêt de créer et de soutenir le fork d’une distribution concurente ?
Coup de pub ?
Personellement, je vois l’inverse de certains d’entre vous : Full RedHat dans les sociétés où je suis passé. C’est vrais que quand j’étais en conctacte avec des administrations j’ai vu un peu Ubuntu mais je n’ai jamais vu de Suse.
Bien que je ne connaisse personne qui y bosse il paraît qu’il y a un vague département « Windows », je connais pas trop ce truc, c’est bien il y en a qui l’utilise ?
Par contre pour y avoir été rataché pendant quelque mois (truc illogique mais les réorg …) je vous certifie qu’il y a encore de l’AIX d’IBM.
#22
Pas tout à fait exact : en aval de centos streams, le code est restabilisé recontrôlé et potentiellement enrichi avec des backports spécifiques et des patches dédiés (pour des questions de stabilité ou de sécurité)… par exemple suite à un problème observé chez un client …
Une preuve simple à comprendre: comment Centos streams peut-il être l’upstream de RHEL quand, par exemple, Centos Streams 8 se retrouve EOL en mai 2024 alors que RHEL 8 aura encore des mises à jour jusqu’en 2029 …
En mai 2027, Il en sera de même pour RHEL 9.x qui continuera en phase de support 2 tandis que Centos Streams 9 s’arrêtera net.
#23
Mais si: bien sûr que RHEL est stabilisée, mais les patchs apportés pendant cette stabilisation sont versés sur l’upstream. C’est ce qui est expliqué dans le post que j’avais cité plus haut, et également dans le blog de redhat:
Ce côté “stable” de RHEL comparé à Streams ne provient que d’une chose: du cycle de release. Pas du code.
Alors, je n’ai pas trouvé écrit noir sur blanc ce qui se passera en 2024 ou 2027, mais je ne vois pas en quoi ça changerait, et il ne faut pas confondre code source et releases. Le EOL de Streams signifie qu’il n’y aura plus de builds et de release. Mais la base de code étant la source de RHEL, elle va continuer à vivre, et pourra donc aussi être utilisée par les rebuilds - je ne vois pas pourquoi redhat changerait le process de build de RHEL à cause du EOL de Streams. Si c’était le cas en effet ce serait négatif pour l’open-source et le modèle poussé par redhat, mais je ne vois pas d’indice disant que ça fonctionnerait autrement après l’EOL de Streams.
Bref, il y a encore beaucoup de confusion .. ce qui n’est pas étonnant vu les erreurs qu’on peut lire partout. Cet article de nextinpact aussi en comporte quelques unes - j’en ai signalées hier mais pour l’instant je ne vois aucune modif de l’article. Ce que je relève:
C’est faux: ce sont les sources du “vieux” centos (qui étaient jusque là maintenues pour les rebuilds) qui sont concernées.
C’est faux: on confond ici CentOS Stream et RHEL. CentOS Stream n’est pas verrouillé. La polémique porte sur RHEL.
C’est encore faux: la licence permet d’accéder aux SRPMs de RHEL. Les sources “upstream”, qui sont celles de CentOS Stream, restent 100% accessibles. Et ce sont essentiellement les mêmes, y compris pour les mises à jour de sécurité, ou dans le cas spécifique d’un embargo, à la fin de la période d’embargo.
Il faut bien comprendre que la différence entre CentOS Stream et RHEL ne vient pas des sources (à part des éléments cosmétiques), mais bien du cycle de release et du support.
#23.1
Ok, je confirme , tu as raison et j’ai tort.
J’ai revérifié quelques dépôts git pour Centos 8 Streams et effectivement, RedHat est plutôt très vertueux.
Reste que le passage intégral vers git est bien plus intéressant pour organiser de pipelines de build que les SRPM, mais je peux imaginer pourquoi ça fait râler ceux qui avaient construit leurs chaînes autour des srpm.
Bref, hormis la communication déplorable de RedHat, c’est globalement un mauvais procès qu’on lui fait.
Reste à savoir si les choses ne vont pas encore changer, mais si c’est juste un accès public aux srpm’s, il n’y a vraiment pas de quoi pousser des cris…
#23.2
Merci pour tes contributions. Ça clarifie bien le sujet.
Pour ma part, au delà de la communication foireuse, je trouve que ça reste honnête. Redhat contribue énormément au libre, c’est normal d’en attendre un retour.
J’ai du mal à voir d’autres raison que la gratuité à vouloir utiliser des clones plutôt que du rhel en direct.
Pour palier le problème de release, il suffit de faire comme toute boite sérieuse le devrait (ce qu’on fait dans mon job actuel). Un ou plusieurs environnements de staging avant de passer en production. Chaque environnement étant connecté à un snapshot du miroir décalé dans le temps. Et c’est autant vrai pour du CentOS que pour du Redhat ou de l’Ubuntu.
#24
Le changement ça fait peur, on râle, on s’agite, et puis finalement on s’adapte, à voir dans quelques mois/années ce qui sortira de toute cette affaire.
Dans le même style, Fedora qui annonce une volonté de mettre en place de la télémétrie activée par défaut dans Fedora 40 se tire une balle dans le pied, ils ont bien tenté d’être rassurant, prendre des précautions, le présenter de manière aussi transparente que possible … C’est partie instantanément en mode Fedora spyware, Fedora evil etc …
#24.1
Ben pour le coup de la télémétrie, il faut voir à quel public fedora s’adresse d’habitude… ce n’est pas une shitstorm inmprévisible pour le coup…
#25
Hors gratuité, c’est les mêmes raisons pour lesquelles on peut avoir 25 cageots de dérivés d’Ubuntu…
Mais pour le monde des serveurs on aura pas des variations sur les thèmes ou les couleurs de fenêtrage, ou une interface pour les gens qui n’aiment que l’interface de windows 8 …
… des addons intéressants … des tunings du noyau plus orienté vers certains secteurs d’activité…
Scientific Linux, par exemple, apportait son lot d’outils et de filesystems pour du HPC…
… mais il est clair que les gesticulations autour de centos ont quand-même plombé l’écosystème et l’appauvrissement par rapport à il y a 10-15 ans est très tangible.
#26
https://rockylinux.org/news/keeping-open-source-open/
#27
Il est où cet avis ANSSI ? Je ne le trouve pas.
#28
Suite de l’histoire : Alma linux annonce se lancer et faire une “vraie” distro rhel-compatible basée sur centos stream, et plus un simple clone : https://almalinux.org/blog/future-of-almalinux/