Je n'ai pas l'intention d'aller voir le code, mais je ne sais pas quel genre d'effort il faudrait pour bricoler le code GPL du client pour éventuellement aller se connecter à un serveur libre.
Une autre manière de voir les choses est de voir cette question de liberté du point de vue pratique: à ma connaissance toutes les forks D'Ubuntu qui veulent modifier les paquets pour une raison ou une autre (comme Trisquel et peut être la version Ubuntu de Mint aussi) n'ont pas essayé de re-créer un serveur snap. Après à l'époque ou ce genre de décisions ont été prises il n'y avait pas vraiment de serveur snap libre vraiment fonctionnel. Des considérations techniques ou éthiques (utilisations de resources VS écologie) peuvent aussi avoir fait partit des décisions.
Du coup la question ici est de savoir si de façon pratique c'est faisable d'utiliser kebe (https://github.com/freetocompute/kebe) qui à été mentionné dans ce thread. Si pour un fork ça prend moins de travail de repackager les snaps en deb, du coup l'intérèt du point de vue d'une distribution est limité.
A noter que même avec SNAP, si les logiciels distribués sont libres (comme VLC, Wesnoth, Libreoffice etc) ça reste sans doute plus simple de migrer à d'autres distributions avec les mêmes logiciels que si on utilise des logiciels pas libre à la base (par exemple avec Microsoft Office -> Libreoffice).
Il reste aussi le fait de pouvoir facilement distribuer un logiciel libre à pas mal de distributions différentes, et la la question est aussi de voir si on peut facilement changer l'URL du serveur snap et/ou comment facilement distribuer un client snap qui peut faire ça.
Après même sans ça ça peut valoir le coup car les compétences pour faire des snaps, les définitions de snaps, etc peuvent du coup être réutilisées facilement avec les versions libres, et des un client alternatifs voient le jour, ça pourrait être simple pour les distributions de migrer à ces clients.
Personnellement j'aimerais vraiment savoir s'il y'a des stores alternatifs qui sont en production car ça change la donne et ça permettrais de mettre à jour l'information sur ce sujet.
Après il y a aussi un autre problème de liberté: le store snap contient pas mal de logiciels pas libres, et en pratique, vu le contexte, je pense pas que ça aide le libre, au contraire. En plus je sait plus si c'est facile ou pas de filtrer les logiciels pas libre et quelle est vraiment la fiabilité de l'indication qui dit que c'est libre ou pas (si elle existe). Du coup ça peut compliquer les forks des repositories (notamment pour avoir des repositories 100% libres).
Un troisième problème est la manière de voir le problème de liberté des logiciels distribués. Par exemple il est possible de faire un logiciel libre qui installe des logiciels pas libres, ou qui dépend de services non libres, ou d'un composant non-libre qu'il télécharge automatiquement etc. Dans certains de ces cas la communauté du libre peut penser que le logiciel est libre tout en ayant en pratique des dépendances non libres qui piège les gens qui utilisent ce logiciel tout en freinant des réponses plus collectives car dans l'esprit collectif le logiciel est libre car les gens qui ne l'utilisent pas n'ont pas regardés de plus près.
Certains repositories prennent ce troisième aspect en considération comme ceux des distributions certifiés par la FSF (il y a une exceptions pour des licences comme cc-by-nd pour des données non fonctionnelles comme des graphiques de jeux), les repositories officiels de Emacs, les repository CRAN (même s'ils permettent quand même des licences non libres comme la licence Artistic V1 et sans doute une ou plusieurs licences creative commons).
[^] # Re: Pas tous libre
Posté par GNUtoo . En réponse au journal snap : de pire en pire.. Évalué à 1.
Une autre manière de voir les choses est de voir cette question de liberté du point de vue pratique: à ma connaissance toutes les forks D'Ubuntu qui veulent modifier les paquets pour une raison ou une autre (comme Trisquel et peut être la version Ubuntu de Mint aussi) n'ont pas essayé de re-créer un serveur snap. Après à l'époque ou ce genre de décisions ont été prises il n'y avait pas vraiment de serveur snap libre vraiment fonctionnel. Des considérations techniques ou éthiques (utilisations de resources VS écologie) peuvent aussi avoir fait partit des décisions.
Du coup la question ici est de savoir si de façon pratique c'est faisable d'utiliser kebe (https://github.com/freetocompute/kebe) qui à été mentionné dans ce thread. Si pour un fork ça prend moins de travail de repackager les snaps en deb, du coup l'intérèt du point de vue d'une distribution est limité.
A noter que même avec SNAP, si les logiciels distribués sont libres (comme VLC, Wesnoth, Libreoffice etc) ça reste sans doute plus simple de migrer à d'autres distributions avec les mêmes logiciels que si on utilise des logiciels pas libre à la base (par exemple avec Microsoft Office -> Libreoffice).
Il reste aussi le fait de pouvoir facilement distribuer un logiciel libre à pas mal de distributions différentes, et la la question est aussi de voir si on peut facilement changer l'URL du serveur snap et/ou comment facilement distribuer un client snap qui peut faire ça.
Après même sans ça ça peut valoir le coup car les compétences pour faire des snaps, les définitions de snaps, etc peuvent du coup être réutilisées facilement avec les versions libres, et des un client alternatifs voient le jour, ça pourrait être simple pour les distributions de migrer à ces clients.
Personnellement j'aimerais vraiment savoir s'il y'a des stores alternatifs qui sont en production car ça change la donne et ça permettrais de mettre à jour l'information sur ce sujet.
Après il y a aussi un autre problème de liberté: le store snap contient pas mal de logiciels pas libres, et en pratique, vu le contexte, je pense pas que ça aide le libre, au contraire. En plus je sait plus si c'est facile ou pas de filtrer les logiciels pas libre et quelle est vraiment la fiabilité de l'indication qui dit que c'est libre ou pas (si elle existe). Du coup ça peut compliquer les forks des repositories (notamment pour avoir des repositories 100% libres).
Un troisième problème est la manière de voir le problème de liberté des logiciels distribués. Par exemple il est possible de faire un logiciel libre qui installe des logiciels pas libres, ou qui dépend de services non libres, ou d'un composant non-libre qu'il télécharge automatiquement etc. Dans certains de ces cas la communauté du libre peut penser que le logiciel est libre tout en ayant en pratique des dépendances non libres qui piège les gens qui utilisent ce logiciel tout en freinant des réponses plus collectives car dans l'esprit collectif le logiciel est libre car les gens qui ne l'utilisent pas n'ont pas regardés de plus près.
Certains repositories prennent ce troisième aspect en considération comme ceux des distributions certifiés par la FSF (il y a une exceptions pour des licences comme cc-by-nd pour des données non fonctionnelles comme des graphiques de jeux), les repositories officiels de Emacs, les repository CRAN (même s'ils permettent quand même des licences non libres comme la licence Artistic V1 et sans doute une ou plusieurs licences creative commons).