Packaging de la licence monétaire Ğ1

Que veut-on pour cette licence ?

L’objectif est-il d’obliger à créditer les auteurs quand le texte de la licence est repris ? d’interdire la réutilisation en non-libre ? serait-ce vraiment utile ?

La publier sous licence libre (même en permissif voire en domaine public) permet de supprimer toute ambiguïté, par rapport à l’absence de licence. L’intérêt du CopyLeft est moins évident ici.

Personnellement, c’est le genre de document que je mettrais en domaine public (CC0). Comme mon flyer pour la G1 qui est en CC0 (qui a pourtant représenté des heures de boulot), car c’est assez court, fait pour pouvoir être reproduit partout facilement, réutilisé par morceaux dans d’autres œuvres de propagande… Et si des gens le réutilisent en non-libre, ce sera quand même très probablement pour promouvoir la G1, donc peu importe.

En revanche, une interdiction qui pourrait avoir du sens serait d’interdire de publier une version modifiée sans en changer le titre, comme ça semble être le cas pour la GPL.

3 Likes

Oui, c’est le principe. Toute oeuvre forkée change le titre, sinon on est dans la contrefaçon (et donc la tromperie de l’utilisateur vis à vis de l’original, ce qui est mal)

2 Likes

Certes oui.

1 Like

C’est cela, la Ğ1 n’est pas Duniter (qui a sa licence). On peut très bien imaginer que la Ğ1 poursuive sa vie par copier/coller de la base de donnée (de la blockchain), gérée par un autre logiciel, voire même pourquoi pas qu’elle poursuive sa vie sous une forme 100% matérielle, ou toute autre type d’évolution.

Ne pas distinguer la monnaie du logiciel qui fait tourner la monnaie, revient à ne pas avoir réalisé la nature de la monnaie. D’où d’ailleurs la claire distinction originelle faite dans Duniter/Ğ1 que Bitcoin/Bitcoin a parfaitement ignoré, semant une confusion toujours d’actualité d’ailleurs (parler des propriétés cryptographiques et de la blockchain pour caractériser la monnaie, comme si cela lui donnait des qualités intrinsèques, et ceci sans mettre le doigt sur sa forme non-libre fondamentale, revient à semer le faux et la tromperie, et à ne pas traiter du sujet fondamental, lequel est le thème central de la TRM).

4 Likes

Je pense que non, pour les raisons largement expliquées précédemment où je me rend compte qu’une licence n’a pas de licence sur elle.

La GPL fait son boulot, et est versionnée en cas de grosse modification. La protection de la licence elle même ne fait pas l’objet d’une licence, et comme tu le mentionnes bien, est dans une simple FAQ.

Notre licence monétaire fait son boulot, et est versionnée en cas de modification. La protection de la licence elle même ne nécessite pas une licence, et comme pour la GPL, peut faire l’objet d’une mention dans une simple FAQ, ou mieux, dans la licence elle-même !

1 Like

A priori, c’était la licence par défaut ajoutée par npm init. Je ne me souviens pas avoir réfléchi à la licence pour la licence.

g1_monetary_license en CC-0 pour les gestionnaire de packets qui ont besoin d’associer une licence à chaque packets me conviens et me semble assez fonctionnel.

Et questionner la gouvernance des choix de modification de la licence me semble une excellent idée, et nécessite je pense un topic dédié.

Je n’avais pas pensé à cette contraindre de dépôt… C’est pas courant un dépôt pour une licence (mais c’est très bien, le site de la GPL fait un peu foutoir html à côté…). Il faut alors une licence qui ne rentre pas en conflit avec les recommandations de @galuel sur le nom et la contrefaçon, recommandations qui sont aussi celles de la FAQ de la GPL.

Et mettre ces recommandations directement dans la licence simplifierait le travail et la clarté de ce qu’il est possible de faire sur la licence.

La CC-0 ne me semble pas convenir.
En regardant Appendix | Choose a License et Non-Software Licenses | Choose a License la CC-BY-SA-4.0 et la GPL-3.0-or-later me semblent le mieux convenir. La GNU-FDL-1.3 n’est pas présente, de coup je ne saurais pas dire.

Bon, j’ai une petite fonction intégrée pour rendre le module Python plus facile à utiliser.
Du coup, je suggère GPL-3.0-or-later.

C’est ok pour moi, du moment qu’il est clair que c’est la licence du dépôt, pas du contenu du texte de la licence elle-même.

Je suggère donc d’ajouter, dans la licence elle-même, ce texte :

« Cette licence ne peut pas être modifiée en dehors du processus de création établit par les développeurs de Duniter et de sa monnaie la Ğ1. Elle peut néanmoins être modifiée sous un autre nom et pour une autre monnaie que la Ğ1. »

Qu’en pensez-vous ?

3 Likes

On peut ajouter cet en-tête à tous les fichiers de licence, par contre cet en-tête ne protège pas juridiquement ce contenu. Il faut utiliser une licence logiciel/œuvre de l’esprit bien définie qui encadre ce contenu.

