Discussion :

[Stéphane le calme]

« J'en ai terminé avec Red Hat (Enterprise Linux) ». Un développeur estime que l'entreprise a trahi la communauté des utilisateurs de Linux,
en mettant le code source de RHEL derrière un paywall

Red Hat est sous une pluie de critiques après avoir suspendu la publication des sources publiques de Red Hat Enterprise Linux (RHEL) sur git.centos.org pour consacrer CentOS Stream comme seul référentiel. Jeff Geerling fait partie de ceux qui ont décidé d'exprimer leur colère. Il affirme que Red Hat viole l’esprit de l’open source et menace les distributions alternatives comme Rocky Linux et AlmaLinux, qui se basent sur le code source de RHEL. Il annonce qu’il ne va plus maintenir le support officiel de RHEL pour ses projets open source, et qu’il va privilégier les autres distributions Linux comme Fedora, Arch, Ubuntu ou Debian.

Il y a deux ans, Red Hat a tué CentOS, une version gratuite largement utilisée de sa distribution Enterprise Linux.

La communauté des utilisateurs de CentOS - moi y compris - a été qualifiée de « freeloaders », utilisant le travail de la toute-puissante société Red Hat, sans rien apporter en retour. Ne vous occupez pas de tous les développeurs open source, contributeurs du noyau Linux et développeurs de logiciels qui ont utilisé CentOS pour tester et créer leur logiciel. Ignorez également le fait que Red Hat construit son produit sur Linux, qu'il n'a pas construit et qu'il ne possède pas.

J'ai presque radié Red Hat à l'époque. C'était comme si quelqu'un me plantait un couteau dans le dos.

La semaine dernière, Red Hat a pris ce couteau et l'a fortement tordu, lorsqu'ils ont publié cet article de blog. Ne nous y trompons pas : cela visait à détruire les distributions que la communauté avait construites pour remplacer ce que Red Hat avait emporté.

Il n'y avait que deux choses qui m'ont retenu après que Red Hat nous ait trahis la première fois : premièrement, au lieu d'attaquer la communauté des utilisateurs open source, de nombreux Red Hatters ont tendu la main et ont demandé : « Comment pouvons-nous faire mieux ? » Cela n'a pas guéri la blessure, mais cela signifiait quelque chose, sachant que quelqu'un chez Red Hat écouterait au moins.

Deuxièmement, et plus important encore, Rocky Linux et AlmaLinux sont intervenus. Ils ont empêché un exode massif de l'écosystème Red Hat, offrant aux développeurs comme moi une cible stable pour mon travail open source. Mais Rocky et Alma comptaient sur Red Hat pour partager leur code source.

Voici comment cela fonctionnait :

1. Red Hat s'emparerait d'une copie de Linux
2. Ils ajouteraient la sauce magique qui en fait Red Hat Enterprise Linux
3. Ils publieraient une nouvelle version
4. Ils mettraient à jour un référentiel de code source avec toutes les données nécessaires pour le construire à partir de zéro

C'est un peu le statu quo car en open source, la source... est ouverte ! Et peu importe si quelqu'un qui utilise votre source en profite aussi... c'est un peu de cela qu'il s'agit ! Nous bénéficions tous du partage de notre travail, et dans ce cas, la licence GPL utilisée par Linux nous oblige légalement à le partager !

Sans ce partage, il n'y aurait pas de Debian, Arch, Mint, Ubuntu, PopOS, Fedora... ou l'une des centaines d'autres distributions Linux qui s'appuient les unes sur les autres et soutiennent la communauté.

Mais Red Hat a décidé de placer le code source derrière un paywall. Maintenant, c'est légal. Techniquement, la GPL le permet. Mais il est généralement impoli et ennuyeux de le faire lorsque le code que vous verrouillez est largement basé sur le code open source d'autres personnes.

Mais... c'est dans leur droit, donc je ne contesterai pas ce point. Ce que je vais argumenter, c'est le contrat d'abonnement actuel, qui pourrait ne pas être légal. Red Hat dit actuellement qu'ils peuvent annuler le compte de n'importe quel utilisateur s'ils téléchargent le code source et le redistribuent.

Supposons que quelqu'un télécharge la source via un abonnement Red Hat et l'utilise pour créer une nouvelle version de Rocky Linux. Si Red Hat vendait au détail en annulant cet abonnement, je me mettrais certainement à l'écoute de cette affaire judiciaire.

Je ne sais pas si la communauté pourrait avancer l'argent pour affronter les puissants avocats d'IBM - c'est peut-être sur cela que Red Hat mise. Mais il y a un autre joueur dans ce jeu qui pourrait le faire, et c'est Oracle. Ne serait-il pas ironique qu'Oracle soit celui qui a renversé Red Hat pour avoir été si arrogant avec leur abus envers leur communauté ?

Mais soyons clairs : tout ce que j'ai vu montre que Red Hat essaie d'étouffer les distributions en aval comme Rocky, Alma et Oracle Linux. Je pense que leur espoir est que les utilisateurs de ces distributions aient peur et souscrivent à un abonnement Red Hat. Ils ont besoin que cela se produise pour verrouiller des bénéfices à court terme pour plaire à leurs seigneurs IBM. C'est mon point de vue cynique.

Ce que fait Red Hat, c'est contourner à la limite de la légalité les termes de la licence GPL de Linux.

Red Hat était autrefois la compagnie des rebelles. Ils avaient l'habitude d'avoir des publicités avant-gardistes citant Gandhi et positionnant Red Hat comme l'outsider courageux, utilisant l'open source pour renverser les anciennes sociétés de logiciels propriétaires.

C'est drôle qu'ils aient été si dévoués à cette citation de Gandhi en particulier. Dans un sens, Red Hat a en quelque sorte gagné, ils sont le choix par défaut pour faire fonctionner Linux dans les grandes entreprises.

L'ironie est que Cory Doctorow a récemment écrit ceci à propos d'une autre entreprise, mais je pense que cela s'applique ici :

VOICI COMMENT meurent les plates-formes : premièrement, elles sont bonnes pour leurs utilisateurs; puis ils abusent de leurs utilisateurs pour améliorer les choses pour leurs clients professionnels; enfin, ils abusent de ces clients commerciaux pour récupérer toute la valeur pour eux-mêmes. Ensuite, ils meurent.

Quelle juxtaposition !

Ils ont accumulé tellement de bonne volonté dans la communauté open source au fil des ans et étaient connus sous le nom de « société open source ».

Mais ils gaspillent cette bonne volonté - du moins en ce qui concerne Linux - au nom du profit.

Les développeurs comme moi, les mainteneurs du référentiel EPEL, les mainteneurs de Fedora qui s'inquiètent à juste titre des impacts à long terme...

On nous dit tous d'ouvrir un compte de développeur Red Hat afin de pouvoir récupérer nos 16 licences de Red Hat Enterprise Linux pour les tester.

Houla !

Merci, je suppose que je vais laisser tomber quelque chose de vraiment productif et passer une semaine à réorganiser mon infrastructure de test et mon automatisation pour travailler avec les licences Red Hat.

Vous savez qui ne m'oblige pas à faire ça ?

Debian. Ubuntu. FreeBSD. Pas même Rocky Linux !

Et s'il vous plaît, dites à vos employés d'arrêter de me fréquenter, en disant que je devrais simplement utiliser CentOS Stream. Il y a une raison pour laquelle Rocky et Alma linux ont été téléchargés des millions de fois. Stream ne remplace pas CentOS.

J'ai donc abandonné la prise en charge d'Enterprise Linux sur tout mon travail, à compter de vendredi dernier.

Et les gens me posent des questions sur Ansible. Soit dit en passant, il s'agit de Red Hat Ansible Automation Platform (par IBM).

Je ne pense pas qu'Ansible va essayer de verrouiller l'accès, mais le fait que je doive passer ne serait-ce qu'une seconde à envisager cette possibilité est insensé !

Qui veut construire autour d'un écosystème où les utilisateurs open source sont appelés freeloaders et où des perturbations massives sont mises en œuvre au milieu d'un cycle de publication, deux fois de suite, sans avertissement ?

Je ne vois pas cela aider Red Hat de quelque manière que ce soit à long terme.

Au final, c'est juste triste :

• C'est triste pour les utilisateurs comme moi qui ont utilisé CentOS et développé des outils qui ont fait entrer les gens dans l'écosystème de Red Hat.
• C'est triste pour Red Hat, qui se battait pour l'open source, mais érige maintenant des barrières autour de son propre code source.
• C'est triste pour tous ceux qui sont encore dans leur écosystème, car ils sont maintenant obligés de faire face aux manigances de licence de Red Hat et à la perte de tant de personnes dans la communauté open source.

Rocky Linux et AlmaLinux ont tous deux annoncé qu'ils trouveraient une voie à suivre. J'espère qu'ils le peuvent.

Quant à moi, j'en ai terminé avec Red Hat Enterprise Linux.

Je maintiendrai la prise en charge de Rocky Linux et AlmaLinux dans la mesure du possible, mais je ne suis pas sûr de pouvoir prendre en charge Enterprise Linux à l'avenir.

Source : billet Jeff Geerling

Et vous ?

Quelle lecture faites-vous de son argumentation ? Partagez-vous son avis ? Dans quelle mesure ?
Que pensez-vous de la décision de Red Hat de mettre le code source de RHEL derrière un paywall?
Utilisez-vous RHEL ou une autre distribution Linux? Qu'en pensez-vous ?
Comment Red Hat pourrait-il rétablir la confiance avec la communauté open source?
Quels sont les défis et les opportunités pour les distributions alternatives comme Rocky Linux et AlmaLinux?

[Stéphane le calme]

Red Hat accuse certains détracteurs de vouloir profiter du code de RHEL sans payer ou de le reconditionner à leur profit,
son vice-président de l'ingénierie répond aux critiques

Le vice-président de l’ingénierie des plateformes de base de Red Hat, Mike McGrath, répond aux critiques sur les changements apportés à git.centos.org, qui ont rendu le code source de RHEL moins accessible aux non-clients.

Il affirme que Red Hat s’engage à respecter les licences open source et à contribuer au code en amont, mais qu’il faut aussi reconnaître la valeur du travail effectué par les employés de Red Hat pour maintenir et soutenir RHEL pendant 10 ans. Il souligne que le code source de RHEL est toujours disponible dans CentOS Stream, qui est le dépôt source où RHEL est construit en public. Il accuse certains détracteurs de vouloir profiter du code de RHEL sans payer ou de le reconditionner à leur profit.

Il défend la culture et les valeurs open source de Red Hat et appelle à la compréhension et au respect mutuel entre les différentes parties prenantes de la communauté.

