1 points par GN⁺ 2023-06-27 | 1 commentaires | Partager sur WhatsApp
  • Jeff Geerling, qui était resté dans l’écosystème Red Hat même après la fin de CentOS, met fin à la prise en charge officielle d’Enterprise Linux à la suite du changement d’accès aux sources de RHEL
  • La nouvelle politique modifie le flux de sources nécessaire aux reconstructions de RHEL, ce qui fragilise la base de distributions dérivées comme Rocky Linux et AlmaLinux
  • Même si la GPL permet de placer les sources derrière un abonnement payant, des conditions permettant de résilier l’abonnement en cas de redistribution peuvent poser des problèmes juridiques et de confiance communautaire
  • Les développeurs ainsi que les mainteneurs d’EPEL/Fedora doivent désormais repenser leur infrastructure de test en fonction d’un compte développeur Red Hat et de 16 licences RHEL
  • Geerling estime que Red Hat est en train de perdre, pour des raisons de profit, la confiance qu’elle avait bâtie dans la communauté open source, tandis que Rocky Linux et AlmaLinux disent chercher chacune leur propre voie de survie

Le problème de l’accès aux sources de RHEL ressurgit après la fin de CentOS

  • Il y a deux ans, Red Hat a mis fin à CentOS, une distribution Enterprise Linux gratuite très utilisée
  • La communauté d’utilisateurs de CentOS était qualifiée de « freeloaders », c’est-à-dire de profiteurs utilisant le travail de Red Hat sans contrepartie, et Geerling se considérait comme faisant partie de cette communauté
  • CentOS servait de base aux développeurs open source, aux contributeurs du noyau Linux et aux développeurs logiciels pour leurs tests et leurs builds
  • Geerling souligne aussi que Red Hat construit ses produits sur Linux, que l’entreprise n’a ni créé ni possédé

La promesse de 2020 et l’impact sur les distributions dérivées

  • Il est indiqué qu’après le changement de cap de CentOS en 2020, Red Hat avait promis de continuer à publier les sources git
  • Le changement actuel met aussi en grande difficulté des projets plus anciens que CentOS parmi les dérivés de RHEL, comme SDL/PUIAS
  • Geerling estime que ces distributions subissent des dégâts collatéraux dans la situation actuelle

Rocky Linux et AlmaLinux avaient empêché un exode massif

  • Si Geerling est resté dans l’écosystème Red Hat après l’arrêt de CentOS, c’est pour deux raisons
    • certains employés de Red Hat ont cherché le dialogue en demandant « comment faire mieux » au lieu d’attaquer la communauté des utilisateurs open source
    • Rocky Linux et AlmaLinux sont apparus et sont devenus des cibles de travail open source stables pour les développeurs
  • Mais ces deux distributions dépendaient d’un modèle dans lequel Red Hat partageait le code source

L’ancien modèle de publication des sources de RHEL

  • L’ancien fonctionnement pouvait être compris comme suit
    • Red Hat prend une copie de Linux
    • Red Hat y ajoute ses propres modifications pour en faire Red Hat Enterprise Linux
    • une nouvelle version est publiée
    • le dépôt de code source contenant les éléments nécessaires à une reconstruction complète est mis à jour
  • Selon cette vision, le cœur de l’open source est que les sources restent ouvertes et que chacun partage son travail afin que tous en bénéficient
  • La licence GPL utilisée par Linux impose légalement le partage du code source
  • Sans ce partage, il serait difficile d’imaginer l’existence de nombreuses distributions Linux comme Debian, Arch, Mint, Ubuntu, PopOS ou Fedora

