Il n'y a aucun intérêt à développer de nouveaux projets en C/C++
On en reparlera quand Rust aura une ABI stable.
Des remplaçants du C et C++, il y en a eu des milliers ces 50 dernières années. Aucun ne les a enterrés, et aucun ne les enterreront de si tôt.
De plus, ce n'est pas un des objectifs de Rust que de remplacer C et C++. Donc ce genre de phrase digne d'un fanatique endoctriné ne sert absolument à rien.
Le C et le C++ ont encore de nombreux cas d'usages. Rien que dans le développement de jeu vidéo par exemple, C++ reste la valeur sûre. Rust commence à y tremper les pieds, mais on est encore loin d'y avoir l'aura qu'a le C++, surtout quand il s'agit de cibler des consoles ou des plateformes que LLVM ne supporte pas.
même dans le libre, il y a un concept comme la relation client (vu qu'à partir du moment ou tu fournis quelque chose,ça existe).
Non. La plupart des licences open source inclus la mention suivante, sous une forme ou une autre :
This software is provided "AS IS," without a warranty of any kind.
L'auteur ne doit rien à ses utilisateurs, qui ne sont pas des clients. Il n'y a pas de contrat, il n'y a personne qui paye, il n'y a aucune garantie donnée ou due.
Tu insinues que modifier l'appareil (code, config ou hardware) pour une seule personne ne nécessite pas de (re)certification ?
Je sais pas d'ou tu sors ça, mais c'est complètement faux. En cas de pépin, bonjour pour aller prouver devant un tribunal que ton changement non certifié n'est pas responsable. En tout cas, le fabricant va pouvoir se dédouaner en 5s montre en main.
Tu dis que ça protège les utilisateurs, et ensuite dans l'exemple que tu donnes, tu parles de l'auteur et pas des utilisateurs.
De plus, dans l'exemple que tu donnes, la GPL n'aurait rien changé. Une grosse boîte peut reprendre ton logiciel, le vendre, et mettre beaucoup plus de moyens que toi, te "volant" (mauvais terme car c'est une liberté que tu donnes, mais c'est ce que tu insinues) ton public cible.
La seule différence ? Si un des utilisateurs de ce fork demande l'accès au code source, l'entreprise est obligé de lui donner. Ce qui n'est pas forcément problématique, après tout, ce n'est pas la technologie que se vend, mais le service autour.
Pour peu que l'entreprise ensuite, ayant "raflé" le marché, mette les moyens pour réécrire le code (dans un autre langage, ou le même langage) de 0, afin de s'affranchir de la GPL et sortir une version proprio, comment est-ce que les utilisateurs sont protégés ?
Je reste non convaincu que la GPL protège les utilisateurs, non elle protège l'auteur et son code source, c'est tout. Et encore, elle le fait très faiblement.
Beaucoup des logiciels que tu cites ne sont pas des logiciels "vendus" et donc ne génèrent aucun revenu, et n'ont aucune entreprise derrière avec un business model.
Le sujet du commentaire original était "il existe peu de logiciel GPL qui sont le produit phare d'une entreprise qui a fait son business model autour de ce dernier", et non "il existe peu de logiciel GPL avec une grande communauté".
Mastodon fonctionne uniquement avec les dons et a récolté en 2022, d'après Wikipedia, 31 300€ de 9 400 donateurs. Pas de quoi payer un seul dev.
On appelle ça rentable ?
Les autres que tu as cité ont pour la plupart une entreprise derrière avec des revenus dans les millions annuels. C'est déjà un peu plus proche du projet avec un business plan ça.
il faut le faire accepter à tous les contributeurs avant, les recontacter et leur faire accepter, sinon enlever / réécrire leurs contributions en cas de refus…
Oui, et cela sera le cas peu importe la licence, GPL, ou MIT, ou proprio.
Quand je dis que la gouvernance n'a rien à voir, je parle de la définition d'opensource. Lua est un projet opensource, la gouvernance n'est pas ouverte.
Mon intuition de béotien est que la MIT et les BSD sont concises car elles donnes des permissions sur un produit soumis aux droits d'auteurs (elles partent de "aucun droit" et en ajoutent), la ou la GPL par du domaine publique et ajoute des restrictions (pas de redistribution proprio, contamination, …).
C'est la que les projets mettent en place un "Contributor License Agreement" qui désigne une entité comme étant propriétaire du code, cela peut être une personne physique, ou une personne morale (association, entreprise, fondation, …).
Si ils ne le font pas, il faut effectivement l'accord de tout un chacun pour changer la licence.
EDIT: En fait, c'est plus une question de gouvernance du projet ça. Cela ne change pas le fait que la licence peut changer, même si c'était du GPL.
Donc, les AWS/GCP/Azure pourront toujours continuer à proposer des services licencié GPL, ce qui ne plaira toujours pas à éditeurs de ces logiciels car cela concurrencera leurs propres offres SaaS, ce qui ne les empêchera pas de changer de licence pour les versions futures.
La GPL aide en faisant en sorte qu'un éditeur comme Redis ne peut plus du jour au lendemain prendre tout le monde de vitesse avec une licence propriétaire.
Et comment elle empêche l'auteur du code de sortir les futures versions sous une licence non libre ?
C'est un logiciel tout droit sorti des laboratoires de Google, issue des 20 ans de travaux sur Borg. Google a transféré la gouvernance de Kubernetes à la CNCF (Cloud Native Computing Foundation) dont Google est l'un des membres fondateurs.
Quand on a les moyens financier des GAFAM, c'est tout de suite plus facile de faire de l'OpenSource. C'est pas pour rien que les plus gros contributeurs OpenSource sont des entreprises d'ailleurs.
N'oublions pas que:
React et GraphQL, ça vient de chez Facebook
Amazon paye des ingénieurs pour contribuer sur des projets OpenSource clés pour eux (comme MariaDB, PostgreSQL justement, …)
Google est l'auteur de Kubernetes, Go, Carbon, BigTable qui a donné naissance à CassandraDB, …
Et on ne va pas oublier Intel et RedHat qui sont parmi les plus gros contributeurs au noyau Linux.
Est-ce que fournir une plateforme qui te permet de te créer un serveur dans le "cloud" (aka: chez quelqu'un d'autre) avec un Redis installé dedans est contaminé par la GPL ?
Car c'est bien là le soi-disant problème : les clouds providers. Ils construisent leurs offres en se basant sur des briques libres (leur droit).
Ces mêmes auteurs ont une offre SaaS pour leurs briques libres :
Du coup, les Google/Amazon/Microsoft/… font directement concurrence à ces offres SaaS. Et ça ne plait pas aux auteurs qui essayent de faire tourner un business (la concurrence, ça fait jamais plaisir).
Sauf que le service fournit par ces "cloud providers" n'est pas le même. Quand je vais chez GCP/AWS/Azure, c'est pas pour avoir "un Redis SaaS". C'est pour avoir une infrastructure complète : VMs, Container Registry, CI/CD pipelines, monitoring, secret management, IAM, …
Dans cette infrastructure, j'y déploie ensuite mes dépendances : base de données, caches, reverse proxies, …
Les cloud providers me fournissent ces dépendances complètement intégrées à leur infrastructure, sans que j'ai besoin d'aller faire le apt install moi même.
Ok, disons qu'ils n'ont plus le droit de le faire, et que je ne veuille pas "self-host" (aka: faire le apt install moi même). Je vais donc chez les SaaS de ces auteurs "libristes", et maintenant je dois payer de la bande passante entrante et sortante de mon infrastructure, ce qui est bien connu comme étant potentiellement l'une des plus grosses dépenses dans le cloud.
Quelle solution ces auteurs proposent ils pour cela ? D'ailleurs. Ou hébergent ils leurs instances clouds si ce n'est chez Google/Amazon/Microsoft/… ?
On est en 2024, les infrastructures hébergées et gérées dans le Cloud, c'est monnaie courante. Le vendor-lock, on s'y résous à contre coeur car c'est plus simple comme ça (il faut avouer que Kubernetes a un peu aider a faciliter la portabilité d'un cloud provider à l'autre, si on reste dans les cas simples).
Avoir un seul contrat avec un seul provider au lieu de 10 contrats (1 par provider pour chacune de nos dépendances), c'est plus facile.
Le dire au préalable sauvera le potentiel contributeur de la frustration d'investir du temps, de l'énergie dans un patch qui ne sera pas accepté, voir ignoré. Cela évitera aussi une mauvaise réputation du style "les développeurs s'en foutent des utilisateurs, ils ignorent même les tickets et pull requests".
Dire à l'avance "on n'accepte pas les contributions" c'est communiquer clairement que la gouvernence du projet se fait en interne avec des personnes séléctionnées au compte goutte.
C'est de la communication, rien de plus. Communiquer ses choix de gouvernence, que tu sois d'accord avec ou non, c'est sain.
[^] # Re: Oui
Posté par David Delassus (site web personnel) . En réponse au lien Faut-il s'intéresser à Rust ? . Évalué à 5.
On en reparlera quand Rust aura une ABI stable.
Des remplaçants du C et C++, il y en a eu des milliers ces 50 dernières années. Aucun ne les a enterrés, et aucun ne les enterreront de si tôt.
De plus, ce n'est pas un des objectifs de Rust que de remplacer C et C++. Donc ce genre de phrase digne d'un fanatique endoctriné ne sert absolument à rien.
Le C et le C++ ont encore de nombreux cas d'usages. Rien que dans le développement de jeu vidéo par exemple, C++ reste la valeur sûre. Rust commence à y tremper les pieds, mais on est encore loin d'y avoir l'aura qu'a le C++, surtout quand il s'agit de cibler des consoles ou des plateformes que LLVM ne supporte pas.
Et c'est qu'un seul exemple parmi tant d'autres.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: C'est quand même très provoc
Posté par David Delassus (site web personnel) . En réponse au lien Bullying in Open Source Software Is a Massive Security Vulnerability. Évalué à 6.
Non. La plupart des licences open source inclus la mention suivante, sous une forme ou une autre :
L'auteur ne doit rien à ses utilisateurs, qui ne sont pas des clients. Il n'y a pas de contrat, il n'y a personne qui paye, il n'y a aucune garantie donnée ou due.
Le reste de ton message, je suis d'accord.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Validation des équipements médicaux
Posté par David Delassus (site web personnel) . En réponse au journal Le fabricant refuse de libérer l'appareil : bientôt un mort ?. Évalué à 3.
Tu insinues que modifier l'appareil (code, config ou hardware) pour une seule personne ne nécessite pas de (re)certification ?
Je sais pas d'ou tu sors ça, mais c'est complètement faux. En cas de pépin, bonjour pour aller prouver devant un tribunal que ton changement non certifié n'est pas responsable. En tout cas, le fabricant va pouvoir se dédouaner en 5s montre en main.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Équipe premier degré
Posté par David Delassus (site web personnel) . En réponse au journal Le roi est mort, vive le roi ! Les alternatives de Redis sont là. Évalué à 3.
"Avoir Redis" et "Avoir besoin de Redis", petite nuance :)
-- dit-il sans avoir lu le lien.
Plus sérieusement, j'introduis rarement du Redis dans mon infra, quand c'est le cas c'est pour soit :
Et dans le cas du cache, j'ai tellement peu d'utilisateurs que ce n'est pas critique du tout (à quoi bon cacher une requête par mois).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Paquets Slackware dans les tuyaux.
Posté par David Delassus (site web personnel) . En réponse au journal Le roi est mort, vive le roi ! Les alternatives de Redis sont là. Évalué à 3.
Merci pour le taf !
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: GPL/BSD, le débat sans fin
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 2. Dernière modification le 31 mars 2024 à 14:55.
Tu dis que ça protège les utilisateurs, et ensuite dans l'exemple que tu donnes, tu parles de l'auteur et pas des utilisateurs.
De plus, dans l'exemple que tu donnes, la GPL n'aurait rien changé. Une grosse boîte peut reprendre ton logiciel, le vendre, et mettre beaucoup plus de moyens que toi, te "volant" (mauvais terme car c'est une liberté que tu donnes, mais c'est ce que tu insinues) ton public cible.
La seule différence ? Si un des utilisateurs de ce fork demande l'accès au code source, l'entreprise est obligé de lui donner. Ce qui n'est pas forcément problématique, après tout, ce n'est pas la technologie que se vend, mais le service autour.
Pour peu que l'entreprise ensuite, ayant "raflé" le marché, mette les moyens pour réécrire le code (dans un autre langage, ou le même langage) de 0, afin de s'affranchir de la GPL et sortir une version proprio, comment est-ce que les utilisateurs sont protégés ?
Je reste non convaincu que la GPL protège les utilisateurs, non elle protège l'auteur et son code source, c'est tout. Et encore, elle le fait très faiblement.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: pros / cons
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 4.
La GPL ne requiert pas de publier le code source (aka: le mettre sur Github). Elle requiert seulement de le donner si l'utilisateur le demande.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 4.
Beaucoup des logiciels que tu cites ne sont pas des logiciels "vendus" et donc ne génèrent aucun revenu, et n'ont aucune entreprise derrière avec un business model.
Le sujet du commentaire original était "il existe peu de logiciel GPL qui sont le produit phare d'une entreprise qui a fait son business model autour de ce dernier", et non "il existe peu de logiciel GPL avec une grande communauté".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: L'avocat du diable? Parlons business plan.
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 4.
Mastodon fonctionne uniquement avec les dons et a récolté en 2022, d'après Wikipedia, 31 300€ de 9 400 donateurs. Pas de quoi payer un seul dev.
On appelle ça rentable ?
Les autres que tu as cité ont pour la plupart une entreprise derrière avec des revenus dans les millions annuels. C'est déjà un peu plus proche du projet avec un business plan ça.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'avais compris l'inverse
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 3.
Seulement si la personne le demande.
Tu peux garder le code chez toi et jamais le mettre sur Github/Gitlab/whatever
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Mieux vaut une petite MIT qu'une grosse GPL
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 2.
Ok, merci pour les clarifications :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'ai pas compris
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 4.
Oui, et cela sera le cas peu importe la licence, GPL, ou MIT, ou proprio.
Quand je dis que la gouvernance n'a rien à voir, je parle de la définition d'opensource. Lua est un projet opensource, la gouvernance n'est pas ouverte.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Mieux vaut une petite MIT qu'une grosse GPL
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 3.
Mon intuition de béotien est que la MIT et les BSD sont concises car elles donnes des permissions sur un produit soumis aux droits d'auteurs (elles partent de "aucun droit" et en ajoutent), la ou la GPL par du domaine publique et ajoute des restrictions (pas de redistribution proprio, contamination, …).
En gros :
Les restrictions sont plus compliquées à préciser dans un texte légal, pour éviter les "loopholes" (trous de boucle en français ?)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'ai pas compris
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 2. Dernière modification le 28 mars 2024 à 14:36.
Ce que tout les projets requiert quand ils deviennent suffisamment gros.
Le code est disponible et livré sous une licence libre. Il est par définition open-source.
La gouvernance du projet n'a rien à voir là dedans.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: L'auteur ou les auteurs ?
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 1. Dernière modification le 28 mars 2024 à 14:32.
C'est la que les projets mettent en place un "Contributor License Agreement" qui désigne une entité comme étant propriétaire du code, cela peut être une personne physique, ou une personne morale (association, entreprise, fondation, …).
Si ils ne le font pas, il faut effectivement l'accord de tout un chacun pour changer la licence.
EDIT: En fait, c'est plus une question de gouvernance du projet ça. Cela ne change pas le fait que la licence peut changer, même si c'était du GPL.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'ai pas compris
Posté par David Delassus (site web personnel) . En réponse au journal GPL vs MIT, que choisir ?. Évalué à 6.
Non car l'auteur a tout les droits sur le code.
La GPL garantie que les autres contributeurs ne peuvent pas privatiser le code dont tu es l'auteur.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Pendant ce temps-là chez Microsoft
Posté par David Delassus (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 4.
Un produit sous GPL, ça peut virer au proprio tout autant qu'un produit sous MIT.
La licence ne s'applique qu'au code existant, pas au code futur.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Correction
Posté par David Delassus (site web personnel) . En réponse au lien Linux 6.9 déprécie EXT2. Évalué à 3.
Linux 6.9
Un jour, j'apprendrais à écrire.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Ah si ils l'aiment l'open source...
Posté par David Delassus (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 4.
Donc, les AWS/GCP/Azure pourront toujours continuer à proposer des services licencié GPL, ce qui ne plaira toujours pas à éditeurs de ces logiciels car cela concurrencera leurs propres offres SaaS, ce qui ne les empêchera pas de changer de licence pour les versions futures.
Et comment elle empêche l'auteur du code de sortir les futures versions sous une licence non libre ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Rectification à propos des licences
Posté par David Delassus (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 3.
La joie de la langue française ou "sans doute" peut s'interpréter comme voulant dire "probablement" :D
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Rectification à propos des licences
Posté par David Delassus (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 2.
Les 2 licences cités sont :
Personne n'a dit que la GPL n'était pas libre à ce que je sache.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Ah si ils l'aiment l'open source...
Posté par David Delassus (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 2.
Kubernetes, c'est le mauvais exemple.
C'est un logiciel tout droit sorti des laboratoires de Google, issue des 20 ans de travaux sur Borg. Google a transféré la gouvernance de Kubernetes à la CNCF (Cloud Native Computing Foundation) dont Google est l'un des membres fondateurs.
Quand on a les moyens financier des GAFAM, c'est tout de suite plus facile de faire de l'OpenSource. C'est pas pour rien que les plus gros contributeurs OpenSource sont des entreprises d'ailleurs.
N'oublions pas que:
Et on ne va pas oublier Intel et RedHat qui sont parmi les plus gros contributeurs au noyau Linux.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Ah si ils l'aiment l'open source...
Posté par David Delassus (site web personnel) . En réponse au journal Redis Open Source bronsonisé. Évalué à 5.
Imaginons que Redis fusse sous GPL.
Est-ce que fournir une plateforme qui te permet de te créer un serveur dans le "cloud" (aka: chez quelqu'un d'autre) avec un Redis installé dedans est contaminé par la GPL ?
Car c'est bien là le soi-disant problème : les clouds providers. Ils construisent leurs offres en se basant sur des briques libres (leur droit).
Ces mêmes auteurs ont une offre SaaS pour leurs briques libres :
Du coup, les Google/Amazon/Microsoft/… font directement concurrence à ces offres SaaS. Et ça ne plait pas aux auteurs qui essayent de faire tourner un business (la concurrence, ça fait jamais plaisir).
Sauf que le service fournit par ces "cloud providers" n'est pas le même. Quand je vais chez GCP/AWS/Azure, c'est pas pour avoir "un Redis SaaS". C'est pour avoir une infrastructure complète : VMs, Container Registry, CI/CD pipelines, monitoring, secret management, IAM, …
Dans cette infrastructure, j'y déploie ensuite mes dépendances : base de données, caches, reverse proxies, …
Les cloud providers me fournissent ces dépendances complètement intégrées à leur infrastructure, sans que j'ai besoin d'aller faire le
apt installmoi même.Ok, disons qu'ils n'ont plus le droit de le faire, et que je ne veuille pas "self-host" (aka: faire le
apt installmoi même). Je vais donc chez les SaaS de ces auteurs "libristes", et maintenant je dois payer de la bande passante entrante et sortante de mon infrastructure, ce qui est bien connu comme étant potentiellement l'une des plus grosses dépenses dans le cloud.Quelle solution ces auteurs proposent ils pour cela ? D'ailleurs. Ou hébergent ils leurs instances clouds si ce n'est chez Google/Amazon/Microsoft/… ?
On est en 2024, les infrastructures hébergées et gérées dans le Cloud, c'est monnaie courante. Le vendor-lock, on s'y résous à contre coeur car c'est plus simple comme ça (il faut avouer que Kubernetes a un peu aider a faciliter la portabilité d'un cloud provider à l'autre, si on reste dans les cas simples).
Avoir un seul contrat avec un seul provider au lieu de 10 contrats (1 par provider pour chacune de nos dépendances), c'est plus facile.
Du coup, comment la GPL aide ici ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Wut?
Posté par David Delassus (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 10.
Le dire au préalable sauvera le potentiel contributeur de la frustration d'investir du temps, de l'énergie dans un patch qui ne sera pas accepté, voir ignoré. Cela évitera aussi une mauvaise réputation du style "les développeurs s'en foutent des utilisateurs, ils ignorent même les tickets et pull requests".
Dire à l'avance "on n'accepte pas les contributions" c'est communiquer clairement que la gouvernence du projet se fait en interne avec des personnes séléctionnées au compte goutte.
C'est de la communication, rien de plus. Communiquer ses choix de gouvernence, que tu sois d'accord avec ou non, c'est sain.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: (lisp (c'est bien))
Posté par David Delassus (site web personnel) . En réponse au journal PySimpleGUI ferme (les sources). Évalué à 5.
T'inquiètes, c'était juste un petit troll gratuit comme on les aime en ce Trolldi 22 mars :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg