RHEL et l’open source : l’essentiel sur la décision controversée de Red Hat
En décidant de limiter l’accès au code de sa distribution supportée de Linux, Red Hat poursuit sa stratégie de mise en avant de « l’open source d’entreprise », quitte à se mettre à dos la communauté… Et, peut-être, une partie de ses clients.
Le 21 juin dernier, Red Hat annonçait un changement à l’allure anodine. Dans un texte d’un peu plus de 2 000 signes, Mike McGrath, vice-président Core Platforms chez Red Hat, informait que CentOS Stream serait « désormais le seul dépôt pour les versions publiques du code source liées à RHEL ».
En clair, après avoir abandonné CentOS Linux au profit de CentOS Steam, Red Hat a décidé d’arrêter l’envoi des « sources correspondantes complètes », des paquets open source utilisés pour recompiler des fourches de RHEL, vers les serveurs FTP git.centos.org.
Pour rappel, en 2014, Red Hat était devenu le berceau de la communauté CentOS Linux, en partie pour distinguer les versions supportées de son OS des distributions non prises en charge.
En dévoilant la fin de vie de CentOS Linux à la fin de l’année 2020, le fournisseur a changé de modèle. Il a instauré un système qui sépare clairement l’amont (le développement), de l’aval (la distribution supportée) de RHEL pour des raisons apparentes d’amélioration des processus de développement.
Alors que CentOS Linux est une distribution dérivée de RHEL légèrement tronquée et non supportée, son substitut – CentOS Stream – est une préversion de Red Hat Linux Enterprise (et downstream de Fedora), une distribution compilée à des fins de développement et de test. Red Hat lui-même déconseille d’utiliser cette distribution expérimentale dans des environnements de production.
Si CentOS Stream peut servir dans des environnements de développement, les entreprises avaient l’habitude d’adopter CentOS Linux dans ce contexte, et de déployer des versions de RHEL supportées par Red Hat en production.
Après l’annonce de 2020 qui avait déjà suscité un tollé, la communauté open source s’était rapidement rassemblé autour de quelques projets « clonés » de RHEL, dont AlmaLinux et Rocky Linux. Tant que Red Hat poursuivait les envois de paquets vers git.centos.org, ces communautés pouvaient rebâtir une image d’un OS open source pro.
Du côté des entreprises, ce changement de politique avait suscité une effervescence sachant que la fin de vie de CentOS Linux est prévue en 2024. À noter que, le 29 juin, le support de cycle de vie étendue de RHEL 7.9 a été repoussé jusqu’à 2028. Si la plupart des organisations regardaient jusqu’alors du côté de la concurrence (SUSE, Ubuntu, Oracle Linux, Amazon, etc.), une partie d’entre elles ont décidé de se ranger à la cause d’Alma Linux et de Rocky Linux.
Deux ans plus tard, certaines d’entre elles, dont le CERN, discutent avec les responsables des communautés pour trouver une solution à l’ultimatum imposé par Red Hat.
Red Hat réduit l’accès au code source de RHEL
Depuis le 21 juin 2023, non seulement le code source complet de RHEL n’est plus accessible sans souscrire à une licence (gratuite ou payante) depuis le Red Hat Customer Portal, mais Red Hat n’a plus l’intention de faire actualiser les dépôts qui permettaient de mettre à jour toutes les fork dérivées de RHEL.
Les réactions ne se sont pas fait attendre sur la toile, forçant Mike McGrath à sortir de son silence pour préciser la pensée de Red Hat le 26 juin dernier. L’effort de communication n’a pas rassuré tous les utilisateurs.
Certains fervents de l’open source reprochent à Red Hat de jouer avec les principes de la licence GPL en assurant que l’éditeur propose désormais un OS « closed source ». Mike McGrath a réfuté cette affirmation en assurant que le code source de CentOS Stream – une bonne partie constitutive de RHEL, donc – est accessible depuis un dépôt GitLab. « Nous enverrons toujours notre code en amont et nous respecterons les licences open source que nos produits utilisent, y compris la GPL », martèle-t-il.
Si l’éditeur continue et continuera à patcher les versions upstreams de RHEL, à savoir Fedora et CentOS Stream, Red Hat ne veut plus simplifier le travail des « rebuilders », ceux qui recompilent les paquets libres pour créer des distributions en aval de RHEL.
« Nous ne trouvons pas de valeur à une recompilation de RHEL et nous ne sommes pas obligés de faciliter la tâche des rebuilders ; c'est à nous qu'il appartient de prendre cette décision ».
Mike McGrathVice-Président, Core Platforms, Red Hat
« Nous ne trouvons pas de valeur à une recompilation de RHEL et nous ne sommes pas obligés de faciliter la tâche des rebuilders ; c’est à nous qu’il appartient de prendre cette décision », argumente-t-il.
Une opinion partagée par Magnus Glantz, principal solutions Architect chez Red Hat qui considère, pour sa part, que « la nature même de l’existence de Rocky Linux est problématique ». Les créateurs du projet alternatif à CentOS offrent également une distribution commerciale via la société CIQ sans contribuer au code de Linux en retour, affirme-t-il.
Red Hat jongle avec la notion de « copyleft », déplore la communauté
Cette position de l’éditeur semble entrer en conflit avec la notion de copyleft porté par la GPLv2, l’une des licences attenantes à RHEL.
« Chaque fois que vous redistribuez le programme (ou tout travail basé sur le programme), le destinataire reçoit automatiquement une licence du donneur de licence original pour copier, distribuer ou modifier le programme sous réserve des présentes conditions », peut-on lire dans le texte de la licence GNU GPL v2. « Vous ne pouvez pas imposer d’autres restrictions à l’exercice par les destinataires des droits accordés par les présentes. Vous n’êtes pas responsable du respect de la présente licence par les tiers ».
Un texte repris quasi in extenso dans le contrat de licence de l’utilisateur final formalisé par Red Hat.
Selon l’analyse de Bradley M. Kuhn développeur et directeur de l’organisation Software Freedom Conservancy, l’éditeur ne contrevient pas aux principes du copyleft. En revanche, « Red Hat (aujourd’hui filiale à part entière d’IBM) expérimente la construction d’un modèle commercial pour le déploiement et la distribution d’un OS qui ressemble, se vit et se comporte comme un modèle propriétaire, mais qui respecte néanmoins la GPL et d’autres conditions standard du copyleft ».
« Les débats se poursuivent, même aujourd’hui, dans les cercles d’experts du copyleft, sur la question de savoir si ce modèle viole la GPL. Il ne fait cependant aucun doute que cette disposition n’est pas dans l’esprit des accords GPL. Le modèle commercial de RHEL est inamical, fallacieux, capricieux et digne d’être critiqué », écrit-il.
Dans un communiqué de presse, les porte-parole de Rocky Linux reprennent cet argument à leur compte en ajoutant que « les conditions de service (TOS) et les accords de licence d’utilisateur final (EULA) de Red Hat imposent des conditions qui tentent d’empêcher les clients légitimes d’exercer leurs droits tels qu’ils sont garantis par la GPL ».
En sus des informations disponibles dans le contrat de licence de l’utilisateur, les annexes de souscriptions de logiciels et de supports consultées par LeMagIT (table 12c, alinéa g) semblent confirmer les dires de Rocky Linux, AlmaLinux et de Bradley M. Kuhn.
Les clones se rebiffent : AlmaLinux et Rocky Linux à la recherche d’alternatives
Les deux communautés cherchent donc des solutions pour maintenir l’existence de leurs distributions Linux.
En ce qui concerne les patchs de sécurité, les responsables d’AlmaLinux ont décidé de s’appuyer sur les mises à jour de CentOS Stream et d’Oracle Linux. « Ces mises à jour seront soigneusement sélectionnées pour s’assurer qu’elles sont totalement compatibles avec RHEL, tout en ne violant pas les licences de Red Hat […] », écrit le 22 juin Benny Vasquez, membre du comité de direction d’AlmaLinux OS Foundation.
Le 30 juin, Jack Aboutboul, responsable de la communauté chez AlmaLinux, prévient que ce « processus est plus laborieux » qu’auparavant. « Nous devons rassembler des données et des correctifs provenant de plusieurs sources, les comparer, les tester, puis les créer pour les publier. Soyez assurés que les mises à jour continueront à circuler comme elles l’ont fait jusqu’à présent ».
En conséquence de la décision de Red Hat, Rocky Linux doit « rassembler le code source à partir de sources multiples, y compris CentOS Stream, les paquets amont vierges et les SRPM RHEL », notent de leur côté les responsables du projet Rocky Linux.
Ceux-là explorent d’autres méthodes qui, en principe, contournent la nécessité d’accepter les conditions commerciales de Red Hat. La première consiste à exploiter des images de conteneurs UBI basés sur RHEL, disponibles à travers Docker Hub, entre autres. « Il est facilement possible d’obtenir des sources Red Hat de manière fiable et sans encombre. Nous avons validé cette méthode à l’aide de conteneurs OCI (Open Container Initiative) et elle fonctionne exactement comme prévu », note-t-il.
L’autre technique consisterait à utiliser des instances cloud à la demande. « Ainsi, n’importe qui peut créer des images RHEL dans le cloud et obtenir ainsi le code source de tous les paquets et errata ».
La solution semble toutefois temporaire.
« Nos conseillers juridiques nous ont assuré que nous avons le droit d’obtenir les sources de tous les binaires que nous recevons, ce qui nous permet de continuer à faire progresser Rocky Linux conformément à nos intentions initiales », assurent les porte-parole de Rocky Linux.
Chez CloudLinux, le fournisseur d’une distribution commerciale d’AlmaLinux (et auparavant de CentOS Linux) destiné aux serveurs d’hébergement mutualisé, le problème se pose différemment. L’entreprise va d’abord assurer les mises à jour de sécurité et dix ans de support pour les deux dernières versions en date de son OS, puis évaluera si elle souhaite apporter une distribution fidèle à RHEL ou non.
La primeur à l’open source d’entreprise
La situation est-elle vraiment surprenante ? Les annonces effectuées en 2020 et 2021 par Red Hat présentaient des signes avant-coureurs. L’éditeur affirmait déjà vouloir donner la priorité à ses partenaires et à ses clients, tout en assurant que les développeurs peuvent souscrire à une licence gratuite permettant de déployer RHEL sur 16 serveurs. Selon les dires de Mike McGrath sur LinkedIn, « Red Hat fait aussi la chasse aux “freeloaders”, un terme non officiel utilisé en interne pour désigner des entreprises ayant 20 licences, mais plus de 150 000 builds communautaires ». En clair, à ceux qui, selon l’avis de Red Hat, abuseraient du système.
Si en principe, la situation affecte peu ou pas du tout les utilisateurs des distributions commerciales de Red Hat, la filiale d’IBM risque d’écorner considérablement son image de défenseur de l’open source. Et ce, malgré les nombreuses contributions monétaires et humaines à une longue liste de projets, Linux compris.
« À mon humble avis, c’est un problème pour Red Hat créé par Red Hat qui n’intéresse que les clients Red Hat et ses compétiteurs », tranche Philippe Ombrédanne, CTO de nexB, une société spécialisée dans l’audit de logiciels tiers et open source, et cofondateur du projet SPDX.
Par cette décision, l’éditeur chercherait à poursuivre le bras de fer avec ses concurrents, dont Canonical, SUSE, Ubuntu, AWS ou encore Microsoft tout en se débarrassant des clones.
« Bien que les changements dans le paysage de l'open source puissent modifier la dynamique, nous croyons fermement que la liberté d'accéder, de modifier et de distribuer des logiciels doit rester ouverte à tous ».
Thomas Di GiacomoCTO & CPO, SUSE
L’annonce de Red Hat a notamment fait réagir Thomas Di Giacomo, CTO et CPO chez SUSE. « Bien que les changements dans le paysage de l’open source puissent modifier la dynamique, nous croyons fermement que la liberté d’accéder, de modifier et de distribuer des logiciels doit rester ouverte à tous », avance-t-il pour le compte de SUSE.
Dans les faits, Red Hat n’a pas de problème avec SUSE qui, selon les dires de Mike McGrath, « joue à la loyale ».
« Dans un écosystème open source sain, la concurrence et l’innovation vont de pair. Red Hat, SUSE, Canonical, AWS et Microsoft créent tous des distributions de Linux avec des marques associées et des efforts de développement de l’écosystème », déclare-t-il. « Ces variantes utilisent et contribuent toutes au code source de Linux, mais aucune ne prétend être “entièrement compatible” avec les autres ».
« Les clones comme Alma et Rocky qui se veulent les descendants de CentOS sont les cibles principales et elles trouveront un moyen de contourner ces limitations », réagit de son côté Philippe Ombrédanne.
Or certaines entreprises, sous l’influence de responsables IT qui ont pu faire part de leur agacement, pourraient se tourner vers l’alternative Debian et un de ses dérivés tels Ubuntu, qui est supporté commercialement par Canonical.
« En pratique, les distributions les plus utilisées dans le monde du cloud sont Debian et Alpine, pas CentOS, pas RHEL, pas Fedora et cela ne risque pas s’améliorer avec ce type d’annonces », estime le CTO de nexB.
Avec l’émergence des conteneurs et de Kubernetes, les développeurs attachés à l’open source se tourneraient vers des alternatives comme NixOS.
Dans la veine des décisions d’Elasticsearch et de MongoDB, l’on observe là un fossé entre « open source d’entreprise » et open source communautaire. Un schisme qui s’avère généralement peu profitable aux deux bords.