Des sources derrière un paywall et la polémique sur les conditions d’abonnement

  • Red Hat a décidé de placer le code source derrière un paywall
  • Geerling reconnaît que cette approche est, techniquement, compatible avec la GPL
  • Il la critique toutefois comme une méthode grossière et irritante, dans la mesure où une grande partie du code ainsi verrouillé repose sur le code open source d’autres personnes
  • Le sujet plus sensible concerne les conditions d’abonnement actuelles de Red Hat
    • Red Hat indique pouvoir résilier le compte d’un utilisateur si celui-ci télécharge puis redistribue le code source
    • si quelqu’un télécharge les sources via un abonnement Red Hat, construit une nouvelle version de Rocky Linux, puis voit son abonnement résilié par Red Hat, Geerling estime qu’il s’agirait d’une affaire judiciaire à suivre de près
  • On ne sait pas si la communauté pourrait réunir les moyens financiers nécessaires pour affronter les puissants avocats d’IBM, mais Oracle est mentionné comme un acteur capable de le faire
  • Geerling considère que l’action de Red Hat se situe au plus près de la limite de légalité des conditions de la GPL pour Linux, et cite cette analyse connexe : le billet de Software Freedom Conservancy

La conviction qu’il s’agit d’une pression sur les distributions dérivées

  • D’après les éléments observés par Geerling, Red Hat cherche à faire pression sur des distributions dérivées comme Rocky, Alma ou Oracle Linux
  • Il pense que Red Hat veut inquiéter les utilisateurs de ces distributions afin de les faire migrer vers des abonnements Red Hat
  • Il ajoute une lecture plus cynique selon laquelle cette mesure servirait à verrouiller des profits à court terme pour satisfaire IBM

L’image passée de l’entreprise open source face à la situation actuelle

  • Red Hat avait autrefois l’image d’une entreprise rebelle, se présentant, avec des publicités citant Gandhi, comme un outsider capable de bousculer les éditeurs de logiciels propriétaires grâce à l’open source
  • Aujourd’hui, Red Hat occupe presque la position de choix par défaut lorsqu’il s’agit de faire tourner Linux dans les grandes entreprises
  • Geerling estime qu’une formule de Cory Doctorow sur le déclin des plateformes s’applique aussi à Red Hat
    • une plateforme commence par bien traiter ses utilisateurs, puis les exploite au profit de ses clients commerciaux, et finit par exploiter aussi ces clients commerciaux pour extraire toujours plus de valeur avant de mourir
  • À ses yeux, Red Hat abandonne, au nom du profit, la bonne volonté qu’elle avait accumulée dans la communauté open source autour de Linux

Une charge opérationnelle supplémentaire pour les développeurs et mainteneurs

  • Des développeurs comme Geerling, les mainteneurs du dépôt EPEL et les mainteneurs Fedora s’inquiètent des effets à long terme
  • Il leur est désormais indiqué de s’inscrire à un compte développeur Red Hat afin d’obtenir 16 licences RHEL pour les tests
  • Geerling estime que cela oblige à revoir l’infrastructure de test et l’automatisation pour les adapter aux licences Red Hat
  • Debian, Ubuntu, FreeBSD et Rocky Linux n’imposent pas ce type de procédure
  • Il s’oppose aussi aux appels des employés de Red Hat à utiliser CentOS Stream
    • si Rocky et Alma Linux ont été téléchargés des millions de fois, ce n’est pas sans raison
    • CentOS Stream n’est pas, selon lui, un remplaçant de CentOS

Fin du support Enterprise Linux et inquiétudes autour d’Ansible

  • Depuis vendredi dernier, Geerling a supprimé la prise en charge officielle d’Enterprise Linux de l’ensemble de ses travaux
  • Il reçoit aussi des questions sur Ansible
    • il présente Ansible comme Red Hat Ansible Automation Platform, c’est-à-dire un produit d’IBM
    • il ne pense pas qu’Ansible cherchera à verrouiller l’accès, mais juge anormal de devoir ne serait-ce qu’envisager cette possibilité
  • Il dit ne pas vouloir construire quoi que ce soit sur un écosystème où les utilisateurs open source sont traités de freeloaders et où deux épisodes de chaos massif se produisent coup sur coup en plein cycle de publication, sans le moindre avertissement

