La librairie python PySimpleGui qui est une surcouche a TkInter proposait (et propose toujours) une approche plus simple pour la création d'interface graphique en Python.
Elle était sous license LGPL et bénéficiait d'un certain succès. On en a même parlé ici (https://linuxfr.org/news/pysimplegui-prenez-plaisir-a-faire-des-interfaces-graphiques-en-python).
Le mois dernier, son auteur a décidé de passer PySimpleGUI sous une licence propriétaire. Encore mieux, il a supprimer tout l'historique et le dépot github contient maintenant que des commits qui datent d'il y a un mois.
Heureusement un fork existe: https://github.com/andor-pierdelacabeza/PySimpleGUI-4-foss
En vrai, on aurait du s'en douter en voyant que le fichier CONTRIBUTING.md du le projet explicitait qu'il refusait les contributions externes et que PySimpleGUI is different than most projects on GitHub. It is licensed using the "Open Source License" LGPL3. However, the coding and development of the project is not "open source".
Pour ma part, j'ai utilisé PySimpleGui sur un projet pour un de mes clients. J'ai pas mal aimé au début mais j'ai trouvé que la définition d'interfaces à base de listes imbriquées ne passaient pas trop à l'échelle. J'avais rapidement l'impression de faire du lisp.
Et le style "direct" (en opposition à la programmation événementielle) était là aussi plus simple au début mais devenait un vrai problème avec une interface complexe. Du coup je pensais pas y revenir, avec le changement de licence, c'est confirmé.
Discussion sur hacker news: https://news.ycombinator.com/item?id=39369353
(Qui semble être l'annonce la plus officielle trouvable)
# Wut?
Posté par Marotte ⛧ . Évalué à 7. Dernière modification le 22 mars 2024 à 18:22.
Ça ne veut rien dire, non ?
La LGPL dit qu’on peut utiliser cette bibliothèque dans un projet propriétaire mais qu’une modification de la bibliothèque elle-même doit être elle aussi opensource.
Mais l’opensource n’implique nullement d’accepter n’importe quelle contribution, ni de rendre transparent le développement.
J’ai l’impression de comprendre ce qu’il voulait dire mais la formulation est totalement incorrecte. L’utilisation du terme opensource en tous cas. Pour ça qu’il a mis des guillemets je suppose mais je trouve quand même toujours ça mal formulé.
[^] # Re: Wut?
Posté par David Delassus (site web personnel) . Évalué à 6.
Cela me fait penser à la gouvernance du projet Lua :
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Wut?
Posté par Marotte ⛧ . Évalué à 6.
Et c’est justement une des libertés qu’autant les licences GPL-like que BSD-like permettent. Moi je trouve ça dommage, puisque c’est se priver de nombreuses contributions externes potentielles, mais on ne peut pas dire que « ce n’est pas opensource ».
[^] # Re: Wut?
Posté par David Delassus (site web personnel) . Évalué à 10.
Grosse différence.
Peut être qu'ils ne font pas de l'open source pour avoir des contributions externes. Peut être qu'ils n'ont pas les resources, le temps, l'énergie, l'envie, de traiter avec des inconnus qui ne partagent pas forcément la même vision de l'avenir du projet.
Je comprends parfaitement l'envie de se fermer aux contributions externes.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Wut?
Posté par raphj . Évalué à 5. Dernière modification le 23 mars 2024 à 14:19.
Beaucoup de gens semblent mélanger modèle de développement et droits sur le code.
Ça m'étonnera toujours.
On peut faire du non libre coopératif (bizarre, mais bon, possible, c'est ce qui se faisait sur le compilateur D dmd avant qu'il ne soit en effet libéré. Ou sur le compilateur sybase du bios de virtualbox. Ou probablement sur tous ces modèles LLM open pas vraiment open. Ou probablement plein de mods de jeux vidéos à licences pas forcément ouvertes voire très claires), et du libre non collaboratif (Des exemples ont été donnés ici, SQLite en est un autre : c'est dans le domaine public dans les juridictions qui permettent de déposer volontairement des choses dans le domaine public, mais ces auteurs ne prennent pas les contributions externes).
Ce genre de confusion de la part d'auteurs de logiciels, ça donne sérieusement l'impression d'un manque de culture dans le monde du développement, et ça fait penser que les décisions ne sont potentiellement pas super bien éclairée.
Je viens de participer à la première édition d'AlpOSS (c'était top !) et un intervenant disait "faut voir aussi l'utilité de mettre une application en open source". Il pensait en terme de développement, mais les droits garantis aux utilisateurs et utilisatrices finales de l'application, c'est déjà une utilité largement suffisante… et même la raison principale qui me motive moi à faire du libre. Je n'ai pas osé intervenir mais c'était un point important, j'aurais peut-être dû.
Les questions de l'open source et des modèles de développement ne sont pas encore assez enseignées dans les écoles d'informatique, et il n'y a pas assez d'information là dessus auprès des dev en poste. Mais bon, ça progresse.
[^] # Re: Wut?
Posté par barmic 🦦 . Évalué à 2.
L'exemple du journal montre que ça n'est pas sans rapport. Le fait d'accepter ou non le partage de la propriété intellectuelle du code (donc accepter les contributions sans CLA) a un impact sur l'évolution de sa licence au moins au même niveau que le fait d'utiliser ou non une licence à copyleft.
Le fait de parler de développement open source plutôt que communautaire ou ouvert aux contribution n'est qu'un détail de vocabulaire bien moins important que le fais de ne pas comprendre les implications que ça induit en terme de licence.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Wut?
Posté par raphj . Évalué à 4. Dernière modification le 27 mars 2024 à 17:51.
Ce n'est pas sans rapport effectivement, les sujets sont très liées, y compris de la manière que tu décris, mais ça reste des concepts très différents. Et bien sûr que les faits sont plus importants que comment on les décrits, et lors d'argumentations on devrait se concentrer sur le fond.
Mais perso, je ne parlais pas de vocabulaire, mais de réelles confusions sur ces choses, dans le fond. J'ai rencontré des gens qui ne font pas bien la distinction code open source et modèle de développement contributif ("ouvert"). Il n'y a qu'à voir comment les gens réagissent quand un projet libre n'accepte pas de contributions : "C'est pas vraiment open source". Bah… si. Peut importe comment on appelle les choses, mais il faut que les concepts soient claires…
… Mais justement, les confusions dans comment on appelle les choses entraînent des confusions sur le fond. Le discours est de fait notre manière de se comprendre et de mener des argumentations claires aussi. Donc c'est quand même important de parler précisément.
Quand quelqu'un nous dit "bof, c'est nul, c'est pas vraiment open source", on peut chercher à comprendre ce qui est important pour cette personne :
Et en vrai, un vocabulaire carré et bien utilisé, ça aide quand même vachement à débroussailler. Ça permet aussi de mettre les concepts / le fond au clair et de penser clairement.
Très souvent, on a quand même confusion de vocabulaire = confusion de fond. C'est comme un code smell, parfois c'est en fait ok, souvent, c'est quand même un réel problème dessous. Autant éviter le code smell du coup, quand on peut.
Utiliser le bon vocabulaire quand on maitrise bien les choses, ça évite aussi de semer la confusion auprès des gens pour qui les choses sont moins claires. On le leur doit.
Du coup, c'est même pire. Il ne faut pas confondre :
Ces trois choses sont très liés mais on a intérêt à pouvoir raisonner clairement en appelant un chat un chat.
C'est ok de se tromper, je le fais moi-même, et je ne vais pas nécessairement reprendre les gens à chaque coin de rue surtout si les idées sont transmises correctement malgré un mauvais terme parce que sinon au secours, mais malgré tout, je pense sincèrement qu'utiliser le bon vocabulaire c'est mieux, tant qu'à faire. Et parfois, une simple correction de vocabulaire a mené à des discussions de fond intéressantes. Évidemment, il faut ne pas être complètement désagréable pour que ça soit possible.
[^] # Re: Wut?
Posté par raphj . Évalué à 3. Dernière modification le 27 mars 2024 à 18:08.
Tout ceci étant dit, la citation du journal n'est pas bonne, le readme dit :
Cette dernière formulation n'est pas problématique et elle est très claire. Il y a eu une modification malheureuse.
[^] # Re: Wut?
Posté par barmic 🦦 . Évalué à 3.
C'est marrant après cette virgule tu ne parle que de vocabulaire et en quoi c'est normale de reprendre sur le vocabulaire.
Tu ressent le même problème quand on parle de service libre par exemple ? D'hébergeur libre ? Quand on parle d'imprimante open source ?…
Reprendre quelqu'un qui a de toute évidence parfaitement compris ce de quoi il parlait puisqu'il utilise à son avantage les possibilités que ça lui donne avec une forme assez pédante de « ouai l'autre il sait même pas utiliser les bons mots lol » me semble à l'opposé de ça. Dans son fichier CONTRIBUTING, il parlait de sa licence d'un côté et de son mode de développement de l'autre rendant parfaitement clair ce qu'il voulait dire et l'utilisation des guillemets montre qu'il sait qu'il fait un abus de langage. Le moquer ou le prendre de haut est une chose, mais il est évident qu'il sait parfaitement où il va.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Wut?
Posté par raphj . Évalué à 4.
Ça tombe bien, je caractérisais mon commentaire précédent avec cette expression. Mais ce n'est même pas vrai, après cette virgule, j'explique qu'il y a des problèmes de compréhension de fond, qui ne se limitent pas à un simple problème de vocabulaire.
Et ensuite, je défends effectivement l'utilisation précise du vocabulaire pour limiter ces problèmes. Je répondais à ton avis que ce n'était pas si important, il se trouve que je ne suis pas d'accord.
Tu parles du commentaire de Marotte qui demande "Ça ne veut rien dire, non ?"
Je ne pense pas que ça soit pédant, … et puis bah oui, c'est un peu le genre de chose qu'il se passe quand on n'utilise pas les bons mots. Les gens ne se comprennent pas bien. C'est la vie. Maintenant à toi de choisir : tu utilises sciemment des expressions qui ne correspondent pas parfaitement en espérant être compris, ou alors tu es précis et tu peux serrer moins les fesses. Je sais ce que je choisis de mon côté, et je respecte les gens qui choisissent différemment. Par ailleurs, je ne parle pas pour Marotte, je parle pour moi.
Et par ailleurs, le fichier CONTRIBUTING en question a été mal cité dans le journal et était tout à fait exact au final.
Mais j'ai l'impression que tu prêtes des intentions aux gens en présence beaucoup trop malicieuses pour ce qu'elles ne le sont en réalité.
Quel est ton but, me prendre en défaut ? Peu importe ma réponse, ça ne change pas mon point de vue sur le fait qu'il vaut mieux être précis. "modèle de développement open source" n'est pas bien défini parce qu'il existe pleins de modèles de développement différents pour des logiciels open source.
De mon côté, je n'utilise pas ces expressions que tu cites (ça a pu m'arriver, c'est facile de reprendre des expressions présentes dans une discussion sans faire trop attention, et ça ne serait pas scandaleux, évidemment. Service libre et hébergeur libre, ce sont des métonymie, comme "mange ton assiette", c'est commun dans les langues vivantes).
[^] # Re: Wut?
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 23 mars 2024 à 23:11.
C’est vraiment mon avis de béotien en développement logiciel que je donne là mais je trouve dommage de fermer le développement par principe. Je veux dire, c’est pas parce que tu acceptes les contributions que tu t’engages à toutes les considérer, à t’investir pour chacune.
Alors c’est sûr qu’à un moment les contributeurs vont se dire : « Mais qu’il aille bien se faire foutre ce projet si on se casse le cul, qu’on propose des patches, et qu’on a même pas une réponse ! » Conséquence : fork (si la nécessité d’utiliser le logiciel en question est forte), ou arrêt de toute contribution (si de toute manière c’est pas très important, on va voir ailleurs).
Donc au final, certes, ça revient très probablement au même. Mais je ne vois pas l’intérêt d’annoncer à l’avance que : le développement ngest pas ouvert aux contributions externes. Je veux dire, s’il ne l’est pas les gens s’en rendrons compte assez vite, et pour le projet en question, bah ça lui laisse une petite possibilité de profiter de LA contribution qui le fait bien…
La seule raison que je vois de, typiquement, garder privé les rapports de bug, c’est chercher à les dérober à la vue des utilisateurs potentiels. En gros, partir du principe que pour l’utilisateur qui n’est pas tombé dessus lui-même le bug n’existe pas…
[^] # Re: Wut?
Posté par David Delassus (site web personnel) . É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: Wut?
Posté par Marotte ⛧ . Évalué à 5.
Ça se défend comme point de vue.
Dire qu’ils n’acceptent pas les contributions c’est justement dire exactement ça (je dirais plutôt « se foutre de leurs contributions » plus précisément). Tu as raison sur le fait que c’est une preuve de transparence certaine.
Tu m’as un peu fait changer d’avis, je dirais qu’il y a en fait du pour et du contre avec les deux approches.
[^] # Re: Wut?
Posté par freem . Évalué à 2.
Perso, je pense qu'il vaut mieux que les projets soient clairs sur leur politique de ce point de vue, justement pour éviter:
Si le projet est clair sur la politique et les objectifs, moins de frustration pour ceux qui s'en servent et ont besoin de le modifier.
Pour moi, les contributions de patch et de rapport de bug sont très, très différentes. Un rapport de bug, bien que déjà utile (enfin, ça dépend, on voit nombre de rapports de "bug" sur github ou le rapporteur a juste la flemme de lire la doc… et ne parlons pas des feature requests complètement à l'ouest…), ce n'est qu'une description d'un comportement erroné. C'est relativement rapide a faire, comparé à un patch.
[^] # Re: Wut?
Posté par lym . Évalué à 2. Dernière modification le 16 avril 2024 à 14:29.
De manière plus terre à terre, se mettre sous une licence GPL en refusant les contributions peut aussi servir d'appeau tout en maitrisant finement les contributeurs et leur nombre, permettant un changement de licence ultérieur bien plus facile car il faudra alors l'accord… de tous les contributeurs!
Et tant que l'appeau dure, l'intérêt majeur est de se fait tester le soft par les utilisateurs qui remontent les bugs et autres suggestions d'amélioration… Et tant que ces derniers sont pris en compte, peu de raison de subir des forks risquant d'affecter ses plans pour la suite.
Il peut certes y avoir d'autres motivations, mais la meilleure garantie qu'un projet libre le restera (et durera, aussi) c'est justement le nombre de ses contributeurs: Allez tenter de re-licencier le kernel Linux, même si Linus qui en est à l'origine devenait assez gâteux avec l'âge pour signer cela, vu la tétrachiée de contributeurs alors à retrouver pour accord!
[^] # Re: Wut?
Posté par pas_pey . Évalué à 1.
L'auteur affirmait plus ou moins dès le départ qu'il ne faisait de l'open source que parce que ça lui faisait de la pub au démarrage mais qu'il ne pensait pas forcément rester sous licence libre au moment de tirer les marrons du feu.
# (lisp (c'est bien))
Posté par David Delassus (site web personnel) . Évalué à 10.
Mais, c'est bien le Lisp pourtant !
https://xkcd.com/297/
PS: Oui Ysabeau, j'ai le droit de hotlink cette image, le site de xkcd fournit même le lien pour le faire.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: (lisp (c'est bien))
Posté par Marotte ⛧ . Évalué à 5.
Mais à priori tu devrais aussi mettre un lien vers la licence d’après https://creativecommons.org/licenses/by-nc/2.5/
Juste une remarque pas une critique, je suis mal placé pour critiquer. ^^
[^] # Re: (lisp (c'est bien))
Posté par David Delassus (site web personnel) . É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
# GUI pour python.
Posté par Gof (site web personnel) . Évalué à 10.
Une bibliothèque GUI de moins pour python?
C'est pas grave, la bibliothèque GUI que je développe (Slint) offrira bientôt une API Python.
En fait, elle existe déjà en version alpha: https://github.com/slint-ui/slint/tree/master/api/python#slint-python-alpha
[^] # Re: GUI pour python.
Posté par jsbjr . Évalué à 4.
Il y une typo dans le lien vers slint.dev
[^] # Re: GUI pour python.
Posté par raphj . Évalué à 5.
Félicitations pour Slint, mais… outch, les gros sabots xD.
[^] # Re: GUI pour python.
Posté par Marotte ⛧ . Évalué à 4.
Loin de moi l’idée de dire que ce que tu fais ne sert à rien, je suis au contraire admiratif du travail que tu fournis, mais n’est-ce pas une « dilution » des efforts de développer une nouvelle bibliothèque, plutôt que de contribuer à celles qui existent déjà ?
Il y a toujours l’utilité de développer ses compétences ça c’est indéniable, ainsi que de pouvoir avoir une bibliothèque qui nous convient parfaitement, mais est-ce que par ailleurs il y avait des défauts/manques/problèmes des bibliothèques existantes qui t’ont poussé à développer Slint ?
Je vais aller voir sur le site mais je me devais de commenter avant de vérifier si la réponse à ma question pouvait s’y trouver ! ^^
[^] # Re: GUI pour python.
Posté par Marotte ⛧ . Évalué à 3.
Très beau site je trouve.
J’aurais tendance à dire que développer une nouvelle bibliothèque comme celle-ci permet en premier lieu de se libérer de toute dette technique qu’un bibliothèque existante peut avoir.
Je reste néanmoins curieux de points plus précis qui ont justifié ce développement. Que je ne remet pas en cause (encore heureux !), c’est pour ma culture personnelle.
[^] # Re: GUI pour python.
Posté par Gof (site web personnel) . Évalué à 10.
J'ai contribué à une bibliothèque existante auparavant : Qt. J'ai travaillé chez Trolltech, puis Nokia, entre 2007 et 2011, et j'ai continué à être actif dans ce projet. J'ai notamment été impliqué dans le projet connu sous le nom de "Qt for MCUs".
Cependant, j'ai remarqué que Qt avait atteint son pic de popularité. À la fin des années 2010, la plupart des applications de bureau se tournaient vers des technologies Web comme Electron. Je me suis alors demandé : pourquoi opter pour une technologie aussi lourde et consommatrice de ressources alors qu'il existe une alternative légère et conviviale comme QML ?
Une explication réside le fait que QML exige une connaissance du C++. Les développeurs maîtrisant ce langage ne sont pas légion, et les bindings pour d'autres langages (comme Python) sont souvent de de seconde classe.
C'est pour ça que nous avons décidé de créer une bibliothèque graphique universelle répondant à plusieurs critères :
Face à l'absence de bibliothèque répondant à ces critères, nous avons décidé de créer la nôtre.
[^] # Re: GUI pour python.
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Je ne comprends pas bien la licence. D'après GitHub c'est du GPLv3, d'après le site c'est GPLv3 pour l'embarqué et royalties free pour web et desktop.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: GUI pour python.
Posté par raphj . Évalué à 6.
À priori quand on clique on y voit plus clair : https://slint.dev/community#community-licenses
[^] # Re: GUI pour python.
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
J'avais vu cette page mais je n'avais pas compris les choses comme ça. Mais effectivement, avec ta lecture ça me semble logique et je comprends la même chose maintenant.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: GUI pour python.
Posté par raphj . Évalué à 2.
Ouais, mais en effet, Gof, ça mériterait plus de clarté, on doit aller lire le texte de la licence pour aller deviner l'idée derrière le modèle de distribution / commercial, pas ouf, faudrait que ça soit clair immédiatement sur la première page à mon avis :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.