Allons-y donc.
Un exemple concret:
Une MR propose d’intégrer au dépôt de la licence monétaire des éléments purement techniques liées à une techno en particulier, j’estime que ça n’a rien à faire dans ce dépôt, qui tranche ? 
3 Likes
Je vais partir un peu loin, mais je sais que certaines monnaies (le gridcoin par exemple), intègrent des systèmes de vote au sein de la blockchain.
La licence ĝ1, finalement, s’approche un peu d’une constitution (limitée à la monnaie bien entendu). De ce constat, les questions de modification ou de grosses décisions sur la licence ne devraient-elles pas être résolues par référendum ?
Évidemment, cela suppose l’existence d’un système de vote dans la chaîne 
1 Like
Ce sera une étape difficile à franchir, mais oui, à un moment donné il faudra une constitution et un système de vote (*). Debian pourrait être une source d’inspiration dans ces domaines. En particulier sur le système de vote (méthode Condorcet) qui privilégie le consensus sur la loi de la majorité.
(*) Disclaiimer : je ne suis pas membre à ce jour. Mais j’aspire à l’être, donc je donne mon avis
Il me semblai que le vote Condorcet privilégiait la majorité.
J’ai une préférence pour le jugement majoritaire.
2 Likes
Attention, je tiens à rappeler que la licence monétaire de la Ğ1, comme les licences logicielles, est rédigée par un petit groupe de personnes qui l’ont fait pour préciser au grand public plusieurs choses :
- Les paramètres de la monnaie
- Les paramètres de la Toile de Confiance
- Les règles de fonctionnement optimale à respecter pour une bonne sécurité de la Toile de Confiance.
2/3 du texte est principalement technique, 1/3 seulement vise à cadrer l’usage de la Toile de Confiance par les Certifications.
Ce N’est donc PAS une constitution. Ce sont des Conditions Générales d’Utilisation, rédigées par les créateurs d’un produit, à destination des usagers, pour se prémunir d’attaque par ingénierie sociale.
Si les CGU devait changer car on se rend compte que les paliers de certifications des référents ou les attaques Sybilles nous obligent à changer l’utilisation des certifications, ce sont les créateurs du produit qui modifieront la licence, pas les utilisateurs (sauf s’ils maîtrisent la théorie des graphes et le fonctionnement des paliers de référents et l’évolution des attaques sibylles et sont donc de fait des contributeurs actifs à la création du produit).
@luke @pini, ce dont vous parlez à plus de sens dans un collectif pour décider de son organisation.
Je suggère pour commencer de constituer un groupe de « rédacteurs » à partir de la liste des contributeurs rémunérés, sur la base du volontariat.
- Les développeurs confrontés aux identités et certifications (soit par le développement d’un serveur ou d’un client ou d’un outil de statistiques sur ce sujet).
- Les contributeurs au fait des questions sur la toile de Confiance (théorie des graphes).
- Les contributeurs au fait des paramètres de la monnaie (formules, etc).
Ensuite deux options :
- Une liste unique des rédacteurs de la licence dite « rédacteurs ». Chaque vote est au même niveau. (le plus simple).
- Deux listes, une avec les « rédacteurs » et une liste de « consultants ». Les « rédacteurs » lancent un vote auquel les « consultants » participent. A la fin la décision revient au groupe des « rédacteurs ».
Qu’en pensez-vous ?
La méthode Condorcet demande à chaun de classer les différentes options par ordre de préférence. Ce qui ressort gagnant, mécaniquement, est l’option qui est globalement la mieux classée. Pas celle qui arrive en premier dans le plus de votes. Un peu comme un Poulidor qui peut gagner en étant toujours deuxième. Il y a plein de doc partout sur cette méthode.
Il y a plusieurs systèmes de vote, optimaux pour certains objectifs, mais ça dépend de l’objectif. Le choix d’un système de vote contient donc une part d’idéologie, il faudra en débattre pour en choisir un. (dans un autre sujet)
J’ai lu un certain nombre de licences logiciels et je peux dire que la « licence ğ1 » n’y ressemble en rien. C’est un document qui définit deux choses :
- Les paramètres de la monnaie
- Les règles de cooptation / exclusion des membres producteurs
Il ne définit pas les conditions d’utilisation de la monnaie : je ne suis pas membre et je peux utiliser la ğ1 comme bon me semble.
Soit ces paramètres et règles sont des invariants qu’on s’interdit de modifier une fois pour toutes; soit ils sont ajustables selon les circonstances (facteurs externes, retour d’expérience), et il faut en définir les conditions d’évolution.
Dans tous les cas c’est bien plus proche du concept de statuts d’une association (mais constitution me plaît mieux comme terme) que d’une licence logicielle.
1 Like
Si la “licence Ğ1” n’est pas à une “licence”, il faut alors changer son nom et revoir son rôle. Ce qui expliquerait les désaccords et la confusion autour de sa nature et de son rôle.
Je ne suis évidemment pas d’accord avec toi, pour les raisons évoquées plus haut. Pour moi la licence porte bien son nom et doit être rédigée par les créateurs du projet, pas par les utilisateurs. Pour la simple raison que sa rédaction se base sur des connaissances techniques précises, pas des ressentis ni des opinions.
Ce ne sont pas des invariants pour certaines données puisque la licence est versionnée.
Nous sommes sur ce fil justement pour en définir les conditions d’évolution.
1 Like
Seuls les créateurs d’origine ? Seuls les développeurs actuels ? Faut-il avoir l’accord de tous les contributeurs antérieurs ? Qu’est-ce qui définit le statut de créateur ? Développeur de client c’est suffisant ? Auto-nomination, co-optation par l’équipe en place, nombre de commits, diplôme certifié de développeur avec option cryptographie, élections, … ?
1 Like
ce qui me parlerais le plus c’est :
- quiconque peut proposer des modifications à la licence (on pourra toujours restreindre plus tard si ça se met à représenter une charge de travail trop importante pour les relecteurices).
- un groupe de relecteurices (à initier sur la base des développeurs actifs, avec les ajustements que propose vit par exemple) qui évolue par cooptation (minimum 5 d’entre eux par exemple) pour les entrées et démission pour les sorties.
- lorsqu’une merge-request est proposée, les relecteurices ont 1 mois pour se prononcer. Si au moins 5 valident et qu’aucun⋅e n’y vois à redire, la merge-request est accepté au bout d’un mois.
Si quelqu’un y à vu quelque-chose à redire, iel est invité⋅e à le justifier et soit à refuser la proposition, soit à faire une contre-proposition (qui elle même aura sont propre délais d’1mois).
En gros, la gouvernance que je propose est au consentement (personne n’est contre).
Qu’en dite-vous ?
2 Likes
Ça me semble bien
1 Like
La façon dont tu différencies les utilisateurs des développeurs est très proche du parallèle « gouvernement » vs « le peuple », qui part souvent du principe que les gens n’ont pas de connaissances. Le texte peut tout à fait être technique et tout de même être soumis à l’approbation: il faut expliquer ce que les modifications induisent et de laisser place à un petit débat pour ceux qui ont des doutes ou des questions.
Le dernier système proposé permet à minima d’instaurer un « qui », puisque qu’il y a une liste définie puis un système de cooptation. Il faudrait également prévoir un système de déchéance en plus de la démission peut-être.
Un potentiel problème est la difficulté d’obtenir de la diversité (opinions divergentes) à cause de la cooptation faite par les gens déjà en place
Je voudrais clarifier ma position pour ne pas laisser les arguments de l’homme de paille proliférer.
Je n’empêche personne de faire quoi que ce soit.
La gouvernance du projet Duniter a toujours été expliquée clairement dans les forums et les conférences. C’est une gouvernance par l’expertise de fait. Les développeurs font les lois (le code, versions ou fork), les administrateurs de serveurs choisissent et exécutent les lois (versions ou fork), et les utilisateurs choisissent les lois (versions ou fork).
La licence me semble rentrer dans ce cadre. C’est là notre point de désaccord.
Si un démocrate veut soumettre au vote des 3000 membres les modifications ayant trait à la licence, libre à lui de le faire. Il devra ensuite convaincre le cercle réduit de ceux qui savent/peuvent modifier la licence de le faire.
Il peut commencer par la première question posée par @elois :
- Faut-il inclure dans le dépôt git de la licence des scripts et configuration de packaging pour NodeJS et Python ?
Et nous faire un retour sur le vote conscient et éclairé des 3000 membres sur cette première question.
Un retour sérieux j’entends, avec la distinction entre les abstentions, ceux qui n’ont pas d’avis, ceux qui n’ont pas compris la question, ceux qui trouvent que la question est mal formulée, etc.
C’est déjà le cas. Il y a eu des propositions sur le forum monnaie-libre.fr. J’ai moi même fait des propositions ici.
Mais je suis d’accord avec @1000i100 sur la proposition.
Cela me convient tout à fait.
Mouais, plutôt déçu de la tournure de la discussion pour une communauté comme celle-là. J’ai dit ce que j’avais en tête, je m’en tiendrai là, je passe
Pour avancer concrètement, j’ai créé un fil de discussion dédié avec un règlement qui reprend exactement la proposition de @1000i100
@luke , @Pini si vous désirez faire partie des relecteurs ou simplement faire des propositions de modification de la licence vous êtes les bienvenus.
Le règlement est une première ébauche en mode wiki, pour être modifié et amélioré, et aussi être signé (si tout le monde est ok avec mon idée de signature au bas de règlement…).
Merci pour le ping. C’est un sujet intéressant, mais je me rends compte que je suis très influencé par la gouvernance Debian où tout est très codifié dans la constitution et la Debian Policy. Votre mode de fonctionnement est à des lieux de tout ça.
Je vais continuer d’observer, et si j’arrive à avoir un avis de temps à autre, ben je le donnerai
5 Likes
Pourquoi pas, je pense que c’est un premier pas vers une structuration, c’est bon à prendre 
Initialement on était tellement peu nombreux que la question de la gouvernance ne s’est tout simplement pas posée. Maintenant qu’on commence à être de plus en plus « nombreux » (même si à mon grand désarroi ça n’augmente pas le nombre de contributeurs réguliers au cœur 
), la question de la gouvernance se pose de plus en plus. Mais il faut des volontés nombreuses et beaucoup d’énergie pour concevoir une gouvernance qui convienne aux concernés, perso j’ai déjà beaucoup trop à faire pour la Ğ1, je ne peux pas consacrer en plus de l’énergie à ça, mais si d’autres le fond, je pourrais donner mon avis et signer (où pas) ce qui émergera