La licence qu’accepte chaque membre de la Ǧ1 me semble intuitivement correspondre à la licence de la monnaie.
Pour autant, elle me semble essentiellement définir le fonctionnement de la WoT… Et imposer d’être présente dans les logiciels manipulant monnaie et/ou WoT.
A ma connaissance, la licence de Duniter-ts est l’AGPLv3
et le document descriptif du protocole étant sur le même dépot, je suppose qu’il est couvert par la même licence, en tant que document. Mais en tant que protocol ?
Bref, j’ai trouvé ta remarque très intéressant, mais me laissant plus de questionnement que de réponses. Ma problématique étant de clarifier et synthétiser ce à quoi doivent s’engager les utilisateurs de la Ǧ1, membre, non membre, développeur… Pour ne pas en faire un document imbitable que de plus en plus de monde rechigne à lire et préfère en avoir une synthèse qu’il accepter sur la confiance qu’il porte à l’auteur de la synthèse.
Je re-cite à ce sujet Inso :
@Galuel Avant de savoir si tu es pour, contre ou plus nuancé sur ce projet de synthétisation de la licence Ǧ1 et éventuellement de sa division en une partie monnaie et une partie WoT explicité comme deux licences différentes, j’aimerais avoir de ta part une clarification sur ce que tu désignerais comme étant la licence de :
La monnaie Ǧ1
Le la WoT sur la quelle repose ses DU et droit à forger des bloc
Duniter (que tu me confirmer que c’est bien juste AGPLv3 ou que c’est plus compliqué que ça)
Du protocole v10, et bientôt v11.
A bientôt,
1000i100
PS : ce n’est pas un MP, parce-que je pense que d’autres réactions seront intéressante à ce sujet.
Alors comme je l’avais déjà dit il y a 1 ans je n’ai pas le même avis, pour moi on ne peut pas dissocier la wot de sa monnaie et vice/versa, la licence Ğ1 est donc la licence de la monnaie Ğ1 et de la wot Ğ1, car la wot définie les comptes créant le DU.
De plus il conviens de rester simple, ne pas perdre l’utilisateur lambda avec plusieurs licences, s’il lis la seule licence qu’il doit lire on à déjà de quoi être très content !
Concernant la distinction entre le protocole et le logiciel qui l’implémente, en effet comme ils étaient historiquement dans le même dépôt ils étaient liés a la même licence : AGPLv3.
Maintenant que nous prévoyons de déplacer le protocole de Duniter dans un autre dépôt (nodes/common/doc), ce pose en effet la question de la licence de ce dépôt. Ce n’est pas a proprement parler du code, donc peut être qu’une CC serait plus adaptée ?
Pour le document du protocole, une CC me semble bien en effet, CC-BY-SA, CC-BY ou CC-0
Après, pour l’usage du protocole en lui même, je n’y ai pas beaucoup réfléchi, mais j’aurais tendance à être favorable à un absence de licence (puisqu’une licence qui interdirais le spam (ou assimilé) impliquerais que l’on puisse faire respecter la licence à quelqu’un d’extérieur) et que pas de licence -> simplicité pour l’usager.
Justement. Si la licence (ou les licences) font des pages et des pages, avec de la redite… Le nombre de lecteur assidu me semble affaibli.
Coté couplage, selon moi, la WoT n’a pas besoin de la Ǧ1, et peu donc avoir une licence qui ne parle pas de monnaie.
La Ǧ1 en revanche me semble intrinsèquement lié à la WoT sur la quelle elle repose.
Après, d’un point de vu expérience utilisateur, est-ce une bonne idée de faire plusieurs licences ? Je ne suis pas sur, sauf si ça permet de clarifier le périmètre de chacune. Par exemple, ça ne me viendrais pas à l’idée de fusionner l’AGPL à la licence de la Ǧ1 sous prétexte que la Ǧ1 repose sur Duniter qui est en AGPL.
Mais l’AGPL n’a pas besoin d’être lu et accepté par chaque utilisateur de la monnaie ou de la WoT. Elle à seulement besoin de l’être par les contributeurs, et hébergeur de nœud, bref, ceux qui fond tourner le logiciel sur leur machine et gère l’accès au code de celui-ci.
On pourrais arguer que les paramètres de la WoT et de la Ǧ1 constituent les droits de l’utilisateur. Mon avis est qu’il s’agit d’explication technique de fonctionnement dont on peut recommander la lecture et la compréhension, mais qui ne nécessite pas d’engagement de l’utilisateur, donc qui pour moi polluent la licence. Elles on leur place dans des annexes (qui peuvent être inclue en fin de licence à condition d’expliciter qu’elles sont là à titre informatif mais qu’elle ne nécessite pas d’engagement de la par de l’utilisateur).
Bref, ma licence Ǧ1 idéale serait constituée :
De l’explicitation du droit des non membres à utiliser la monnaie sans se soucier du reste de la licence.
Des engagements relatif à la WoT demandé à chaque membre et futur membre (N’avoir qu’un compte membre, ne certifier que des gens suffisamment proche pour pouvoir identifier s’il créaient plusieurs comptes membres, ne certifier que des gens respectant la licence, ne certifier qu’après s’être assuré que le destinataire à lu, compris et accepté la licence).
Du droit des membres à co-créer leur DU quotidien (être crédité du même montant que les autres membre, réévalué régulièrement pour croître avec l’évolution de la masse monétaire. cf détails en annexe).
Des garantie et limite de conservation du statut de membre (le statut de membre est garantie pour 1an sauf révocation volontaire, et ré-évalué à chaque renouvellement. Les critère pour être membre son multiples, pour éviter les abus (détails en annexe). Celui à retenir est de rester certifié par au moins 5 membres.).
En explicitant que cette partie s’adresse au producteur de logiciel (et donc que les simple utilisateurs de la Ǧ1 peuvent l’ignorer), l’engagement de passer par l’acceptation de la licence par l’utilisateur avant d’émettre sur le réseau une demande d’adhésion pour devenir membre ou renouveler son statuts de membre (histoire de se rafraîchir la mémoire et de faire publicité des évolutions de la licence).
Enfin j’ajouterais les sections suivantes :
Les membres peuvent exprimer leur “vote” concernant les évolutions des règles de la monnaie, de la TdC et de la licence en faisant tourner un nœud dans la version qu’il cautionnent.
PS : cela sort du cadre de la licence pour dériver sur l’implémentation de la WoT, je serais favorable à stocker en blockchain chaque nouvelle version de la licence, et d’inclure dans les demandes d’adhésion la version de licence accepté par l’utilisateur (et refuser les demande d’adhésion ou de renouvellement avec une version de la licence obsolète). Et du coup d’inclure à la licence l’obligation pour les développeur de clients Ǧ1 permettant d’émettre ces documents de présenter la licence à chaque fois, et pour un renouvellement, d’expliciter s’il y a un changement ou non par rapport à la version qu’ils avait accepté à leur précédent demande d’adhésion comme membre.
Une alternative qui ne demande pas de changement du protocole, mais seulement des comportement client, est, à chaque demande de renouvellement, de comparer la licence actuellement inclue dans le logicielle comme version active à celle qui était active lors de la demande d’adhésion précédente du membre. Si elle est identique, on peu expliciter qu’elle n’a pas changer, et en proposer la lecture pour rappel, si elle à changé, afficher la nouvelle version, idéalement avec un diff par rapport à celle qui avait été acceptée.
La WoT doit respecter la Ğ1, et Duniter pour être compatible Ğ1 doit respecter le code monétaire et le code de la WoT.
De la même façon donc que l’AGPL impose aux logiciels clients d’être sous licence libre, on peut affirmer que la licence Ğ1 impose à la WoT, puis aux moyens d’implémenter WoT et Ğ1 d’être compatibles avec la monnaie libre. Donc dans l’ordre on a :
1°) Le code de la monnaie = pour tout membre unique DU(t+1) = Du(t) + c²*(M/N)(t) (qui permet de changer la fréquence d’actualisation du DU, on peut en effet choisir d’autres unités de mesures temporelles que le jour ou 6 mois), mais pas de changer la valeur de c = 10% / an = 4,88% / 6 mois = …
2°) Le code de la WoT = fonctionnement décentralisé à membre unique, à limite de stock de certifications et de distance (dont les valeurs actuelles sont 100 et 5) + autres paramètres, qui pourra être modifié / amélioré sans changer son principe fondamental. (par exemple passer la distance à 4 ou 6 ne change pas fondamentalement le système monétaire lui-même.
3°) Le code des logiciels qui implémentent WoT et Ğ1 qui doit être compatible AGPL, mais aussi respecter les licences 1°) et 2°)