IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Stéphane le calme

6PARTAGES

14  0 
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?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de rapsys
Membre du Club https://www.developpez.com
Le 13/07/2023 à 10:44
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 !
3  0 
Avatar de OrthodoxWindows
Membre émérite https://www.developpez.com
Le 07/07/2023 à 14:38
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.
2  0 
Avatar de floyer
Membre averti https://www.developpez.com
Le 08/08/2023 à 19:27
La GPL permet de ne distribuer qu’à peu de monde…. Mais ne permet pas d’interdire aux destinataires de redistribuer eux même.
2  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 12/07/2023 à 21:58
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.
1  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 13/07/2023 à 11:41
ne serait-ce pas le fromage qui dit au camenbert qu'il pu ?
1  0 
Avatar de floyer
Membre averti https://www.developpez.com
Le 08/08/2023 à 16:33
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.
1  0 
Avatar de floyer
Membre averti https://www.developpez.com
Le 05/07/2023 à 18:20
"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.
0  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 05/07/2023 à 18:56
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.
0  0 
Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 09/07/2023 à 20:16
Citation Envoyé par marc.collin Voir le message
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.
0  0 
Avatar de phil995511
Membre éprouvé https://www.developpez.com
Le 12/07/2023 à 13:31
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 !!!
0  0