Nous avons été traités de méchants; On m'a taxé de cadre IBM qui a été installé pour transformer Red Hat en source fermée - et ce n'est que le « bon » truc. Alors mettons les choses au clair.

Je m'appelle Mike McGrath et je suis vice-président de l'ingénierie des plates-formes principales chez Red Hat. Je suis ici depuis 16 ans et avant de commencer à travailler ici, j'étais bénévole dans le projet Fedora. L'open source et tout ce que cette expression implique sont très importants pour moi. Au cours de la semaine dernière, j'ai vu beaucoup de gens dire beaucoup de choses méchantes et fausses sur les Red Hatters qui travaillent dur et qui, comme moi, accordent une grande importance à ce travail.

Malgré ce qui se dit actuellement à propos de Red Hat, nous rendons notre travail acharné facilement accessible aux non-clients. Red Hat utilise et utilisera toujours un modèle de développement open source. Lorsque nous trouvons un bogue ou écrivons une fonctionnalité, nous apportons notre code en amont. Cela profite à tous les membres de la communauté, pas seulement à Red Hat et à nos clients.

Nous ne nous contentons pas de prendre des packages en amont et de les reconstruire. Chez Red Hat, des milliers de personnes passent leur temps à écrire du code pour activer de nouvelles fonctionnalités, à corriger des bogues, à intégrer différents packages, puis à prendre en charge ce travail pendant longtemps - ce dont nos clients et partenaires ont besoin.

Il s'agit des heures et des nuits tardives que nous passons à rétroporter un correctif vers un code qui a maintenant 5 à 10 ans ou plus*; à tout moment, nous prenons en charge 3 à 4 flux de versions majeures, tout en appliquant des correctifs et des rétroportages à tous. De plus, 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 comme Fedora, CentOS Stream ou le projet du 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 - il y a une valeur énorme dans le travail que nous faisons.

Nous enverrons toujours notre code en amont et respecterons les licences open source utilisées par nos produits, ce qui inclut la GPL. Quand je dis que nous respectons les différentes licences open source qui s'appliquent à notre code, je le pense. J'ai été choqué et déçu du nombre de personnes qui se sont tellement trompées sur les logiciels open source et la GPL en particulier - en particulier, les observateurs de l'industrie et même les vétérans qui, je pense, devraient en savoir plus. Les détails, y compris les licences et les droits open source, sont importants, et ce sont des choses que Red Hat a aidé non seulement à former, mais aussi à préserver et à faire évoluer.

Je pense qu'une grande partie de la colère suscitée par notre récente décision concernant les sources en aval provient soit de ceux qui ne veulent pas payer pour le temps, les efforts et les ressources consacrés à RHEL, soit de ceux qui veulent le reconditionner à leur propre profit. Cette demande de code RHEL est fallacieuse.

Nous devons payer les gens pour faire ce travail - ces contributeurs passionnés qui traversent ces longues heures et nuits qui croient aux valeurs open source. Le simple fait de reconditionner le code que ces individus produisent et de le revendre tel quel, sans valeur ajoutée, rend la production de ce logiciel open source insoutenable. Cela inclut les travaux critiques de rétroportage et les futures fonctionnalités et technologies en cours de développement en amont. Si ce travail devient insoutenable, il s'arrêtera, et ce n'est bon pour personne.

Je veux mentionner spécifiquement les reconstructeurs, différents des distributions qui pourraient, par exemple, ajouter une nouvelle architecture ou un indicateur de compilation (nous vous aidons pleinement à étendre les capacités de Linux plutôt que de les imiter).

Il fut un temps, il n'y a pas si longtemps, que Red Hat trouvait de la valeur dans le travail effectué par des reconstructeurs comme CentOS. Nous avons poussé nos SRPM vers git.centos.org dans un package soigné qui les a rendus faciles à reconstruire ; nous l'avons même démarqué pour eux. Plus récemment, nous avons déterminé qu'il n'y a pas de valeur à avoir un reconstructeur en aval.

La position généralement acceptée selon laquelle ces reconstructions gratuites ne sont que des entonnoirs produisant des experts RHEL et se transformant en ventes n'est tout simplement pas la réalité. J'aimerais que nous vivions dans ce monde, mais ce n'est pas comme ça que ça se passe réellement. Au lieu de cela, nous avons trouvé un groupe d'utilisateurs, dont beaucoup appartiennent à de grandes ou très grandes organisations informatiques, qui veulent la stabilité, le cycle de vie et l'écosystème matériel de RHEL sans avoir à prendre en charge les mainteneurs, les ingénieurs, les rédacteurs et bien d'autres rôles qui le créent. Ces utilisateurs ont également décidé de ne pas utiliser l'une des nombreuses autres distributions Linux.

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 Linux avec des efforts de développement de marque et d'écosystème associés. Ces variantes utilisent et contribuent toutes au code source Linux, mais aucune ne prétend être « entièrement compatible » avec les autres.

En fin de compte, nous ne trouvons pas de valeur dans une reconstruction RHEL et nous ne sommes aucunement obligés de faciliter les choses pour les reconstructeurs*; c'est notre droit. Cela m'amène à CentOS Stream, dont il y a une immense confusion. Je reconnais qu'il s'agit d'un changement dans une tradition de longue date où nous sommes allés au-delà des attentes, et un changement comme celui-ci peut semer la confusion. Cette confusion s'est manifestée par des accusations selon lesquelles nous devions devenir source fermée et à propos de prétendues violations de la GPL. Il y a CentOS Stream le livrable binaire et CentOS Stream le référentiel source. La source gitlab CentOS Stream est l'endroit où nous créons les versions RHEL, à la vue de tous. Appeler RHEL «*source fermée*» est catégoriquement faux et inexact. CentOS Stream évolue plus rapidement que RHEL, il n'est donc peut-être pas sur HEAD, mais le code est là. Si vous ne le trouvez pas, il s'agit d'un bogue, veuillez nous en informer.

