Avant de lire la suite, merci d’aller voir la proposition principale qui indique l’intention et la structuration des différentes propositions.
La proposition d'annexe ''Règles logiciels Ǧ1''
Règles s’appliquant aux logiciels intéragissant avec la blockchain Ǧ1
Les logiciels Ǧ1 permettant la certification (ou le renouvellement) doivent à chaque certification indiquer où trouver la licence complète (ou l’inclure).
Les logiciels interagissant avec la blockchain Ǧ1 doivent être auditables grâce à une licence libre. Le respect de ces conditions est nécessaire pour que les logiciels Ǧ1 soient conformes à la présente licence.
Cette règle ne permet pas de publier de logiciel porte-feuille (crypto-currency wallet) sous une licence logicielle propriétaire ? Est-ce souhaitable de simplement interdire cela ? Pourquoi mettre en place cette contrainte ? Qu’est-il prévu de faire si quelqu’un le faisait si cette règle venait à être mise en application ?
Au contraire, tous les communs (y compris la monnaie) gagneraient à fonctionner publiquement.
Une licence « propriétaire » est par définition privée…
Ce n’est une contrainte que pour ceux qui veulent tout contrôler sans partager…
Pour la dernière question, c’est de la responsabilité des certificateurs en premier lieu, mais aussi des utilisateurs…
Cette question devrait être abordée dans le cadre d’une communication de base comme j’en parle dans ma proposition de création d’un socle commun à tous.
C’est une bonne question qui mérite toute une réflexion. Pour le côté technique, @pini et @1000i100 seront plus à même de te répondre. Pour le côté « libriste » c’est à la communauté de se demander si des logiciels propriétaires interagissant avec la G1 peuvent en entraver les principes et dans quels cas. On pourrait dans cette réflexion différencier les logiciels permettant la certification de ceux permettant juste des échanges monétaires, etc.
Tout comme il n’y a pas encore de « loi » permettant de bannir une personne détenant plusieurs comptes co-créateurs de monnaie, il n’y aurait pas encore de loi si cette règle était adoptée et venait à être transgressée. Ce serait pour l’instant donc, comme le disait @1000i100, simplement une sorte de « sceau de non conformité » qui serait diffusé (mais par qui? Commité étique? Mouvement organique?) à propos du logiciel transgresseur. Mais ça établirait un précédent pour si un jour il y a « un organisme de loi juniste » quel qu’il soit.
@Moul, @Natha a dit l’essentiel, je reformule avec mes mots :
Selon moi oui : Permettre librement l’audit des app qui intéragissent avec la blockchain me semble un bon moyen de réduire les risques de détournement de fond et de perte de confiance associé.
L’usage de licence libre me semble aussi propice à l’ajout de fonctionnalité transverse via des merge-request à chacun des logiciels de l’ecosystème. Je pense notament à un système de notification unifié qui sera d’autant plus efficace qu’il est implémenté dans toutes les app de l’écosystème (ou au moins toutes celles répandue).
Enfin, politiquement, la décentralisation de la confiance me me semble aller dans le même sens que la décentralisation technique. Si on cherche à avoir un système qui ne repose pas sur une autorité centrale à la quelle il faut faire confiance, il me semble logique de ne pas faire une confiance aveugle à un éditeur logiciel sans pouvoir vérifier/auditer son travail de manière « décentralisé » (par des tiers indépendants).
Rien de techniquement contraignant, mais un opprobre social : Si c’est inscrit de ne pas le faire dans un texte validé par toute la communauté, il est bien plus simple de diffuser et d’emporter l’adhésion communautaire à boycotter l’app contrevenante. Si elle n’est pas ou très peu utilisé, c’est assez dissuasif pour l’auteur, quelles que soient ses intentions (sauf script pour usage perso).
Et c’est aussi un levier fort pour qu’une app initialement développée de manière propriétaire voie son code libéré : avoir le choix entre un relais communautaire pour faire la promotion d’une nouvelle app libre, ou le dénigrement et le boycott de son app si on la garde propriétaire, il faut avoir les reins solides et une intension de non partage robuste pour préférer la 2nd option.
Bref, c’est clairement un parti pris d’étendre la condition de liberté du code aux logiciels interagissant avec la blockchain plutôt qu’aux seuls logiciels permettant la certification, mais c’est un parti pris qui me semble bénéfique pour la communauté.
Tout contre-argumentaire est bienvenu pour identifier les tenants et les aboutissant de ce choix, et donc décider de le retenir ou non.
Merci pour vos réponses claires. Ça signifierait que cette règle s’appliquerait qu’aux apps qui gèrent à minima la toile de confiance principale ? Une app qui gèrerait par exemple uniquement des transferts ou l’exploration de blockchain ne serait pas mal vu au près de cette règle de la licence Ğ1 ?
Pour aller plus loin dans la réflexion, est-ce qu’imposer une licence copyleft ferait sens dans ce cas ?
En tant qu’utilisatrice du logiciel, personnellement, mis à part le respect des 4 liberté des licences copyleft, j’apprécie aussi le côté « pérennité » et évolution libre d’un programme efficace.
En effet. à choisir entre une licence libre simple et une copyleft de qualité équivalente, je n’ai aucune hésitation.
Cependant, étant aussi militante (définitivement et sans limite du LL ), mon point de vue n’est peut être pas tout à fait objectif…
Avec ce que tu mets après nous avoir remercié pour la clarté de nos réponses, j’ai un doute sur le fait qu’on ait été clair
Dans ma compréhension :
La v0.3.0 actuellement en vigueur informe uniquement que Duniter est un logiciel libre :
Pour plus de précisions dans les détails techniques il est possible de consulter directement le code de Duniter qui est un logiciel libre [src]
Ce que nous proposons, c’est que ça devienne une condition pour que les app qui interagissent avec la blockchain Ǧ1 soient conformes à la licence de la Ǧ1 que ces derniers soient en licence libre. Cela y compris s’ils ne permettent pas la certification.
Concernant la « publicité de la licence Ǧ1 » la version actuelle 0.3.0 demande :
Les logiciels Ğ1 permettant aux utilisateurs de gérer leur utilisation de Ğ1 doivent transmettre cette licence avec le logiciel ainsi que l’ensemble des paramètres techniques de la monnaie Ğ1 et de la TdC Ğ1 qui sont inscrits dans le bloc 0 de Ğ1. [src]
Ce que nous proposons c’est :
La licence renvoyant elle-même par son lexique aux règles et paramètres de fonctionnement de blockchain Ǧ1 et TDC Ǧ1.
Dans le cas où la checklist est validée, cette obligation pour les app d’indiquer où inclure la licence Ǧ1 devient :
sachant que « les questions de la checklist », avec les « Recommandation d’implémentation » pour les dev, revient à en afficher 5 à chaque certification.
), mon point de vue n’est peut être pas tout à fait objectif…