- Le projet WiX Toolset adopte une politique de Open Source Maintenance Fee (frais de maintenance open source) afin d’assurer sa pérennité à long terme
- Le code source reste fourni gratuitement conformément à la licence, mais la politique de frais de maintenance s’applique à la plupart des actions, comme ouvrir des issues, publier des commentaires ou télécharger de nouvelles versions
- En particulier, si ce projet est utilisé pour générer des revenus, le paiement de ces frais de maintenance est obligatoire
- Le paiement peut être effectué en devenant sponsor GitHub
- Petites organisations (moins de 20 personnes) : 10 $/mois
- Organisations de taille moyenne (20 à 100 personnes) : 40 $/mois
- Grandes organisations (plus de 100 personnes) : 60 $/mois
- Plus de détails sur cette politique sont disponibles sur le site officiel Open Source Maintenance Fee
2 commentaires
En pratique, c’est quasiment la même chose que RHEL.
Avis Hacker News
J’aime bien cette innovation. L’idée de base, c’est que personne ne veut voir ça devenir closed source, que le code reste librement accessible à tous, et que chacun puisse l’utiliser librement. Parce que le coût marginal de distribution du code est en pratique nul. En revanche, les mainteneurs ne veulent pas fournir gratuitement leur travail aux entreprises comme s’il s’agissait d’une œuvre de charité. Leur temps est limité, donc il est naturel qu’ils veuillent une part de revenu quand ils contribuent à une activité qui en génère. Ce n’est pas grave si ce n’est pas parfaitement applicable de manière coercitive. Désormais, les mainteneurs ont la liberté de répondre aux réclamations par « si vous voulez qu’on s’en occupe, payez ». Les entreprises qui paient obtiennent un certain niveau de support, et les utilisateurs ordinaires gardent la même expérience. Seules les entreprises qui ignorent cet avertissement en subissent les conséquences, et c’est particulièrement efficace face à des arguments du type « beaucoup d’utilisateurs importants sont affectés ». Si c’est vraiment nécessaire, il est normal de payer. Avec la hausse du code, des rapports, etc. générés par l’IA, je trouve que c’est une solution assez élégante à un problème fréquent dans l’open source
J’ai des sentiments mitigés là-dessus. Je ne suis pas utilisateur de Wix, et c’est un avis général sur le sujet plutôt que sur ce cas précis. On ne peut forcer personne à maintenir un projet open source. Toutes les corrections sont volontaires. Aucune entreprise ne peut obliger quelqu’un à accepter une PR ou à faire le travail. Les développeurs FOSS sont souvent sous pression, mais en l’absence d’incitation financière, ils peuvent tout simplement refuser. Il peut y avoir des plaintes, mais il n’y a aucune obligation de corriger le problème. Le modèle du sponsoring donne au fond l’impression de transformer le FOSS en business model. Et à partir de là, ce n’est plus vraiment du FOSS. L’essence du FOSS, c’est que n’importe qui peut copier, modifier et en faire une activité commerciale. C’est ce qu’on accepte avec la plupart des licences. Mon avis ne sera peut-être pas populaire, mais je ne pense pas qu’il y ait lieu de s’emporter sur cette affaire
Je voudrais souligner deux aspects négatifs de cette politique. D’abord, cela pourrait rendre plus difficile l’attraction de nouveaux contributeurs. On risque de créer une structure à deux vitesses entre contributeurs payés et non payés. Des réactions du type « moi je corrige des bugs gratuitement pendant que d’autres gagnent de l’argent » peuvent apparaître. Ensuite, à partir du moment où de l’argent entre en jeu, la relation devient beaucoup plus transactionnelle. Puisqu’il y a paiement, il y a aussi des attentes et du travail demandé en retour. Bien sûr, le modèle bénévole a lui aussi des problèmes de pérennité
Je ne trouve pas ça si innovant. On est simplement passé d’un produit gratuit à un produit désormais vendu. Autrement dit, ça ressemble à une activité gérée comme une entreprise classique
Je pense qu’il vaudrait mieux permettre à n’importe qui de payer pour la fonctionnalité ou le support qu’il souhaite, et garder le code en closed source jusqu’à un certain seuil. Selon l’intérêt et les revenus, cela pourrait prendre quelques mois ou quelques années. Ensuite, le code finirait par être publié en open source. Sinon, tout le monde attend que quelqu’un d’autre paie à sa place. Il faudrait bien sûr concevoir le système pour éviter une multiplication des forks, mais c’est tout à fait faisable
Je pensais déjà que plusieurs projets open source fonctionnaient ainsi. Je croyais que c’était le cas du consultant qui maintient Busybox, mais j’ai peut-être mal compris la situation
Cela n’a absolument rien à voir avec Wix, le créateur de sites web ; ici on parle de WiX Toolset
La présentation dit : « Le toolkit qui permet de créer l’expérience d’installation Windows la plus puissante. Open source depuis 2004 ! »
Merci. Au début, j’avais cru qu’il s’agissait de Wix. Wix produit vraiment beaucoup de bibliothèques React Native de grande qualité
J’ai découvert cette politique un peu par hasard il y a quelques mois, en étudiant des installateurs pour mon propre projet open source. Si le code source est sous licence OSI, je n’ai aucun problème de principe avec la vente de binaires. En revanche, cette phrase dans le README m’a gêné : « Pour assurer la pérennité à long terme de ce projet, l’utilisation de WiX Toolset implique des frais de maintenance open source. Le code source est fourni librement sous licence, mais toutes les autres fonctionnalités, y compris la création ou les commentaires d’issues, la participation aux discussions et le téléchargement des releases, sont elles aussi soumises à ces frais. En d’autres termes, une utilisation à but lucratif nécessite des frais de maintenance. » J’imagine qu’on peut l’interpréter de bonne foi, car c’est un concept difficile à résumer en une courte phrase. Mais justement, le raccourci « si vous en tirez un revenu, vous devez payer » risque d’induire en erreur. Puisque la licence MS-RL n’impose aucune restriction pour un usage commercial si l’on compile soi-même, cela ressemble à mes yeux à une forme d’« intimidation » destinée à pousser les utilisateurs commerciaux à devenir sponsors. Je comprends les difficultés des mainteneurs open source, mais cette approche ne m’a pas semblé éthique. J’ai donc renoncé à utiliser WiX, alors même que je ne suis pas un utilisateur commercial
C’est une manière claire de dire qu’ils ne fourniront pas de support gratuit aux utilisateurs commerciaux. Tu disais que l’explication n’était pas claire, mais la phrase citée précise bien que « le code source peut être utilisé librement selon les termes de la licence »
Les startups et les petites entreprises qui manquent de moyens prennent souvent un projet open source, le compilent elles-mêmes, en font leurs propres artefacts de distribution et le gèrent en interne. Une fois une certaine taille atteinte, il devient plus intéressant de payer pour un support officiel qui prend en charge tout ce processus. Cette politique vise à pousser les entreprises à payer ce support officiel lorsqu’elles ne veulent pas assumer elles-mêmes le risque lié à l’usage de simples binaires open source sans support direct
Résumer cette idée en une seule phrase est vraiment très difficile, parce que les attentes autour des projets open source varient énormément. Si quelqu’un a une suggestion pour améliorer le texte, je suis preneur à tout moment
À mes yeux, cela signifie que si tu fais une demande en représentant une organisation à but lucratif, il faut payer pour ouvrir la discussion. Si la communication poursuit un intérêt commercial, elle devient payante
En lisant les commentaires de l’issue GitHub, l’équipe m’a semblé assez raisonnable. Si j’ai bien compris, ils ne veulent de l’argent que dans les cas où il y a réellement des revenus. Si c’est vraiment un développeur solo ou un produit très naissant, ils ne s’en soucieront probablement pas tant que ça. Il existe aussi une page de sponsoring
Il est aussi question du site lui-même : https://opensourcemaintenancefee.org/. Il n’est lisible correctement qu’en mode sombre ; en mode clair, on ne voit presque rien. En plus, il était impossible d’ouvrir une issue dans le dépôt. Peut-être que l’auteur verra ce commentaire ici (peu probable)
Ah, donc pour ouvrir une issue il fallait payer les frais de maintenance ! Je plaisante
Oh, c’était un vrai problème sérieux. C’est maintenant corrigé grâce à un contributeur aléatoire !
Si c’était le service juridique de mon entreprise, face à une EULA de ce genre, au lieu de nous dire de payer, il nous dirait simplement d’arrêter immédiatement d’utiliser cet outil. Je pense que la plupart des entreprises réagiraient ainsi. Peut-être que cela convient aux mainteneurs, mais j’ai toujours soutenu que si l’on veut garder l’open source tout en limitant l’usage commercial, il faut choisir l’AGPL. L’AGPL est presque du poison pour les entreprises. Aucune société où j’ai travaillé n’autorisait l’usage de code AGPL dans un produit commercial. Ensuite, il suffit de vendre une licence commerciale
Les projets open source fonctionnent souvent comme un système de charité et d’honneur. Les contributeurs y gagnent de l’honneur, les entreprises qui les utilisent y gagnent des revenus. Chacun en retire donc un bénéfice, et cela profite indirectement à l’humanité. Personnellement — peut-être naïvement — je pense que cette forme de charité pourrait revenir à l’humanité de manière plus directe et plus explicite. Par exemple, lorsqu’un projet sort sous licence publique, les entreprises qui l’utilisent pour générer du chiffre d’affaires pourraient verser environ 1 % de leur revenu à un fonds mondial, une sorte de « Decentralized Universal Kindness Income » (DUKI). Les entreprises qui contribuent activement au projet pourraient bénéficier d’une exemption totale ou partielle, ce qui leur donnerait un certain avantage même si de grands groupes concurrents réutilisent ensuite le projet (c’est d’ailleurs pour ce genre de raison que Redis a changé de licence). Les contributeurs gagneraient une reconnaissance et un prestige bien plus grands à l’échelle mondiale, et les entreprises qui donnent pourraient non seulement utiliser largement les ressources open source, mais aussi en tirer un bénéfice d’image et de réputation marketing. Elles pourraient devenir bien plus compétitives que des entreprises uniquement centrées sur le profit. J’appelle cela une « licence DUKI ». L’idée centrale consiste à ajouter à la licence MIT une seule condition de partage des bénéfices. Malheureusement, je n’ai pas l’influence nécessaire pour promouvoir cette idée, et je ne sais pas si les mainteneurs et fondateurs qui structurent l’écosystème open source seraient prêts à l’adopter
Il est indiqué que « le code source est librement disponible sous licence, mais toutes les autres activités, y compris l’ouverture d’issues, les commentaires, la participation aux discussions et le téléchargement des releases, exigent le respect des frais de maintenance », et j’ai été surpris de voir que cela incluait aussi le téléchargement des releases. Je ne suis pas juriste, mais à mon sens cela semble entrer en conflit avec la licence elle-même. En particulier avec la clause selon laquelle « chaque contributeur accorde une licence de droit d’auteur non exclusive, mondiale et gratuite permettant de distribuer, utiliser et modifier ses créations et œuvres dérivées ». De cette façon, on ne fait qu’ajouter de la confusion, et on finit pratiquement par pousser à automatiser la création de forks qui mirroirent les releases. D’ailleurs, le dépôt fournit déjà les GitHub Actions pour cela
La clause de licence que tu cites signifie seulement qu’on a le droit de copier, modifier (ou compiler) et distribuer ce code. Elle n’impose pas l’obligation de distribuer aussi les binaires. En réalité, cette manière de faire est assez courante. La plupart des licences open source ne s’appliquent qu’au code source. L’observation sur l’« incitation à l’automatisation du mirroring et des forks » se tient, mais pour les développeurs logiciels, cloner directement et compiler soi-même est en fait quelque chose de simple et naturel. Autrefois, recopier et utiliser directement les sources était la façon normale de faire, et c’est aussi pour cela que le FOSS a gagné en popularité. Ce n’est pas un « contournement » ; c’est plutôt l’essence même du FOSS
Je suis entièrement d’accord. Mais dans la réalité, cela ne s’est pas passé ainsi. La plupart des entreprises ont jugé nos frais de maintenance tout à fait raisonnables et ont préféré bénéficier d’un support officiel sans avoir à assumer les risques de maintenance et de fork du projet
Je ne sais pas si c’est moi qui ne comprends pas le « hype » autour de cette affaire. La licence ne change pas, donc si on ne paie pas les frais de maintenance, on n’a simplement pas de support ? Si quelqu’un signale une faille, WiX ne la corrigera que si l’auteur du signalement paie d’abord les frais ? Ou bien si un utilisateur d’entreprise propose une bonne idée de fonctionnalité, elle sera ignorée tant qu’il n’aura pas payé ? Tout cela me paraît assez évident. Les auteurs open source ont toujours choisi eux-mêmes quelles PR accepter et à quelles issues prêter attention. Ils ont toujours pu facturer du support. Je me demande donc en quoi ce système de frais de maintenance serait innovant. Ce n’est pas une critique. Je trouve très bien de publier un outil sous licence open source, et il est tout à fait normal de recevoir du financement. Si des contributeurs se sentent exclus, ils peuvent toujours forker. Ce n’est pas un concept nouveau. Bien sûr, un fork est une décision qui demande des ressources financières et humaines non négligeables. Même une très grande entreprise comme Amazon a souvent plus intérêt à payer les auteurs initiaux pour obtenir leur attention. On a déjà vu des cas comme LibreOffice, io.js, OpenTofu ou neovim. Si l’on arrive à faire émerger une vraie bifurcation comme LibreCAD, c’est aussi une forme de savoir-faire. io.js a d’ailleurs contribué à rendre nodejs plus sain, donc cela avait du sens. La force de la communauté, c’est justement l’un des grands atouts de l’open source. Tout le monde peut contribuer, que ce soit avec du code, de la documentation, de l’argent ou des idées. Merci à WiX de participer à la communauté de cette manière, et j’espère que cela continuera bien
L’installateur WiX est un outil complexe et difficile à comprendre. Je ne l’utilisais que parce qu’il était gratuit. S’il devenait payant, je choisirais plutôt un produit commercial plus simple et mieux accompagné. Rob Mensching avait déjà tenté de monétiser cela avec un service de conseil et de support à 5 000 dollars par an, mais il semble que cela ne suffise pas
Dire que « le seul avantage, c’était la gratuité » est vrai pour ceux qui utilisaient cet outil sans vouloir y consacrer d’argent. Mais la plus grande valeur de WiX ne réside pas simplement dans sa gratuité. WiX Toolset permet d’exploiter le potentiel de Windows Installer d’une manière qu’aucun autre outil d’installation ne permet. Si l’on n’avait pas besoin de capacités avancées, alors oui, l’outil pouvait paraître inconfortable et plein de limites. Mais pour des problèmes d’installation complexes, ces fonctionnalités très pointues étaient justement indispensables. Sur le point des « 5 000 dollars par an de monétisation par le conseil », je ne gagne pas simplement 5 000 dollars par an avec WiX en tant que tel. Avec mon équipe et grâce à des décennies d’expérience accumulée dans les packages d’installation, ainsi qu’aux outils avancés fournis par FireGiant, je propose des services sur mesure haut de gamme via le programme « WiX Developer Direct ». Nous offrons des permanences mensuelles, des garanties SLA, des revues de code annuelles, des outils avancés et d’autres services premium, et nos clients les apprécient beaucoup. Ce n’est pas une question de dire que cela ne suffit pas, mais l’affaire récente de XZ Utils m’a fait prendre conscience à quel point la pérennité de l’open source est réellement un sujet grave. J’ai donc cherché une solution, et l’Open Source Maintenance Fee me paraît être une option assez pertinente pour un projet comme le mien. WiX Toolset est actuellement le premier à adopter ce modèle, ce qui lui donne aussi un rôle de terrain d’expérimentation pour voir, par essais et erreurs, comment cela fonctionne en pratique. Jusqu’ici, cela se passe très bien
En réalité, WiX est essentiellement un outil qui permet d’écrire directement en XML la structure de base de données interne utilisée par Windows Installer. Le format MSI et Windows Installer étant extrêmement complexes, cette réputation n’est pas vraiment propre à WiX ; c’est plutôt le format MSI lui-même qui ressemble déjà à un « labyrinthe complexe » dès le départ
Je croyais que la licence appartenait à Microsoft, mais si l’on regarde le texte intégral de la licence, il est indiqué que « les releases binaires publiées sur GitHub et NuGet.org sont soumises à une EULA qui exige le paiement de frais de maintenance ». Je ne suis pas juriste non plus, mais dans ce cas, si on compile soi-même puis qu’on redistribue, on peut donc contourner ces frais ? Et même distribuer gratuitement le résultat ?
Le code appartient à la .NET Foundation, pas à Microsoft (l’histoire est un peu longue). Compiler soi-même pour contourner les frais de maintenance est bel et bien totalement autorisé. Il faut simplement assumer toi-même les 500 000 lignes de code. Bon fork à toi !
D’après le README du dépôt, le code source est open source, mais les fonctionnalités d’issues et de releases du dépôt nécessitent le paiement des frais de maintenance