Posté par flagos .
Évalué à 3 (+1/-0).
Dernière modification le 20 octobre 2024 à 23:26.
Oui, c'est leur explication, mais je vois avoue ne pas avoir bien compris le fond de l'affaire, et je partage pour avoir vos lumières. Le commentaire donné est le suivant :
the SDK and the client are two separate programs
code for each program is in separate repositories
the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3
Le problème, c'est que si une partie de la fonctionnalité est dans un sdk qui n'est pas sous une licence libre, est ce qu'on peut vraiment considérer que c'est un client libre ?
Je sais pas de quoi on parle fonctionnellement, mais si ca vient de chez bitwarden, j'imagine que ce n'est pas une fonctionnalité annexe.
Bref, si quelqu'un comprend ce qui se passe chez Bitwarden.
Le problème, c'est que si une partie de la fonctionnalité est dans un sdk qui n'est pas sous une licence libre, est ce qu'on peut vraiment considérer que c'est un client libre ?
Question intéressante à laquelle je serais tenté de répondre "oui". Tant qu'on a le code et que le code fournit est sous licence libre. Par exemple, si je fais un programme en C# qui nécessite un compilateur non-libre pour être compilé (exemple hypothétique parce que je ne connais pas la licence réelle du compilateur C#), est-ce que mon programme peut-être libre ? Mais ça gêne peut-être la liberté 1… Je ne sais pas.
Bref, si quelqu'un comprend ce qui se passe chez Bitwarden.
Il y a quantité de commentaires sur le ticket qui disent qu'ils ont un positionnement très flou depuis quelques temps et qu'ils cherchent peut-être à sortir du libre. Mais je ne sais rien de plus que ce disent ces commentaires.
Disclaimer: IANAL, et je ne connais pas Bitwarden plus que de nom.
Le problème, c'est que si une partie de la fonctionnalité est dans un sdk qui n'est pas sous une licence libre, est ce qu'on peut vraiment considérer que c'est un client libre ?
Non.
You may not use this SDK to develop applications for use with software other
than Bitwarden (including non-compatible implementations of Bitwarden) or to
develop another SDK.
Tu n'as pas le droit
1. d'utiliser le SDK avec un fork de Bitwarden,
2. avec un logiciel qui n'est pas issu de Bitwarden,
3 de refaire un "SDK" compatible pour un autre logiciel afin de profiter du client pour un autre logiciel que Bitwarden.
Tu peux à la limite chercher les APIs nécessaires à faire un nouveau SDK sans ces restrictions et faire un client vraiment libre (sans t'aider du SDK). Mais dans l'état, ce n'est pas le cas: il y a des modifications qui te sont interdites.
D'autant plus que le client étant sous GPL, si tu veux pouvoir jouir de la redistribution telle que permise par la GPL, il te faut pouvoir y lier le SDK sous licence compatible avec la GPL, ce que tu n'as pas.
Il semblerait qu'il y ait plusieurs interprétations de ce qui est "lier" une bibliothèque (ici le SDK) dans des langages interprétés comme js. Encore une fois IANAL, mais je pense que si on veut respecter l'idée première de la GPL (permettre la modification et la redistribution d'un soft dans son intégralité avec la possibilité de l'adapter pour qu'il soit fonctionnel quelque soit le cas de figure), alors non. Ce client n'est pas libre.
permettre la modification et la redistribution d'un soft dans son intégralité avec la possibilité de l'adapter pour qu'il soit fonctionnel quelque soit le cas de figure
Il y a sûrement plusieurs façons de lire la liberté 1 (liberté d'étudier un programme et de le modifier pour ses besoins), mais le fait d'avoir un SDK non libre n'est pas forcément un frein. Tout dépend de ce qu'on nomme le "programme" en question…
Après je reste un peu surpris par ce mini "scandale". Le côté serveur de Bitwarden n'a jamais été libre, on ne peut pas l'auto-héberger. C'est pourtant un composant central de l'offre Bitwarden. Alors le fait que le SDK ne soit pas libre, je trouve ça assez secondaire en fait.
Il y a sûrement plusieurs façons de lire la liberté 1 (liberté d'étudier un programme et de le modifier pour ses besoins), mais le fait d'avoir un SDK non libre n'est pas forcément un frein.
Pas forcément, tout dépend de tes besoin. Mais pour considérer qu'il est libre, il est nécessaire que ce soit indépendant de ton besoin. Je devrais pouvoir fournir un service basé dessus et avoir la garantie de pouvoir adapter le code peu importe ce qui arrive. Ici j'ai clairement des limitations de ce côté.
Alors le fait que le SDK ne soit pas libre, je trouve ça assez secondaire en fait.
Pas forcément, je prends l'exemple de Signal. L'important est que le client soit libre pour s'assurer que le service est fourni tel qu'annoncé. La partie serveur ne fait "que" servir de couche de transport et à part pour quelques métadonnées, la plupart les garanties sont dans le fait que c'est chiffré avant d'arriver aux serveurs. Le fait que le client soit ouvert est important dans ce cas. Si tu ne fais pas confiance dans leurs binaires tu peux au moins recompiler leur code.
Ici, si c'est le SDK qui s'occupe d'une partie des fonctionnalités comme le chiffrage… tu as intérêt à minima de pouvoir le recompiler toi même, voir même à en faire une version compatible avec un fork et une réimplémentation des APIs de bitwarden pour le côté serveur, parce que ça correspond à ce que tu utilisais et recherche. Avec cette licence.. ben, tu peux pas. Tu es dépendant de leur volonté.
bof avoir de la messagerie instantanée où seul le client est libre rend ipso facto le service global non libre : le fait de ne pas pouvoir instancier le serveur chez toi vaut à ce type de client la qualification à raison d'anti-fonctions sur f-droid (promotion d'un service non libre, obligatoire pour le coup en plus…).
Quand bien même le serveur serait sous GPL, il est important de pouvoir s'affranchir d'un seul service fourni par un seul fournisseur (rien n'empêche de déployer du code GPL distinct de celui qui est public, avec des modifications qui ne seraient pas rendues publiques), surtout le jour où leurs conditions ne sont plus acceptables : c'est là qu'il est intéressant de pouvoir déployer le tien ou d'utiliser celui d'un tiers de confiance ;-)
Pour un client autonome, dépendre d'un compilateur non libre ou d'une bibliothèque est gênant — il faut patcher pour utiliser un compilateur libre, il faut réimplémenter une bibliothèque libre fournissant l'API — mais n'enlève pas le caractère libre du programme.
Lorsque c'est un service (client + serveur), ça ne sert à rien d'avoir un client libre tant qu'un serveur libre ne sera pas redéveloppé pour le même service (ce qui est un frein un peu plus grand pouvant enfermer tes données/ton historique, voire mettre à mal leur contenu — les failles ça n'arrive pas qu'aux autres…).
bof avoir de la messagerie instantanée où seul le client est libre rend ipso facto le service global non libre
On est d'accord pour le service, mais ça n'enlève pas vraiment le côté libre ou non du client.
Pour un client autonome, dépendre d'un compilateur non libre ou d'une bibliothèque est gênant…
Lorsque c'est un service (client + serveur), ça ne sert à rien d'avoir un client libre tant qu'un serveur libre ne sera pas redéveloppé pour le même service…
Je ne vois pas trop la différence, tu peux réécrire l'interfaçage pour dépendre d'un autre service, libre lui. Il y aura sans doute un peu plus de boulot pour bien t'intégrer avec le nouveau service, en particulier si les fonctionnalités fournies sont fort différentes, mais ça ne change pas fondamentalement le problème.
ce qui est un frein un peu plus grand pouvant enfermer tes données/ton historique
Et pour la question des données on est d'accord que si tu en dépends à ce point, la question ne se posent même pas. C'est tout en libre sur un environnement maitrisé dès le départ. Note, même dans ce cas, les failles ça n'arrive pas qu'aux autres, a fortiori quand c'est pas ton boulot principal. Et on parle pas encore de théorie et pratique.
Maintenant, on parle d'un service de messagerie.. c'est vaste ! Si tu prends Mattermost et Signal, l'usage et donc importance d'avoir un serveur libre n'est déjà pas la même.
Si signal ferme demain, j'ai toujours mes données en local et j'harcèle mes contacts pour qu'ils me suivent sur l'alternative qui y ressemble le plus. Si le serveur n'est pas libre, mais que le client est à source ouverte, me garanti que les données à disposition du serveur sont acceptables (et donc recompilable), ça me va.
Bref, c'est à peser en fonction de l'outil et l'utilisation.
C'est vrai, Bitwarden a un modèle économique freemium et open core comme GitLab. Le code du serveur est partiellement disponible et partiellement libre en AGPL 3.0, mais ça reste propriétaire pour certains morceaux (licence Bitwarden).
Par contre, on peut tout à fait héberger le serveur soi-même, même si c'est réputé lourdingue, en particulier pour la partie base de données pour les grosses installations. Il faut avoir une licence pour pouvoir profiter des fonctionnalités payantes.
Du côté auto hébergement, Vaultwarden est vraiment simple et convient parfaitement pour des petites structures (et peut-être pour des grandes aussi d'ailleurs).
# Un bug ?
Posté par Faya . Évalué à 1 (+0/-1).
[^] # Re: Un bug ?
Posté par flagos . Évalué à 3 (+1/-0). Dernière modification le 20 octobre 2024 à 23:26.
Oui, c'est leur explication, mais je vois avoue ne pas avoir bien compris le fond de l'affaire, et je partage pour avoir vos lumières. Le commentaire donné est le suivant :
Le problème, c'est que si une partie de la fonctionnalité est dans un sdk qui n'est pas sous une licence libre, est ce qu'on peut vraiment considérer que c'est un client libre ?
Je sais pas de quoi on parle fonctionnellement, mais si ca vient de chez bitwarden, j'imagine que ce n'est pas une fonctionnalité annexe.
Bref, si quelqu'un comprend ce qui se passe chez Bitwarden.
[^] # Re: Un bug ?
Posté par Faya . Évalué à 2 (+0/-0).
Question intéressante à laquelle je serais tenté de répondre "oui". Tant qu'on a le code et que le code fournit est sous licence libre. Par exemple, si je fais un programme en C# qui nécessite un compilateur non-libre pour être compilé (exemple hypothétique parce que je ne connais pas la licence réelle du compilateur C#), est-ce que mon programme peut-être libre ? Mais ça gêne peut-être la liberté 1… Je ne sais pas.
Il y a quantité de commentaires sur le ticket qui disent qu'ils ont un positionnement très flou depuis quelques temps et qu'ils cherchent peut-être à sortir du libre. Mais je ne sais rien de plus que ce disent ces commentaires.
[^] # Re: Un bug ?
Posté par Elfir3 . Évalué à 5 (+3/-0).
Disclaimer: IANAL, et je ne connais pas Bitwarden plus que de nom.
Non.
Tu n'as pas le droit
1. d'utiliser le SDK avec un fork de Bitwarden,
2. avec un logiciel qui n'est pas issu de Bitwarden,
3 de refaire un "SDK" compatible pour un autre logiciel afin de profiter du client pour un autre logiciel que Bitwarden.
Tu peux à la limite chercher les APIs nécessaires à faire un nouveau SDK sans ces restrictions et faire un client vraiment libre (sans t'aider du SDK). Mais dans l'état, ce n'est pas le cas: il y a des modifications qui te sont interdites.
D'autant plus que le client étant sous GPL, si tu veux pouvoir jouir de la redistribution telle que permise par la GPL, il te faut pouvoir y lier le SDK sous licence compatible avec la GPL, ce que tu n'as pas.
Il semblerait qu'il y ait plusieurs interprétations de ce qui est "lier" une bibliothèque (ici le SDK) dans des langages interprétés comme js. Encore une fois IANAL, mais je pense que si on veut respecter l'idée première de la GPL (permettre la modification et la redistribution d'un soft dans son intégralité avec la possibilité de l'adapter pour qu'il soit fonctionnel quelque soit le cas de figure), alors non. Ce client n'est pas libre.
[^] # Re: Un bug ?
Posté par Christophe . Évalué à 3 (+1/-0).
Il y a sûrement plusieurs façons de lire la liberté 1 (liberté d'étudier un programme et de le modifier pour ses besoins), mais le fait d'avoir un SDK non libre n'est pas forcément un frein. Tout dépend de ce qu'on nomme le "programme" en question…
Après je reste un peu surpris par ce mini "scandale". Le côté serveur de Bitwarden n'a jamais été libre, on ne peut pas l'auto-héberger. C'est pourtant un composant central de l'offre Bitwarden. Alors le fait que le SDK ne soit pas libre, je trouve ça assez secondaire en fait.
[^] # Re: Un bug ?
Posté par Elfir3 . Évalué à 3 (+1/-0).
Pas forcément, tout dépend de tes besoin. Mais pour considérer qu'il est libre, il est nécessaire que ce soit indépendant de ton besoin. Je devrais pouvoir fournir un service basé dessus et avoir la garantie de pouvoir adapter le code peu importe ce qui arrive. Ici j'ai clairement des limitations de ce côté.
Pas forcément, je prends l'exemple de Signal. L'important est que le client soit libre pour s'assurer que le service est fourni tel qu'annoncé. La partie serveur ne fait "que" servir de couche de transport et à part pour quelques métadonnées, la plupart les garanties sont dans le fait que c'est chiffré avant d'arriver aux serveurs. Le fait que le client soit ouvert est important dans ce cas. Si tu ne fais pas confiance dans leurs binaires tu peux au moins recompiler leur code.
Ici, si c'est le SDK qui s'occupe d'une partie des fonctionnalités comme le chiffrage… tu as intérêt à minima de pouvoir le recompiler toi même, voir même à en faire une version compatible avec un fork et une réimplémentation des APIs de bitwarden pour le côté serveur, parce que ça correspond à ce que tu utilisais et recherche. Avec cette licence.. ben, tu peux pas. Tu es dépendant de leur volonté.
[^] # Re: Un bug ?
Posté par BAud (site web personnel) . Évalué à 4 (+2/-0).
bof avoir de la messagerie instantanée où seul le client est libre rend ipso facto le service global non libre : le fait de ne pas pouvoir instancier le serveur chez toi vaut à ce type de client la qualification à raison d'anti-fonctions sur f-droid (promotion d'un service non libre, obligatoire pour le coup en plus…).
Quand bien même le serveur serait sous GPL, il est important de pouvoir s'affranchir d'un seul service fourni par un seul fournisseur (rien n'empêche de déployer du code GPL distinct de celui qui est public, avec des modifications qui ne seraient pas rendues publiques), surtout le jour où leurs conditions ne sont plus acceptables : c'est là qu'il est intéressant de pouvoir déployer le tien ou d'utiliser celui d'un tiers de confiance ;-)
Pour un client autonome, dépendre d'un compilateur non libre ou d'une bibliothèque est gênant — il faut patcher pour utiliser un compilateur libre, il faut réimplémenter une bibliothèque libre fournissant l'API — mais n'enlève pas le caractère libre du programme.
Lorsque c'est un service (client + serveur), ça ne sert à rien d'avoir un client libre tant qu'un serveur libre ne sera pas redéveloppé pour le même service (ce qui est un frein un peu plus grand pouvant enfermer tes données/ton historique, voire mettre à mal leur contenu — les failles ça n'arrive pas qu'aux autres…).
[^] # Re: Un bug ?
Posté par Elfir3 . Évalué à 2 (+0/-0).
On est d'accord pour le service, mais ça n'enlève pas vraiment le côté libre ou non du client.
Je ne vois pas trop la différence, tu peux réécrire l'interfaçage pour dépendre d'un autre service, libre lui. Il y aura sans doute un peu plus de boulot pour bien t'intégrer avec le nouveau service, en particulier si les fonctionnalités fournies sont fort différentes, mais ça ne change pas fondamentalement le problème.
Et pour la question des données on est d'accord que si tu en dépends à ce point, la question ne se posent même pas. C'est tout en libre sur un environnement maitrisé dès le départ. Note, même dans ce cas, les failles ça n'arrive pas qu'aux autres, a fortiori quand c'est pas ton boulot principal. Et on parle pas encore de théorie et pratique.
Maintenant, on parle d'un service de messagerie.. c'est vaste ! Si tu prends Mattermost et Signal, l'usage et donc importance d'avoir un serveur libre n'est déjà pas la même.
Si signal ferme demain, j'ai toujours mes données en local et j'harcèle mes contacts pour qu'ils me suivent sur l'alternative qui y ressemble le plus. Si le serveur n'est pas libre, mais que le client est à source ouverte, me garanti que les données à disposition du serveur sont acceptables (et donc recompilable), ça me va.
Bref, c'est à peser en fonction de l'outil et l'utilisation.
[^] # Re: Un bug ?
Posté par cg . Évalué à 3 (+1/-0).
C'est vrai, Bitwarden a un modèle économique freemium et open core comme GitLab. Le code du serveur est partiellement disponible et partiellement libre en AGPL 3.0, mais ça reste propriétaire pour certains morceaux (licence Bitwarden).
Par contre, on peut tout à fait héberger le serveur soi-même, même si c'est réputé lourdingue, en particulier pour la partie base de données pour les grosses installations. Il faut avoir une licence pour pouvoir profiter des fonctionnalités payantes.
Du côté auto hébergement, Vaultwarden est vraiment simple et convient parfaitement pour des petites structures (et peut-être pour des grandes aussi d'ailleurs).
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.