Retour

2025/04/11

9. Réflexion sur la décision de Red Hat de retenir le code source

Dans son article de blog daté du 21 juin 2023, «
Poursuivre l’évolution de CentOS Stream », Red Hat a annoncé qu’il limiterait la publication du code source de Red Hat Enterprise Linux (RHEL) aux seuls clients et partenaires.

Depuis lors, ce sujet a été couvert par de nombreux sites d’actualités, et les fournisseurs et communautés qui développent des clones de RHEL, tels qu’Oracle, AlmaLinux et Rocky Linux, ont réagi fortement à cette décision.

Que signifie l’annonce de Red Hat ? Pourquoi a-t-elle provoqué une telle réaction ? Pour le comprendre, il est nécessaire de connaître l’histoire de Linux, la manière dont les distributions sont développées et les licences impliquées.

Ici, nous examinerons simplement ce récent tumulte, y compris la signification de l’annonce de Red Hat, les réactions des autres entreprises et les prévisions des tendances futures.

Comprendre l’annonce de Red Hat

Pour comprendre cette annonce, il faut d’abord comprendre CentOS Stream. Examinons cette annonce tout en présentant CentOS Stream.

Annonces de Red Hat/IBM liées à CentOS

Pour avoir une vue d’ensemble, revenons sur la situation de CentOS.

  • 2004 : Première version de CentOS
  • 2014 : Red Hat acquiert CentOS
  • 2019 : IBM acquiert Red Hat
  • 2020 : Fin du projet CentOS annoncée
  • 2021 : En réponse à l’arrêt du développement de CentOS, la communauté lance AlmaLinux et Rocky Linux
  • 2023 : Le code source de RHEL sera disponible uniquement pour les clients et partenaires

CentOS a une histoire étonnamment longue, remontant à la version 2.0 en 2004. À l’époque, il existait plusieurs distributions compatibles avec RHEL, et elle n’était pas aussi établie qu’aujourd’hui. En particulier, Scientific Linux a été utilisée pendant de nombreuses années et a existé jusqu’en 2020. Oracle Linux a été lancé en 2006.

En 2014, Red Hat a acquis CentOS, qui était jusque-là un projet indépendant. Cela a suscité des avis pour et contre, mais je me souviens qu’il y avait beaucoup de voix pour accueillir cette décision, surtout parce que la sortie de CentOS était quelque peu retardée à l’époque.

En 2019, IBM a acquis Red Hat. Comme vous le savez tous, CentOS allait subir une transformation majeure à partir de ce moment.

La fin de CentOS et la transition vers CentOS Stream

Le début de ce grand changement a été l’annonce de la fin du projet CentOS en 2020. Comme mentionné précédemment dans « Partie 8 : Passer de CentOS à Oracle Linux », le projet CentOS a pris fin et a été remplacé par CentOS Stream (le support pour CentOS 7 se terminera le 30 juin 2024, et celui de CentOS 8 est déjà terminé).

La raison pour laquelle cela a causé un tel émoi est que CentOS Stream a été positionné comme l’amont (upstream) de RHEL.

Jusqu’à présent, CentOS était populaire en tant que distribution gratuite compatible avec RHEL. Cependant, avec l’arrivée de CentOS Stream, elle ne peut plus être qualifiée de distribution compatible avec RHEL. De plus, CentOS Stream utilise une méthode de publication continue (rolling release). Par conséquent, elle doit toujours être à jour, ce qui la rend difficile à utiliser dans des environnements de production.

C’est ce qu’on appelle le « choc CentOS ».

L’annonce de Red Hat

Red Hat a publié les deux blogs suivants concernant la divulgation du code source :

Tout d’abord, nous présenterons les parties importantes de « Poursuivre l’évolution de CentOS Stream ». Puisque divers articles de presse l’expliquent en détail, nous l’avons raccourci ici pour privilégier la clarté plutôt que la précision de la traduction.

À mesure que la communauté CentOS Stream grandit et que le monde des logiciels d’entreprise fait face à de nouvelles dynamiques, nous voulons affiner notre focus sur CentOS Stream comme colonne vertébrale de l’innovation Linux en entreprise. Nous poursuivons nos investissements et renforçons notre engagement envers CentOS Stream.

