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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