La licence logicielle et la déclaration du droit d’auteur pourra être assigné à la Fondation Monnaie Libre une fois crée. Concernant, la gestion des évolutions du contenu de la licence, je laisse ça de côté pour ceux qui veulent s’en occuper. C’est pas le sujet de mon intervention sur le dépôt.

Voilà :

Je donne deux semaines pour la review. Jusqu’au 4 mai.
Je veux bien au minimum la review d’un développeur Python (@vit, @matograine) et d’un contributeur technique à l’écosystème Duniter/Ğ1 (@Galuel, @elois, @1000i100, @kimamila, @cgeek, @poka, @HugoTrentesaux, @tuxmain, @gerard94).
Qui se dévoue pour qu’il y ait une personne parmis ces deux groupes ?

Le dépôt de la licence monétaire Ğ1 ne devrait pas contenir des éléments techniques qui concernent des technos particulières, il devrait contenir uniquement le texte de la licence monétaire dans chaque langue et la licence du dépôt.

Tout ce python n’a rien à faire dans ce dépôt, c’est pareil pour le package.json d’ailleurs. Si vous avez besoin d’un « paquet » adapté à votre techno contenant la licence monétaire, vous devez le faire en dehors de ce dépôt, par exemple créer un autre dépôt pour ça et intégrer la licence monétaire via submodule ou tout autre moyen.

7 Likes

Pour quelle·s raison·s souhaitez-vous que le texte de la licence soit séparé du packaging et de son environnement ?

J’ai voulu intégrer cette fonction dans le dépôt pour que les autres clients Python puissent trouver le chemin vers ce module, pour lire la licence. Je peux la remettre dans Silkaj, si ça dérange trop, c’est juste dommage pour les autres clients Python. Ça peut aussi aller dans DuniterPy, mais je trouve que ça a plus ça place dans g1_monetary_license.

J’ai voulu en faire un paquet, pour que ce dépôt ne soit plus un subtree dans Silkaj. Mais, un dépôt unique qui génère des paquets Python, Npm, Debian, $Distrib intégrable dans tous les clients. Avec ta proposition, je me retrouve dans la situation dans laquelle je souhaite m’extirper, à savoir créer un autre dépôt pour le packaging Python, avec un subtree à l’intérieur. De plus, ça multiple les dépôts, car il en faudra d’autres pour le packaging dans les autres langages.

Je vois pas l’intérêt de séparer les énergies ainsi. J’aimerais qu’il y ait une bonne raison d’aller dans cette direction. Est-ce lié au choix de la licence logicielle et du contenu qu’elle encadre ? À la « gouvernance » de ce dépôt ? Ton message ne contient pas d’argumentation pour aller dans cette direction. Pouvez-vous argumenter ce choix.

1 Like

Je suis assez d’accord avec @elois. Il ne faut pas compliquer l’accès à la licence. Il faut le texte en plusieurs langues et c’est tout. Même le format Restructured Text .rst, (que j’affectionne particulièrement), me paraît superflu ici. Il faudrait revenir à un texte brut en .txt.

Je ne suis toujours pas convaincu du besoin d’une licence sur le dépôt qui tendrait à penser que c’est la licence de copie/modification libre de la licence, ce qui serait faux, car, comme toute licence, elle est rédigée de façon privée par un groupe de personne autorisée à le faire (comme toutes les licences les plus connues), et selon une gouvernance dont les règles sont établies par un règlement (généralement celui d’une association, entreprise ou fondation). Donc pas modifiable librement.

Si il y a besoin d’intégrer la licence Ğ1 dans un logiciel, un simple ajout dans le script de build ou de packaging du logiciel pour télécharger la dernière version du texte sur le dépôt permet de le faire. Cela ne disperse pas les énergies. Amha.

2 Likes

Et donc je serais censé rajouter du code Rust au dépôt de la licence monétaire pour l’intégrée proprement à ğcli et poka serait censé intégrer du code Dart au dépot de la licence monétaire pour l’intégrée proprement à Ğecko ?

Dsl, mais je trouve ça tout simplement délirant, si tu veux juste pas te faire chier avec un subtree, tu peux intégrer le texte de la licence via un script de build, son contenu ne change pas tout les 4 matins, et si un changement important du contenu de la licence monétaire surviens, chaque client peut publier un hotfix pour prendre en compte ces changements.

Tu inverses la charge de la preuve, c’est toi qui demandes (via une MR), d’ajouter du code python dans le dépôt de la licence monétaire Ğ1, c’est à toi de justifier ce choix.

Ce que je comprends de ta justification c’est que ça te simplifie la vie à toi par rapport à ta manière d’intégrer le texte de la licence monétaire dans silkaj, mais il n’y a aucune raison que la licence monétaire favorise les besoins de silkaj en particulier.

Et puis ce n’est pas conforme au principe Separation Of Concern.
La licence monétaire Ğ1 est agnostique du client Ğ1 utilisé et doit le rester (et par extension son dépôt).