À mesure que la communauté CentOS Stream croît et que les logiciels d’entreprise adoptent de nouvelles dynamiques, nous continuerons d’investir et de renforcer nos efforts dans CentOS Stream.

Red Hat a indiqué son engagement envers CentOS Stream, et dans le paragraphe précédent, il mentionne que certaines personnes accueillent favorablement la sortie rapide des versions en amont.

CentOS Stream est apparu comme une option dynamique et tournée vers l’avenir. Certaines personnes peuvent l’accueillir favorablement. Cependant, il est important de se rappeler qu’il existe également une demande en aval pour une compatibilité totale avec RHEL. Surtout pour une utilisation en entreprise, la stabilité est souvent plus importante que le changement et l’innovation.

CentOS Stream sera désormais le seul référentiel pour les publications publiques du code source lié à RHEL. Pour les clients et partenaires de Red Hat, le code source restera disponible via le portail client de Red Hat.

CentOS Stream sera le seul référentiel pour les publications publiques du code source lié à RHEL à l’avenir, et les clients et partenaires de Red Hat continueront d’avoir accès au code source via le portail client de Red Hat.

Le texte original met également cela en gras. C’est une manière détournée de dire les choses, mais en termes simples, cela signifie que « le code source de CentOS Stream sera rendu public, mais celui de RHEL ne le sera pas ».

Ensuite, il y a « L’engagement de Red Hat envers l’open source : Une réponse aux changements sur git.centos.org ».

Ceci est un résumé de la première moitié de l’article. Le texte original est long, donc il a été omis.

Red Hat adopte un modèle de développement open source, et le développement de nouvelles fonctionnalités, les corrections de bogues, le rétroportage de correctifs et divers tests engendrent beaucoup de coûts. De plus, c’est une tâche minutieuse de toujours gérer 3 à 4 versions majeures et de rétroporter des correctifs sur un code vieux de 5 à 10 ans. En outre, il est nécessaire de refléter les projets en amont tels que Fedora et le projet du noyau Linux.

Je ressens que beaucoup de colère suite à notre récente décision concernant les sources en aval vient soit de ceux qui ne veulent pas payer pour le temps, l’effort et les ressources investis dans RHEL, soit de ceux qui veulent le reconditionner pour leur propre profit. Cette demande pour le code RHEL est malhonnête.

Je suis exaspéré par la malhonnêteté des distributions compatibles avec RHEL qui se contentent de reconstruire le code source de RHEL sans y contribuer.

Il y a ici une dénonciation du « free riding » (profiter sans contribuer).

Les logiciels open source se sont développés pour diverses raisons. La principale raison de leur développement est probablement les avantages pour les utilisateurs, comme le fait qu’ils peuvent être utilisés gratuitement ou à faible coût, et qu’il n’y a pas de verrouillage par un fournisseur car le code source est publiquement disponible. Cependant, il y a aussi des avantages pour les développeurs. La qualité s’améliore à mesure que plus d’utilisateurs signalent des bogues, le développement progresse avec l’augmentation du nombre de membres du développement, et le nombre d’utilisateurs augmente lorsque la documentation et les informations techniques sont disponibles dans plusieurs langues.

Ces dernières années, le « free riding » est devenu un problème sur les méga-clouds comme Amazon Web Services. Redis, Elasticsearch, MongoDB et d’autres services ont changé leurs licences en opposition au « free riding » sur les méga-clouds.

Nous fournissons également des abonnements Red Hat Developer gratuits et Red Hat Enterprise Linux (RHEL) pour l’infrastructure open source. L’abonnement développeur fournit RHEL gratuitement aux développeurs et permet une utilisation jusqu’à 16 systèmes, encore une fois, sans coût. Cela peut être utilisé par des individus pour leur propre travail et par les clients RHEL pour le travail de leurs employés.

Nous offrons des abonnements Red Hat Developer et Red Hat Enterprise Linux pour l’infrastructure open source (services pour la communauté de développement open source) sans frais.

Bien que les conditions d’utilisation le rendent assez limité, RHEL propose un programme gratuit pour certains utilisateurs.

