- Le changement des conditions de mise à disposition des sources de RHEL doit être compris dans la longue histoire d’Unix, de GNU, de Linux et d’IBM, et IBM/Red Hat estime respecter le principe du GPL selon lequel « le destinataire d’un binaire reçoit aussi les sources »
- À ses débuts, le logiciel était créé et partagé par des chercheurs et des utilisateurs selon leurs besoins, mais à partir des années 1980, le copyright et les licences se sont renforcés, faisant diverger EULA, contrats de code source, licences permissives et GPL
- GNU et Linux ont grandi grâce au code source ouvert et aux contributions de la communauté, et IBM a renforcé la confiance dans l’écosystème après avoir annoncé un investissement d’un milliard de dollars dans Linux, puis embauché des développeurs et fait face au procès SCO
- RHEL est un produit serveur d’entreprise qui s’appuie sur Fedora comme base d’expérimentation, et Red Hat cherche à amortir via les licences clients les coûts du support, de l’assurance qualité, de la documentation, de l’ingénierie de publication et de l’organisation mondiale de support
- Les utilisateurs de clones de RHEL peuvent choisir une autre distribution Linux, mais pour les créateurs de clones, il serait plus productif de construire une distribution concurrente de RHEL plutôt qu’une simple copie
Position de départ pour comprendre le changement chez Red Hat
- Les récents changements des conditions commerciales de Red Hat ont suscité la controverse, mais l’essentiel est la manière de fournir les sources aux clients ayant reçu les binaires de RHEL
- L’essence du GPL est de garantir l’accès au code source et la possibilité de le modifier, afin que les destinataires de binaires puissent corriger des bugs et étendre le système d’exploitation
- IBM/Red Hat considère qu’il fournit aux clients sous contrat le code source ainsi que les informations nécessaires pour reconstruire les versions distribuées, et continue aussi à envoyer en amont les modifications apportées au code sous GPL
- Il est difficile de regrouper tous les intérêts sous le seul mot « communauté », et les utilisateurs qui n’ont pas besoin du même niveau d’ingénierie et de support peuvent choisir une autre distribution Linux
Du partage logiciel à l’ère des licences
- Vers 1969, la programmation était surtout pratiquée par des chercheurs, des professeurs et des ingénieurs pour leurs propres travaux, et le métier de « programmeur professionnel » était encore rare
- Des groupes d’utilisateurs comme DECUS distribuaient les logiciels écrits par leurs clients au prix de la copie, et de nombreux utilisateurs publiaient leur code dans le domaine public
- À l’époque, l’application du copyright et des brevets au logiciel était limitée ; pour protéger du code, il fallait donc s’appuyer sur le secret commercial, le droit des contrats et la distribution de binaires
- Au début des années 1980, avec l’application d’un copyright fort aux binaires comme au code source, les développeurs ont eu besoin de licences pour expliquer les droits accordés aux utilisateurs
- Des EULA sont apparus pour les utilisateurs finaux
- Des contrats de code source distincts s’appliquaient aux développeurs
Les bases posées par Unix, BSD et GNU
- Unix a démarré en 1969 chez Bell Labs, puis s’est diffusé vers des universités de recherche comme UC Berkeley, le MIT, Stanford et CMU
- Le BSD Unix d’UC Berkeley fournissait la mémoire virtuelle paginée à la demande, une pile TCP/IP native et de riches utilitaires, servant de base à plusieurs premiers fournisseurs Unix
- Des produits comme SunOS, Ultrix et HP/UX ont adopté une base BSD
- Le commentaire de John Lions sur Unix Version 6 a longtemps été empêché de publication officielle, mais ses copies ont appris à d’innombrables programmeurs Unix la structure du noyau et la logique de sa conception
- Les licences de code source Unix d’AT&T étaient coûteuses et restrictives ; certaines entreprises ont donc choisi des accords de redistribution pour vendre des systèmes de type Unix en binaire uniquement
- Après avoir découvert des distributions Unix fournies uniquement en binaire, Richard M. Stallman a lancé le projet GNU, estimant inacceptable que les utilisateurs ne puissent pas effectuer les modifications dont ils avaient besoin
- L’objectif de GNU était de créer un système d’exploitation libre garantissant que quiconque distribue des binaires fournisse aussi les sources et la possibilité de les modifier
- Des logiciels directement utiles aux programmeurs, comme emacs, une suite de compilateurs et divers utilitaires, ont été créés en premier
Différence entre licences permissives et GPL
- Des universités comme le MIT et UC Berkeley voulaient distribuer leur code de recherche plutôt que le vendre, mais après l’application du copyright, elles ont eu besoin de licences définissant les conditions d’usage et les limitations de responsabilité
- Ces licences ont ensuite été qualifiées de licences permissives dans le monde open source
- Elles permettent aux développeurs de créer des distributions en binaire uniquement
- Elles n’obligent pas à publier aux utilisateurs finaux les modifications apportées au-delà du code source reçu à l’origine
- Le GPL a été présenté comme une licence restrictive imposant que l’utilisateur final ayant reçu un binaire puisse aussi voir les modifications
- Le GPL a fait l’objet de nombreuses incompréhensions à ses débuts
- Certains pensaient que les binaires produits avec le compilateur GNU étaient eux aussi soumis au GPL
- D’autres pensaient qu’on ne pouvait pas vendre du code sous GPL, ce que RMS contestait
- Des entreprises comme Walnut Creek et Prime Time Freeware for Unix vendaient des collections de logiciels open source sur CD-ROM et DVD
La pression sur le marché Unix et l’ascension de Linux
- Des fournisseurs de systèmes comme DEC, HP, Sun et IBM ont construit des systèmes d’exploitation de type Unix basés sur AT&T System V ou sur la famille BSD, en embauchant ingénieurs, rédacteurs de documentation, équipes QA et chefs de produit
- On estime que chaque entreprise dépensait environ 1 à 2 milliards de dollars par an pour produire un système de type Unix compétitif
- Microsoft vendait le même système d’exploitation indépendamment des fabricants de PC et a fait pression sur les fournisseurs Unix en remontant vers le marché des serveurs
- Le projet du noyau Linux a démarré fin 1991 à la confluence de plusieurs facteurs, et fin 1993 plusieurs distributions entraient déjà dans une phase de croissance
- Des logiciels issus de GNU, du MIT, de BSD et de projets indépendants existaient déjà
- Les informations sur l’intérieur des systèmes d’exploitation devenaient abondantes sur Internet
- L’Internet haut débit commençait à entrer dans les foyers
- Des processeurs peu coûteux capables de mémoire virtuelle paginée à la demande devenaient courants
- Il y a eu de la chance et des opportunités
- Il y avait aussi un chef de projet obstiné et charismatique
- Des distributions comme Soft Landing Systems, Yggdrasil, Debian, Slackware et Red Hat sont apparues, certaines commerciales, d’autres communautaires
Linux et le modèle communautaire
- L’une des raisons pour lesquelles Linux a attiré l’attention du grand public avant BSD est que BSD était alors pris dans le procès « Unix Systems Labs Vs BSDi »
- Le GPL a produit un effet dynamique en imposant la distribution du code source avec les binaires, et comme tout le monde pouvait lancer un projet de distribution sans demander d’autorisation, des centaines de distributions ont vu le jour
- Le X Window System vient du Project Athena du MIT, tout comme Kerberos
- Le développement du X Window System a ensuite quitté le MIT et Project Athena pour passer au X Consortium, qui a ouvert en 1993 et fermé en 1996
- L’OSF a été créé pour définir des standards de code source et d’API pour les systèmes Unix, avant de fusionner avec X/Open en 1996 pour devenir l’Open Group
- Plusieurs consortiums ont d’abord bénéficié de financements importants, puis ont vu leurs ressources se tarir à mesure que les entreprises participantes se retiraient en pensant que « d’autres paieraient les coûts »
Le problème de la soutenabilité du développement FOSS
- Dans les débuts du FOSS, un petit nombre de développeurs travaillait avec passion pour un petit nombre d’utilisateurs, souvent sans rémunération
- La croissance du nombre d’utilisateurs a fini par dépasser celle des développeurs, augmentant la pression sur la maintenance
- Le manque de développeurs était particulièrement visible dans les domaines jugés moins « sexy », comme la QA, l’ingénierie de publication, la documentation et la traduction
- Certains développeurs se sentaient mal à l’aise à l’idée que d’autres gagnent de l’argent avec du code qu’ils avaient contribué gratuitement, mais l’auteur estime que Linux ne peut progresser rapidement que si des entreprises peuvent aussi en tirer des revenus
- Avec le temps, la communauté en est venue à inclure non seulement les auteurs de code, mais aussi les personnes chargées de la documentation, de la traduction et de la promotion ; plus tard encore, le nombre de personnes n’utilisant qu’un logiciel gratuit sans comprendre le logiciel de liberté a augmenté
Piratage logiciel et coût du logiciel libre
- Le piratage logiciel consiste à copier et utiliser illégalement un logiciel en violation de sa licence
- Certains membres des communautés FOSS considèrent avec légèreté la propriété intellectuelle ou le copyright, mais sans copyright, le contrôle sur le logiciel disparaît lui aussi
- Lors d’une conférence au Brésil, lorsqu’il a affirmé qu’il fallait utiliser du « Free Software », le public a répondu : « Tous nos logiciels sont free »
- À l’époque, près de 90 % des logiciels de bureau au Brésil étaient piratés
- Dans une telle situation, une partie de l’avantage de coût du Free Software disparaît
- L’auteur estime que si chaque personne utilisant un noyau Linux versait seulement 1 dollar par plateforme matérielle, cela suffirait facilement à financer l’essentiel du développement FOSS
L’implication d’IBM dans Linux
- Au sein d’IBM, certaines personnes croyaient déjà au FOSS et travaillaient sur des projets pendant leur temps libre ; Daniel Frye a cherché à les regrouper dans une organisation FOSS interne pour faire avancer Linux
- L’auteur se souvient d’une lettre de Lou Gerstner indiquant qu’autrefois IBM n’allait vers l’open source que lorsqu’il y avait une raison business, mais qu’à l’avenir l’entreprise n’irait vers le logiciel propriétaire que lorsqu’il y aurait une raison business
- IBM a alors annoncé un investissement d’un milliard de dollars dans Linux, ce qui a fait grand bruit
- IBM a ensuite embauché des développeurs Linux pour travailler à plein temps sur différents pans de l’écosystème, et a également rémunéré des développeurs dans des domaines comme l’Apache Web Server
- Environ un an plus tard, IBM avait récupéré son premier investissement d’un milliard de dollars et a annoncé un autre milliard
- IBM a vendu ses activités PC portables et desktop à Lenovo et racheté Price Waterhouse Cooper, se repositionnant comme entreprise de solutions métier
- Dès lors, les solutions métier n’avaient plus besoin d’être liées uniquement au matériel et aux logiciels IBM
- L’Open Source était vu comme un moyen pour les fournisseurs de solutions IBM de construire de meilleures solutions à moindre coût
Le rôle d’IBM dans le procès SCO
- Santa Cruz Operations produisait une distribution Unix fondée sur du code AT&T, avant d’être vendue plus tard à Caldera Group
- Après avoir changé son nom en SCO, Caldera a adopté une stratégie judiciaire contre les vendeurs Linux, affirmant que Linux contenait du code source AT&T et violait les termes des licences
- Une grande partie de la communauté Linux estimait ces accusations fausses et, au vu des contrats AT&T et Novell, il paraissait difficile de croire que Santa Cruz Operations détenait réellement le copyright sur le code AT&T
- IBM, Novell, Red Hat et d’autres ont participé à la bataille judiciaire, et les tribunaux ont finalement conclu, selon ce récit, que SCO pouvait tout au plus soulever la question d’un contrat disparu avec IBM, tandis que Linux n’avait pas de problème en soi
- Le fait que Big Blue ait pris part au combat judiciaire a donné aux vendeurs et aux utilisateurs de Linux la confiance que l’affaire se terminerait bien
Red Hat et le modèle économique de RHEL
- Red Hat est parti d’une petite entreprise de Raleigh, solide techniquement mais faible en business et en marketing, puis Bob Young l’a rejointe pour aider à définir la politique et la direction de l’entreprise
- Bob Young comparait Red Hat au « Heinz ketchup de Linux », et l’entreprise a bâti ses revenus sur un modèle de vente de services
- Avec le temps, Red Hat s’est concentré sur une activité d’entreprise centrée sur RHEL
- Le desktop n’était important qu’en tant que plateforme de développement pour RHEL, et le développement desktop a été confié à Fedora
- Fedora sert de base d’essai pour intégrer ensuite de nouvelles idées dans RHEL
- Les clients de RHEL sont des entreprises et des administrations exigeant des environnements « mission critical » et « always on », exploitant souvent non pas des dizaines ou des centaines, mais des milliers de systèmes
- Ces clients traitent des exigences de service comme le MTTF, le MTTR ou une disponibilité de 99,999 %, avec clauses de pénalité, et attendent non pas un simple support de niveau 1 mais du support de niveau 2 et 3
- Red Hat investit dans le support entreprise, la QA, la documentation, la certification et l’ingénierie de publication, et ses clients paient pour cela
Les entreprises full stack et la logique du rachat de Red Hat par IBM
- Le cas d’Oracle rachetant la propriété intellectuelle de Sun Microsystems est présenté comme une stratégie full-stack consistant à contrôler à la fois le matériel, le système d’exploitation et les applications
- Une entreprise full stack peut modifier l’ensemble de la pile pour favoriser les applications, et tester l’ensemble pour identifier les inefficacités et les faiblesses
- IBM et Apple sont décrites comme des entreprises full stack, dont les produits coûtent plus cher mais trouvent malgré tout de nombreux clients exigeants prêts à payer
- Dans son activité de solutions métier, IBM avait besoin d’une solution full stack basée sur Linux, et le RHEL de Red Hat disposait déjà de la réputation et de l’ingénierie nécessaires aux solutions d’entreprise
Les clones de RHEL et le changement des conditions chez Red Hat
- Avec le temps, certains clients ont adopté un schéma consistant à n’acheter qu’un petit nombre de systèmes RHEL, puis à faire tourner le reste de leur parc sur d’autres distributions compatibles bug pour bug avec Red Hat
- Cette approche réduisait les coûts pour les clients, mais diminuait aussi les revenus de Red Hat alors que l’entreprise effectuait la même quantité de travail ; Red Hat s’est donc retrouvée sous pression pour augmenter ses prix, réduire ses effectifs ou abandonner d’autres projets
- IBM/Red Hat a pris la décision commerciale de ne distribuer le code source et les informations de build qu’aux clients achetant des licences pour tous les systèmes exécutant RHEL
- Cette condition est présentée comme compatible avec le cœur du GPL
- La personne qui reçoit le binaire peut obtenir les sources pour corriger des bugs et étendre le système
- Red Hat et IBM continuent d’envoyer en amont leurs modifications du code sous GPL
- Le partage avec la communauté au sens large et des idées se poursuit également
- L’auteur ne qualifie pas les développeurs de clones de « freeloaders », mais il estime que les utilisateurs qui exploitent des clones sans rien rendre à la communauté, sous quelque forme que ce soit, s’en rapprochent
Proposition : créer de la concurrence plutôt que des clones
- Après les changements de Red Hat, plusieurs distributions ont annoncé vouloir continuer à produire du « not RHEL », ce qui risque de rendre encore plus confuse pour l’utilisateur général la question de savoir quelle distribution choisir
- Au lieu de fabriquer plusieurs clones séparés, il vaudrait mieux unir les efforts pour créer une bonne distribution commune, ou bâtir un véritable concurrent de RHEL
- L’auteur voit d’un bon œil l’annonce de SuSE d’investir 10 millions de dollars pour construire un concurrent de RHEL
- Il note toutefois qu’il n’est pas bon marché de mettre en place les mêmes canaux commerciaux, des équipes de support mondiales et un dispositif de support entreprise comparable
- 10 millions de dollars peuvent n’être qu’un point de départ
- Les clients de RHEL doivent choisir en tenant compte de la valeur du support fourni par Red Hat/IBM et leurs partenaires de distribution
- Si IBM ne souhaite plus faire affaire avec des clients qui n’achètent qu’une seule copie de RHEL pour faire tourner le reste sur des distributions gratuites, ces clients devront trouver un autre fournisseur d’Enterprise Linux capable d’assumer ce type de profil
Conclusion personnelle
- Jon « maddog » Hall explique qu’il pratique l’ouverture du code source et la fourniture du code aux clients depuis avant même la naissance de l’Open Source, de la Free Software Foundation et du projet GNU
- La contribution à la communauté ne se limite pas à écrire du code, de la documentation ou des rapports de bugs
- On peut promouvoir le Free Software auprès des écoles, des entreprises et des gouvernements
- On peut créer un Linux Club ou aider les initiatives Upgrade to Linux
- Tant qu’une entreprise ne viole pas les licences, elle peut définir ses conditions commerciales, et les clients sont libres de les accepter ou de les refuser
- Il y a un déséquilibre à dépeindre Red Hat et IBM comme le « mal » tout en ignorant les entreprises fondées sur des licences permissives qui ne garantissent pas les sources aux utilisateurs finaux, ou qui ne proposent que des licences propriétaires fermées sans autoriser de clones
- Pour les chercheurs, les étudiants, les amateurs et les personnes disposant de très peu de moyens, il existe des centaines de distributions Linux prenant en charge jusqu’à des architectures que RHEL ne couvre pas
1 commentaires
Avis sur Hacker News
Depuis la fin des années 90, j’ai utilisé Red Hat Linux (au début Caldera Linux, un clone des années 90), Fedora, RHEL et ses clones (Scientific, CentOS, Rocky), à titre personnel, pour l’enseignement et au travail, et je les ai recommandés aussi bien sur desktop que sur serveur.
Quand on me demandait quoi choisir pour utiliser Linux, je disais souvent qu’il y avait deux options stables et bien prises en charge : Red Hat et Debian. Mais, à mon avis, Red Hat est mort récemment. RIP.
Je ne suis plus sûr que Fedora restera un projet open source actif. Si IBM est en train de tuer les clones de RHEL, pourquoi prendre le risque de penser que Fedora ne sera pas le prochain ?
Je sais bien qu’« RHEL dérive de Fedora » et que « Fedora est un projet open source distinct », mais aujourd’hui RHEL dérive de CentOS Stream. Dans ce cas, je me demande à quoi sert Fedora, et pourquoi Red Hat devrait fournir de l’ingénierie et de l’infrastructure à Fedora.
Fedora est bien un projet séparé, mais la plupart des contributions viennent d’employés de Red Hat. Si IBM décide demain que CentOS Stream suffit et cesse de financer Fedora, Fedora pourra-t-il tenir de manière indépendante ?
C’est peut-être simplement de la peur, de l’incertitude et du doute (FUD), mais je ne fais plus confiance à une distribution Linux détenue par IBM. J’ai déjà migré mes machines personnelles vers Debian, et je recommande aussi Debian au travail. Pour une organisation qui personnalise fortement ses installations Linux, choisir une distribution à la base incertaine Red Hat/IBM plutôt qu’un projet entièrement open source et sans conditions me paraît irresponsable. Trompé une fois, c’est la faute de l’autre ; trompé deux fois, c’est ma faute, et je ne me laisserai pas avoir à nouveau par IBM.
Fedora continue donc de servir de banc d’essai pour tout ce qui se trouve dans CentOS, et donc dans RHEL. Je me demande quel argument on peut opposer à une méthode de développement qui consiste à modéliser les futures versions de RHEL à partir d’une « distribution du futur » comme Fedora.
Pour ceux qui ne suivent pas de près le noyau Linux, maddog est une figure légendaire.
Son point de vue est très intéressant et appréciable, en particulier sa manière de structurer le sujet à partir de l’histoire. Connaître l’histoire aide vraiment à saisir le contexte. L’article original est long, mais il vaut la peine d’être lu.
J’ai environ 30 ans de moins que Jon Hall, donc je n’ai pas pu connaître directement ses accomplissements autrement que par des récits oraux ou écrits. Il n’a pas non plus laissé derrière lui un livre à très grand succès ou un logiciel que je pourrais utiliser (d’accord, il y a Linux for Dummies), si bien que je voyais régulièrement des gens le qualifier de légende sans comprendre pourquoi.
J’ai fini par poser la question à la communauté du noyau Linux, qui m’a expliqué l’étendue de ses contributions. D’une certaine manière, il a été le mentor de Linus. Quand ils se sont rencontrés en 1994, Linus était un étudiant de 25 ans et Jon un responsable marketing de 44 ans chez DEC. J’imagine souvent leur conversation comme une scène du genre : « Mon garçon, écoute-moi bien. Voilà ce que tu dois faire maintenant. »
En pensant à cela, une phrase de la biographie Wikipedia de Jon Hall ressort : à l’époque où il travaillait chez Digital, il s’est intéressé pour la première fois à Linux et a joué un rôle important pour obtenir l’équipement et les ressources permettant à Linus Torvalds de réaliser le premier portage vers la plate-forme Alpha de Digital.
Une ligne de son parcours LinkedIn montre la même perspective. Senior Marketing Manager, DEC, 1983-1998 : en 1994, il a rencontré Linus Torvalds, reconnu la valeur commerciale de Linux, et obtenu le financement pour porter Linux sur les processeurs Alpha 64 bits, ouvrant une ligne d’activité de plusieurs milliards de dollars autour de supercalculateurs haute performance basés sur Linux.
WP : https://en.wikipedia.org/wiki/Jon_Hall_(programmer)
LI : https://www.linkedin.com/in/maddog/
Je suis d’accord avec l’idée selon laquelle « les gens qui utilisent ces clones sans rien rendre à la communauté, sous quelque forme que ce soit, sont des “passagers clandestins” », mais c’est quelque chose que le logiciel libre a toujours accepté dans une certaine mesure. Mettre quelque chose à disposition gratuitement, cela signifie aussi que tout le monde ne rendra pas quelque chose — voire quoi que ce soit — en retour.
La différence avec quelque chose comme Oracle Awesome Linux, c’est que ceux-là vendent le travail à valeur ajoutée de Red Hat et son écosystème sous forme de service. En pratique, c’est du genre : « achetez ceci si vous voulez être pris en charge avec nos autres produits ; nous le distribuons tel que Red Hat le publie ».
À mon avis, le changement de Red Hat vise surtout à rendre plus coûteux un modèle économique propriétaire du type « Oracle Red Hat for X ». Les gens qui ne pouvaient pas se permettre RHEL pour une infrastructure haute performance académique ne le peuvent toujours pas et choisissent simplement autre chose.
Caqueter à propos de Fedora ici n’a pas grand intérêt. Fedora est un projet à vocation commerciale qui répond aux besoins de l’entreprise, et il existera jusqu’au jour où il n’existera plus.
Red Hat n’est pas Microsoft. Tout le monde reconnaît qu’il existe de nombreuses distributions, dont beaucoup sont excellentes. On peut même lancer une distribution aujourd’hui. Mais « bon, on n’a qu’à utiliser Debian » n’est pas vraiment une réponse valable non plus. Debian est un excellent projet et un excellent produit, mais si vous avez choisi Red Hat pour d’autres raisons que le CD offert avec un magazine en 1998, Debian risque de ne pas être idéale sans beaucoup de travail. Au final, c’est une question d’argent entre le coût de faire faire le travail par des humains en interne et celui de le confier à Red Hat pour que ces personnes puissent faire autre chose.
Cela me rappelle l’époque où je donnais des serveurs et de l’hébergement au projet Fedora. En configurant les serveurs, j’ai demandé au responsable : « Vous voudrez sans doute faire tourner RHEL ? » Il a répondu « oui ». Puis j’ai demandé : « Vous avez une clé de licence utilisable ? » Il a répondu : « Je peux en obtenir une, mais c’est pénible, installez simplement CentOS. »
L’instructeur nous a recommandé d’utiliser CentOS pour les exercices après le cours (avant le rachat de CentOS). Plus tard, sur l’un des projets, nous avons finalement utilisé Red Hat.
Ensuite, c’était CentOS et des clones, et pendant un moment, quand les gens disaient RHEL, ils semblaient en fait vouloir dire CentOS.
Qt, c’est pareil. Même si presque tout leur logiciel dépend de Qt, ils restent sur Qt 4.x pour éviter de payer Digia.
En tant qu’employé de Red Hat, j’apprécie le point de vue de maddog. J’aimerais que d’autres puissent avoir une vision aussi large de ce que les entreprises font pour l’open source.
Voir de l’intérieur comment les choses se construisent change la perspective. J’aimerais pouvoir expliquer aux gens ce que nous vendons réellement. Nous ne vendons pas du logiciel ni des licences logicielles.
Nous ne contournons pas les licences open source, et nous ne changeons pas les licences non plus. Nous essayons de permettre aux personnes qui font un travail utile pour nos clients de continuer à travailler. Une grande partie de ce que nous faisons remonte vers les projets amont et est partagée avec les concurrents, la communauté et les utilisateurs.
C’est agréable d’entendre maddog raconter de si bonnes histoires historiques. Quand il a fait l’une des visites à Austin dont il parle dans son texte, je travaillais au LTC, et j’ai eu l’occasion de discuter avec lui autour d’un déjeuner. C’était il y a environ 20 ans.
Il est toujours intéressant d’entendre ce qu’une personne dans ses 70 ans considère comme des « points d’inflexion » dans sa carrière. La façon dont mes propres points d’inflexion s’entremêlent avec les leurs est particulièrement frappante.
J’étais en plein milieu du bazar SCO, mais je ne sais pas si je peux parler de certaines choses. Peut-être que les avocats de l’entreprise ont désormais suffisamment pris leur retraite, ou sont morts, pour que je puisse dire ce que j’ai envie de dire. Si la motivation me vient.
Je suis content que maddog continue à partager ses histoires. Plus je vieillis, moins j’ai envie de partager quoi que ce soit avec n’importe qui sur Internet. Les conversations qui ont du sens pour moi se passent aujourd’hui presque toutes en face à face, et je vois peu d’intérêt à partager ou à m’impliquer avec des personnes que je ne connais pas personnellement.
L’entreprise où je travaille voulait mettre RHEL sur les serveurs haute performance que nous fabriquons, mais on nous a proposé environ 1 million de dollars par licence, sans possibilité de négociation. Cela aurait rendu notre produit beaucoup trop cher.
Nous sommes donc finalement passés à CentOS, puis à Rocky, et nous avons embauché une équipe d’environ 30 personnes pour gérer cela (ainsi que d’autres projets). Je respecte Red Hat et leur droit de gérer leur logiciel comme ils l’entendent, mais au vu de notre expérience ces dernières années, j’ai l’impression qu’ils cherchent à tirer le maximum de leur marque. Je me demande ce que cela donnera dans les cinq prochaines années.
Dans les passages « J’ai commencé à programmer en 1969 » et « en réalité, il était non seulement difficile de vendre du logiciel, mais on ne pouvait pas non plus lui appliquer le droit d’auteur », je me demande si c’était vraiment la situation juridique en 1969. Était-il exact qu’on ne pouvait pas appliquer le droit d’auteur au logiciel ?
Il est tout à fait plausible que l’auteur l’ait cru en 1969, mais je me demande si cette croyance était juridiquement exacte.
Je ne pratiquais pas le droit à l’époque, mais d’après ce que j’en ai entendu, il n’était pas clair si le droit d’auteur s’appliquerait aux logiciels, ni comment il s’appliquerait le cas échéant. Cela dit, les acteurs avisés s’attendaient généralement à ce qu’une forme de protection apparaisse pour les logiciels écrits, au-delà du secret des affaires.
Il y avait toutes sortes de questions, de théories et de propositions sur le fait de savoir si cela se ferait dans le cadre du droit d’auteur, ou via un régime spécifique au logiciel. Aux États-Unis, la réponse est devenue claire lorsque « computer program » a été intégré à la définition du champ d’application du droit d’auteur. Même aujourd’hui, lorsqu’on discute des questions qui subsistent, on continue de citer CONTU, la commission qui a poussé cette recommandation.
https://en.wikipedia.org/wiki/Software_copyright#History
C’est étrange de ne pas croire Jon Hall, mais de vouloir croire un parfait inconnu sur les réseaux sociaux.
J’ai rencontré maddog vers 2000, lors d’un événement à Paris que je co-organisais. Nous lui avons posé beaucoup de questions, et il a donné des réponses pleines de recul. Parfois, il les enveloppait dans de longues histoires, comme dans l’article mis en lien.
Celle dont je me souviens le mieux est celle-ci. « Question : comment pouvons-nous aider Linux à gagner de la part de marché sur le desktop, au-delà des quelques points qu’il a déjà ? »
« Réponse : vous ne pouvez pas. Trouvez un marché qui n’utilise pas encore d’ordinateurs, créez un produit qui réponde à ses besoins, et faites en sorte que ce produit utilise Linux. Pensez par exemple aux smartphones. »
C’est agréable de voir que maddog est toujours activement impliqué dans le FOSS.
Vers la fin des années 90, au COMDEX de Chicago, il m’avait convaincu, avec un ami, de tenir son stand pendant quelques heures pour qu’il puisse faire un tour du salon. Je ne me souviens plus si c’était LPI, LI, ou une autre organisation liée à Linux. Je crois que nous distribuions des CD de distributions et expliquions Linux aux visiteurs.
C’était une période folle où Linux déferlait sur le monde du PC, et Tux était partout.