L'engagement de Red Hat en faveur de l'Open Source : réponse aux changements apportés à git.centos.org

J'ai passé beaucoup de temps ce week-end à réfléchir aux réactions de notre secteur d'activité à mon dernier article de blog. Nous avons été accusés de malveillance, puis on m'a qualifié de cadre supérieur d'IBM dont la mission est de transformer Red Hat en fournisseur de logiciels fermés, entre autres. Mettons les choses au clair. 

Je m'appelle Mike McGrath et je suis vice-président du service Core Platforms Engineering chez Red Hat. Je travaille ici depuis 16 ans, et avant d'arriver, j'étais bénévole pour le projet Fedora. L'Open Source, et tout ce que cette notion implique, est très important pour moi. Au cours de la semaine dernière, j'ai vu de nombreuses personnes dire des choses peu aimables et fausses à propos d'employés Red Hat passionnés qui, comme moi, accordent une grande importance à ce travail.

Malgré ce qui se dit actuellement à propos de Red Hat, nous rendons notre travail acharné accessible aux personnes qui ne font pas partie de nos clients. Red Hat utilise et utilisera toujours un modèle de développement Open Source. Lorsque nous détectons un bogue ou développons une nouvelle fonction, nous partageons notre code en amont. Ce procédé profite à tous les membres de la communauté, et pas seulement à Red Hat et à nos clients.  

Nous ne nous contentons pas de prendre des paquets en amont pour les recréer. Chez Red Hat, des milliers de personnes passent leur temps à rédiger du code pour activer de nouvelles fonctions, à corriger des bogues, à intégrer différents paquets, puis à les prendre en charge pendant une longue période, ce dont nos clients et partenaires ont besoin. 

Il s'agit de longues heures et de nuits passées à rétroporter un correctif vers du code qui date de 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 à l'ensemble d'entre eux. De plus, lorsque nous développons des correctifs pour résoudre des problèmes liés à RHEL, nous ne les appliquons pas uniquement à cet outil : ils sont appliqués d'abord en amont, à des projets tels que Fedora, CentOS Stream ou le projet du noyau lui-même, puis nous les rétroportons. La maintenance et la prise en charge d'un système d'exploitation pendant 10 ans représentent une tâche herculéenne. Le travail que nous effectuons est extrêmement précieux.

Nous partagerons toujours notre code en amont et respecterons les licences Open Source utilisées par nos produits, y compris la licence GPL. Lorsque je dis que nous respectons les différentes licences Open Source qui s'appliquent à notre code, je le pense sincèrement. J'ai été choqué et déçu par le nombre de personnes qui ont asséné des contre-vérités à propos des logiciels Open Source et de la licence GPL en particulier, y compris des observateurs du secteur et même des vétérans qui, selon moi, devraient savoir qu'ils se trompent. Les détails, y compris les licences et les droits Open Source, ont leur importance, et ce sont des éléments que Red Hat a contribué 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 personnes qui ne veulent pas payer pour le temps, les efforts et les ressources investis dans RHEL, soit de personnes qui souhaitent le reconditionner pour leur propre profit. Cette demande de code concernant RHEL est fallacieuse. 

Nous devons payer les personnes qui réalisent ce travail, ces contributeurs passionnés qui passent de longues heures et de longues nuits à croire aux valeurs de l'Open Source. Le simple fait de reconditionner le code produit par ces personnes et de le revendre tel quel, sans valeur ajoutée, rend la production de ce logiciel Open Source non viable, y compris le travail critique de rétroportage ainsi que les futures fonctions 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 souhaite mentionner spécifiquement les personnes qui réalisent la recréation (à la différence des distributions) et qui peuvent, 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 n'y a pas si longtemps, Red Hat appréciait le travail effectué par des recréateurs tels que CentOS. Nous avons poussé nos SRPM vers git.centos.org dans un paquet soigné qui les a rendus faciles à recréer ; nous en avons même retiré toute trace de notre marque. Plus récemment, nous avons déterminé qu'il n'y avait aucun intérêt à disposer d'un outil de recréation en aval. 

L'opinion généralement admise selon laquelle ces recréations gratuites ne sont que des entonnoirs de conversion qui attirent des experts RHEL et se transforment en ventes n'est tout simplement pas la réalité. J'aurais aimé que nous vivions dans ce monde, mais les choses sont différentes. Au lieu de cela, nous avons trouvé un groupe d'utilisateurs, dont beaucoup appartiennent à de grandes ou très grandes organisations informatiques, qui souhaitent bénéficier de la stabilité, du cycle de vie et de l'écosystème matériel de RHEL sans avoir à gérer les personnes en charge de la maintenance, les ingénieurs, les rédacteurs ainsi que toutes celles et tous ceux qui créent le produit. Ces utilisateurs ont également décidé de ne pas utiliser l'une des nombreuses autres distributions Linux.

Dans un écosystème Open Source sain, concurrence et innovation vont de pair. Red Hat, SUSE, Canonical, AWS et Microsoft créent des distributions Linux en y associant des efforts en matière de branding et de développement d'écosystèmes. Ces variantes utilisent toutes le code source Linux et y contribuent, mais aucune ne prétend être « entièrement compatible » avec les autres.

En fin de compte, nous pensons qu'une recréation de RHEL n'apporte aucune valeur et nous ne sommes pas tenus de faciliter la tâche des recréateurs : la décision de le faire ou non nous appartient. Ce sujet m'amène à CentOS Stream, qui suscite une immense confusion. Je reconnais que ce changement vient bousculer une tradition de longue date qui nous a permis de dépasser toutes les attentes, et peut générer une certaine confusion qui s'est manifestée sous la forme d'accusations selon lesquelles nous aurions opté pour un code source fermé et enfreint la licence GPL. Il y a d'un côté le livrable binaire CentOS Stream, et de l'autre le référentiel source CentOS Stream. La source gitlab CentOS Stream est l'endroit où nous développons les versions de RHEL, à la vue de tous. Prétendre que RHEL est une « source fermée » est catégoriquement faux. CentOS Stream évolue plus rapidement que RHEL, il n'est donc peut-être pas accessible sur HEAD, mais le code est bien présent. Si vous ne le trouvez pas, il s'agit d'un bogue. Veuillez nous en informer.

Nous proposons également des souscriptions gratuites Red Hat Developer et Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure. La souscription Developer met RHEL gratuitement à disposition des équipes de développement et permet d'utiliser jusqu'à 16 systèmes, encore une fois, sans frais. La solution peut être utilisée à titre personnel ou par les clients RHEL dans le cadre du travail de leurs équipes. La souscription RHEL for Open Source Infrastructure est conçue pour permettre aux projets Open Source (qu'ils soient ou non affiliés à Red Hat) d'accéder gratuitement à RHEL afin de répondre à des besoins en matière 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 les égards, Red Hat a réussi sa mission et j'espère qu'il en sera de même pour de nombreuses entreprises Open Source. Vous pouvez décider vous-même si les recréations en aval sont utiles pour vous et si vous souhaitez ou non simplifier le travail des recréateurs. 

Le simple fait de recréer du code, sans valeur ajoutée ni modification, représente une menace réelle pour les entreprises Open Source de tous bords. Cette menace a la capacité de reléguer l'Open Source au rang d'activité réservée aux amateurs et aux pirates.

Nous ne voulons pas de cette issue et je sais que les membres de notre communauté, nos clients et nos partenaires ne le souhaitent pas non plus. L'innovation se produit en amont. Grandir grâce aux contributions des autres, tel est l'objectif de l'Open Source. Continuons à stimuler l'innovation, à nous soutenir les uns les autres et à aller de l'avant.