Pourquoi cela a-t-il reçu une si forte réaction ?

La cause de ce tumulte est que « CentOS, qui peut être utilisé gratuitement en tant que compatible avec RHEL, n’existera plus » et « le code source lié à RHEL autre que CentOS Stream ne sera pas rendu public ». Approfondissons un peu cela. Nous expliquerons comment créer une distribution compatible avec RHEL et la GPL.

Comment créer une distribution compatible avec RHEL

Le diagramme ci-dessous montre comment créer une distribution compatible avec RHEL. Les distributions compatibles avec RHEL ont été développées à partir du code source (SRPM) de RHEL ou de CentOS. Beaucoup de distributions étaient basées sur CentOS, qui est exempt de restrictions de droit d’auteur et facile à modifier.

Le problème est de savoir comment la créer à l’avenir. Le code source de RHEL est limité à des utilisateurs spécifiques tels que les clients et les partenaires. Seul CentOS Stream est devenu un référentiel de code source accessible à tous. Cependant, CentOS Stream est l’amont de RHEL. Reconstruire la source de CentOS Stream ne la rendra pas compatible avec RHEL.

GPL et l’accord d’entreprise Red Hat

Le noyau Linux est un programme sous licence GPL v2. Certains pourraient trouver étrange de ne pas publier le code source car Linux est sous GPL. Voici une brève explication de la GPL et de l’accord d’entreprise Red Hat, qui sont importants pour comprendre la licence RHEL.

La GPL est une licence très puissante avec les caractéristiques suivantes : Les clauses de la GPL ont été traduites en japonais par des bénévoles, mais certaines parties sont difficiles à comprendre et sujettes à des interprétations différentes, alors considérez cela comme approximatif.

  • Utilisation commerciale autorisée
  • L’auteur n’assume aucune responsabilité
  • Inclure les avis de droit d’auteur et aucune garantie.
  • Le code source doit être rendu public lors de la distribution
  • Si vous créez un logiciel qui utilise tout ou partie d’un programme sous licence GPL, vous devez également le distribuer sous GPL.

La partie importante à noter est celle qui dit « Il y a une obligation de rendre le code source public au moment de la distribution ». L’interprétation générale est que « quiconque possède le code objet (code binaire) a le droit d’obtenir le code source ». Cependant, on peut aussi dire que « quiconque n’a pas le code objet n’a pas le droit d’obtenir le code source ».

Pour donner un exemple concret, disons qu’une entreprise développe un programme qui utilise un logiciel GPL modifié uniquement en interne. Bien que ce logiciel soit sous GPL, il n’est pas rendu public, donc il n’y a pas besoin de publier le code source, y compris les parties modifiées, au public.

Bien que la GPL ait des caractéristiques fortes concernant la divulgation du code source, elle présente les caractéristiques ci-dessus. Par conséquent, Red Hat impose certaines restrictions à ses clients en concluant un accord d’entreprise Red Hat avec eux. Bien que nous n’entrerons pas dans les détails de l’accord d’entreprise Red Hat, il contient de nombreuses clauses restrictives.

Réactions des fournisseurs et des projets

En réponse à l’annonce de Red Hat, les fournisseurs et projets développant des distributions compatibles avec RHEL ont publié diverses déclarations. Voici quelques-unes d’entre elles.

AlmaLinux

AlmaLinux est un projet lancé par CloudLinux, une entreprise ayant une expérience en tant que système d’exploitation Linux pour l’hébergement. Ce fut la première sortie après le projet CentOS. Trois articles de blog ont été publiés rapidement successivement.

Voici un résumé :

  • Les RPM source compatibles avec RHEL sont plus difficiles à obtenir, mais les mises à jour de sécurité sont disponibles plus rapidement.
  • Maintenir une position en aval de RHEL, mais abandonner la compatibilité 1:1 avec RHEL, et viser la compatibilité binaire
  • Contribuer à l’ensemble de l’écosystème Linux d’entreprise, y compris la communauté open source et les plateformes en amont telles que Fedora et CentOS Stream.