Enfin comme le dit justement @vit , un contributeur au contenu de la licence monétaire Ğ1 (traduction, correction de typo, autre …) ne doit pas avoir à gérer du contenu spécifique pour telle ou telle techno.

2 Likes

À la fin, on aurait donc dans le même dépôt, des scripts, configs et autres manifests pour tout ça : JS, Python, Rust, Dart, Julia, Java, C, Arduino, Ruby, Debian, ArchLinux, RPM, Minetest…

Un peu comme si on mettait tous les bindings d’une même lib dans un même dépôt.

Si on veut vraiment tout mettre dans le même dépôt, il faudrait au moins séparer en dossiers, sinon ça va être le bazar, les différents outils risquent d’interférer, et le contributeur qui ne connaît pas une des technos sera perdu.

1 Like

De mon point de vue :

  • 1 dépôt avec uniquement la licence dans différentes langues.
    Un format .md ou .rst me semble acceptable en considérant que son affichage en tant que texte brut est satisfaisant. Si ce n’est as le cas, alors revenir au .txt me semble en effet plus agnostique et préférable.
  • 1 dépôt de publication qui ne contient que des script de build/publication pour chaque contributeur qui voudrait en faire un package dans son écosystème pour en faciliter l’intégration. Ce dépôt importerais le dépôt de licence et le décorerais avec le nécessaire d’usage pour son écosystème cible.
    Cela peut se faire avec une CI quotidienne qui si la version de la licence est identique à la cible déjà publiée, ne fait rien, et si elle est différente, poursuit le build et publication jusqu’à son terme.

Coté licence, le dépôt de la licence elle même, que ce soi du CC-0, du CC-ND ou CC-SA (ça n’existe pas mais c’est ça qui me parlerais) ou pas de licence autre que la licence elle même, ça me va.

Une licence impliquant de citer l’auteur de la licence à chaque usage me semble dommage, à moins d’inclure cet auteur dans la licence, et que ce soit une fondation.

Et du coup, GPL, FDL ou autre, si elle permettent de répondre au fait de ne pas avoir à lister tout les autreurs/contributeur de la licence, de la diffuser librement, y compris dans des logiciels dont la licence n’est pas libre et viral, ça me va. Si dès la licence on impose que tout les soft qui gère la certification soit sous licence libre viral, ça peut m’aller mais seulement après un débat pour mener à cette prise de décision de façon collective.

Le dépôt avec les script de build, une licence AGPL ou BSD like ou WTFPL ou CC-0, globalement ça m’est totalement égale. En revanche, les packets publié dans les écosystème cible devrait selon moi hériter d’une licence permettant les usages de la licence que je site plus haut, donc plutôt des licences très permissive (style CC-0, MIT…) plutôt que AGPL, GPL…, sauf à ce que l’obligation de garder tout les soft de l’écosystème qui gère les certifications en libre soit actée par la communauté. Et dans ce cas, la question d’en interdire l’usage commercial pourrais aussi se poser.

Bref, que pensez-vous de l’approche 2 dépôts ?

Que pensez-vous de mes réflexions en matière de licence ?

Êtes-vous d’accord que la licence Ǧ1 n’est nécessaire et donc ne défini le cadre que des logiciels gérant la certification ?
Les logiciels ne permettant pas de certifier qui que ce soit n’ont pas besoin de respecter ni d’inclure la licence Ǧ1 car il sont en dehors de son périmètre d’application.

1 Like

Il y a une infinité de façon de faire et des contraintes différentes pour chaque couple (techno, méthodologie).
C’est à chaque développeur de logiciel concerné de faire comme bon lui semble pour intégrer la licence Ğ1 dans son logiciel, parler de faire un package est déjà un cas particulier réducteur, mais cela n’est pas le sujet ici, merci de créer un autre sujet pour ça :slight_smile:

Si le dépôt de la licence monétaire ne contient que cette dernière dans chaque langue (ce que je souhaite), alors il n’y a effectivement pas besoin de licence associée au dépôt.

On ne peut pas imposer cela, car la licence monétaire n’est pas un logiciel, et n’a pas de licence logicielle associée. Où alors il faut inclure explicitement dans le texte de la licence monétaire des contraintes sur les logiciels permettant de gérer son compte Ğ1, ça me semble être une mauvaise idée, j’y suis opposé.

La licence Ǧ1 est également nécessaire pour les logiciels permettant de créer et publier un document d’identité sur le réseau Ğ1.

Il n’y aurait pas 2 dépôts, mais juste un seul dépôt qui contient la licence monétaire dans chaque langue. Le fait que certains dev de certains logiciels clients souhaite faire un dépôt pour packager la licence Ğ1 pour leur stack technique n’est pas le sujet ici.

1 Like

Voici une MR pour supprimer le paquet npm, merci aux utilisateurs de ce paquet npm de prendre leurs dispositions (le déplacer ailleurs où faire autrement) :

1 Like