Forker un logiciel libre (en créer une nouvelle version indépendante de l’original) est une décision difficile, qui risque de diviser sa communauté. Je propose ici la traduction en français d’un article que j’avais initialement écrit en anglais et publié sur le blog du logiciel de création de sites web SQLPage à propos du fork d’une bibliothèque populaire du langage de programmation Rust.
Sommaire
Je suis plongé dans le milieu du logiciel libre depuis mon adolescence, et aujourd’hui, je ne peux pas imaginer un monde sans lui.
Tout au long de ma carrière d’ingénieur logiciel, je n’ai jamais rencontré d’entreprise technologique qui ne soit pas fondée sur les logiciels libres et open source. Chaque entreprise ajoute en général sa propre touche propriétaire à ce vaste paysage open source, mais elles ne font en fin de compte que former un petit mélange privateur au sommet d’un colossal iceberg de système d’exploitation, d’outils, et surtout de bibliothèques logicielles partagées et libres. Dans le monde du logiciel, l’open source est véritablement la force motrice de l’innovation.
L’argent dans le monde du logiciel
Les courants financiers qui parcourent l’industrie du logiciel défient toutes les normes conventionnelles.
Contrairement à d’autres secteurs où des acteurs clés du début de la chaîne de production tels que les compagnies pétrolières s’enrichissent en fournissant des produits essentiels à d’autres entreprises, le domaine du logiciel renverse le scénario.
Dans ce domaine, ce sont les géants de l’informatique qui font face aux clients finaux, comme Google, qui récoltent les bénéfices; et il arrive souvent que les créateurs des logiciels libres qui forment les fondations de Google et d’innombrables autres entreprises travaillent gratuitement.
Les développeurs de logiciels libres observent cette dynamique intrigante, parfois même satisfaits de voir leurs logiciels libres développés gratuitement alimenter la création d’entreprises qui font des millions de dollars de bénéfices.
SQLx : Une merveille du monde de Rust
SQLx est l’une des nombreuses bibliothèques logicielles qui se trouvent dans la partie immergée de cet iceberg logiciel. Il s’agit d’un formidable pilote de base de données SQL pour le langage de programmation Rust, qui harmonise la connexion à une multitude de bases de données. Il est téléchargé environ 20 000 fois par jour.
La fameuse version 0.7
Le principal mainteneur de SQLx a cherché à trouver un juste milieu – créer un bon logiciel libre tout en cherchant la pérennité économique de son projet. Cet effort a conduit à une décision cruciale : extraire les pilotes de base de données de la bibliothèque de base. Tout en conservant la plupart des pilotes en tant que logiciels libres sous la licence permissive MIT, la compatibilité avec Microsoft SQL Server a été abandonnée. Ce changement architectural significatif a également nécessité la suppression d’autres fonctionnalités du cadre de base, et l’introduction d’une nouvelle API, rendant la migration depuis la version précédente non triviale.
SQLPage
En tant que principal responsable du serveur d’applications web SQLPage, qui repose sur sqlx, j’ai été confronté à un tournant décisif. Deux possibilités s’offraient à moi :
- une migration difficile vers SQLx v0.7, en faisant une croix sur la possibilité d’utiliser SQLPage avec Microsoft SQL Server;
- attendre, et rester sous SQLx v0.6, une solution qui impliquait de conserver des dépendances obsolètes, contenant potentiellement des failles de sécurité rendant le logiciel vulnérable.
Après beaucoup d’hésitations, j’ai choisi une troisième voie : forker SQLx.
Désolé, j’ai forké
La situation me désole. Je suis vraiment en faveur d’un monde du logiciel libre financièrement viable. J’espère que l’auteur original arrivera à commercialiser ses futurs nouveaux pilotes de base de données et qu’ils le compenseront dûment pour les contributions inestimables qu’il a apportées.
Mais, j’ai vraiment besoin d’un bon ensemble de pilotes de base de données sous une licence permissive pour Rust, j’ai besoin de certaines des fonctionnalités qui ont été supprimées dans la v0.7, et je veux que les bases SQL Server fonctionnent avec SQLPage. J’ai donc créé sqlx-oldapi, un fork de SQLx v0.6.
Dans le fork :
- J’ai méticuleusement mis à jour toutes les dépendances vers leurs dernières itérations, m'assurant ainsi que les fondations restent robustes et sûres.
- Les fonctionnalités essentielles qui manquaient ont été incorporées pour répondre à des besoins spécifiques, et des bogues de longue date ont été résolus. Notamment, le support des types de données a été renforcé, avec par exemple un décodage efficace avec perte des valeurs
DECIMALen tant que flottants dans tous les pilotes, et un décodage sans perte vers les types natifs de rust. - Mes efforts se sont concentrés sur l’élévation du pilote SQL Server au même niveau que ses pairs. Cela a impliqué la correction de bugs et de crashs, et le support de nouveaux types de données comme
DATETIMEetDECIMAL.
La liste complète des changements peut être trouvée dans le changelog.
Notes de conclusion
- J’espère sincèrement que sqlx réussira à financer son développement.
- Aux développeurs et développeuses qui se trouvent à la même croisée des chemins que moi avec SQLPage, sachez que sqlx-oldapi vous attend, prêt à vous aider dans vos efforts, librement. Les contributions et les rapports de bogues sont les bienvenus sur github.
Et si vous voulez savoir pourquoi l’URL de cette page se termine par .sql, jetez un œil à SQLPage. [NdT : l’URL de l’article original est https://sql.ophir.dev/blog.sql?post=I’m sorry I forked you ]
Réactions à l’article original
L’article traduit ci-dessus a suscité de nombreuses réactions sur le forum de discussion anglophone reddit. La plus importante est probablement celle de l’auteur principal de sqlx, qui était mécontent de la présentation que l’article faisait de la situation, et qui a notamment apporté deux corrections importantes.
- L’auteur principal développe SQLx durant son temps de travail, et prend les décisions concernant cette bibliothèque libre en accord avec son employeur. Si la commercialisation de pilotes de base de données rapporte de l’argent, il n’ira pas directement au développeur, mais à son employeur. L’objectif affiché serait de pouvoir justifier d’accorder plus de temps exclusivement au développement de sqlx.
- Il y avait bien eu une annonce originale du passage du pilote de base de données pour SQL Server sous une licence propriétaire, mais une nouvelle annonce avait déjà été faite, depuis longtemps, lorsque l’article de blog a été publié. SQLx n’a désormais plus l’intention de publier les futurs nouveaux pilotes de base de données sous une licence privatrice, mais de les publier sous la licence libre (mais restrictive) AGPL, et de vendre des exemptions à la licence aux entreprises qui le souhaitent. Pour le moment, rien n’a encore été publié, il n’y a pas de pilote, ni libre ni propriétaire, pour SQL Server avec SQLx v0.7.
Et vous, qu’en pensez-vous ? Que pensez-vous de l’idée viabiliser le développement d’un logiciel en le publiant sous une licence libre, mais restrictive, en commercialisant des exceptions à la licence ? Est-il correct de forker un logiciel libre dont l’auteur essaie de rendre son projet plus pérenne en le monétisant ?
# Heu, et la quatrième voie ?
Posté par Pinaraf . Évalué à 9. Dernière modification le 25 août 2023 à 08:40.
Si sqlx 0.7 permet d'avoir des pilotes de bases de données à part, alors pourquoi ne pas avoir choisi de coder uniquement un pilote SQL Server pour sqlx 0.7 ? Évitant ainsi le fork (sauf pour le motif de la perte de fonctionnalités si j'ai bien compris, mais ça aurait pu être contribué directement à sqlx non ?)
[^] # Re: Heu, et la quatrième voie ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Parce que la réaction du projet "je suis libre mais quand même" pourrait être de compliquer la vie aux pilotes tiers en cassant la rétrocompatibilité régulièrement ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Heu, et la quatrième voie ?
Posté par Pinaraf . Évalué à 6.
Enfin là tu supposes que la personne sera hostile au point de se tirer volontairement des balles dans les pieds juste pour le plaisir d'emmerder les autres… C'est le cas d'une partie de l'humanité, mais pas toute quand même. De plus, si ce comportement avait lieu, le fork serait toujours possible.
[^] # Re: Heu, et la quatrième voie ?
Posté par Ltrlg . Évalué à 1.
Casser la compatibilité pour les pilotes plus souvent que pour les utilisateurs est explicitement prévu par les auteurs : Note: Semver Exempt API. Il faudra voir comment cette possibilité est utilisée, mais les pilotes tiers ne semblent pas une préoccupation des développeurs de sqlx (ce qui est compréhensible vus leurs objectifs, mais dommage pour les plus petits SGBD).
[^] # Re: Heu, et la quatrième voie ?
Posté par lovasoa (site web personnel) . Évalué à 0.
C'est une bonne remarque. Pour un pilote indépendant cela signifie:
[^] # Re: Heu, et la quatrième voie ?
Posté par Pinaraf . Évalué à 5.
Mais n'est-ce-pas autant, voire plus de travail que de maintenir un fork complet, que ce soit pour tenir à jour quand les dépendances évoluent, ou pour corriger d'éventuels problèmes de sécurité ?
[^] # Re: Heu, et la quatrième voie ?
Posté par lovasoa (site web personnel) . Évalué à 1.
Si il n'y a pas de nouvelles fonctionnalités, et que les dépendances sont stables, c'est raisonnable.
[^] # Re: Heu, et la quatrième voie ?
Posté par barmic 🦦 . Évalué à 0.
Je sais pas mais sqlx a l'air assez limité aujourd'hui comme driver, il lui manque beaucoup de drivers (Oracle, DB2, Ingres, MS Acces, LibO Base et énormément de plus petites bases moins connues mais très bien faites1) et il me semble qu'il y a un travail en cours dans les bases de données SQL pour passer à des protocoles asynchrones.
et pour le support de Mariadb a l'air de ne pas être de premier ordre, mais uniquement se baser sur la compatibilité MySQL, je ne connais pas assez les différences entre les base et le travail de sqlx pour savoir si c'est impactant pour l'utilisateur. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Heu, et la quatrième voie ?
Posté par lovasoa (site web personnel) . Évalué à 2.
C'est vrai que je n'ai pas insisté dessus dans la dépêche, mais la nouvelle architecture de la bibliothèque rendait la migration difficile, et supprimait des fonctionnalités de l'ancienne version, qui n'étaient pas implementables dans un design où le cœur de la bibliothèque n'avait pas connaissance de la liste des pilotes.
# Correct
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Il essaye de le rendre pérenne en rendant une partie non libre.
Pas de pitié pour
les croissantsles privateurs.Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Correct
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Ouh là, pas d'accord. D'une part, le droit de faire une scission est un droit fondamental et qui ne dépend pas du fait que l'auteur originel prenne telle ou telle décision.
Ensuite, le développeur originel a tout à fait le droit de changer sa licence (sauf si le logiciel intègre des contributions extérieures significatives, de gens qui ne sont pas d'accord avec ce changement).
[^] # Re: Correct
Posté par lovasoa (site web personnel) . Évalué à 4.
Ce que je précise à la fin de la dépêche, c'est qu'il comptait publier un nouveau pilote sous licence AGPL. Libre donc, mais sous des conditions plus restrictives.
[^] # Re: Correct
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Ce n'est pas plutôt une réponse au commentaire « quatrième voie » ?
[^] # Re: Correct
Posté par Colin Pitrat (site web personnel) . Évalué à 2.
Le droit de forker est présent quel que soient les circonstances.
La vraie question c'est seras tu réellement prêt à maintenir le fork dans la durée ? As-tu une vision pour ce nouveau projet ?
# Oui, on a le droit
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8.
Le droit à la scission (je ne sais pas pourquoi le mot anglais fork a été gardé dans la traduction) est une des libertés essentielles du logiciel libre (pouvoir redistribuer des versions modifiées). Qu'à titre personnel, le développeur le ressente mal, je peux comprendre mais il ne serait pas du tout normal d'essayer de culpabiliser les scissionneurs ou, pire, d'essayer d'interdire les scissions.
Donc, pour répondre à la question à la fin, oui, on a le droit de scissionner et on n'est pas obligé de se justifier. Après, bien sûr, qu'on ait le droit de le faire n'implique pas de le faire tous les matins, c'est une décision difficile, mais qui ne dépend pas du développeur originel (sinon, le logiciel n'est pas libre).
[^] # Re: Oui, on a le droit
Posté par lovasoa (site web personnel) . Évalué à 6.
Oui, on a le droit de le faire. Mais la question était plutôt: était-ce une bonne chose de le faire? Était-ce, dans ce cas, bénéfique?
[^] # Re: Oui, on a le droit
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 1.
Savez-vous si votre scission n'a pas contribuée à pousser l'employeur de l'auteur original à choisir le modèle avec licence AGPL + privateur à la place de celui non libre par défaut ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Oui, on a le droit
Posté par lovasoa (site web personnel) . Évalué à 4.
Non, la décision avait été annoncée avant la scission.
[^] # Re: Oui, on a le droit
Posté par PhRæD . Évalué à 5.
Je ne pense pas qu’aborder la question en terme de morale (bien ou mal) soit le bon point de vue.
Pour moi, il faut plutôt le voir sous l’aspect utile / inutile : si dans quelque temps personne n’utilise cette scission, c’est qu’elle n’apporte pas grand-chose.
Dans tous les cas, aucun « mal » n’aura été fait.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Oui, on a le droit
Posté par bayo . Évalué à 3.
Je ne pense pas que ce recentrage soit fait en terme moral, mais essaie de caractériser une réalité concrète.
Bon et mauvais renseigne surtout sur la personne qui les prononce. Oui je suis Spinoziste.
On peut certainement mettre des mots sur ce que l'on entend exactement par "bon pour le projet". J'entends, pour faire simple : n'y avait-il pas une approche plus profitable pour tout le monde.
Ca n'est pas une question vite répondue.
[^] # Re: Oui, on a le droit
Posté par totof2000 . Évalué à 2. Dernière modification le 25 août 2023 à 09:45.
Peut-être parce que la majorité de gens ne savent pas l'utiliser ?
Tu m'apprends qu'on disait scissionner (je n'aurais jamais pensé que le verbe issu de la même raçine avait cette forme), et je ne suis pas sûr que tout le monde le sache ( j'aurais plutôt tourné ma phrase en disant "on a le droit de faire scission").
Peut-être aussi parce qu'un des synonymes de ce mot est "faire dissidence", et que dans le cadre d'un logiciel, ce terme ne reflète pas forcément la même idée que "fork" (dissidence est souvent employé avec une connotation négative, alors que fork me paraît plus neutre).
[^] # Re: Oui, on a le droit
Posté par lejocelyn (site web personnel) . Évalué à 6.
Sinon le terme scinder est pas mal non plus, non ? De mon côté, c'est le premier qui me vient à l'esprit quand on me parle de scinder. scissonner, je pense que je vais réserver à la charcuterie ;)
[^] # Re: Oui, on a le droit
Posté par 태 (site web personnel) . Évalué à 10.
Je pense que plutôt que scission, scinder, scissionner, il faudrait dire saucisson et saucissonner.
On peut alors mettre en garde contre les saucissons secs (forks hostiles) et se plaindre de saucissons d'âne.
[^] # Re: Oui, on a le droit
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Couper du saucisson, ça ne fait plusieurs saucissons.
Peut être dériver?
Moi je dis fourchetter en général /o\
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Oui, on a le droit
Posté par Frédéric Blanc . Évalué à 2.
Dériver est effectivement pertinent (on dérive par exemple les canaux de rivières), sinon on a aussi fourcher, plus proche de l'anglais et moins long à écrire et prononcer que fourchetter :-)
[^] # Re: Oui, on a le droit
Posté par Arkem . Évalué à 4.
Pour bien saucissionner, mieux vaut un bon couteau qu'une fork
[^] # Re: Oui, on a le droit
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
Visiblement, d'aucuns préfèrent le verbe scinder…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Oui, on a le droit
Posté par totof2000 . Évalué à 3.
Si je n'avais été "influencé" par la scission, je pense que c'est auusi le terme qui me serait venu à l'esprit.
[^] # Re: Oui, on a le droit
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2.
Pour moi scinder ne convient pas : dans ma tête, ça veut dire diviser en deux quelque chose. Alors qu'un fork est une nouvelle aventure qui s'appuie sur les bases précédentes. Bifurquer me semble mieux convenir… mais je ne me vois pas utiliser aucun de ces mots, notamment au travail. Voilà une des raisons pour lesquelles les anglicismes persistent.
PS: je suis surpris qu'il n'ait été mentionné nulle part ici que SQLPage a récemment fait l'objet d'un article(je ne sais plus quel était son status) sur DLFP
[^] # Re: Oui, on a le droit
Posté par lovasoa (site web personnel) . Évalué à 2.
Il y a eu une dépêche détaillée : https://linuxfr.org/news/ecrire-une-appli-web-en-une-journee-avec-sqlpage
# Et vous, qu’en pensez-vous ?
Posté par barmic 🦦 . Évalué à 5.
C'est un risque que le développeur de SQLx a pris. Il le savait. Et toi tu a priorisé le fait que ton logiciel se comporte comme avant plutôt que de t'adapter aux changements la bibliothèque.
Que veut-tu qu'on te dise ? C'est tes choix. Si ça te pose un cas de conscience ne le fait pas, si tu veux le faire fais-le.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# encore merci le libre
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 25 août 2023 à 10:11.
Une n-ième démonstration de pourquoi le libre est utile : ne pas dépendre de la volonté d'un développeur!
Il n'y a pas à être désolé, le développeur initial a changé sa position vis à vis du libre, le fork est une réponse justement contre ça, et une arme jamais utilisée quand il y a besoin n'est pas une arme.
Notons le côté foireux de l'excuse pour quitter le libre :
Aucun rapport. Le libre c'est surtout travailler dans le futur, pas de capitaliser sur le passé, Google utilise le passé, si il a un besoin il n'hésitera pas à payer pour faire évoluer.
Personne n'a d'obligation à travailler gratuitement, c'est ce que je répète souvent à des entreprises qui me demandent un fix rapide pour leur workflow : on a un contrat de maintenance? Ben si tu n'en as pas, c'est que tu en avais pas besoin, maintenant si tu veux un fix ponctuel tu payes plein pot l'urgence (en pratique la moitié des entreprises payent, l'autre moitié ne trouve plus bizarrement le fix si urgent).
C'est considérer le libre comme un produit d'appel dont la seule valeur est de vendre du non libre, cf MySQL, ça dit long sur la vision qu'on les gens sur le libre (=vous utiliser comme pub gratuite et garder la partie bankable). Pas grande différence avec la vision du non libre dans la pratique, et absolument rien de nouveau, la seule différence ici étant d'être MIT pour mieux se faire connaître puis passer à vendre du non libre en cours de route, mais ça devient de moins en moins nouveau comme tentative.
Oui, car l'auteur initial a utilisé le libre pour se faire connaître puis essaye de quitte le libre une fois connu, et considérer non correct une liberté du libre reviendrait à trouver non correct le libre en pratique.
L'auteur initial a explicitement (via la licence) autorisé ce fork, on a l'approbation de l'auteur initial même si le lendemain il dit le contraire car son approbation ne l'arrange plus.
Ce qui ne serait pas correct est de considérer l'usage d'une liberté du libre comme non correct, si vous n'aimez pas les libertés du libre le plus simple est de ne pas faire de libre (par contre, faut assumer, vous n'aurez pas la pub "cool" du libre, normal).
ensuite, il y a 2 logiciels, un libre MIT et un libre AGPL/proprio, les 2 ont le même niveau de "correct" au présent (on se fout du passé, de qui a fait quoi avant, l’intérêt est le présent/futur) et que le meilleur business model gagne.
encore merci le libre de ne pas lier les gens à la volonté changeante d'un développeur, si il y a un besoin le logiciel peut être repris par un autre sans avoir une rente sur le passé (à par le nom, c'est un sujet aussi certes, mais moindre que le code si le fork est utile).
[^] # Re: encore merci le libre
Posté par totof2000 . Évalué à 1.
C'est une vision bien belliqueuse du développement logiciel que tu as là. La possibilité de scission (ou fork) n'est pas forcément une arme. C'est une fonctionnalité, c'est tout.
Pour le reste, je suis assez d'accord avec ce que tu exprimes.
[^] # Re: encore merci le libre
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 25 août 2023 à 11:33.
Une arme n'est pas forcément faite pour être utilisée, cf armes nucléaires.
Et en pratique, c'est une arme car elle a pour résultat de casser l'objectif de l'auteur initial : si une version libre continue d'exister et est maintenue, la version non libre a moins d’intérêt pour ceux ayant la thune, et vaut donc mieux réfléchir à 2x avant de changer de business model car à vouloir plus que la thune en libre par le biais d'une version non libre perdre tout au profit du fork.
Si tu veux un autre mot, la possibilité de fork est un moyen de pression pour que l'auteur initial ne fasse pas trop n'importe quoi. A noter que des fois ça ne marche pas du tout cf libav fork échoué de FFmpeg suite à désaccords de dev (mais toujours en libre) et tout le monde est repassé chez FFmpeg mais ça n'a pas été non plus été inutile car FFmpeg a aussi un peu changé suite au fork.
Et surtout : dans la vraie vie ce n'est pas tout le monde de gentil, les anti-militaristes c'est passé de mode (même les verts allemands qui vient de l'anti-militarisme ont compris qu'il faut des armes quitte à être traités de personnes belliqueuses) car ce n'est pas une solution à la paix, juste perdre des droits (et dans le cas cité, il y a eu perte car l'auteur a décidé de supprimer des droits).
PS : il y a des forks amicaux ou complémentaires (pour cible différente) qui ajoutent plutôt que soustraient, je parle du sujet ici qui est un fork pour garder ce qu'il y avait avant suite à décision de changement de l'auteur initial.
[^] # Re: encore merci le libre
Posté par Misc (site web personnel) . Évalué à 5.
Je ne pense pas que "arme" soit l'analogie la plus adapté. Mais clairement, "moyen de pression" colle mieux.
En fait, c'est clairement un jeu de pouvoir (comme la défédération dans le fedivers), et c'est pour ça que les gens annoncent bien fort les forks et les défédérations, car ça n'est pas simplement une mesure technique (à savoir modifier du code), mais bien une façon de communiquer et de se positionner vis à vis de quelque chose. C'est plus visible pour le fedivers (et c'est pour ça qu'il y a tellement de dramastodon), mais ça reste valable pour le logiciel.
Ensuite, quand on regarde tout ça, la menace, c'est quoi ? "tu va avoir moins de PR à reviewer, et moins de bugs à corriger" ?
Il y a tout de même un certain hubris a croire que sa propre valeur est tel qu'un fork va faire changer d'avis quelqu'un d'autre. Parfois, c'est vrai quand il y a du monde, et parfois, c'est pas le cas.
[^] # Re: encore merci le libre
Posté par totof2000 . Évalué à 2.
Il me semble d'ailleurs que certains projets ont forké, puis ont de nouveau fusionné après avoir réglé les différends. Mais le fork n'est pas non plus la seule possibilité : par exemple lorsque, dans ledomaine du son, OSS a voulu changer ses licences, le libre a créé ALSA. Ca veut dire que le fork est peut-être le moyen le plus simple pour faire pression sur un projet pour qu'il reste libre, mais il y a d'autres moyens de pression dans le cas ou un développeur ou éditeur voudrait "fermer" son logiciel.
[^] # Re: encore merci le libre
Posté par Psychofox (Mastodon) . Évalué à 4.
Il aurait tout simplement pu parler de couteau. Le couteau est un outil lorsqu'utilisé pour son usage normal, une arme lorsque non.
Mais à vrai dire pas besoin d'analogie, je ne vois aucun cas ou un fork peut être une arme. La licence te donne le droit de forker quand ça te botte, y compris pour te mettre économiquement en compétition avec l'auteur initial. C'est dans les dispositions donc normalement accepté implicitement par celui qui choisit une license libre. Si ça ne plait pas au developpeur original, ce n'est pas parce que le fork est une arme. C'est parce que le developpeur original n'adhère pas aux licences libres.
[^] # Re: encore merci le libre
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2.
Ou tout simplement pour l'adapter à des besoins précis qui n'ont pas vocation à être couverts par la version généraliste du projet…
Je crois que c'est la première fois que j'arrive à lire une intervention de Zenitram presque en entier, tout en étant, en plus, plutôt d'accord ! L'événement aurait-été encore plus remarquable s'il l'avait publié la veille, le 24 Août étant traditionnellement une date où se produisent des catastrophes (mais aussi, plus rarement, de grandes avancées).
# Petite erreur d'analyse
Posté par Yuul B. Alwright . Évalué à 7.
Je pense qu'il y a une erreur d'analyse sur plusieurs points.
Pour commencer: Les "géants de l'informatique" ne récoltent pas les bénéfices du libre. Si une entreprise récolte de l'argent, c'est par ce qu'elle vent un travail. Que ce soit un service fourni, de la maintenance, du sur-mesure, de la distribution, etc. Bref, elles ne sont pas payées pour le logiciel mais pour la travail fourni.
Et les "géants de l'informatique" existaient déjà avant que le logiciel libre ne soit populaire. Vu leur moyens, si elles n'ont pas un logiciel libre sous la main, "les géants" développent une solution maison et proprio pour leurs services. Et au final "ils" sont toujours là et on a moins de logiciels libres. Au moins, avec du logiciel libre, on peu se passer de ces géants et même plus facilement les concurrencer.
Ensuite, le travail bénévole: Il est possible de gagner de l'argent avec du logiciel libre. Et de pleins de façons: Vente de services, sur-mesure, maintenance, formation, etc. Alors oui, on va rencontrer des difficultés. Mais on les rencontrera également si on fait du logiciel non libre, avec le même résultat.
Quand les gens pensent à limiter les droits des logiciels qu'elles et ils développent, et à vendre des licences d'utilisation, ils et elles pensent tout de suite à Adobe ou Microsoft. Mais elles et ils oublient toutes les personnes, entreprises comme particuliers, qui se sont cassés les dents en vendant du logiciel privateur. Ce n'est pas par ce que tu mets en vente quelque chose que les gens vont acheter. Et tu vas rencontrer les mêmes difficultés qu'avec du logiciel libre: Des concurrents mieux connus, avec un marché captif, avec plus de capitaux, etc; Tu devra faire face aux mêmes discriminations sur tes revenus, ou l'accès aux écoles, au temps libre, aux capitaux ou à un réseau de clients potentiels, etc; Tu aura des clients qui ne voudront quand même pas payer et qui vont soit contourner tes mesures soit renoncer à utiliser tes logiciels.
Et, si tu as un marché pour vendre une licence d'utilisation d'un logiciel non libre, alors tu as aussi un marché pour un financement participatif du développement d'un logiciel libre.
Au final, si tu n'arrive pas à vivre d'un logiciel libre, tu n'arrivera pas à en vivre quel que soit le modèle de développement. Car les problèmes que tu rencontre ne peuvent pas être réglés avec un modèle de développement logiciel: Ils nécessitent de s'attaquer aux problèmes à leurs racines. Racines qui ne sont pas dans l'informatique. On ne peut pas tout régler avec une licence et de bonnes intentions. Le logiciel libre se charge de ce qu'on peut régler avec le logiciel.
# le probleme n'est peut-etre pas SQLx mais SQLserver et leurs bibliotheques
Posté par NeoX . Évalué à 7.
il me semble que meme pour PHP desormais il faut aller chercher le pilote SQLserver chez microsoft et installer ces fichiers pour ensuite pouvoir inclure du SQLserver dans ton code PHP…
du coup, soit tu maintiens tout une pile coherente, avec tous les pilotes mais tu dois tester chaque nouvelle version de microsoft sql server for Rust ?
soit tu arretes de faire du SQLserver dans ton produit car tu ne veux plus dependre du pilote propriétaire sur lequel tu n'as pas la main, etc
[^] # Re: le probleme n'est peut-etre pas SQLx mais SQLserver et leurs bibliotheques
Posté par lovasoa (site web personnel) . Évalué à 3. Dernière modification le 26 août 2023 à 21:32.
Le protocole de communication avec SQL server est un peu complexe, mais il est bien documenté, et il est stable. De mon expérience pour le moment, il ne pose pas particulièrement plus de problèmes qu'un autre.
Et c'est un gros plus pour les utilisateurs de SQLPage de pouvoir juste télécharger le logiciel, et qu'il se connecte tout de suite à leur base de données, quelle qu'elle soit. Et l'utilisateur le plus actif sur le forum communautaire de SQLPage, f8dca, est d'ailleurs un utilisateur de SQL Server.
[^] # Re: le probleme n'est peut-etre pas SQLx mais SQLserver et leurs bibliotheques
Posté par NeoX . Évalué à 3.
ce que je pensais avoir dit c'est que c'est peut-etre microsoft qui ne veut pas que les logiciels comme SQLx (et SQLpage) embarque les pilotes, car ceux ci ne seront peut-etre alors pas mis à jour aussi rapidement que ceux publié par MS directement.
là preuve deja pour ton projet, tu parles d'implementer la version d'avant, en utilisant les anciennes API, etc
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.