Le deuxième blog explique comment suivre les mises à jour de sécurité en utilisant OpenSSL comme exemple. Cybertrust (MIRACLE LINUX), qui développe des distributions compatibles avec RHEL au Japon, a annoncé un partenariat avec CloudLinux, le principal sponsor d’AlmaLinux.

Rocky Linux

Rocky Linux est un projet fondé par Gregory Kurtzer, le fondateur du projet CentOS. Le support est fourni par CiQ, une entreprise fondée par Gregory Kurtzer. Ce projet publie également trois blogs.

Voici un résumé :

  • Compatibilité à 100 % avec RHEL jusqu’au niveau des bogues
  • Accomplir notre mission de fournir une distribution compatible avec RHEL stable et durable
  • Contribuer à l’ensemble de l’écosystème Linux d’entreprise, y compris la communauté open source et les plateformes en amont telles que Fedora et CentOS Stream.
  • Bien que les conditions de service et les accords de licence utilisateur final de Red Hat restreignent les droits accordés par la GPL, le site fournit des moyens légaux d’obtenir le code source (en utilisant l’image de conteneur Red Hat Universal Base Image et en utilisant des instances à paiement à l’usage sur les clouds publics).
  • Lancement de OpenELA, un projet pour promouvoir Enterprise Linux, avec Oracle et SUSE.

Oracle

Oracle, le développeur d’Oracle Linux, a publié les nouvelles suivantes :

Certains contenus sont un peu sarcastiques par rapport à AlmaLinux et Rocky Linux, mais l’essentiel est le suivant :

  • Il est impliqué dans la communauté Linux depuis 25 ans, avec pour objectif d’en faire le meilleur système d’exploitation serveur gratuit pour tous.
  • Oracle a lancé Oracle Linux en 2006, choisissant la compatibilité avec RHEL pour éviter de diviser la communauté Linux.
  • Nous avons respecté la GPL et rendu nos binaires et codes sources ouverts. Contrairement à IBM (Red Hat), nous n’interférons pas avec les droits des utilisateurs via des contrats d’abonnement.
  • L’intention de ne pas divulguer le code source cette fois vise-t-elle à éliminer les concurrents ?
  • Continuer à maintenir la compatibilité avec RHEL dans la mesure du possible
  • Oracle continuera de contribuer à la communauté Linux et publiera les binaires et le code source. Les distributions en aval sont les bienvenues.

SUSE

Enfin, il y a SUSE. Bien qu’elle soit une distribution basée sur RPM, elle n’était pas compatible avec RHEL, mais elle a annoncé qu’elle entrerait sur le marché des distributions compatibles avec RHEL.

Conclusion

Red Hat a sans aucun doute été le leader sur le marché du Linux d’entreprise. De plus, les contributions de l’entreprise à la communauté open source, pas seulement à Linux, sont incommensurables. C’est pourquoi cette annonce a été une surprise.

Bien que seulement trois mois se soient écoulés depuis l’annonce de Red Hat, les autres entreprises ont réagi rapidement. Non seulement tous les principaux fournisseurs de distributions compatibles avec RHEL ont annoncé leurs contre-mesures, mais même SUSE, qui a une forte part de marché en Europe, a annoncé sa participation. Par conséquent, il est peu probable que les distributions compatibles avec RHEL disparaissent ou que les correctifs de sécurité soient considérablement retardés.

Ce cas me rappelle le « procès SCO contre Linux » qui a duré de 2003 à 2010. Commençant par SCO, le détenteur des droits d’auteur de Linux, poursuivant IBM, cela s’est étendu à des poursuites contre Novell et Red Hat, et a même laissé entendre des poursuites contre les utilisateurs généraux de Linux. En plus d’être fortement critiqué dans le monde entier, SCO n’a remporté aucun procès et a fini par payer une énorme somme en frais juridiques.

Cette fois, il n’y a pas la malveillance de type troll de brevets de SCO. Cependant, il est peu probable que quelque chose qui aura beaucoup d’opposants dans le monde de l’open source réussisse. Cependant, il y a aussi un besoin pour CentOS Stream en tant qu’amont, donc une coexistence avec le camp en aval compatible avec RHEL pourrait être tentée.