Nous proposons également des abonnements Red Hat Developer gratuits et Red Hat Enterprise Linux (RHEL) pour l'infrastructure Open Source. L'abonnement développeur fournit gratuitement RHEL aux développeurs et permet d'utiliser jusqu'à 16 systèmes, encore une fois, sans frais. Cela peut être utilisé par les particuliers pour leur propre travail et par les clients RHEL pour le travail de leurs employés. RHEL for Open Source Infrastructure est destiné à donner aux projets open source (qu'ils soient ou non affiliés à Red Hat de quelque manière que ce soit) un accès gratuit à RHEL pour leurs besoins d'infrastructure et de développement.

Enfin, j'aimerais m'adresser à toutes les entreprises open source, que votre code soit ouvert aujourd'hui ou que vous envisagiez de passer à un modèle open source. À tous points de vue, Red Hat a « réussi » et j'espère que de nombreuses entreprises open source réussiront comme nous. Vous pouvez décider vous-même si les reconstructions en aval sont utiles pour vous et c'est à vous de vous faciliter la tâche ou non.

Le simple fait de reconstruire le code, sans ajouter de valeur ni le modifier de quelque manière que ce soit, représente une menace réelle pour les entreprises open source du monde entier. Il s'agit d'une menace réelle pour l'open source, et qui a le potentiel de redonner à l'open source une activité réservée aux amateurs et aux hackers.

Nous ne voulons pas cela et je sais que les membres de notre communauté, nos clients et nos partenaires ne le souhaitent pas. L'innovation se passe en amont. S'appuyer sur les épaules des autres, c'est ce qu'est l'open source. Continuons à stimuler l'innovation, soutenons-nous les uns les autres et continuons d'avancer.

Source : Red Hat

Et vous ?

Que pensez-vous de son argumentation ? Quels sont les points les plus intéressants pour vous ?
Quelle est votre expérience avec RHEL ou CentOS?
Pensez-vous que Red Hat a pris la bonne décision en limitant l’accès au code source de RHEL?
Quels sont les défis ou les opportunités que vous voyez pour l’avenir de l’open source?
Comment évaluez-vous la qualité et la fiabilité de RHEL par rapport aux autres distributions Linux?

[Stéphane le calme]

Comment la négligence de Red Hat en matière d'open source nuit réellement à la communauté Linux,
d'après un mainteneur Linux qui estime que les distributions gérées par des entreprises ne sont pas dignes de confiance

Linux est partout. C’est une technologie aimée et utilisée par beaucoup, qui façonne notre monde chaque jour. La majorité des sites web les plus populaires lui font confiance pour fournir du contenu à leurs utilisateurs, et l’informatique d’entreprise ne serait pas la même sans lui. Le secret de ce qui rend Linux si puissant, flexible et évolutif repose sur trois choses : l’open source, la passion et la communauté.

Pour Jay, un mainteneur Linux qui est derrière Learn Linux TV, Red Hat est en train de saper ces aspects importants de ce qui fait de Linux la solution puissante, stable et évolutive qu’elle est - tout en jetant sa propre base de clients loyaux sous le bus proverbial.

Il a donné plusieurs exemples de la façon dont Red Hat a fait des déclarations et des promesses trompeuses (ou carrément fausses), et a également indiqué comment Red Hat a trahi sa propre base de clients. Toutefois, il estime que bien que Red Hat qui empoisonne son propre approvisionnement en eau, la société autrefois aimée de Linux n’est que le symptôme d’un problème beaucoup plus large : « L’entreprise qui soutient Linux ne peut tout simplement pas être digne de confiance. Voyons pourquoi c’est le cas, mais d’abord nous allons résumer ce qui s’est passé récemment ».

La dernière gaffe de Red Hat

Le 22 juin 2023, Red Hat a annoncé qu’il modifiait les modalités d’obtention du code source de Red Hat Enterprise Linux. Certaines des distributions Linux les plus importantes de nos jours, comme AlmaLinux OS, Rocky Linux (entre autres) doivent leur existence à ce fait. Mais avec la décision récente, Red Hat rend essentiellement cette existence difficile à maintenir. Au cours des nombreuses années où j’ai travaillé avec Linux, je n’ai jamais pensé voir un moment où Red Hat essaierait littéralement de détruire des projets open source. Mais comme nous le verrons au fur et à mesure, ce n’est que la partie émergée de l’iceberg.

Red Hat fait subir un travail supplémentaire aux organisations

Si vous êtes administrateur système, vous savez comment ça se passe. Vous devez faire fonctionner les serveurs de votre organisation du mieux que vous pouvez. C’est le travail, et souvent, les heures sont longues. C’est à nous d’installer les correctifs, de développer une analyse des causes profondes lorsque les choses tournent mal, et aussi de passer à une version plus récente lorsque notre distribution Linux choisie arrive en fin de vie. Ce n’est tellement pas rare que cela nous semble être une montagne de travail, mais nous aimons quand même notre travail. Alors que nous pouvons être compréhensifs lorsque nous devons renoncer à un week-end, nous sommes moins compréhensifs lorsque le logiciel lui-même nous cause du travail, spécifiquement, du travail qui ne devrait même pas être nécessaire.

La chose intéressante ici, c’est que Red Hat lui-même a causé aux services informatiques du monde entier d’être encore plus débordés. En 2020, lorsque CentOS (une autre distribution appartenant à Red Hat) a changé de direction soudainement, cela signifiait que les administrateurs système devraient soit accepter la nouvelle voie, soit passer à autre chose s’ils n’aimaient pas la direction que prenait CentOS.

Ce changement a été un choc pour beaucoup, car CentOS était considéré comme une alternative gratuite et stable à RHEL pour ceux qui ne voulaient pas ou ne pouvaient pas payer pour le support officiel. En transformant CentOS en une distribution “stream” qui suit le développement de RHEL au lieu de le refléter après coup, Red Hat a essentiellement rendu CentOS moins fiable et moins adapté aux besoins des entreprises.

Heureusement, des projets comme AlmaLinux OS et Rocky Linux sont nés pour combler le vide laissé par CentOS et offrir une compatibilité binaire avec RHEL sans frais ni contraintes. Ces projets ont été accueillis avec enthousiasme par la communauté Linux, qui a vu en eux une lueur d’espoir face à la trahison de Red Hat.

Lorsque CentOS 8 a été abandonné en 2020, les organisations ont perdu 3 186 jours de leur fenêtre de support promise de 3 650 jours. Pour être juste, Red Hat possède CentOS, et ils peuvent fournir autant (ou aussi peu) de support qu'ils le souhaitent. Par conséquent, Red Hat n'a rien fait de mal du point de vue du « peuvent-ils faire cela » (ils le peuvent, et ils l'ont fait). Mais cela ne change rien au fait qu'ils ont promis une chose et qu'ils ont fait autre chose. Plusieurs fois. Cela nuit à la confiance. Et les systèmes d'exploitation sont certainement l'une des principales choses sur lesquelles une organisation s'appuie et doit faire confiance. En supprimant la fenêtre de support que Red Hat promettait aux utilisateurs de CentOS, ils ont sapé cette confiance.

Et cet odieux abus de confiance aurait dû être la fin de cette histoire – il est difficile pour une organisation de pardonner d'avoir été mise dans la situation dans laquelle elle se trouvait. Au lieu de cela, ce n'était absolument pas le seul cas où Red Hat faisait des déclarations trompeuses ou fausses. Une autre affirmation fausse a été faite dans l'article de la FAQ CentOS que la société a publié pour annoncer que CentOS Stream était la nouvelle voie à suivre :

Donc, ici, il était promis aux organisations (et à l'ensemble de la communauté Linux) que le code source de RHEL continuerait d'être disponible en téléchargement. Grâce à cette promesse, AlmaLinux OS et Rocky Linux ont pu exister. Ils s'appuient sur le code source au centre de cette promesse.

Red Hat porte un coup dur à ces projets

Mais le 22 juin 2023, Red Hat a porté un nouveau coup dur à ces projets, en annonçant qu’il allait restreindre l’accès au code source de RHEL à partir du 1^er juillet 2023.

Oui, ils ont barré cette section. Je dois leur donner du crédit cependant, ils n'ont pas supprimé la réponse d'origine au moins. De cette façon, nous avons un exemple tangible réel de leur manque de confiance, à l'air libre. Il mentionnait littéralement « Rien ne changera sur la façon dont le code source est publié » juste pour revenir complètement là-dessus. Alors, voilà, un autre mensonge pur et simple, juste là sur leur site Web.

Selon Red Hat, cette décision vise à « améliorer la sécurité et la qualité du code source de RHEL et à réduire la complexité et les coûts associés à sa maintenance ». En pratique, cela signifie que les projets qui se basent sur le code source de RHEL devront s’inscrire auprès de Red Hat et utiliser un outil spécifique pour le télécharger, au lieu de pouvoir le faire librement via un navigateur web ou un client FTP. Cela rend également plus difficile la vérification de l’intégrité du code source, puisque les sommes de contrôle ne seront plus disponibles publiquement.

Red Hat affirme que cette mesure ne viole pas les termes de la licence GPL, qui oblige les distributeurs de logiciels libres à fournir le code source correspondant aux binaires qu’ils distribuent. Cependant, elle va clairement à l’encontre de l’esprit de l’open source, qui repose sur la transparence, la collaboration et la liberté. En rendant l’accès au code source de RHEL plus difficile et plus opaque, Red Hat entrave le travail des projets qui veulent offrir une alternative à RHEL sans compromettre la stabilité, la sécurité et la compatibilité. Il s’agit d’une tentative évidente de protéger ses intérêts commerciaux au détriment de la communauté Linux.

Red Hat n’est pas le seul coupable

Bien que Red Hat soit le principal responsable de cette situation, il n’est pas le seul coupable. En fait, il n’est que le symptôme d’un problème plus large : l’entreprise qui soutient Linux ne peut pas être digne de confiance. Qu’il s’agisse de Canonical (la société derrière Ubuntu), de SUSE (la société derrière openSUSE et SLES), ou d’autres acteurs du marché Linux, ils ont tous un point commun : ils doivent faire des profits. Et pour faire des profits, ils doivent parfois prendre des décisions qui ne sont pas dans l’intérêt de la communauté Linux, mais dans celui de leurs actionnaires, de leurs partenaires ou de leurs clients.

Cela ne veut pas dire que ces entreprises sont mauvaises ou mal intentionnées. Elles contribuent beaucoup à l’écosystème Linux et à l’open source en général. Elles emploient des développeurs talentueux, sponsorisent des événements, soutiennent des projets, et offrent des services utiles. Elles ont aussi le mérite d’avoir rendu Linux plus accessible, plus populaire et plus professionnel. Mais elles ont aussi leurs limites, leurs intérêts et leurs agendas. Et parfois, ces derniers entrent en conflit avec ceux de la communauté Linux.

Par exemple, Canonical a été critiqué à plusieurs reprises pour ses choix controversés, comme l’intégration d’Amazon dans le tableau de bord d’Unity, l’abandon de Mir au profit de Wayland, ou encore le passage forcé à Snap pour certaines applications. SUSE a également fait face à des critiques pour avoir abandonné le support officiel d’openSUSE Leap au profit d’une version communautaire moins stable. Et ces exemples ne sont que la partie visible de l’iceberg.

La vérité est que les entreprises qui soutiennent Linux ont souvent des motivations différentes de celles des utilisateurs et des développeurs qui font vivre Linux. Elles peuvent changer de direction sans préavis, imposer des technologies propriétaires ou fermées, ou encore restreindre l’accès aux ressources dont dépendent d’autres projets. Elles peuvent aussi être influencées par des forces extérieures, comme les gouvernements, les lobbyistes ou les concurrents. Bref, elles peuvent faire du tort à Linux sans même s’en rendre compte.

Comment protéger Linux ?

Face à ce constat alarmant, on peut se demander comment protéger Linux des entreprises qui le soutiennent. La réponse n’est pas simple ni unique, mais elle repose sur quelques principes fondamentaux :

• Privilégier les distributions Linux qui sont indépendantes ou soutenues par des fondations à but non lucratif, comme Debian, Fedora, Arch Linux, Gentoo, etc. Ces distributions sont plus proches de l’esprit originel de Linux et sont moins susceptibles de subir des pressions commerciales ou politiques. Elles sont aussi plus transparentes, plus collaboratives et plus respectueuses des choix des utilisateurs.
• Participer activement à la communauté Linux. Que ce soit en contribuant au code source, en signalant des bugs, en proposant des améliorations, en écrivant de la documentation, en aidant les autres utilisateurs, en faisant des dons, ou en soutenant les projets qui nous tiennent à cœur, il est important de s’impliquer dans la vie de Linux et de faire entendre sa voix. C’est ainsi que l’on peut influencer le développement de Linux et le protéger des intérêts contraires.
• Promouvoir les valeurs de l’open source et du logiciel libre. Il ne suffit pas d’utiliser Linux, il faut aussi le défendre et le faire connaître. Il faut sensibiliser les gens aux avantages de l’open source et du logiciel libre, comme la liberté, la sécurité, la qualité, la flexibilité et la créativité. Il faut aussi dénoncer les pratiques nuisibles ou abusives des entreprises qui soutiennent Linux, comme la restriction de l’accès au code source, l’imposition de technologies fermées ou propriétaires, ou encore la trahison de la base de clients.

Et Jay de conclure en disant :

La morale de l'histoire est la suivante : aucune organisation ne devrait faire confiance aux distributions Linux gérées par des entreprises. Ils n'ont pas votre meilleur intérêt à l'esprit, comme Red Hat l'a montré à maintes reprises en faisant de fausses déclarations et en nuisant à la communauté même qu'ils servent. Soyons clairs - Linux appartient aux États-Unis et Red Hat profite d'une communauté d'ingénieurs passionnés et de passionnés qui l'ont aidé à atteindre le sommet. Sans nous, il n'y aurait pas de Red Hat. L'entreprise ferait bien de s'en souvenir.

Source : vidéo de Jay

Et vous ?

Quelle est votre distribution Linux préférée et pourquoi ?
Quelles sont les pratiques des entreprises qui soutiennent Linux qui vous dérangent le plus ?
Que pensez-vous de l'argumentation de Jay ? Partagez-vous son point de vue selon lequel « aucune organisation ne devrait faire confiance aux distributions Linux gérées par des entreprises » ? Dans quelle mesure ?
Quels sont les projets open source ou logiciels libres que vous soutenez ou que vous utilisez ?

[floyer]

"Red Hat affirme que cette mesure ne viole pas les termes de la licence GPL, qui oblige les distributeurs de logiciels libres à fournir le code source correspondant aux binaires qu’ils distribuent. "

La licence GPL impose non seulement la mise à disposition des sources (ce que fait RedHat), mais oblige la distribution de ces sources sous une forme redistribuable (sans restriction). Or, RedHat interdit désormais d'utiliser ces sources pour faire une offre concurrente.

[chrtophe]

Or, RedHat interdit désormais d'utiliser ces sources pour faire une offre concurrente.

Non, Redhat rend plus complexe l'accès aux sources, mais les fournie. Du moins c'est ce que j'ai compris.

[Bruno]

Rocky Linux présente les failles juridiques de la licence de RHEL qui permettront à sa reconstruction de perdurer,
un discours en faveur de l’open source, mais qui doit encore faire ses preuves

Le projet Rocky Linux, qui vise à créer une distribution Linux compatible avec Red Hat Enterprise Linux (RHEL), a annoncé qu’il allait exploiter les failles juridiques de la licence de RHEL pour offrir une alternative gratuite aux utilisateurs. Rocky Linux compte utiliser le programme Red Hat Developer Subscription, qui permet aux développeurs individuels d’accéder gratuitement à RHEL pour un usage personnel, ainsi que le service Red Hat Universal Base Image (UBI), qui fournit des images de conteneurs basées sur RHEL sans frais.

La bataille qui oppose depuis des décennies Red Hat aux diverses organisations qui clonent sa distribution Linux d'entreprise a pris une nouvelle tournure. Red Hat est sous une pluie de critiques après avoir suspendu la publication des sources publiques de Red Hat Enterprise Linux (RHEL) sur git.centos.org pour consacrer CentOS Stream comme seul référentiel. Jeff Geerling, développeur, fait partie de ceux qui ont décidé d'exprimer leur colère. Il affirme que Red Hat viole l’esprit de l’open source et menace les distributions alternatives comme Rocky Linux et AlmaLinux, qui se basent sur le code source de RHEL. Il annonce qu’il ne va plus maintenir le support officiel de RHEL pour ses projets open source, et qu’il va privilégier les autres distributions Linux comme Fedora, Arch, Ubuntu ou Debian.

CentOS Stream est une distribution Linux développée par le projet CentOS. Il s'agit d'une version en amont (upstream) de Red Hat Enterprise Linux (RHEL). Elle agit comme une vitrine de développement pour les fonctionnalités et les mises à jour futures de RHEL. CentOS Stream offre aux utilisateurs un accès précoce aux nouvelles technologies et innovations introduites dans RHEL. Cela permet également une collaboration plus étroite entre les ingénieurs de Red Hat, les partenaires, les clients et les membres de la communauté CentOS pour tester, intégrer et fournir des retours d'expérience sur les fonctionnalités en cours de développement.

Avant CentOS Stream, Red Hat publiait les sources publiques de RHEL sur git.centos.org. Lorsque le projet CentOS s'est recentré sur CentOS Stream, l'éditeur de logiciels open source a maintenu ces référentiels même si CentOS Linux n'était plus développé à partir de RHEL. Mais ce ne sera plus le cas maintenant que Red Hat a décidé de faire de CentOS Stream le seul référentiel pour les versions publiques du code source liées à Red Hat Enterprise Linux (RHEL). C'est ce qu'on lit dans un billet blog de Red Hat.

Dans un billet de blog intitulé Keeping Open Source Open, le projet Rocky Linux pour sa part décrit deux façons différentes d'obtenir le code source de RHEL sans enfreindre les accords de licence de Red Hat.

Depuis la création du projet Rocky, nous avons donné la priorité à la reproductibilité, à la transparence dans la prise de décision et au fait qu'aucun fournisseur ou entreprise ne puisse jamais prendre le projet en otage. Lorsque nous avons commencé, nous avons discuté de notre modèle et de notre mission, et nous avons décidé de ne pas diviser la communauté Enterprise Linux.

Au contraire, dans l'esprit des principes et des normes de l'open source, nous avons créé quelque chose de compatible avec Red Hat Enterprise Linux (RHEL). En adhérant à cette approche, nous respectons un standard unique pour Enterprise Linux et nous nous alignons sur les objectifs initiaux de CentOS.

Cependant, Red Hat a récemment exprimé son point de vue selon lequel il "ne trouve pas de valeur dans une reconstruction de RHEL". Même si nous pensons que ce point de vue est étroit d'esprit, Red Hat a adopté une position ferme et a limité l'accès aux sources de RHEL à ses seuls clients payants. Ces sources consistent principalement en des paquets de projets open source en amont qui n'appartiennent pas à Red Hat.

Auparavant, nous obtenions le code source de Rocky Linux exclusivement à partir du dépôt Git de CentOS, comme ils le recommandaient. Cependant, ce dépôt n'héberge plus toutes les versions correspondant à RHEL. Par conséquent, nous devons maintenant rassembler le code source à partir de sources multiples, y compris CentOS Stream et les SRPM RHEL.

En combinant ces sources, Rocky Linux espère créer une distribution qui soit identique à RHEL sans enfreindre les droits d’auteur de Red Hat. Une option consiste à utiliser les images de conteneurs UBI qui sont basées sur RHEL et disponibles à partir de plusieurs sources en ligne (y compris Docker Hub). En utilisant l'image UBI, il est possible d'obtenir facilement des sources Red Hat de manière fiable et sans encombre. La méthode a été validée à l'aide de conteneurs OCI (Open Container Initiative) et elle fonctionne exactement comme prévu.

Une autre méthode exploitée est celle des instances de cloud public payées à l'utilisation. Ainsi, n'importe qui peut créer des images RHEL dans le cloud et obtenir ainsi le code source de tous les paquets. « C'est la méthode la plus facile pour nous d'évoluer, car nous pouvons faire tout cela par le biais de pipelines CI, en faisant tourner des images dans le cloud pour obtenir les sources via DNF, et en les postant automatiquement dans nos dépôts Git », déclare l’équipe Rocky Linux.

Ces méthodes sont possibles grâce à la puissance de la GPL. Personne ne peut empêcher la redistribution des logiciels sous GPL. Pour réitérer, ces deux méthodes permettent d'obtenir légitimement les binaires RHEL et les SRPM sans compromettre l’engagement envers les logiciels libres ou accepter des limitations des CGU ou des CLUF qui entravent les droits.

Selon les conseillers juridiques de Rocky Linux, c’est possible d'obtenir les sources de tous les binaires que reçus, ce qui permet de continuer à faire progresser Rocky Linux conformément à aux intentions initiales.

Les avantages et les inconvénients d’un leader du marché

RHEL reste un produit important pour de nombreuses grandes entreprises, comme le souligne le fait que "Big Purple" vient de prolonger la durée de vie de l'assistance pour RHEL 7. Cette dernière devait arriver en fin de vie l'année prochaine, dix ans après son lancement, mais elle aurait bénéficié d'un sursis d'exécution : ELS jusqu'en 2028... avec la version 3.10 du noyau.

De nombreuses personnes au sein de la communauté des utilisateurs de Red Hat sont extrêmement contrariées par ce changement de politique en matière de code source, et beaucoup d'entre elles indiquent qu'elles envisagent de passer à d'autres distributions - notamment Debian, peut-être en raison de son cycle de vie de support à long terme. Le problème serait que les utilisateurs professionnels ne choisissent pas les distributions sur la base de leur valeur technique, mais plutôt en fonction de l'assistance fournie par des tiers.

L’annonce de Rocky Linux est un message fort et clair en faveur de l’open source et de la communauté. Elle exprime la volonté de continuer à offrir une alternative gratuite et compatible à Red Hat Enterprise Linux (RHEL), malgré les changements d’accessibilité des sources. Rocky Linux met en avant les valeurs telles que la stabilité, la production, le support et la migration. Elle souligne également les réalisations du projet, comme la sortie de la version 9.2 et l’arrivée de Theodore Ts’o, programmeur connu principalement pour ses contributions au noyau Linux, au conseil d’administration.

Bien que Rocky Linux reconnaisse les défis techniques posés par les changements de sources, son annonce manque les détails sur les avantages concrets de Rocky Linux par rapport à RHEL, comme les performances, la sécurité ou la compatibilité. Elle pourrait aussi inclure des témoignages d’utilisateurs satisfaits ou des chiffres sur le nombre d’installations ou de contributeurs.

Source : Rocky Linux

Et vous ?

Quel est votre avis sur le sujet ?

Selon Red Hat, il n'existe « pas de valeur dans une reconstruction de RHEL », partagez-vous cet avis ?

Rocky Linux a-t-il des chances face à la concurrence d’autres distributions Linux d’entreprise ?

Quels peuvent être les avantages de la distribution de Rocky Linux en termes de performances, de sécurité et de compatibilité ?

Quels seraient les risques et les opportunités pour Rocky Linux suite aux changements d’accessibilité des sources de RHEL ?

Voir aussi :

Red Hat consacre CentOS Stream comme le seul référentiel pour les sources publiques de Red Hat Enterprise Linux (RHEL), une décision qui pourrait perturber certains acteurs du monde de l'open source

La distribution CentOS Linux est morte : Red Hat n'investira plus ses ressources pour soutenir le système après 2021, et CentOS Stream, utilisé en amont de RHEL, ne remplacera pas CentOS Linux

Red Hat annonce un RHEL sans frais pour les petits environnements de production, notamment pour les charges de travail de production avec jusqu'à 16 serveurs de production

[OrthodoxWindows]

Ah bah voilà, les libristes se rendent compte que Red Hat ne soutient pas le libre

A mettre en relation avec ça : https://www.developpez.net/forums/d2.../#post11704500

Red Hat suspend sa participation financière à la FSF suite au retour de Richard Stallman au conseil d'administration de la FSF,
et lui demande d'apporter des changements dans sa gouvernance

Un commentaire avait été fait sous cet article, qui s'est avéré totalement prémonitoire (l'auteur à supprimé son compte entre temps) :

Red Hat n'est pas citée par la FSF dans la liste des donateurs en 2020. La société semble avoir fait des dons en 2019 et 2018, mais pas en 2017 et 2016.

Les pages dons de la FSF ont au moins le mérite de montrer l'état des forces politiques en présence. Google a fait des dons conséquents à la FSF jusqu'en 2016. 2016, c'est justement l'année où RMS a critiqué le faux libre qui inclut des surcouches propriétaires. Bizarrement, Google n'est plus citée dans la liste des donateurs les années suivantes.

Toujours est-il qu'il faut se méfier de ces fondations américaines dont la survie dépend du bon vouloir de leurs donateurs. Si autant d'organisations ont promptement réagi contre le retour de RMS à la FSF, c'est peut-être aussi pour ne pas contrarier leurs généreux mécènes.

[Madmac]

rendu à ce niveau, il faut tout une infrastructure et sans investissement de la part d'une entreprise ça risque d'être difficile

autrement il y a suse avec une multitude de produit et un excellent support

Mais le support pour les paquetages est en chute libre. Il est possible de se débrouiller avec les Flatpacks. Mais ce n'est pas pas le cas pour tout les cas de figure. À une certaine époque, c'était une très bonne distro pour un programmeur, mais ce n'est plus le cas. J'ai tenté d'installer le langage Dart sans succès. Et pour la majorité des nouveaux langages comme Go, on doit passé par la compilation.

[Stéphane le calme]

SUSE investit 10 millions de dollars pour créer un fork de RHEL et proposer une alternative à CentOS Stream sans restrictions,
à l'intention des entreprises mais aussi de la communauté

SUSE, la société derrière Rancher, NeuVector et SUSE Linux Enterprise (SLE), a annoncé qu'elle allait créer une distribution compatible avec Red Hat Enterprise Linux (RHEL) à partir du code source public de ce dernier. SUSE prévoit d'investir plus de 10 millions de dollars dans ce projet au cours des prochaines années. L'objectif est de préserver le choix et la liberté des entreprises et de la communauté open source face au risque d'enfermement par un fournisseur. SUSE compte également contribuer à une fondation open source qui assurera l'accès gratuit au code source alternatif.

Tout a commencé fin 2020, lorsqu'une équipe de Red Hat, qui assurait le développement et la maintenance de la distribution CentOS (Community enterprise Operating System), a annoncé « qu'au cours de l’année prochaine, nous passerons de CentOS Linux, la reconstruction de Red Hat Enterprise Linux (RHEL), à CentOS Stream, qui vient juste avant une nouvelle version de RHEL ».

Cela signifiait que, pour les utilisateurs de la distribution GNU/Linux destinée aux serveurs et aux postes de travail, CentOS 8 serait abandonnée plus tôt que prévu. Initialement, la maintenance de cette distribution devait être assurée jusqu’au 31 mai 2029. Mais contre toute attente, Red Hat a décidé unilatéralement de rapprocher cette date au 31 décembre 2021. En plus de cette annonce qui vient couper l’herbe sous les pieds des utilisateurs utilisant CentOS 8, Red Hat a déclaré qu’il n’y aura pas de version 9 de CentOS. À la fin du cycle de vie de CentOS 8, les utilisateurs de CentOS devront soit se tourner vers CentOS Stream 8 qui est utilisé en amont pour le développement de RHEL 8, soit payer pour utiliser RHEL 8 ou chercher d’autres alternatives.

Cette annonce n’a pas laissé indifférents les utilisateurs de CentOS. Plusieurs utilisateurs ont réagi pour crier leur mécontentement. « C’est affreux. C’est la preuve des inconvénients de l’acquisition de Red Hat par IBM. Imaginez si vous dirigiez une entreprise et avez déployé CentOS 8 sur la base de la promesse d’une durée de vie de 10 ans. Vous êtes totalement foutu maintenant, et Red Hat le sait », a fait remarquer un internaute. « CentOS a toujours été une alternative gratuite à Redhat. Moi et beaucoup d’autres personnes l’avons utilisée parce que c’était un moyen de profiter des avantages de Red Hat sans payer. C’est vraiment assez intelligent de leur part d’inciter les gens à cesser de faire ce qu’ils faisaient et de les amener à payer de l’argent pour soutenir leurs équipes de développement. Les gens qui ne sont pas prêts à payer (moi y compris) sont maintenant à juste titre embêtés. Mais nous n’avons jamais été leurs clients en premier lieu, donc nous n’avons pas vraiment d’importance », a souligné un autre utilisateur.

« En faisant de CentOS une distribution de test, Red Hat détruit complètement son utilité en tant que système d’exploitation stable, libre et prêt pour l’entreprise. Cette décision semble être une stratégie de Red Hat pour convaincre les gens qui veulent un système d’exploitation d’entreprise stable d’être forcés de migrer vers leur système d’exploitation à but lucratif, d’un coût prohibitif », dénonçait une pétition ouverte sur le site change.org. « Red Hat vient simplement de tuer CentOS. Mais qu’il ne s’imagine pas qu’il va récupérer la base d’utilisateurs de la distribution », confie un intervenant.

Mais Red Hat a tenté de les rassurer à cette période

Chris Wright, vice-président senior et directeur de la technologie de Red Hat a expliqué sur le site de l’entreprise

« En septembre 2019, nous avons annoncé CentOS Stream, une plate-forme de développement en amont conçue pour les membres de la communauté CentOS, les partenaires Red Hat, les développeurs d’écosystèmes et de nombreux autres groupes et qui permet de voir plus rapidement et facilement ce qui suit dans Red Hat Enterprise Linux (RHEL) pour aider à façonner le produit. Depuis son introduction, nous avons constaté un grand enthousiasme de la part des partenaires et des contributeurs autour de CentOS Stream et du flux continu d’innovation que le projet fournit ».

« Eu égard à cela, nous avons informé le conseil d’administration du projet CentOS que nous transférons entièrement notre investissement de CentOS Linux à CentOS Stream. Pour soutenir cette décision, le vice-président avance que Facebook qui gère des millions de serveurs prenant en charge son vaste réseau social mondial a migré (ou est en train de migrer) vers un système d’exploitation dérivé de CentOS Stream. Il précise que le réseau social a reconnu déjà la valeur de CentOS Stream et contribue à stimuler l’innovation interne de cette distribution. Comme autre exemple pour justifier la bonne foi de Red Hat suite aux récentes décisions de l’entreprise, Chris Wright rapporte qu’Intel, partenaire de longue date de Red Hat, est également engagé avec CentOS Stream. En outre, Red Hat précise que « CentOS Stream ne remplace pas CentOS Linux ; il s’agit plutôt d’une prochaine étape naturelle et inévitable destinée à atteindre l’objectif du projet qui est de promouvoir l’innovation Linux en entreprise ».

Quelques alternatives s'offraient alors aux utilisateurs...

• Rocky Linux : un projet qui venait d’être annoncé par Gregory Kurtzer, le cofondateur de CentOS. Selon l’auteur, il devait être conçu pour être 100 % compatible avec Enterprise Linux maintenant que CentOS a changé de direction. Rocky Linux vise à fonctionner en aval comme CentOS le faisait après que les entreprises ont ajouté leurs commits et non avant. Les utilisateurs pourront donc l’utiliser en production.
• Oracle Linux : est une distribution Linux compilée à partir du code source de Red Hat Enterprise Linux. Elle est distribuée gratuitement par Oracle et disponible partiellement sous la licence publique générale GNU depuis fin 2006. Pour les entreprises qui utilisent les systèmes Oracle, Oracle Linux est considéré comme le choix idéal.
• ClearOS : se présente comme un système d’exploitation simple, sécurisé et abordable basé à la fois sur CentOS et RHEL. Il fournit une interface Web intuitive et un magasin d’applications avec plus de 100 applications. ClearOS est disponible en 3 éditions principales : Home, Business et Community Edition. L’édition Home est idéale pour les petits bureaux. L’édition Business est conçue pour les petites et moyennes entreprises qui préfèrent bénéficier d’un support payant, tandis que l’édition Community est absolument gratuite.
• Springdale Linux (anciennement PUIAS Linux) : un système d’exploitation complet pour les postes de travail et les serveurs, construit avec les packages sources de Red Hat Enterprise Linux. En plus des packages hérités de RHEL, le projet fournit également plusieurs autres référentiels : « Addons » qui contient des packages supplémentaires non inclus dans une distribution standard de Red Hat ; « Computational » qui contient des logiciels spécifiques au calcul scientifique ; et « Unsupported » qui contient divers packages expérimentaux. La distribution est maintenue par l’Institute for Advanced Study et l’Université de Princeton aux États-Unis.
• CloudLinux : une distribution de reconstruction RHEL conçue pour les fournisseurs d’hébergement partagé. Étant donné qu’elle requiert des frais d’abonnement pour une utilisation en production, CloudLinux ressemble plus à RHEL qu’à CentOS. Cependant, à la suite de l’annonce de Red Hat, les responsables de CloudLinux OS ont déclaré qu’ils publieraient un remplacement de CentOS au premier trimestre 2021. Le nouveau fork sera un « OS séparé, totalement gratuit, entièrement compatible avec RHEL 8 et les versions futures ».

...mais en 2023, tout a basculé

Fin juin, Red Hat a annoncé que CentOS Stream deviendra le seul référentiel des versions publiques du code source lié à Red Hat Enterprise Linux (RHEL). Cette décision, selon l'éditeur de logiciels open source, vise à se concentrer davantage sur CentOS Stream en tant que moteur d'innovation pour Linux d'entreprise. Red Hat estime que l'évolution vers CentOS Stream permet une transparence et une ouverture accrues dans le développement de Red Hat Enterprise Linux. Mais pour plusieurs observateurs, il s'agit d'une décision purement vicieuse ayant pour but d'écarter certains acteurs de la communauté Linux.

Avant CentOS Stream, Red Hat publiait les sources publiques de RHEL sur git.centos.org. Lorsque le projet CentOS s'est recentré sur CentOS Stream, l'éditeur de logiciels open source a maintenu ces référentiels même si CentOS Linux n'était plus développé à partir de RHEL. Mais ce ne sera plus le cas maintenant que Red Hat a décidé de faire de CentOS Stream le seul référentiel pour les versions publiques du code source liées à Red Hat Enterprise Linux (RHEL). C'est ce qu'on lit dans un billet blog de Red Hat.

Si cette décision n'est pas surprenante, beaucoup pensent qu'elle risque de perturber certains acteurs du monde de l'open source. En effet, en limitant les sources publiques de RHEL à CentOS Stream, il sera désormais plus difficile pour les distributions communautaires et les distributions Linux d'entreprise dérivées telles qu'Alma Linux, Rocky Linux, Oracle Linux, etc., de fournir des versions entièrement compatibles avec les versions RHEL cibles. Or cette compatibilité stricte est nécessaire pour permettre aux utilisateurs de passer d'une distribution à une autre sans rencontrer de problèmes de compatibilité ou de fonctionnalité.

Plusieurs membres de la communauté ont critiqué le fait que le code source de RHEL soit derrière un paywall

C'est le cas de Jeff Geerling qui a annoncé qu’il ne va plus maintenir le support officiel de RHEL pour ses projets open source.

La communauté des utilisateurs de CentOS - moi y compris - a été qualifiée de « freeloaders », utilisant le travail de la toute-puissante société Red Hat, sans rien apporter en retour. Ne vous occupez pas de tous les développeurs open source, contributeurs du noyau Linux et développeurs de logiciels qui ont utilisé CentOS pour tester et créer leur logiciel. Ignorez également le fait que Red Hat construit son produit sur Linux, qu'il n'a pas construit et qu'il ne possède pas[...].

Les développeurs comme moi, les mainteneurs du référentiel EPEL, les mainteneurs de Fedora qui s'inquiètent à juste titre des impacts à long terme...

On nous dit tous d'ouvrir un compte de développeur Red Hat afin de pouvoir récupérer nos 16 licences de Red Hat Enterprise Linux pour les tester.

Houla !

Vient alors SUSE

Dans un billet de blog, SUSE a annoncé qu'elle allait créer une distribution compatible avec Red Hat Enterprise Linux (RHEL) à partir du code source public de ce dernier. SUSE prévoit d'investir plus de 10 millions de dollars dans ce projet au cours des prochaines années.

Dirk-Peter van Leeuwen, PDG de SUSE, a déclaré : « Pendant des décennies, la collaboration et le succès partagé ont été les éléments constitutifs 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 soient pas soumis à l'enfermement des fournisseurs et aient un véritable choix demain comme aujourd'hui ».

SUSE reste pleinement engagé à investir dans ses solutions Linux très appréciées telles que SLE et openSUSE sur lesquelles comptent d'innombrables entreprises clientes satisfaites et la communauté. Dans le même temps, il reconnaît que les entreprises et la communauté open source méritent le choix et la liberté vis-à-vis des fournisseurs. SUSE a une longue histoire dans l'autonomisation et la prise en charge des utilisateurs avec des environnements Linux mixtes.

SUSE s'engage à travailler avec la communauté open source pour développer une alternative compatible à long terme et durable pour les utilisateurs de RHEL et CentOS. SUSE prévoit de contribuer ce projet à une fondation open source, qui fournira un accès gratuit et continu au code source alternatif.

« Cet effort de collaboration démontre l'engagement profondément enraciné de SUSE à favoriser l'innovation et à favoriser le développement communautaire, et il renforce les valeurs fondamentales des logiciels open source. Nous invitons la communauté à s'engager activement et à collaborer pour façonner l'avenir de ce logiciel essentiel », a déclaré le Dr Thomas Di Giacomo, directeur de la technologie et des produits, SUSE. « Nous croyons fermement que cette nouvelle distribution Linux compatible RHEL, ainsi que le portefeuille de SUSE, aideront la communauté et les clients à naviguer dans les avancées sans précédent de Linux d'entreprise, du cloud computing, de la conteneurisation, de la périphérie, de l'IA/ML et d'autres technologies émergentes ».

« La communauté Linux d'entreprise a besoin de standardisation, de stabilité et de cohérence », a déclaré Gregory Kurtzer, PDG de CIQ et fondateur de Rocky Linux. « CIQ apporte de la stabilité à nos partenaires, nos clients et notre communauté en créant une large coalition d'entreprises, d'organisations et d'individus partageant les mêmes idées. SUSE a incarné les principes fondamentaux et l'esprit de l'open source ; CIQ est ravi de collaborer avec SUSE pour faire progresser une norme Linux d'entreprise ouverte ».

Source : SUSE

Et vous ?

Que pensez-vous de la démarche de SUSE ?
Que pensez-vous du changement opéré par Red Hat sur CentOS ?
Utilisez-vous CentOS ou un fork alternatif ? Si oui, lequel et pourquoi ?
Quels sont les avantages et les inconvénients de CentOS Stream par rapport à RHEL ?
Quelles sont vos attentes en matière de distribution Linux pour entreprise ?

[Mathis Lucas]

Oracle jette de l'huile sur le feu en critiquant la décision de Red Hat de restreindre l'accès au code source de RHEL
il promet de ne pas faire de même avec sa propre distribution Oracle Linux

Oracle s'invite dans la polémique suscitée par la récente décision de Red Hat de restreindre l'accès au code source de sa distribution RHEL. La firme de Santa Clara, en Californie, a dénoncé cette décision et affirme qu'IBM tente de tuer la concurrence entre les distributions Linux pour augmenter ses bénéfices. Il s'agit là d'une déclaration surprenante de la part d'Oracle qui est reconnu comme étant une entreprise avide de licences logicielles. En outre, Oracle a également déclaré qu'elle continuerait à distribuer gratuitement le code source de sa distribution Oracle Linux et à le rendre compatible avec RHEL en amont, sans préciser comment il obtiendra les sources à l'avenir.

Oracle s'attaque à Red Hat et à IBM au sujet d'une supposée violation de la GPL

Red Hat s'est attiré une condamnation générale après avoir annoncé le mois passé qu'il commencerait à restreindre l'accès au code source de Red Hat Linux Enterprise (RHEL) aux clients payants. De plus, l'accord conclu avec les clients leur interdit de partager et de redistribuer le code source ou de l'utiliser pour créer une distribution en aval. Cette mesure a été perçue comme un moyen de cibler Rocky Linux, AlmaLinux et Oracle Linux, qui sont tous deux compatibles à l'identique avec RHEL et dont on pense généralement qu'ils sont en violation de la GPL. Cette décision fait suite à une série de choix et de décisions controversés d'IBM et de sa filiale Red Hat.

Après l'annonce, AlmaLinux a rapidement travaillé sur une voie à suivre et Rocky Linux a également partagé quelques idées sur la façon dont ils pourraient continuer à fournir une distribution Linux compatible avec RHEL. Bref, IBM et Red Hat ne publient le code source de RHEL depuis le 21 juin et la situation est tendue entre Big Blue et les développeurs qui dénoncent une violation des principes fondamentaux de la communauté des logiciels libres et open source. De nombreux développeurs dont les distributions Linus sont basées sur RHEL de Red Hat ou compatibles avec cette dernière ont réagi à l'annonce, sauf Oracle. Mais c'est désormais chose faite.

L'entreprise a publié lundi un communiqué de presse intitulé "Keep Linux Open and Free - We Can't Afford Not To" (Gardez Linux ouvert et libre - nous ne pouvons pas nous permettre de ne pas le faire) critiquant ouvertement la décision de Red Hat. Le communiqué a été publié par Edward Screven, architecte en chef d'Oracle, et Wim Coekaerts, responsable du développement d'Oracle Linux. Le géant de Santa Clara a accusé Red Hat et IBM de ne pas être de bons citoyens de l'open source et a déclaré qu'il avait rendu sa distribution Oracle Linux compatible à l'échelle 1:1 avec RHEL afin de ne pas fragmenter davantage la communauté Linux :

Bien qu'Oracle et IBM aient des distributions Linux compatibles, nous avons des idées très différentes sur nos responsabilités en tant qu'administrateurs de logiciels libres et sur le fait d'opérer sous la GPLv2. Oracle a toujours mis les binaires et les sources d'Oracle Linux à la disposition de tous. Nous n'avons pas de contrats d'abonnement qui interfèrent avec les droits d'un abonné à redistribuer Oracle Linux. En revanche, les contrats d'abonnement d'IBM précisent que vous êtes en infraction si vous utilisez ces services d'abonnement pour exercer vos droits au titre de la GPLv2. Et maintenant, depuis le 21 juin, IBM ne publie plus le code source de RHEL.

Le billet de blogue fait référence à un billet de suivi de Red Hat dans lequel Mike McGrath, vice-président de Core Platforms Engineering, a tenté de justifier la décision de l'entreprise en disant qu'il s'agissait de payer les ingénieurs de Red Hat pour le travail qu'ils effectuent. Oracle dissèque ensuite la réponse, en se penchant sur la véritable motivation derrière la décision de Red Hat et d'IBM :

Intéressant. IBM ne veut pas continuer à publier 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.

Le blogue poursuit en mentionnant CentOS. Il n'est pas surprenant que CentOS soit en tête de liste des préoccupations de l'auteur qui tente de justifier la rétention du code source de RHEL. CentOS a été une distribution gratuite compatible avec RHEL très populaire. En décembre 2020, IBM l'a effectivement supprimée en tant qu'alternative gratuite à RHEL. Deux nouvelles alternatives à RHEL ont vu le jour à la place de CentOS : AlmaLinux et Rocky Linux. Aujourd'hui, en retenant le code source de RHEL, IBM les a directement attaquées.

Et c'est peut-être là la véritable réponse à la question de savoir pourquoi : éliminer les concurrents. Moins de concurrents signifie plus d'opportunités de revenus pour IBM.

Oracle a lancé ce qui est maintenant appelé Oracle Linux en 2006, et le plan était de fournir une distribution Linux compatible avec RHEL, afin de ne pas fragmenter la communauté Linux et de soutenir une plate-forme commune pour les clients et les fournisseurs de systèmes indépendants (ISV). Maintenant que la compatibilité avec RHEL est incertaine, Screven et Coekaerts affirment dans leur billet de blogue qu'Oracle Linux maintiendra la compatibilité jusqu'à la version 9.2 et qu'après cela, l'entreprise prévoit de travailler avec les clients et les éditeurs de systèmes indépendants pour résoudre les problèmes qui pourraient survenir.

Quant à Oracle, nous continuerons à poursuivre notre objectif pour Linux de manière aussi transparente et ouverte que nous l'avons toujours fait, tout en minimisant la fragmentation. Nous continuerons à développer et à tester nos produits logiciels sur Oracle Linux. Oracle Linux continuera à être compatible avec RHEL dans la mesure où nous pouvons le faire. Dans le passé, l'accès d'Oracle aux sources RHEL publiées a été important pour maintenir cette compatibilité. D'un point de vue pratique, nous pensons qu'Oracle Linux restera aussi compatible qu'il l'a toujours été jusqu'à la version 9.2, mais après cela, il peut y avoir une plus grande chance qu'un problème de compatibilité survienne. Si une incompatibilité affecte un client ou un ISV, Oracle s'efforcera de remédier au problème.

La communauté est divisée en ce qui concerne l'interprétation de la licence GPL

Le commentaire a beaucoup surpris dans la communauté. Oui, il s'agit même Oracle qui, en janvier 2019, a mis fin aux mises à jour publiques gratuites du JDK Oracle pour les utilisateurs commerciaux non clients d'Oracle, ce qui a incité Red Hat à prendre en charge OpenJDK 6 et OpenJDK 7. C'est ce même Oracle qui reproche à Red Hat de mettre fin à la distribution gratuite du code source de RHEL aux non-clients. Selon les termes de la GPL, et d'après certains analystes, Red Hat n'est tenu de fournir le code source qu'aux clients payants recevant les binaires RHEL. La décision de Red Hat ne violerait donc pas les termes de la GPL.

Par contre, Bruce Perens, l'un des fondateurs du mouvement open source, a déclaré par courrier électronique à The Register qu'IBM, comme Red Hat avant lui, se joue de la GPL. Selon lui, le problème serait lié à une mauvaise interprétation de la GPL. « La GPL exige que les changements soient partagés en tant que code source. Si elle était écrite aujourd'hui, elle exigerait qu'elles soient partagées publiquement en ligne. Comme elle a été inventée à l'époque des bandes magnétiques pour les données, elle exige seulement que le code source soit donné aux personnes qui reçoivent la version binaire du programme », a déclaré Bruce Perens.

Selon Perens, IBM profite de cette situation d'une manière qui n'est peut-être pas équitable pour la communauté des contributeurs qui ne travaillent pas pour lui : « si vous avez RHEL, vous signez un contrat stipulant que vous ne donnerez le code source à personne d'autre pas même aux personnes qui ont écrit le programme et qui méritent d'être informées des bogues et des corrections. Telle est la triste réalité de l'open source commercial aujourd'hui. Les grandes entreprises jouent avec le paradigme et exploitent la communauté. En tant que développeurs, nous ne devrions pas continuer à les nourrir sans modifier substantiellement les licences ».

En outre, Bradley Kuhn, chargé de mission au Software Freedom Conservancy, a déclaré que ce qui ressemble à une bataille pour les clients d'entreprise pourrait nuire à la communauté open source. Kuhn a contesté l'interprétation d'Oracle de la GPL : « Oracle laisse entendre que la GPL exige que tout le code source soit mis à la disposition du public. IBM et Red Hat ont raison lorsqu'ils affirment qu'ils ne doivent fournir le code source correspondant complet (CCS) qu'à ceux qui reçoivent une distribution binaire ou qui demandent le code source complet en même temps qu'une offre de code source de la part d'un distributeur ». Kuhn a ajouté :

« Si le fait de ne pas fournir le CCS à l'ensemble du public fait de quelqu'un un mauvais citoyen du logiciel libre, cela ne signifie pas (en soi) qu'il y a eu violation de la GPL. Malheureusement, la guerre des mots entre ces deux entreprises de logiciels essentiellement propriétaires (IBM et Oracle) ne fait que détourner l'attention des principales préoccupations liées au modèle commercial de RHEL. Les contrats RHEL exigent des clients qu'ils consentent à des audits de type BSA. Lors de l'audit, s'ils trouvent ne serait-ce qu'une copie supplémentaire (légitime !) que vous avez faite d'un logiciel sous licence GPL, ils révoquent définitivement vos services RHEL ».

Kuhn a déclaré qu'il n'était pas certain que le modèle commercial de Red Hat soit compatible avec la GPL. « S'il est autorisé, il est très proche de la limite. Je ne pense pas que nous devrions nous contenter de la GPL. Je ne pense pas que nous devrions lui donner un laissez-passer », a-t-il déclaré. Selon les experts, il est possible que l'affaire se termine devant les tribunaux, bien qu'il soit douteux que le Software Freedom Conservancy ou quiconque dans la communauté soit désireux de déposer une plainte. IBM a montré qu'il avait un appétit pour les litiges longs et coûteux. Kuhn préférerait que la situation soit résolue par un meilleur comportement.

« Red Hat, qui appartient à IBM, devrait cesser volontairement et immédiatement cette pratique. Red Hat s'est longtemps targué d'avoir une position morale supérieure à celle d'Oracle. Tout le modèle commercial d'Oracle est centré sur l'utilisation de licences propriétaires agressives qui laissent leurs clients dans l'angoisse. J'ai été triste de voir le modèle commercial de RHEL pencher de plus en plus dans cette direction », a déclaré Kuhn. La position d'Oracle est similaire à celle de SUSE, qui a également souligné son engagement en faveur des principes de l'open source. En outre, Oracle s'engage ensuite à ne jamais adopter l'approche de Red Hat :

Nous voulons souligner aux développeurs Linux, aux clients Linux et aux distributeurs Linux qu'Oracle s'engage en faveur de la liberté 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 favorablement les distributions en aval de toutes sortes, communautaires et 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.

Source : Oracle

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des déclarations d'Oracle ? Les comprenez-vous ?
Que pensez-vous de la décision de Red Hat de restreindre l'accès au code source de RHEL ?
Selon vous, la décision de Red Hat viole-t-elle les termes de licence GPL ? Pourquoi ?

Voir aussi

Red Hat consacre CentOS Stream comme le seul référentiel pour les sources publiques de Red Hat Enterprise Linux (RHEL), une décision qui pourrait perturber certains acteurs du monde de l'open source

Rocky Linux présente les failles juridiques de la licence de RHEL qui permettront à sa reconstruction de perdurer, un discours en faveur de l'open source, mais qui doit encore faire ses preuves

Comment la négligence de Red Hat en matière d'open source nuit à la communauté, selon un mainteneur Linux qui estime que les distributions gérées par des entreprises ne sont pas dignes de confiance

Red Hat accuse certains détracteurs de vouloir profiter du code de RHEL sans payer ou de le reconditionner à leur profit, son vice-président de l'ingénierie répond aux critiques

[phil995511]

Pourquoi la Linux fondations et la Gnu fondations n'ont-ils pas encore pris parti et modifié les licences utilisée par de Linux pour obliger tous les acteurs de ce marché à partager tous les codes sources utilisés ?! Ils se doivent d'empêcher IBM ainsi que tout autre acteur du marché à chercher à s’approprier ce qui ne leur appartient pas !!!

[LittleWhite]

Bonjour,

Pour avoir vu dans changements de licence effectuer par certains projets open source, cela est une chose plutôt compliquée (pour faire bien, c'est-à-dire, aussi légalement que possible). Notamment, il faut :

• être sur que la nouvelle licence ne sera pas en désaccord avec les bibliothèques utilisées dans le projet, et même, les morceaux de code qui auraient pu être repris d'autres projets ;
• demandé l'accord à tous les contributeurs du projet

Si vous n'avez pas l'accord ou si une licence est en conflit avec votre nouvelle licence, alors vous devez chercher une bibliothèque de remplacement (cela sera du travail), ou réécrire le code.

Donc, c'est un travail. Et là, je ne parle pas du cas d'un changement de licence sur une bibliothèque, mais sur une application finale. Du coup, j'imagine que cela sera encore plus compliquée pour la bibliothèque. Et puis, vous allez vous faire forké dès que vous allez annoncer votre changement de licence (oh!, mais c'est déjà arrivé et pour des changements moindres (LibreOffice, le drama Audacity...)).

Aussi, je pense que votre proposition va à l'encontre de la philosophie de ce genre de projets. Pourquoi autant de projets sous licence MIT, Apache 2 ou autre. C'est de l'altruisme, sûrement dans l'espoir de voir un monde meilleur. Ces gens savent et ont accepté que oui, leurs contributions gratuites seront un jour ou l'autre utilisées par une grande société et seront même à la source de certaine richesse et ce, peu importe les valeurs morales des utilisateurs.

[rapsys]

Oracle c'est la société qui a racheté un concurrent à son SGDB pour stopper le développement dessus et capter les clients qui lui échappaient encore.

Il ne faut pas non plus oublier que c'est à cause d'Oracle que Red Hat avait déjà cessé de distribuer le détail des patchs de son noyau linux pour ne fournir qu'un gros patch cumulatif pour leur compliquer le travail de pompe...

Bref, ce que fait Red Hat est mal, mais Oracle c'est encore pire !

[Aiekick]

ne serait-ce pas le fromage qui dit au camenbert qu'il pu ?

[Fifou625]

personnellement j'estime que dans une mesure tout les acteurs ont raison sur certain point,
le problème du libre: c'est qu'il y a une personne qui fait à manger et les autres peuvent manger sans échange réciproque et ça pose un gros problème : tout les clone de redhat n'existerai pas si RHEL n'était pas là avec tout le process de dev/QA . et pour ça il faut developpeur payé à plein de temps et il faut les payer , les clones de RHEL ne font que surfer/sangsue/leech sur RHEL. (après RHEL pourrait fournir des tarifs plus flexible abordable en fonction du revenu de l'entreprise client (surtout sans support))
après le problème de redhat c'est que ça les oblige à faire un paywall qui s'éloigne de l'esprit du logiciel libre.



->une solution serait que tout les acteurs redhat/suse/oracle crée une fondation qui possèdera/développera une distribution linux pour entreprise (commun à tous) (similaire à RHEL) avec le même niveau d'assurance qualité/certification, les développeurs seront engagé par cette fondation , elle même financée par les acteurs sur un pourcentage de la vente du support/certification/formation du coup il n' y aura plus besoin "de faire un paywall si tout le monde est mis à contribution" . en gros il faut séparer le développement de la distribution de son support.

[Madmac]

Pourquoi la Linux fondations et la Gnu fondations n'ont-ils pas encore pris parti et modifié les licences utilisée par de Linux pour obliger tous les acteurs de ce marché à partager tous les codes sources utilisés ?! Ils se doivent d'empêcher IBM ainsi que tout autre acteur du marché à chercher à s’approprier ce qui ne leur appartient pas !!!

Parce qu'il existe des zones grises. Imagine que tu fabrique un interpréteur de Python qui tourne 250% plus vite. (implicitement le code original n'est pas utiliser) Est-ce que tu as moralement l'obligation de ne pas le vendre?

[Stéphane le calme]

Jon ‘maddog’ Hall, un pionnier du logiciel libre, défend la décision de Red Hat de rendre RHEL payant.
Rappelant que « logiciel libre » n’est pas synonyme de gratuité, il estime que l'entreprise ne viole pas la licence GPL

Red Hat, la société évoluant dans le domaine du logiciel libre et de l’open source, a récemment annoncé qu’elle allait modifier sa politique de distribution de son produit phare, Red Hat Enterprise Linux (RHEL). Au lieu de fournir le code source et les binaires de RHEL à tout le monde, Red Hat a décidé de limiter l’accès aux seuls clients qui achètent une licence pour chaque système qui exécute RHEL. Cette décision a suscité de nombreuses réactions dans la communauté du logiciel libre, certains la considérant comme une trahison des principes de l’open source, d’autres comme une stratégie commerciale légitime.

Parmi les voix qui se sont exprimées sur ce sujet, il y en a une qui a une autorité particulière : celle de Jon “maddog” Hall, un pionnier du logiciel libre et un ami personnel de Linus Torvalds, le créateur du noyau Linux. Hall a publié un billet dans lequel il revient sur l’histoire du logiciel libre, explique les raisons qui ont poussé Red Hat à prendre cette décision, et défend le respect de la licence GPL qui régit le code source de RHEL.

Hall commence par rappeler qu’il a commencé à développer en 1969, à une époque où il n’y avait pas de droits d’auteur ni de brevets sur les logiciels, et où les développeurs partageaient leurs codes sources entre eux par le biais de sociétés d’utilisateurs comme DECUS (Digital Equipment User’s Society). Il raconte comment il a rencontré Linus Torvalds en 1994, alors que ce dernier venait de créer Linux, un système d’exploitation libre inspiré d’Unix. Il décrit ensuite comment Red Hat s’est imposée comme la première entreprise à proposer une distribution Linux professionnelle, destinée aux entreprises et aux administrations qui avaient besoin d’un système stable, sécurisé et supporté.

Hall explique que Red Hat a toujours respecté la licence GPL, qui oblige à fournir le code source des logiciels modifiés ou dérivés à ceux qui reçoivent les binaires. Il souligne que Red Hat a contribué à de nombreux projets open source, comme GNOME, SELinux ou systemd, et qu’elle continue à envoyer ses modifications « en amont » aux développeurs originaux. Il reconnaît cependant que Red Hat a rencontré un problème avec certains clients qui profitaient du code source de RHEL pour créer ou utiliser des distributions « compatibles », sans payer de licence à Red Hat. Il s’agit notamment de CentOS, Oracle Linux ou Rocky Linux.

Hall affirme que cette pratique réduisait les revenus de Red Hat, et donc sa capacité à investir dans le développement et le support de RHEL. Il soutient que Red Hat a donc pris une décision commerciale légitime en limitant l’accès au code source et aux binaires de RHEL aux seuls clients qui paient une licence pour chaque système. Il précise que cette décision ne viole pas la licence GPL, puisque les clients qui reçoivent les binaires reçoivent aussi le code source. Il ajoute que Red Hat propose toujours des alternatives gratuites à RHEL, comme Fedora ou Red Hat Developer Subscription.

Hall conclut en disant qu’il comprend la frustration de certains utilisateurs qui se sentent privés d’un accès gratuit à RHEL, mais qu’il ne voit pas en quoi cela porte atteinte à la communauté du logiciel libre. Il rappelle que le logiciel libre n’est pas synonyme de gratuité, mais de liberté. Il invite ceux qui veulent continuer à utiliser des distributions « compatibles » avec RHEL à se regrouper pour en créer une seule et bonne, au lieu de se disperser dans plusieurs projets concurrents. Il espère que cette situation permettra de renforcer la collaboration entre les acteurs du logiciel libre, et non pas de créer des divisions.

Ce qui va suivre constitue des extraits de son billet.

Pourquoi les entreprises paieraient-elles pour utiliser RHEL ?

Certaines entreprises (celles que nous appelons «*entreprises*») ne sont pas des universités ou des amateurs. Ces entreprises (et gouvernements) utilisent des termes tels que « mission critique » et « toujours actif ». Elles ne mesurent généralement pas leur nombre d'ordinateurs en dizaines ou en centaines, mais en milliers… et elles en ont besoin pour bien fonctionner.

Elles parlent de "Mean Time to Failure" (MTTF) et "Mean Time to Repair" (MTTR) et veulent avoir des "Terms of Service Agreements" (TSA) qui parlent de tant d'heures de disponibilité qui sont garanties (99.999 % de disponibilité) avec des pénalités si elles ne sont pas respectées. Et en règle générale, les sociétés informatiques savent que pour chaque "9" à droite de la virgule décimale, vous devez investir 100 fois plus de travail et de dépenses pour y arriver.

Et généralement, dans ces "Conditions d'utilisation", vous parlez également du nombre de « Points de contact » que vous avez entre le client et le fournisseur de services. Moins il y a de «*points de contact*», moins votre contrat coûte cher, car le «*point de contact*» fourni par le client aura plus de connaissances sur le système et le problème que votre utilisateur moyen.

De plus, sur ces contrats, le client ne fait pas appel à ce que nous appelons dans l'industrie « l'assistance de première ligne ». Le client a déjà appliqué tous les correctifs, redémarré le système et s'est assuré que la souris est branchée. Le client appelle donc un numéro spécial et obtient la deuxième ou la troisième ligne d'assistance.

Bref, des gens sérieux. Des gens vraiment sérieux. Et ces gens vraiment sérieux sont prêts à dépenser beaucoup d'argent pour l'obtenir.

J'ai travaillé à la fois pour les entreprises qui souhaitaient acheter ces services et pour celles qui devaient fournir ces services.

Beaucoup de gens comprendront que plus le nombre de systèmes que vous avez sous contrat est élevé, plus vous aurez de problèmes. De même, plus vous avez de systèmes sous contrat, plus le coût de la prestation de services par système est faible s'il est réparti uniformément entre tous les clients et systèmes qui ont besoin de ce support d'entreprise.

IBM a généralement été l'une de ces entreprises qui ont fourni un support vraiment sérieux.

Note personnelle de Jon “maddog” Hall

Comme je l'ai dit plus haut, j'ai été dans la communauté "Open Source" avant qu'il y ait l'Open Source, avant qu'il y ait la Free Software Foundation, avant qu'il y ait le projet GNU.

J'ai 73 ans et j'ai passé plus de 50 ans dans « la communauté ». J'ai des marques de fouet dans le dos pour avoir promu le code source et donné des sources même lorsque j'aurais pu être renvoyé ou traduit en justice pour cela, car le client en avait besoin. La plupart des gens qui se moquaient de moi parce que je supportais Linux quand je travaillais pour le groupe Digital Unix travaillent maintenant pour des sociétés Linux. C'est bon. J'ai la peau épaisse, mais les marques de fouet sont toujours là.

Il y a tellement de façons dont les gens peuvent aider à construire cette communauté qui n'ont rien à voir avec la capacité d'écrire du code, d'écrire de la documentation ou même de générer un rapport de bogue raisonnable.

Promouvoir simplement le logiciel libre auprès de vos écoles, entreprises, gouvernements et comprendre la communauté ferait beaucoup de chemin. Créer un club Linux dans votre école ou aider les autres à passer à Linux sont des moyens par lesquels les utilisateurs de Linux (qu'il s'agisse d'individus, d'entreprises, d'universités ou de gouvernements) peuvent contribuer à la communauté.

Mais beaucoup de resquilleurs ne le feront même pas.

Le mot de la fin

Jusqu'à présent, j'ai vu quatre distributions différentes dire qu'elles continueraient la production de « pas RHEL », générant encore plus de distributions pour que l'utilisateur moyen dise « laquelle dois-je utiliser »*? S'ils veulent vraiment faire cela, pourquoi ne pas simplement travailler ensemble pour en produire une bonne ? Pourquoi ne pas faire de leurs propres distributions un concurrent de RHEL*? Combien de temps continueront-ils à se taper dessus quand ils découvriront qu'ils ne peuvent pas gagner d'argent en le faisant ?

SuSE a déclaré qu'elle investirait dix millions de dollars dans le développement d'un concurrent de RHEL. Fantastique! RIVALISER. Créez une entreprise concurrente de Red Hat avec les mêmes canaux commerciaux, une équipe d'assistance mondiale, etc., etc. Vous constaterez que ce n'est pas bon marché de le faire. Dix millions peuvent vous aider à démarrer.

Ma réponse à tout ça ? Les clients RHEL devront décider ce qu'ils veulent faire. Je suis sûr qu'IBM et Red Hat espèrent que leurs clients verront la valeur de RHEL et le support que Red Hat/IBM et leurs partenaires de distribution lui fournissent.

Le reste des clients qui veulent juste acheter une copie de RHEL et ensuite exécuter une distribution « gratuite » sur tous leurs autres systèmes, peu importe comment il est créé, eh bien, il semble qu'IBM ne veuille plus faire affaire avec eux, alors ils devront s'adresser à d'autres fournisseurs qui ont des distributions Linux adaptées aux entreprises et qui peuvent tolérer ce type de client.

Je soulignerai également qu'IBM et Red Hat ont présenté un ensemble de conditions commerciales à leurs clients, et que ces derniers sont libres de les accepter ou de les rejeter. IBM et Red Hat sont alors libres de créer un autre ensemble de conditions commerciales pour un autre ensemble de clients.

Je veux m'assurer que les gens sachent que je n'ai aucune haine pour les personnes et les entreprises qui fixent des conditions commerciales tant qu'elles ne violent pas les licences sous lesquelles elles se trouvent. Les affaires sont les affaires.

Cependant, je soulignerai qu'aussi « diaboliques » que Red Hat et IBM ont été dépeints dans ce changement d'entreprise, il n'y a aucune mention de toutes les entreprises qui prennent en charge les « licences permissives » Open Source, qui ne garantissent pas les sources à leurs utilisateurs finaux, ou n'offrent que des licences "Closed Source"….qui ne permettent pas et n'ont jamais permis de faire des clones… Ces personnes et entreprises n'ont pas le droit de jeter des pierres (et vous savez qui vous êtes).

Red Hat et IBM mettent leurs sources à la disposition de tous ceux qui reçoivent leurs binaires sous contrat. C'est la GPL.

Pour tous les chercheurs, étudiants, amateurs et personnes avec peu ou pas d'argent, il existe littéralement des centaines de distributions qu'ils peuvent choisir, et beaucoup fonctionnent sur d'autres architectures intéressantes que RHEL ne traite même pas.

Source : billet Jon “maddog” Hall

Et vous ?

Que pensez-vous de son point de vue ?
Quelle est votre opinion sur la décision de Red Hat de changer sa licence pour RHEL ?
Pensez-vous que cette décision respecte les principes du logiciel libre et de la licence GPL ?
Connaissez-vous d’autres exemples de sociétés qui ont modifié leur politique de distribution de logiciels libres ou open source ?
Quelles sont les alternatives gratuites à RHEL que vous utilisez ou que vous envisagez d’utiliser ?
Quels sont les avantages et les inconvénients de payer une licence pour RHEL par rapport à utiliser une distribution “compatible” ?

Voir aussi :

« J'en ai terminé avec Red Hat (Enterprise Linux) ». Un développeur estime que l'entreprise a trahi la communauté des utilisateurs de Linux en mettant le code source de RHEL derrière un paywall

[bloginfo]

Malgré la décision de licencier une personne de Red Hat qui œuvrait sur le projet Fedora, IBM n'a pas l'intention de laisser choir son labo dont elle a besoin pour RHEL.

Vive Fedora !

[floyer]

C’est vraiment une présentation tronquée de la licence GPL. Elle oblige à rendre les sources accessibles, mais ce n’est pas la seule obligation. L’une des autres obligations est de fournir les versions modifiées avec la licence d’origine (GPL) qui permet explicitement la redistribution. RedHat n’a donc pas le droit de livrer des logiciels GPL en demandant à ses clients de ne pas les redistribuer, de ne pas en dériver des distributions concurrentes (comme AlmaLinux), etc.

Par contre, une distribution est une collection de logiciels dont les licences sont variées. RedHat peut donc interdire la redistribution de certaines parties de RHEL. À regarder licence par licence.

Si c’est bien fait, les logiciels restreints on un fichier «*license*» adapté indiquant les restrictions de distribution.

[emilie77]

"Au lieu de fournir le code source et les binaires de RHEL à tout le monde" ce n'est pas une violation de la GPL?