OpenELA : Oracle, SUSE et CIQ s’unissent contre la décision de Red Hat

Les intérêts d’Oracle, SUSE et CIQ convergent

Pour rappel, en décembre 2020, Red Hat a décidé d’abandonner le projet CentOS, une version downstream et open source de RHEL. L’entreprise a réorganisé son cycle de développement en proposant une version open source en bêta continuelle, CentOS Stream. Celle-ci est positionnée entre Fedora et RHEL. Pour autant, Red Hat maintenait l’accès aux paquets open source pour recompiler une distribution downstream de RHEL. La décision rendue publique le 21 juin, puis détaillée le 26 juin clôt ce chapitre. Elle vise à empêcher les « cloneurs » et les « profiteurs » (freeloaders en VO) d’accéder à une distribution serveur de Linux à des fins commerciales ou pour ne pas payer la souscription Red Hat.

En réaction, les responsables des projets Rocky Linux, AlmaLinux, mais aussi Oracle Linux ont exploré des alternatives pour continuer à mettre à jour, puis faire évoluer leurs distributions de Linux dépendantes des travaux de Red Hat. Bien conscient que cela créait un trou dans la raquette, SUSE, éditeur de SUSE Linux Enterprise (SLE), avait rapidement affiché son soutien aux projets lésés par la décision de Red Hat. Comme souvent, Oracle a réagi de manière agressive en remettant la faute sur les ambitions commerciales d’IBM. Dans un même temps, le fournisseur a invité les éditeurs et membres de communauté à se ranger sous sa bannière afin de poursuivre le développement de paquets Oracle Linux compatibles avec les autres distributions libres issues de RHEL.

Si la prise de position d’Oracle n’a pas été mal accueillie, au contraire, certains ont rappelé les mesures passées prises par le fournisseur à l’encontre de projets open source. Aussi, en juillet dernier, le fournisseur ne présentait pas véritablement de solutions pour combler le vide créé par la décision de Red Hat.

De leur côté, CIQ et SUSE ont clairement fait comprendre qu’ils s’associeraient pour développer une alternative. SUSE a pour sa part annoncé un investissement de 10 millions de dollars pour fourcher une distribution de RHEL « disponible sans restriction », développée en parallèle de SLE.

Oracle les a finalement rejoints.

OpenELA ne fournira pas une énième distribution de Linux

« De nombreuses grandes organisations nous ont contactés pour exprimer l’importance d’un code source communautaire pour Linux Enterprise qui puisse servir de point de départ à des distributions compatibles », déclare Wim Coekaerts, responsable du développement d’Oracle Linux, chez Oracle, dans un communiqué de presse. « OpenELA est notre réponse à ce besoin […] ».

OpenELA est un terrain « neutre » : dans un premier temps, les trois éditeurs affichent une représentation égale à la tête de l’association. Cela pourrait changer : celle-ci entend accueillir toutes les entreprises et organisations qui soutiennent sa démarche.

Pour autant, il ne s’agit pas de lancer un remplaçant de CentOS. L’ONG n’a pas vocation à créer une énième distribution de Linux, mais à rendre les outils et les sources accessibles à tous pour compiler des versions donwstreams compatibles avec RHEL.

« [OpenELA] représente un engagement pour aider la communauté open source à continuer à développer des distributions compatibles [avec RHEL] », poursuit Wim Coekaerts

L’association fournira dans un premier temps les paquets nécessaires à la compilation de distributions compatibles « bug pour bug » avec RHEL 8, 9 et « possiblement » RHEL 7. Rocky Linux et Oracle avaient déjà pris des mesures en ce sens.

« Le projet s’engage à assurer la disponibilité continue des sources OpenELA pour la communauté, et ce indéfiniment », lit-on dans le communiqué de presse qui accompagne la création de l’association.

Dès la fin du mois de juillet dernier, Thomas Di Giacomo, CTO de SUSE évoquait auprès de ComputerWeekly, publication sœur du MagIT, la volonté de l’éditeur allemand de créer une « fondation et une communauté » pour maintenir des binaires compatibles avec RHEL.

Dans le détail, OpenELA doit fournir toutes les « sources nécessaires pour obtenir une version entièrement compatible avec Enterprise Linux », à travers un dépôt Git. Le dépôt contiendra également les données « d’errata de sécurité », des guides pour maintenir la compatibilité avec RHEL. Le site de l’organisation permettra par ailleurs de télécharger un « kit de branding » pour les distributions downstreams qui utiliseraient les paquets mis à disposition par OpenELA. Oracle établira une documentation pour les usagers et les administrateurs.

Un projet qui devra faire ses preuves

Si tout se déroule selon les plans de CIQ, SUSE et Oracle, OpenELA prendra la place de git.centos.org comme source première pour les distributions en aval de Linux Enterprise.

« Il s’agit essentiellement d’une nouvelle source upstream pour toutes les EL, qui est ouverte et ne dépend pas d’une seule entreprise », résument les porte-parole de Rocky Linux, dans un billet publié sur LinkedIn.

Les trois éditeurs n’ont pas dit s’ils exploiteront les paquets mis à disposition par Red Hat à travers le dépôt GitLab de CentOS Stream, comme l’espère Red Hat depuis 2020.

En tout cas, les professionnels de l’IT ont réagi positivement à l’annonce de la création d’OpenELA.

« Cela promet de beaux jours à nos distributions EL et permettra certainement de redonner la confiance en notre écosystème », avance Antoine Le Morvan, ingénieur système Linux chez Vivalto Santé et membre de la Rocky Enterprise Software Foundation sur LinkedIn.

D’autres sont plus prudents, comme Joshua Warcop, Solutions Architect chez Diversified.

« OpenELA a encore un long chemin à parcourir. Pour l’instant, nous en sommes au stade de l’idéation, tandis que les acteurs se rassemblent. Tout dépendra de l’exécution. Je suis sceptique, mais c’est au moins une pièce du puzzle RHEL-FOSS », écrit-il en son nom sur X (ex-Twitter).

Pour sa part, AlmaLinux a fait le choix de rendre sa distribution compatible avec les binaires de RHEL. S’il ne reproduit pas « bug pour bug » l’OS de Red Hat, AlmaLinux devra pouvoir exécuter les applications développées par-dessus RHEL.