Rocky et Alma annoncent qu’ils trouveront une voie

  • Geerling ne pense pas que cet épisode soit bénéfique à long terme pour Red Hat
  • Il résume la situation comme quelque chose de triste pour trois catégories d’acteurs
    • les utilisateurs qui se servaient de CentOS et développaient des outils attirant de nouvelles personnes vers l’écosystème Red Hat
    • Red Hat, qui se battait autrefois pour l’open source mais érige désormais des barrières autour de son propre code source
    • les personnes restées dans l’écosystème Red Hat, qui doivent composer avec les problèmes de licence et le départ de la communauté open source
  • Rocky Linux et AlmaLinux ont chacune annoncé chercher un moyen d’avancer
  • Geerling dit qu’il continuera à prendre en charge Rocky Linux et AlmaLinux dans la mesure du possible, mais qu’il n’a plus la certitude de pouvoir continuer à prendre en charge Enterprise Linux à l’avenir

1 commentaires

 
GN⁺ 2023-06-27
Avis sur Hacker News
  • Je trouve ce type de commentaire à chaud, émotionnel et assez léger sur les faits, peu constructif
    Cette décision de Red Hat me déplaît, et la direction que prend Red Hat m’inquiète beaucoup. Pour la première fois depuis plus de 10 ans, je réévalue l’écosystème sur lequel s’appuient mon travail et les entreprises où je prends des décisions
    Il devient difficile de croire que la direction de Red Hat se soucie encore vraiment de l’open source, et même si c’était le cas, elle a montré qu’elle pouvait nuire à l’open source pour augmenter son chiffre d’affaires à court terme
    Cela dit, si je comprends bien, le terme freeloaders a été utilisé par une seule personne, on ne sait pas clairement qui était visé dans ce contexte, ni s’il s’agissait d’un avis personnel ou de la position de l’entreprise. Cela ne semble pas non plus désigner les gens qui utilisaient CentOS tout en contribuant réellement à la communauté
    Dans une grande organisation, il y a forcément des gens qui ont des opinions que l’ensemble de l’entreprise ne partage pas ; juger toute l’organisation à partir des mots d’une seule personne est injuste et contre-productif
    Je ne vois pas bien quel est l’objectif ici. Polariser la situation en termes de bien contre mal, pour que chacun se replie sur son camp par peur que le « camp d’en face » utilise chaque parole et chaque décision contre lui ?
    J’aime beaucoup le contenu de l’OP, mais je m’inquiète un peu de le voir trop s’enfoncer dans la formule du succès sur YouTube, qui consiste à susciter l’émotion, surtout la colère et l’indignation ; du coup, il traite aussi cette affaire de manière excessivement émotionnelle

    • Indépendamment de ce que Red Hat a réellement dit, je me demande pourquoi on ne pourrait pas simplement appeler ça du parasitisme
      Tous les utilisateurs de CentOS n’étaient pas des parasites, et il en va de même pour les utilisateurs de ses successeurs spirituels. Mais la majorité des utilisateurs de CentOS ne redonnaient quoi que ce soit, d’une manière ou d’une autre, ni à CentOS ni à la communauté plus large du logiciel libre / open source
      Et un nombre important d’entre eux utilisaient CentOS parce qu’ils voulaient tous les avantages de Red Hat EL sans vouloir en payer le prix
      Cela ressemble quand même beaucoup à du parasitisme. Les licences open source copyleft autorisent le parasitisme [1], et elles autorisent aussi Red Hat à restreindre l’accès au code source. Tant que l’entreprise respecte ses obligations de licence envers ses clients, il n’y a pas de problème
      Red Hat injecte énormément d’argent dans l’écosystème du logiciel libre / open source, et je trouve tout à fait légitime qu’elle pousse les clients qui ont largement les moyens à payer un abonnement. Pour les autres utilisateurs, il existe beaucoup d’alternatives
      [1] Avec une licence non copyleft, Red Hat n’aurait bien sûr aucune obligation de fournir le code source
    • Ce n’est pas Red Hat qui les a qualifiés de freeloaders, c’était une formulation employée dans un article de The Register
      « Après avoir laissé passer suffisamment de temps pour éliminer la plupart des clones, Red Hat a aussi supprimé la version gratuite officielle de son produit phare payant. À la place, l’entreprise est passée à une offre de version d’essai gratuite, annoncée avec un discours positif sur la participation de la communauté, etc. En réalité, cela revenait à couper l’accès à ce qui, du point de vue de Red Hat, pouvait ressembler à une bande de profiteurs. Cette mesure incluait aussi le déploiement gratuit en production de RHEL pour les développeurs, mais limité à 16 machines maximum »
      https://www.theregister.com/2023/06/23/red_hat_centos_move/
    • Geerling est très doué pour faire remonter son contenu en haut des listes
      J’ai ressenti la même chose à propos de son deuxième billet sur Red Hat. Il publie parfois des choses intéressantes, mais la plupart du temps, le marketing façon YouTube est vraiment trop appuyé
      Je sais qu’il fait délibérément ça pour obtenir des métriques, et j’espère que ça fonctionne bien pour lui et lui attire le public qu’il cherche. Vu qu’il ne change pas de méthode, c’est probablement le cas
    • Dire que c’était « une seule personne », c’est minimiser : l’idée que les utilisateurs de CentOS étaient des profiteurs était assez largement partagée, à l’intérieur comme à l’extérieur d’IBM
      Je me souviens de l’annonce initiale de la suppression de CentOS au profit de CentOS Stream. Beaucoup d’employés d’IBM, c’est-à-dire de Red Hat, défendaient ce changement en décrivant les utilisateurs de CentOS comme des gens qui utilisaient gratuitement un produit payant
      Il y avait aussi beaucoup de gens sur Hacker News, Reddit, etc., pour défendre cette position. J’aimerais qu’on n’essaie pas de réécrire l’histoire
    • Au contraire, je pense qu’il faut ce type de réaction émotionnelle. Un principe de base en pédagogie, c’est que plus le lien entre l’action et la conséquence est proche, plus le conditionnement fonctionne bien
      Ils devraient craindre un retour de bâton à chaque fois
      Les gens doivent être réellement prêts à partir. Sinon, on finit comme sur Reddit, où au bout du compte tout revient exactement comme avant
  • Je comprends le point de vue de Jeff, mais il me semble que c’est déjà la troisième fois en une semaine qu’un billet de cette personne sur ce sujet arrive en première page de HN
    J’ai l’impression qu’il n’y a plus rien à tirer de cette pierre. Jeff est libre de prendre son ballon et de rentrer chez lui, et Red Hat aussi, d’ailleurs
    Mais j’ai l’impression qu’on a dépassé le stade de la « nouvelle notable », et je ne pense pas qu’un billet de plus, exprimant la frustration de Jeff, fasse vraiment avancer la discussion

    • Personnellement, ça ne me gêne pas. Dans le monde de l’open source, c’est une grosse affaire, et même après plusieurs années, pour quelqu’un comme moi qui ne connaissait pas très bien CentOS et RHEL, ce genre de billets apporte quand même une certaine prise de conscience
      Je ne sais pas s’il en fallait trois, ni s’ils devaient tous finir en première page de HN, mais dans l’ensemble, ça ne me semble pas être un si gros problème. C’est simplement ce que les gens ont choisi de voter
    • Je ne pense pas que le public visé par ce billet soit Hacker News
    • Je comprends aussi la réaction de ceux qui demandent qui est Geerling ;-)
      Je plaisante, mais il y a quelques jours encore, j’ai dû le chercher sur Google moi aussi. Ces temps-ci, je ne suis plus beaucoup de chaînes de YouTubers tech
  • Pour reprendre la formulation de Jeff, l’ancienne méthode consistait à ce que Red Hat prenne une copie de Linux, y ajoute une « sauce magique » pour en faire Red Hat Enterprise Linux, publie une nouvelle version, puis mette à jour dans le dépôt de code source toutes les données nécessaires pour reconstruire le tout depuis zéro
    Pour ajouter quelques précisions, la partie sauce magique a désormais disparu. Toute sauce secrète ou tout équipement de boîte noire est maintenant exposé publiquement dans CentOS Stream
    Red Hat ne développe plus RHEL derrière le pare-feu de l’entreprise ; tout le travail se fait désormais publiquement dans CentOS Stream. Il n’y a qu’une exception pour les CVE de sécurité, mais dans les faits ils arrivent dans CentOS Stream et RHEL en même temps une fois l’embargo levé
    Au fond, tout ce débat vient du fait qu’on ignore délibérément CentOS Stream. Les clones de RHEL n’ont qu’à suivre CentOS Stream, et ils peuvent aussi reproduire la « sauce secrète » qu’est le flux CI/CD de CentOS Stream
    Aujourd’hui, le processus pour cloner RHEL est bien plus simple qu’à n’importe quelle époque passée

    • J’ai deux réflexions
      Reproduire à l’identique, bugs compris, demande désormais plus d’efforts qu’il y a quelques semaines. Et cela revient à faire ce travail en parallèle de Red Hat lui-même, donc avec une duplication des efforts
      Et quand on voit que ce changement a forcé Rocky et AlmaLinux à s’adapter en plein milieu du cycle de publication de 9.x, tout comme l’arrêt précédent de CentOS était déjà intervenu au milieu du cycle 8.x avec moins de 24 heures de préavis, il est difficile de penser que ce changement a été fait « uniquement pour améliorer le développement de CentOS et de RHEL »
      Si c’était vraiment l’objectif, cela aurait dû être annoncé au moins quelques semaines, et si possible quelques mois, à l’avance pour que la communauté puisse s’organiser. Au lieu de cela, elle s’est fait prendre de court deux fois de suite
    • Pour commencer, Jeff ne doit rien à Red Hat et il est libre d’arrêter le « support » de RHEL pour n’importe quelle raison, ou même sans raison
      Cela dit, dire qu’ils « prennent une copie de Linux » résume de manière excessivement simpliste l’énorme quantité de travail que Red Hat fournit pour produire une version de RHEL
      Red Hat assemble des centaines voire des milliers d’upstreams pour produire RHEL, contribue à beaucoup d’entre eux, teste l’ensemble comme un tout, aide ses partenaires à certifier leurs logiciels dessus, et fait bien d’autres choses encore
      Il est exact que Red Hat ne « possède » pas le noyau Linux, mais l’entreprise y contribue énormément depuis très longtemps. Et RHEL n’est pas seulement un noyau, ni même un unique upstream. C’est le résultat de milliers de paquets testés ensemble puis publiés comme un produit supporté
      Ce que Red Hat cherche à protéger, ce n’est pas le code source d’un projet particulier ni même de plusieurs projets, mais la valeur créée en assemblant tous ces éléments. Et, par coïncidence, ce que demandent les entreprises, les concurrents et la communauté, ce n’est pas le code source en tant que tel, mais précisément cette valeur
      Tout le monde veut en pratique l’instantané d’un moment précis qui fait consensus comme standard de fait. Parce que l’ensemble de la communauté n’a pas réussi à se mettre d’accord sur un autre standard viable permettant de cibler largement les applications. Ce standard a un nom : c’est RHEL, et il appartient à Red Hat
      Si vous le souhaitez, vous pouvez prendre toutes les pièces et les assembler vous-même. Mais personne, en dehors de Red Hat, n’a le droit de certifier cela comme étant RHEL, officiellement ou officieusement
      Si cela vous met en colère, je recommande sincèrement d’essayer de faire de Debian le standard que tout le monde cible pour ses certifications. Ou bien de créer une entreprise qui dépasse Red Hat et prenne la place que RHEL occupe aujourd’hui
      Mark Shuttleworth critique depuis des années le modèle économique de Red Hat autour de RHEL, mais quand on voit qu’Ubuntu Pro repousse désormais certaines mises à jour de paquets à cinq ans et fait payer les mises à jour des dépôts Universe et Main, cela ressemble quand même beaucoup à quelque chose de similaire
    • On ignore délibérément le fait que CentOS Stream est l’upstream de RHEL. CentOS était le downstream de RHEL
      Oracle Linux, Alma Linux et Rocky Linux sont tous des downstreams de RHEL
      Vous pouvez passer la journée à affirmer à quel point CentOS Stream ressemble à RHEL. Vous pouvez dire que le fait qu’il soit désormais l’upstream ne change rien pour vous
      Mais dans les faits, le fait d’être un upstream ou un downstream compte pour beaucoup d’utilisateurs et d’entreprises
      Il est aussi important qu’IBM tente de bloquer l’accès au code open source et cherche à empêcher les abonnés de redistribuer ce même code open source
      IBM cause des dommages extrêmes à l’écosystème open source dont elle tire profit
    • Il y a quelques semaines, les source RPM étaient encore fournis publiquement, donc je considère qu’à ce moment-là, cloner RHEL était plus simple
  • C’est moi qui ai écrit ce tweet
    Mike, qui avait été le premier à signaler cela sur Mastodon, vient de mettre à jour son tweet — ou plutôt son toot — pour indiquer que ses contacts chez Red Hat ont confirmé qu’il s’agissait d’un bug
    L’abonnement développeur reste toujours limité à 16 serveurs
    https://twitter.com/fareszr/status/1673145072714665984

  • RHEL bénéficie d’un avantage important dans l’écosystème des pilotes, dont ils ne mesurent peut-être pas eux-mêmes toute la portée. Je pense qu’ils risquent de le gâcher
    Quand l’industrie a commencé à prendre Linux au sérieux, RHEL était la distribution dominante. Du coup, par accident, RHEL et ses distributions dérivées sont devenues la principale cible des pilotes matériels commerciaux
    Par exemple, des cartes réseau à faible latence peu connues ou des cartes de capture de paquets sont plus faciles à faire fonctionner sur des distributions dérivées de RHEL que sur d’autres systèmes. Quand on parle aux entreprises qui fabriquent ce type de matériel, elles partent du principe que la famille RHEL est le standard par défaut
    C’est grâce au support des pilotes que les distributions dérivées de Red Hat sont devenues la norme parmi les distributions commerciales. Mais Red Hat n’a pas récupéré ce volume de déploiement. En pratique, le gros des installations se trouve du côté de CentOS/Rocky/Alma, déployés dans des hedge funds, des sociétés de trading pour compte propre, des grilles d’exploration pétrolière, etc.
    À mes yeux, cette situation autour des pilotes constitue la vraie valeur de l’écosystème Red Hat. L’espace utilisateur est un peu désordonné et le gestionnaire de paquets n’a rien d’impressionnant. Pourtant, on déploie des distributions dérivées de RHEL parce que les pilotes fonctionnent sans trop de problèmes
    Si Red Hat parvient à éliminer les distributions dérivées, cela déclenchera un point de bascule où l’industrie cessera de considérer la famille RHEL comme la cible standard pour les pilotes
    Une entreprise qui utilisait CentOS sur 5 000 serveurs ne va pas soudain payer 350 dollars par an et par serveur. Elle migrera vers Debian et acceptera la douleur de la transition. La culture des pilotes commerciaux suivra rapidement. Un tel changement culturel peut se produire en quelques jours, pas en quelques années
    Je pense que le modèle de facturation au serveur de Red Hat est naïf. Pour 350 dollars par an, on n’obtient qu’une licence sans support. Cela générera peut-être un peu de revenus auprès des petites entreprises et des sociétés qui ont des attentes traditionnelles en matière de service, mais est-ce vraiment là que se trouve l’opportunité ?
    Quand on construit un datacenter, on veut pouvoir démarrer chaque serveur en PXE. Cela permet de changer l’image système d’une grille en créant une nouvelle image PXE puis en redémarrant les hôtes. Mettre cette configuration en place est pénible, et ce serait bien que Red Hat propose une solution prête à l’emploi bien conçue
    Un modèle du genre 2 000 dollars par an pour 100 serveurs par site, avec support du boîtier PXE lui-même, suffirait. Si Red Hat prenait cette voie, il pourrait coexister avec les distributions dérivées. Sous forme d’appliance, cela pourrait devenir un produit universel, comme un pare-feu ou un commutateur réseau

    • Si ça ne te dérange pas, j’aimerais comprendre ce qui fait que les pilotes pour du matériel plus spécialisé sont mieux adaptés, ou se compilent mieux, sur RHEL
      J’ai l’impression que RHEL applique essentiellement des correctifs sur le même noyau sans trop changer les interfaces. Donc j’aurais tendance à penser que des pilotes fournis en source, ou même certains pilotes sous forme de blobs binaires, devraient pouvoir se compiler et fonctionner à peu près comme sur un noyau standard
      À part le fait que les développeurs de pilotes utilisent RHEL/CentOS et valident leur fonctionnement dessus, est-ce qu’il y a quelque chose qui m’échappe ?
  • L’analyse juridique de RHEL et de la GPL publiée par la Software Freedom Conservancy, celle liée par l’OP, était ce qu’il y avait de plus intéressant
    https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...

    • À cause de formulations ambiguës du genre « contourner la ligne », j’ai du mal à considérer que c’est une très bonne analyse
      On peut utiliser du code GPL d’autrui dans un produit et le vendre. Si quelqu’un en fait la demande, il faut « divulguer » les sources GPL ainsi que son propre code dérivé du code GPL. Ici, divulguer veut simplement dire qu’il faut les fournir sur demande, pas qu’il faut mettre en place une page de téléchargement publique ni les rendre faciles d’accès
      On peut les envoyer sur le support demandé, DVD ou clé USB par exemple, et facturer à peu près le coût du support. Autrement dit, il n’est pas nécessaire de rendre les sources faciles à obtenir, ni de fournir gratuitement le produit compilé
      Il y a beaucoup de choses qu’on peut faire à l’intérieur des limites de la GPL. Si IBM/Red Hat agit dans ce cadre, où est le problème ?
      On peut aussi faire ce genre de chose sans la GPL. Par exemple, SQLite3 est dans le domaine public, mais il existe un SQLite Consortium, et j’imagine qu’il procure de très bons revenus à D. R. Hipp et à ses employés. S’il y a si peu de concurrence par des forks, c’est surtout parce qu’il est très difficile de forker SQLite3 de manière fiable, notamment parce que la meilleure suite de tests est propriétaire et gardée secrète
      Pour les entreprises, l’open source est un outil. Pour les particuliers aussi, l’open source est un outil. Quand un jeune qui débute a peu de ressources, il peut créer un logiciel utile en open source, gagner en notoriété, puis obtenir un meilleur emploi ou l’occasion de lancer son entreprise
    • Il y a eu une discussion hier : https://news.ycombinator.com/item?id=36452101
  • Les MBA d’IBM ont enfin pris le contrôle de Red Hat
    L’idée, c’est d’essorer encore un dollar de plus, même si cela se retourne contre eux à long terme. On savait bien que ça finirait par arriver, et franchement, ce qui surprend, c’est que cela ait pris si longtemps

    • Ces MBA-là visent leur bonus annuel
      C’est quelque chose qu’on voit dans beaucoup d’entreprises aujourd’hui. Des projets démarrent alors qu’ils n’iront nulle part ou seront bientôt annulés, les bonus tombent, les gens partent, et le cycle recommence
      Ceux qui restent pour le profit à long terme passent pour des idiots. D’un autre point de vue, on peut aussi se dire que les travailleurs ont enfin percé à jour le secret des entreprises
    • J’entends souvent ce sentiment, mais d’après ce qu’on voit à l’intérieur de Red Hat et dans l’actualité publique, rien ne vient vraiment l’étayer
      Cette décision semble avoir été prise avec une forte implication de personnes présentes depuis longtemps. Et si la réalité était exactement l’inverse ?
  • Les formulations du genre « oublions aussi que Red Hat construit son produit sur Linux, qu’ils n’ont ni créé ni possédé » passent à côté du fait qu’une part importante du succès durable de Linux est due à Red Hat
    Red Hat a eu une influence majeure en poussant la conformité réglementaire et en finançant des développements alignés sur ces exigences, ce qui a permis à Linux d’être compétitif sur les contrats publics, et les développements Linux directement soutenus par Red Hat ont aussi été énormes
    Bien sûr, Red Hat n’est pas l’unique raison du succès de Linux, mais il est clair que le succès de RHEL a joué un grand rôle pour faire de Linux une plateforme adaptée aux datacenters

    • Pas vraiment. Dans les datacenters, Ubuntu et Debian sont bien plus utilisés que Red Hat
      Linux a gagné en popularité par une diffusion de base, puis les entreprises sont venues gagner de l’argent dessus. Aujourd’hui, il existe un récit selon lequel les entreprises auraient fait tourner la machine dès le départ, mais ce n’est pas la réalité
  • Il y a plusieurs raisons pour lesquelles Stream ne peut pas être un équivalent de la famille CentOS, c’est-à-dire un substitut à Alma ou Rocky, entre autres
    Premièrement, Stream ne peut pas servir de base pour construire des paquets compatibles EL. Rien ne garantit que Stream ne casse pas la compatibilité ABI
    Deuxièmement, Stream n’a pas un long cycle de support sur plusieurs années, donc il ne peut pas être utilisé comme système stable. Bien sûr, il n’y a pas besoin du support sous licence payante de Red Hat, et il existe une grande communauté prête à aider via des rapports de bugs et des tests

    • Il est faux de dire qu’il n’y a aucune garantie sur le non-respect de la compatibilité ABI
      À strictement parler, on peut dire qu’il n’y a pas de garantie, mais une telle rupture casserait aussi une future version de RHEL, donc ce serait un bug
      La durée de support est de 5 ans
    • Je me demande généralement combien de temps les paquets restent dans Stream avant de passer à EL
  • J’apprécie sincèrement et je soutiens à 100 % le droit de chacun, Jeff compris, à prendre position lorsqu’il décide à quoi consacrer son temps
    Le temps qui nous est donné est limité et, en particulier quand ce à quoi on tient évolue, il faut aussi utiliser ce temps en conséquence. Le billet de Jeff, « Saying No », montre bien pourquoi c’est important
    Ce que j’ai du mal à comprendre, en revanche, c’est l’usage excessif d’anecdotes liées à IBM, des formulations reconstruites qui donnent l’impression que Red Hat a tenu des propos irrespectueux envers la communauté, et l’aplomb nécessaire pour dire des choses comme « dites aux employés d’arrêter [tel comportement] »
    Je comprends que cette affaire ait pu être ressentie comme une rupture de confiance, et qu’une confiance brisée soit probablement ce qui fait le plus mal. Donc je comprends aussi la réaction émotionnelle
    Mais en tant que mainteneur ou contributeur open source, pour alléger bien davantage sa propre charge cognitive, il aurait sans doute mieux valu simplement cesser le support et passer à autre chose
    https://www.jeffgeerling.com/blog/2022/just-say-no