Amendement de la charte pour l'allégement de la clause root et de la clause 100% libre

neil · Juin 21, 2023, 5:33

Bonjour,

Depuis plusieurs portées, de plus en plus de membres du collectif se prononcent en faveur de candidatures qui ne respectent pas systématiquement tous les critères requis par la charte, et notamment le critère « 100 % logiciel libre ». La récurrence de cette tendance semble s’affirmer au fil des votes :

10 votes pour, 10 votes blanc (total 36 votes) sur la candidature de RollenspielMonster (portée 14)
5 votes pour, 5 votes blanc (total 28 votes) sur la candidature de Paheko (portée 15)
15 votes pour, 10 votes blanc (total 51 votes) sur la candidature d’Osuny (portée 16)
En parallèle, des candidats qui utilisaient GitHub ou Updown.io (plateformes propriétaires) ont également été acceptés malgré ce critère.

Pourquoi modifier la Charte ?

Certains commentaires en réponse à des candidatures suggèrent que les idées qui ont mené à l’aboutissement de la charte dans sa version actuelle sont en décalage avec le contenu de la charte elle-même.

Fort heureusement, la charte n’est pas figée dans le marbre, on peut donc décider collectivement de la modifier afin qu’elle reflète mieux les intentions dans lesquelles elle a été rédigée.

De plus, certains CHATONS expriment la nécessité de suivre la charte à la lettre pour garder une forme de cohérence, plutôt que d’y déroger au nom des intentions que l’on prête à ses auteur·ices, et seraient à même de changer leur vote si la charte évolue.

Pour moi, cette proposition de révision est complémentaire (mais indépendante) avec celle de la révision de la liste de conformité proposée par Quentin de DeuxFleurs.

Portée

Pour s’assurer que le processus de révision de cette charte ne prenne pas un an et demi, je vous propose d’en limiter la portée à certains critères très spécifiques :

la question de l’utilisation des logiciels libres, de plateformes libres ou de formats ouverts par le CHATONS ;
la « clause root » ou du niveau de contrôle que le CHATONS doit avoir sur son infrastructure, qui est très liée.

L’idée est d’envoyer des modifications mineures sur deux ou trois critères, pas de réécrire la charte en entier. Une sorte de Charte V2.1 en somme.

À titre personnel, je pense donc que les modifications suivantes devraient être écartées dans le cadre de cette révision faute d’être trop importantes pour être facilement intégrées dans l’immédiat :

la création de « CHATONS amis », de MATOUS, d’un baromètre CHATONS, d’un label ou d’une certification CHATONS ;
les modifications portant sur le processus de décision, la gouvernance, le statut associatif, les conditions d’exclusion de membres du collectif, le pourcentage de votes pour/contre requis pour valider ou invalider une candidature…
j’exclus aussi de facto les révisions portant sur un durcissement des critères actuels. Merci de créer votre propre thread séparé pour cela.

Calendrier

Cette modification n’a pas besoin d’attendre la structuration juridique du collectif, d’autant plus que Angie a déclaré que le GT asso se mettait en pause pour l’instant. De plus, ces critères de la charte provoquent des polémiques et alimentent des tensions tous les 6 mois, ce qui semble appeler à un traitement rapide du problème.

Je vous propose l’agenda suivant pour étudier cette révision de la charte :

du 21 juin au 2 août : on échange ensemble sur les contraintes et enjeux de cette révision en suggérant des améliorations
du 3 au 6 août (Camp CHATONS) : on étudie les remarques émises jusqu’à présent et on compile une « proposition finale »
du 7 août au 15 septembre : on vote collectivement pour adopter ou rejeter cette nouvelle proposition. Si elle est acceptée, elle pourra entrer en vigueur dès la prochaine portée !

Bienveillance et écoute

Compte tenu de la teneur des discussions en la matière, j’appelle l’équipe de médiation ainsi que les personnes disposant des pouvoirs de modération sur ce forum à être intransigeant·es sur le respect et la bienveillance attendues de chacun·e dans cet échange, et je vous enjoins à faire usage de la Force™ si des personnes malintentionnées tentent de faire obstruction aux discussions.

Je suis conscient que l’objet de notre discussion porte sur des positions manifestement irréconciliables, que le dialogue ne semble plus être possible avec certain·es d’entre nous et que l’adoption d’une telle réforme pourrait amener certains CHATONS à quitter le collectif.

Mais je suis aussi intimement convaincu que si cette révision vient à aboutir, elle sera co-construite par des personnes qui auront le souci de l’écoute des autres, et proposeront des modifications qui conviendront à une large majorité de CHATONS et qui donneront au collectif une meilleure diversité et inclusivité.

Premières suggestions

Je commence avec une première suggestion de révision, sur trois critères. Elle est peu aboutie et perfectible, c’est normal, c’est un travail collectif et j’ai mes biais. Si vous trouvez mieux, je vous invite à participer à la discussion.

Section « hébergeurs », clause « root », critère requis

Version actuelle :

le CHATON doit avoir les accès administrateur (accès root) sur le système d’exploitation faisant fonctionner les services en ligne finaux ;

Problème constaté :

Comme l’ont souligné ljf et Quentin dans la candidature d’Osuny, ce critère exclut de facto certains modèles d’hébergement qui impliquent un niveau de maîtrise inférieur, que l’on peut retrouver dans les déploiements à l’échelle industrielle (Container as a Service, stack Kubernetes, CDN…) ou plus petite (serveur FTP sans accès root…).
Comme le soulevait Quentin de DeuxFleurs, les méthodes d’hébergement des infrastructures informatiques ont évolué, et ce critère n’est plus adapté à ces évolutions.

Proposition de solution :

le CHATON doit avoir un niveau de contrôle suffisant sur son infrastructure pour garantir la confidentialité des données hébergées ;

Explication de la solution :

Cette révision allège légèrement le critère, mais fait reposer plus de poids sur les épaules de la structure candidate, qui devra porter la responsabilité de démontrer que les données hébergées sont sécurisées et en lieu sûr. Pour cela, la structure devra s’assurer que son hébergeur n’a pas accès aux données, ce qui revient au critère 2 de la section hébergeurs « en cas de location de serveurs […], le CHATON doit s’assurer que le fournisseur s’engage contractuellement à ne pas accéder aux données ; »
Cela permet à des CHATONS de lancer des services de type « hébergement wordpress / nextcloud » sur un serveur FTP ou dans un service de gestion de conteneurs (Podman/Docker/Kubernetes), ce qui a du sens pour les infrastructures un peu plus industrialisées, à condition que la confidentialité des données soit toujours garantie.
Concernant les CDN : descends de tes grands chevaux tout de suite, chevalier GNU Cette suggestion n’a pas pour but de « légaliser tous les CDN au sein des CHATONS », mais d’en permettre le concept si la confidentialité des données de ses utilisateur·ices est préservée. Par exemple, plusieurs CHATONS dont Hadoly, DeuxFleurs et des FAI associatifs ont évoqué la possibilité de lancer un service de CDN CHATONS. Le candidat n’aurait donc pas la main sur le CDN, mais les données seraient quand même entre de bonnes mains (ou plutôt, entre de bonnes pattes).

Section « ouverts », clause « 100% logiciel libre », critère requis

Version actuelle :

le CHATON s’engage à utiliser exclusivement des logiciels soumis à des licences libres, au sens de la Free Software Foundation, qu’elles soient compatibles ou non avec la licence GPL. Concernant les microcodes matériels pour lesquels il n’y a pas d’alternatives libres fonctionnelles, les logiciels d’amorçages (BIOS), ainsi que tout composant matériel ou logiciel auquel le CHATON n’a pas accès, ce dernier s’engage à en diffuser publiquement la liste, ainsi que leur objet.

Problème constaté :

Plusieurs choses.

Le problème « 100 % logiciels libres » :

Certains services ou logiciels n’ont pas d’alternatives libres à ce jour qui permettent d’assurer un niveau de service identique, ou même convenable, avec du 100% libre. Par exemple : l’envoi d’emails à grande échelle ou certains outils qui répondent à des besoins spécifiques, comme des outils d’accessibilité ou Bugsnag. L’usage de ces outils propriétaires dont aucune alternative viable n’existe peut (et doit !) toujours être discutée et questionnée, mais ce critère ne laisse aucune place pour la discussion : c’est soit 100 %, soit rien.
Selon pyg, qui a rédigé ce même critère dans la V1 de la Charte, « Le 100 % logiciel libre doit être un horizon, un moyen. Et non une fin, une obligation. ». Si l’on veut d’une société libre, exiger le 100% logiciel libre en condition préalable et absolue est contre-productif, car le « libre » ne se limite pas seulement au logiciel.

Le problème de la licence FSF :

ljf soulève le problème que représente la définition de « licence libre, au sens de la Free Software Foundation » qui interdit techniquement l’usage de logiciels tels que ElasticSearch ou MongoDB qui pourraient utiliser des licences non compatibles FSF.
Personnellement, ça me pose problème d’élever la FSF comme autorité décisionnaire de ce qui est libre ou non, compte tenu de sa gouvernance pro-Stallman et de ce que Stallman représente aujourd’hui. (Et je ne veux pas débattre sur ce que Stallman est ou n’est pas, sur ce qu’il a fait ou n’a pas fait, je dis juste que ça me dérange et vous avez le droit de penser autrement.)

Le problème de la portée du critère :

La formulation « le CHATON s’engage à utiliser exclusivement des logiciels soumis à des licences libres » dépasse le simple hébergement de services, et peut s’étendre à toute son activité de CHATONS. Il n’y a pas de restriction sur la portée de ce critère et je trouve ça intrusif.

Proposition de solution :

le CHATON s’engage à utiliser autant que possible des logiciels libres sur son infrastructure, et se doit de lister sur son site web tout logiciel utilisé qui contreviendrait à ce critère ;

Explication de la solution :

Avec ce critère, la Charte impose que la structure candidate fasse de son mieux pour choisir le plus de logiciels libres que possible dans sa stack technique, et lui demande de lister dans une partie de sa documentation technique tout logiciel dont il aurait connaissance qui ne respecterait pas cettte condition.

Sur le « 100 % logiciels libres » :

Ce critère pose sur nous, membres du collectif, la responsabilité de vérifier que la structure candidate est de bonne foi. Si nous jugeons que l’outillage technique contient des logiciels propriétaires qui sont facilement remplaçables par du libre ou dont l’usage est superflu, et que le candidat ne souhaite pas s’améliorer sur ce point, libre à nous de sanctionner cet usage de logiciels propriétaires par le vote.
Ainsi, en vérifiant le respect de la charte, on n’applique plus un vote binaire, bête et méchant « tu as un logiciel pas libre = vote -1 », mais un vote d’appréciation, plus nuancé, qui nous laisse le choix de juger si telle ou telle dépendance logicielle est vraiment nécessaire ou non. Ce critère nous redonne le choix de la nuance, car les candidats ne sont jamais blancs ou noirs.

Sur le problème de la licence FSF :

Solution simple : on enlève la mention de la FSF. Ce qui relève de la définition d’un logiciel libre ou non est laissé à l’appréciation et au bon sens de chacun·e. Après tout, chaque libriste aura toujours sa définition de ce qui est libre ou non, peu importe l’avis de la FSF, l’OSI ou les autres groupes avec lesquels tout le monde ne sera jamais d’accord, et c’est peut-être pas plus mal de laisser cette liberté aux votant·es.

Sur la portée :

Facile : on ajoute « sur son infrastructure » pour spécifiquement désigner les serveurs qui font tourner ses services, et pas les outils personnels du CHATON par exemple.

Section « ouverts », clause « formats ouverts », critère requis

Version actuelle :

le CHATON s’engage à n’utiliser que des formats ouverts dans l’exercice de son activité d’hébergement ;

Problème constaté :

La portée de ce critère me semble beaucoup trop large et intrusive. « L’exercice de son activité d’hébergement » peut désigner des logiciels qui ne sont pas à destination des hébergé·es. Par exemple, si le CHATONS utilise Microsoft Excel sur son poste personnel pour sa comptabilité CHATONS, il enfreint ce critère (même si c’est mal d’utiliser Excel et qu’il ferait mieux d’utiliser Paheko, est-ce une raison de le sanctionner de la sorte ?
De plus, il a déjà été relevé que des outils comme OnlyOffice (qui permet d’éditer des documents Office en collaboration sur Nextcloud) peuvent enregistrer des fichiers en format propriétaires (.docx et consorts). Héberger une instance OnlyOffice, est-ce conforme à la Charte ? La question se posait sur le forum il y a deux ans.
Enfin, ce critère interdit au CHATON de proposer des formats propriétaires, même à côté de formats libres, ce qui me semble être une restriction disproportionnée. Un CHATONS qui propose un formulaire d’adhésion en .odt et en .docx pour garantir une meilleure compatibilité logicielle enfreindrait la charte.

Proposition de solution :

le CHATON s’engage à publier les documents adressés à ses bénéficiaires dans des formats ouverts ;

Explication de la solution :

Cette formulation réduit la portée du critère aux documents adressés aux bénéficiaires du CHATON et ne s’étend plus à ses documents internes.
Elle lève également l’ambiguité derrière l’usage de OnlyOffice vu que ce logiciel propose au moins un format ouvert (dont celui de LibreOffice), ce qui suffit à satisfaire ce critère.
Cette formulation retire l’exclusivité « n’utiliser que », et permet ainsi au CHATON de publier des versions de ses documents en formats propriétaires uniquement si une version alternative existe en format libre.

Pad de la Charte v2.1

(merci @ppom !)
https://md.picasoft.net/TT7py9htTmOZmvvMQ6aKPA?view=

À vous !

quentin · Juin 21, 2023, 8:57

Super Neil ton projet de révisions de la charte et tes 3 propositions, elles sont déjà très bien en l’état je trouve, et mettent le doigt sur les points sensibles qui sont ressortis des dernières candidatures. Je partage totalement ta vision de « cibler » les modifications pour avancer rapidement : pour ma part je considérerai ça comme une victoire si on arrivait à les transporter officiellement jusqu’à la charte, ne serait ce que pour se prouver qu’on (= les membres du collectif) est capable de le faire.

Les modifications que tu proposes me semblent laisser également plus de place à l’interprétation, aux débats, aux échanges, sur ces sujets qui sont sensibles, ce qui me semble être une volonté ayant émergée.

Je me sens par contre obligé de confesser une inquiétude : comment peut-on s’assurer que cette plus grande liberté d’interprétation proposée par la charte se transformera bien en des échanges et débats plus riches ? En effet, nous n’avions pas l’air d’être d’accord sur les sujets qui peuvent être discutés pendant une candidature (doit-on se baser sur l’audit + « jurisprudence » ou ), ni sur le sens que doit avoir notre vote (doit-on voter par rapport à la pertinence de la candidature selon nous ou la juger à l’aune de l’audit réalisé ?).

Je vois cependant Neil que tu y apportes un début de réponse dans ton message :

Ainsi, en vérifiant le respect de la charte, on n’applique plus un vote binaire, bête et méchant « tu as un logiciel pas libre = vote -1 », mais un vote d’appréciation, plus nuancé, qui nous laisse le choix de juger si telle ou telle dépendance logicielle est vraiment nécessaire ou non. Ce critère nous redonne le choix de la nuance, car les candidats ne sont jamais blancs ou noirs.

Peut-être qu’on pourrait extraire ce point là pour le mettre dans une motion un peu « attenante » qui préciserait un peu le comportement attendu lors du vote. Par exemple d’encourager les membres à prendre part au débat, d’interroger la candidature vis à vis du projet du collectif (via sa charte + manifeste), et de voter selon son ressenti de la pertinence de la candidature pour le collectif ?

Merci pour cette proposition et bonne soirée

ljf · Juin 21, 2023, 11:30

Section « hébergeurs », clause « root », critère requis

Quel niveau de confidentialité ?

Ça me semble très flou. La confidentialité par rapport à qui ? Si on héberge des écolos, faut-il garantir la confidentialité vis à vis de l’état ? Personnellement, je ne trouve pas raisonnable d’héberger des militant⋅es écolos sur des chatons OVH ou Hetzner.

Évidemment, on pourra en discuter dans les candidatures, mais je trouverais plus juste d’avoir un critère obligatoire qui correspond au modèle de menace du grand public et un autre recommandé (qui existe déjà) correspondant aux modèles de menace plus spécifiques. SI nous étions transparent sur les critères couverts, nous pourrions alors mieux orienter.

« Être root » semblait pensé comme « être hébergeur »

Si on utilise du PaaS type Scalingo ou un FTP sur un mutu, peut-on considérer que l’on a son infrastructure ? Que l’on est hébergeur ? Sera-ton sollicité en cas de requête LCEN ou est-ce que ce sera directement Scalingo ?

Pour moi la clause root n’était pas qu’une question de confidentialité, mais aussi d’avoir la main sur l’avenir du service proposé. Quid si on voit du CaaS sans que le chaton puisse ou ne sache migrer ailleurs ?

Proposition de solution alternative

Ajout de:

le chaton doit avoir un niveau de contrôle technique suffisant sur ses services et son infrastructure notamment pour garantir autant que possible la confidentialité des données hébergées ;

Suppression de:

le CHATON doit avoir les accès administrateur (accès root ) sur le système d’exploitation faisant fonctionner les services en ligne finaux ;

le CHATON doit informer ses visiteurs et visiteuses, utilisateurs et utilisatrices du degré de contrôle qu’il a sur son infrastructure ;

Passage en critère recommandé de

en cas de location d’infra (virtuelles ou dédiées), le CHATON doit s’assurer que le fournisseur s’engage contractuellement à ne pas accéder aux données ;

Section « ouverts », clause « 100% logiciel libre », critère requis

Remarques:

Je trouve ça intéressant de faire la compta avec LibreERP (Odoo) pour ReflexLibre ou avec COIN/Calc pour ARN. De fait, ça participe à protéger les données des usager⋅es de nos services.
Je ne serais pas super content, si une bdd était envoyée via wetransfer…
C’est difficile pour ARN d’empêcher ses bénévoles d’utiliser windows mac ou android si ça leurs chantent…
Je n’ai aucun soucis à imaginer l’usage d’un service tiers ou même proprio qui monitore des URLs, quel impact sur les données qu’on nous confie ?
Sur l’usage de réseaux privateurs, ARN a adopté depuis longtemps la charte du RAP qui pourrait être plus complète mais pause déjà une base: https://arn-fai.net/fr/blog/charte .

Proposition de solution alternative

Critère requis

le CHATON doit utiliser autant que possible des logiciels libres sur son infrastructure ainsi que pour le traitement des données hébergées, et se doit de lister sur son site web tout logiciel utilisé qui contreviendrait à ce critère. La validité de ces exceptions est laissée à l’appréciation du collectif ;

le chaton ne fais pas la promotion des réseaux sociaux publicitaires et évite de mettre du contenu exclusif sur les réseaux sociaux publicitaires

Critères recommandés :

le CHATON s’engage à utiliser autant que possible des logiciels libres dans le cadre de son activité

Section « ouverts », clause « formats ouverts », critère requis

Sur une ligne similaire:

Proposition de solution alternative

Critère requis

le CHATON s’engage à publier les documents adressés à ses bénéficiaires dans des formats ouverts ;

Critères recommandés :

le CHATON s’engage à n’utiliser que des formats ouverts dans l’exercice de son activité d’hébergement ;

neil · Juin 22, 2023, 9:35

Merci pour vos réponses

Tu as tout à fait raison de relever que ça ne peut marcher que si les CHATONS jouent le jeu. Et vu la longueur des threads de chaque candidature, j’ai tendance à croire que les débats sont déjà très riches et que ça marche plutôt bien. J’ai envie de croire qu’on peut assouplir la Loi et faire confiance aux votant·es pour vérifier l’esprit de la Loi.

Alors oui, il y aura toujours une bonne partie des CHATONS qui n’auront pas plus de 5 minutes à consacrer à chaque candidature et qui se limiteront donc à l’expression d’un vote. C’est à cela que sert la grille de conformité à mon sens. Il reste à savoir comment nous pourrons l’adapter à des critères qui ne sont plus binaires (case cochée ou pas) et qui nécessitent une évaluation qualitative, mais je pense qu’on trouvera bien comment faire

Section « hébergeurs », clause « root », critère requis

Plutôt d’accord avec ta remarque sur le flou concernant la « confidentialité ». On peut préciser un peu.

L’activité d’hébergement de services me semble très large, a beaucoup évolué pour changer de forme. Par exemple, je trouve qu’une structure qui propose un service d’hébergement de site web à des assos, en s’appuyant sur une offre d’hébergement de type FTP d’un autre hébergeur et en s’occupant de la maintenance/mise à jour du site, me semblerait avoir sa place parmi les CHATONS dans l’idée.

La question se pose à l’identique avec du VPS classique (ou même du dédié), donc root ou non. À moins que le CHATONS utilise LUKS sur son disque (et je ne pense pas que ça soit le cas de beaucoup de structures − et en excluant les méthodes qui consiste à extraire la clé de déchiffrement de la RAM), les données seront techniquement accessibles en clair par l’hébergeur.
Et oui, si une requête de la police passe par l’hébergeur plutôt que le CHATONS, on ne peut rien faire, on ne sera même pas au courant qu’il y en aura eu une. Le seul moyen de résoudre ce problème c’est de passer par l’autohébergement, or ça me semble effectivement démesuré d’avoir ce niveau d’exigence quand seulement 30% des CHATONS s’autohébergent.

J’ai tendance à croire que c’est plus facile de migrer depuis une infrastructure CaaS, où les volumes utilisés par les conteneurs sont clairement délimités, que sur une machine classique sur laquelle tout est installé sur la même machine. Pareil pour le FTP, l’accès étant cloisonné aux fichiers du serveur web. Je n’a donc pas l’impression que ça soit le problème.

Tout ça pour dire que je suis d’accord avec tes propositions.

Section « ouverts », clause « 100% logiciel libre », critère requis

Je pense que ce n’est pas envisageable pour tout le monde, en particulier en ce qui concerne les logiciels de la comptabilité qui doivent être « Bercy-compliant » au sein des entreprises. Si tous les chatons étaient des assos, j’ai envie de dire qu’on pourrait exiger du libre parce qu’il y a pléthore d’alternatives, mais ce n’est pas le cas des ERP d’entreprise (et Odoo ne convient vraiment pas à tout le monde).

Et puis, c’est plus compliqué de délimiter ce qui fait partie des logiciels utilisés « pour le traitement des données hébergées ». L’OS des bénévoles de la compta en fait-il partie ? Comme tu disais, difficile de les empêcher d’utiliser Windows/Mac (et objectivement, les passer sous Linux n’est peut-être pas ce qui va changer le monde).

Mais de toute façon, le critère écrit sous cette forme n’impose plus du 100 % libre quoi qu’il arrive, donc il reviendrait aux CHATONS de se faire leur propre avis pendant les votes, ce qui me semble très bien.

La question des réseaux sociaux pourrait faire l’objet d’un critère, étant donné que c’est une question récurrente dans les candidatures qui ont fait débat (certaines personnes ont reproché à Osuny d’utiliser LinkedIn, par exemple).

Remarque : J’ai lu la charte de la RAP et je me suis fait la réflexion qu’on ne coche pas les cases à La Contre-Voie. Notre position est plutôt d’encourager la tendance inverse : d’inviter les personnes du milieu du libre à venir sur les réseaux propriétaires plutôt que de sensibiliser les libristes déjà convaincu·es sur Mastodon, quitte à être plus actifs et actives sur les réseaux des GAFAM plutôt que sur Mastodon car il y a plus de travail de sensibilisation à faire − voir notre FAQ. (bon, ça, c’est dans l’idée : en pratique on n’y arrive pas, car on n’aime pas les utiliser non plus.)

Remarque générale : bien vu pour les critères recommandés, je n’y avais pas prêté attention.

ljf · Juin 22, 2023, 7:34

Moui enfin on peut très bien sensibiliser sur ces réseaux sans pour autant proposer du contenu exclusif qui nourrit la bête…

NB: J’ai proposé ce critère car pour certaines personnes le critère 100% libre (de la charte actuelle) s’applique aussi aux réseaux sociaux. Donc j’ai estimé que c’était dans le scope définit dans le sujet initial.

denis · Juin 23, 2023, 1:38

Tout d’abord bravo et merci pour ce travail ! J’imagine que que tu as dû te taper plusieurs fois la relecture des tickets de candidature, personnellement je ne crois pas que j’aurais su le faire. J’ai cependant 3 problèmes de fond :

je ne pense pas que les changements proposés soient juste une mise à jour mineure de la charte, par conséquent je ne vois pas de problème à ce que nous passions plusieurs mois à travailler à une v3 (on n’a qu’une seule portée tous les 6 mois, il n’y a pas d’urgence)
je suis partagé quant au fait de travailler comme si l’association n’allait pas exister
je crois que chaque reformulation n’est pas forcément nécessaire en prenant en compte que la structure a tout à fait le droit d’avoir une activité hors charte en plus de son activité chaton !

Par ailleurs, je préfèrerais qu’il y ait un thread de discussion par sujet, parce que d’une part je n’ai pas les capacités cognitives pour tout suivre en même temps (il y a pour le moment peu de réponses et je suis déjá perdu) et d’autre part je n’ai pas le même niveau de maturité pour chaque sujet, et pour chaque sujet j’ai plusieurs remarques et propositions à faire, je crains qu’un message en huit parties pour tout exposer ne soit jamais lu (sauf peut-être par des utilisateurs quotidiens du forum).

neil · Juin 23, 2023, 11:37

Bonjour denis,

C’est une mise à jour sur des critères particulièrement importants, c’est vrai. Pas mal de raisons me motivent à proposer de délimiter la prise de décision dans le temps et à limiter la portée des modifications :

Le timing tombe plutôt bien : on peut se donner un peu plus d’un mois de réflexion et d’échanges, puis le camp CHATONS est là pour rassembler une bonne partie des CHATONS et compiler l’ensemble dans une proposition que l’on peut voter.
Je ne pense pas qu’il y ait beaucoup plus d’évolutions sur un sujet en un mois ou en un an. Les personnes qui veulent essayer de changer la situation n’attendront pas deux mois avant d’intervenir sur cette question ; les autres, faute d’implication insuffisante sur le sujet, participeront à travers leur vote à la fin.
Je pense qu’il y a beaucoup de choses à revoir dans cette charte, notamment concernant l’accessibilité, la question internationale, la gouvernance… mais si on essaye d’appliquer toutes ces modifications d’un coup, on ne va jamais s’en sortir. Je pense qu’on est plus efficaces si l’on modifie la charte morceau par morceau, trois ou quatre critères à la fois. De plus, tous les critères que l’on aborde et tente de modifier ici sont interdépendants et/ou complémentaires, donc ça me semble pertinent de les modifier ensemble.
Laisser la situation telle quelle le plus longtemps possible va dans l’intérêt des personnes qui défendent le status-quo, qui préfèreraient noyer cette proposition par un débat sans fin.
Continuer dans cette démarche de rejeter les candidatures sur ces critères-là, c’est envoyer un mauvais signal aux futures structures candidates, et personne n’a envie d’avoir un débat polémique de 150 commentaires dans sa candidature. Ce n’est peut-être pas pour rien si nous n’avons eu que 3 candidatures (de dernière minute qui plus est) pour cette dernière portée, et cette tendance pourrait se poursuivre.
Yolo, on tente de caser ça en 3 mois et on verra ce que ça donne Si la proposition finale n’est pas adoptée par le vote, au moins, elle aura abouti à un résultat et on pourra se baser dessus pour les propositions suivantes. On n’a rien à craindre d’essayer de faire bouger les choses. Et je ne crains pas le vote.

L’année dernière, il y avait déjà un atelier « révision de la Charte » au camp CHATONS, encadré par Angie, qui portait sur la totalité de la charte. On n’a pu aborder que quatre ou cinq critères en une heure et demi, et de mémoire, l’atelier s’est conclu par : « bon, il y a beaucoup trop de modifications à traiter, peut-être qu’il vaut mieux attendre le statut associatif ». Il aurait fallu trois jours pour faire une première passe complète.

Un an plus tard, le GT asso annonce se mettre en pause pour une durée indéterminée faute de manque d’implication des membres du collectif.

Que gagnerions-nous à attendre deux ans de plus pour que les membres s’impliquent dans la structuration associative du collectif ? Les membres seront-ils plus impliqués dans un an ? Compte tenu le nombre de CHATONS inactifs, les candidatures qui tendent à diminuer et les débats polémiques qui pourraient faire fuir les nouvelles structures, j’admets que j’ai des doutes.

Par contre, si l’on révise la charte, peut-être qu’on pourra accueillir des structures qui ne sont pas raccord avec la charte actuelle, et qui pourront participer à la structuration associative.

J’ai l’impression que cette idée d’avoir « des activités hors charte en marge de l’activité CHATONS » mène à des suggestions très alambiquées. Par exemple, pour la candidature de RollenspielMonster qui proposait une quinzaine de services libres + un TeamSpeak, il lui a été suggéré de créer une deuxième structure à côté de son CHATONS spécifiquement pour héberger le TeamSpeak, avec par exemple un nom de domaine différent et un site différent juste pour le TeamSpeak (suggestion qui me paraît complètement aberrante et complexe à mettre en œuvre pour pas grand-chose).

Ce ne serait pas une simple reformulation, donc. Ça reviendrait à autoriser l’utilisation (très limitée, minutieusement contrôlée et à l’appréciation des votant·es) de logiciels non-libres comme partie intégrante de l’activité CHATONS de la structure. C’est faire en sorte que ce cas d’usage soit permis par la Charte, en permettant aux membres CHATONS de contrôler d’eux-mêmes l’adhésion aux idées qui nous rassemblent.

Vu que la discussion devrait durer un mois et 10 jours (et pas plus), je pense qu’on peut essayer de tout mettre sur le même thread, d’autant plus que les notions abordées sont complémentaires, et qu’étendre la discussion sur plusieurs threads pourrait rendre les échanges justement plus difficiles à suivre. On verra à l’usage.

De toute façon, il y a de grandes chances que l’élaboration de cette proposition ne soit travaillée que par la minorité de celles et ceux qui ont le temps de s’impliquer dans le collectif et de lire le forum. C’est malheureusement souvent comme ça. Cela dit, le vote sur la proposition finale sera collectif, ce qui permettra donc aux personnes qui n’ont pas le temps de suivre d’avoir leur mot à dire.

J’attends donc avec impatience ton message en huit parties

kaiyou · Juin 23, 2023, 12:18

Bonjour et merci neil et auteurices des premières réponses pour le temps passé. J’imite ljf et réponds point par point aux propositions.

Sur la temporalité : il faut aller vite et petit. Au risque de citer encore un personnage décrié :

Release early, release often

Section « hébergeurs », clause « root », critère requis

Entièrement en phase avec l’analyse de neil, et j’y aurais instinctivement ajouté des exemples, notamment le besoin de contractualiser ces garanties dans le cas de dépendances à un tiers. C’est pourquoi la formulation de ljf me semble être sur la bonne voie.

Il faut pour autant rester réaliste : un fournisseur ne s’engage pas contractuellement à ne pas accéder aux données en France. Il s’engage à n’y accéder que dans les cas déterminés par la loi, notamment sur réquisition d’un juge. Une formulation plus raisonnable me semblerait être :

en cas de dépendance à un tiers pour le fonctionnement des services (location d’infrastructure virtuelle ou dédiée, hébergement de nom de domaine, etc.), le CHATON doit rechercher les meilleures dispositions contractuelles pour la protection des données hébergées et documenter publiquement ces garanties ;

Section « ouverts », clause « 100% logiciel libre », critère requis

De même en phase avec l’analyse, et entièrement aligné avec la proposition complétée par ljf.

Section « ouverts », clause « formats ouverts », critère requis

Il me semble sur ce point qu’on rate le sujet, ou bien j’interprète mal la charte en l’état. L’enjeu n’est-il pas bien plus large que la communication de documents avec les bénéficiaires ? Il me semble couvrir les formats de stockage et d’export de la donnée, voire les protocoles employés pour partie.

Je n’ai pas de proposition de reformulation à ce stade, voyons déjà si je fais fausse route dans l’interprétation.

Section « alternatifs », clause « libertés fondamentales », critère requis

Je me permets de l’ajouter, possiblement à ignorer puisque l’intérêt de la clause est très difficile à contester, bien que restons francs : elle est inapplicable par la majorité des CHATONS.

le CHATON s’engage à prioriser les libertés fondamentales de ses utilisateurs et utilisatrices, notamment le respect de leur vie privée, dans chacune de ses actions ;

Hors c’est un fait, dans certaines situations, nous plaçons les libertés fondamentales au second plan, an particulier lorsque la loi qui s’applique à nos structures justifie de ces privations de libertés. Exemple classique plutôt sur la liberté d’expression que la vie privée : l’article 11 de la DDHC impose une limite à la liberté d’expression. Nous hébergeurs (pour les CHATONS sous droit français du moins), notamment soumis à la LCEN, sommes directement impactés par ces considérations, qui prévalent sur le droit fondamental à l’expression.

Nous pourrions renvoyer à la DDHC comme fondement pour les libertés fondamentales, le fait est qu’elle est qu’elle est peu explicite sur les considérations de vie privée. Peut-être devrions nous toutefois renvoyer à la DUDH si ce n’est pas jugé trop pompeux. Elle affirme ce que sont les libertés fondamentales et explicite (de manière plus générale et plus détaillée que la DDHC) que leur exercice demeure encadré par la loi (article 29).

La formulation pourait être ainsi modifiée :

le CHATON s’engage dans chacune de ses actions à tenir compte des libertés fondamentales de ses utilisateurs et utilisatrices, au titre de la Déclaration universelle des droits de l’homme de 1948, notamment de l’article 12 consacrant le droit à la vie privée et de l’article 19 consacrant le droit à la libre expression.

neil · Juin 23, 2023, 12:39

Merci pour tes précieuses remarques ! On est sur la bonne voie

Tout à fait d’accord. Pour autant, cette modification ne porte pas tout à fait sur la clause root, mais sur le critère juste après dans la section Hébergeurs qui parle des modalités de l’engagement contractuel.

Concernant cette suggestion ainsi que celle que tu as ajouté en fin de message sur la clause « libertés fondamentales » : je ne sais pas si ça vaut le coup d’étendre la portée de cette révision aux questions légales (c’est-à-dire : ce que le CHATONS s’engage à faire à travers la Charte mais ne peut pas légalement tenir). Qu’en pensez-vous ?

Je pense qu’on peut peut-être trouver d’autres critères qui ne sont pas légalement tenables dans ce genre, mais comme tu l’as dit, peut-être vaudrait-il mieux aller « vite et petit », et garder les questions légales pour la révision suivante ? La question est totalement ouverte et d’ailleurs, je serais intéressé d’avoir l’avis de @ljf à ce sujet puisqu’il a également émis une suggestion sur cette question légale.

Personnellement, s’il y a consensus là-dessus et que ça ne nécessite pas de modifier trop de critères, je dirais qu’on peut l’intégrer dans la portée de la révision.

On pourrait poser la question à ses rédacteur·ices, mais j’aurais tendance à dire que cette question est déjà couverte par un autre critère dans la même section et donc, déjà répondue :

le CHATON s’engage à faciliter la possibilité pour les hébergées à quitter ses services avec les données associées dans des formats ouverts ;

ppom · Juin 23, 2023, 3:40

Hello ! Cette évolution de la charte est bienvenue, merci pour votre travail !

Je vous propose d’ajouter vos prochaines propositions de modification à ce document partagé : Révision de la Charte CHATONS : v2.1 - CodiMD . Y figurent les parties de la charte qui sont discutées et vos propositions.

J’espère que ça nous aidera à y voir plus clair.

ljf · Juin 23, 2023, 4:04

Ni Hetzner, ni OVH ne propose à ma connaissance de tels engagements, difficile donc de garder ça en requis au vu de la composition actuelle du collectif.

Pour moi c’était dans le scope de ce topic car ce critère spécifie directement « VPS et dédié », hors si d’autres formes d’hébergement de code sont finalement acceptées par le biais du retrait de la clause root (mutu, container), il semble nécessaire d’adapter ce critère aussi.

Je me rends d’ailleurs compte que j’ai laissé l’ancienne formulation et j’approuve la formulation de @kaiyou

J’étais justement en train de faire la même chose

ljf · Juin 23, 2023, 5:11

Les redites

Bon, en relisant l’ensemble sous forme compilée, je trouve que notre charte est quand même très verbeuse et longue. Exemple, nous pourrions probablement fusionner d’une façon ou d’une autre:

en cas de dépendance à un tiers pour le fonctionnement des services (location d’infrastructure virtuelle ou dédiée, hébergement de nom de domaine, etc.), le CHATON doit rechercher les meilleures dispositions contractuelles pour la protection des données hébergées et documenter publiquement ces garanties ;

ET

le CHATON s’engage à éviter l’utilisation des services de fournisseurs - informatiques ou non - dont les pratiques sont incompatibles avec les principes de la présente charte, notamment en termes de préservation et de captation des données privées. Le cas échéant, le CHATON en informe ses utilisateurs et utilisatrices.

Précision libertés fondamentales

Pour moi c’est en dehors du scope, ce critère n’a jamais bloqué les candidatures lors des audits au prétexte que « la charte dit qu’il faut » alors que les votants aurait peut être voter différemment sinon… (cf message initial de neil).

Bon après je suis moi-même très tenté de proposer d’autres choses… AAAAAAAAAAAAAAAAHHHHHHHHHHHHHHH

Meewan · Juin 23, 2023, 7:44

Juste un petit point pour les auto-hébergeurs (je crois qu’on est assez nombreux mais souvent c’est des tout petits chatons)

La question de la porté de la clause sur les logiciels lires se pose:

Le routeur est doit il utiliser un logiciel libre ? (dans ce cas la plupart des chatons auto-hébergés ne respectent pas la charte)
et les firmware ? (dans ce cas je pense que quasiment aucun chaton n’est dans les clous)

En dehors des FAI associatifs et de OVH (qui est hors de prix) les FAI font tout pour empêcher de remplacer leur box par des routeurs classiques (notamment en évitant bien soigneusement de fournir les informations technique dont on aurait besoin pour ça). D’un point de vue de l’utilisateur ça ne change pas grand chose puisque les données sont chiffrés au niveau du serveur WEB et le routeur ne les vois jamais en clair.

Bien entendu je doute que quelqu’un propose d’imposer des firmware libres, je ne l’ai mis que comme exemple si on veut le pousser a l’extrême, mais je pense qu’il serait intéressant, sinon de poser des une liste des cas acceptables au moins qu’on se pose collectivement la question.

Pour les logiciels de supervision publique le problème est a mon sens le problème est complexe::

il est impossible pour un chaton avec un seul serveur de mettre en place cet outil (il faut forcement un deuxième serveur sur un réseau différent)
les options libres sont… limités voir inexistantes (Chez katzei nous utilisions statping qui n’était plus maintenu, maintenant nous utilisons statping-ng qui n’est plus maintenu non plus¹)
c’est une brique par laquelle les données des utilisateurs ne passeront jamais².

¹ On avait commencer a développer une alternative au sein de katzei mais les membres n’ont pas le temps/l’énergie pour ça
² Je ne suis pas favorable a permettre les supervision publiques privatives mais je comprend pourquoi certains⋅es font ce choix.

denis · Juin 26, 2023, 12:39

Je réponds à ce qui est déjà présent dans ce fil de discussion, parce que je suis connecté à titre exceptionnel via un dispositif clavier/souris. Mais clairement il est impossible de participer à ces débats en utilisant d’autres dispositifs (le téléphone mobile en ce qui me concerne, mais aussi les lecteurs d’écran ou le client e-mail…)

Il ne serait pas plus simple de commencer par la définition des enjeux et de ne choisir une formulation ensuite ?

Je crains que « un niveau de contrôle suffisant » soit interprété comme « les accès root », du coup l’objectif d’éviter les débats dans les candidatures ne serait pas atteint. Je pense que c’est le mot « infrastructure » qui cause le plus de problèmes dans ce critère de la charte.

Je ne comprends pas ce qu’est un « serveur FTP », as-tu un exemple ?

Pareil, je ne comprends pas ce dont il s’agit dans un contexte où la charte serait bloquante pour rendre ce type de service

Du coup on ne pourrait pas simplifier directement la charte pour postuler que le candidat chaton n’a pas à rendre de compte pour son usage de services qui sont fournis par des chatons ?

Si c’est la FSF qui pose problème, on peut changer pour la SPI qui est constamment mise à jour

C’est faux. Il n’y a qu’une seule définition de logiciel libre, c’est le respect des 4 libertés. Si certaines règles posent problème on peut utiliser une autre définition, mais pas appeler ça « libre ».

J’aime bien cette formulation, telle qu’elle est écrite (sauf sur son infrastructure que je remplacerais par dans son infrastructure). Mais je ne vois pas l’intérêt de ne pas mettre une référence (la FSF, la FSFE, la SPI, l’OSI, un décret du premier ministre ou une catégorie wikipedia, …) si l’objectif est d’éviter un débat à chaque candidature.

Je comprends la nécessité de remettre en cause le premier item, mais qu’est-ce qui pose problème dans le second ?

je suis d’accord avec la formulation proposée par @ljf

Profitons alors de cette amélioration de la charte pour préciser cela, ça me semble 100 fois plus souhaitable qu’une référence au « bon sens » comme on a pu lire plus haut !

Désolé je m’arrête là pour les réponses, je n’en suis qu’au 4ème message et j’y ai déjà passé plusieurs heures : il me semble impossible de travailler comme ça.

neil · Juin 26, 2023, 4:01

Merci pour ton message, et merci de te prêter au jeu

Ce qui me semble être un problème, c’est justement la mention explicite d’accès root, qui ne laisse pas de place pour d’autres systèmes dans lesquels un CHATONS ne disposerait pas ces accès.

Pour prendre une offre d’un géant français connu, il y a l’hébergement web mutualisée d’OVH. Un CHATONS qui utiliserait ce type d’hébergement dispose d’accès FTP pour y déposer ses fichiers sur le serveur web d’OVH, ainsi que d’un accès à une base de données (sur une instance de MySQL mutualisée également). Dans ce cas-là, le CHATONS ne disposerait pas d’accès root.

On peut sans doute trouver un meilleur mot pour « infrastructure » s’il pose problème.

Pour reprendre un géant français, Scaleway propose des services pour gérer un environnement Kubernetes (et OVH propose un service similaire). D’autres hébergeurs proposent l’hébergement de conteneurs (un peu comme le présente le géant américain Heroku). Dans ces cas-là, le niveau de contrôle est plus étendu qu’un simple accès FTP, mais il n’y a pas de droits root non plus.

Je pense qu’on peut trouver d’autres cas d’hébergement dans lesquels l’accès root n’est plus une nécessité pour fournir des services. Pour information, le post de @quentin dans la candidature d’Osuny a déjà bien déblayé le sujet.

Ça signifierait interdire l’usage de ces services en dehors de ceux hébergés par des CHATONS. Ça me semble problématique car 1. Pour le cas des CDN, actuellement, aucun CHATONS ne propose ce service ; et 2. on peut rencontrer des « hébergeurs éthiques » qui pourraient tout à fait être compatibles CHATONS, mais qui ne font pas partie du collectif (et/ou n’ont pas envie d’en être).

Je ne suis pas d’avec toi, je pense que ce que l’on appelle « logiciel libre » aujord’hui a beaucoup évolué ces dernières années. ~~Je me retiendrai d’entrer dans un long monologue pour justifier ma position, mais~~ (edit: raté) je te réfère aux réflexions d’autres personnes que moi sur la question, en tâchant de résumer leur position (au risque de mal traduire leurs propos…) :

Les 4 libertés et le Libre face à la réalité des usages modernes - aeris, PSES 2019 − aeris avance que les 4 libertés de Stallman ne sont plus suffisantes pour garantir les libertés numériques des utilisateur·ices, et suggère de les refondre pour les adapter au monde moderne (29:10), notamment en lui ajoutant des critères de respect de la vie privée (privacy by design) ou des questions d’éthique ;
Contributopia : Peut-on faire du libre sans vision politique ? − pyg, Capitole du Libre 2018 @pyg commence sa conférence en présentant la définition qu’en donne Framasoft avec l’équation suivante : logiciel libre = open-source + valeurs éthiques et sociales (en précisant que les quatre libertés restent toujours valables). C’est par ailleurs cette équation que nous utilisons aujourd’hui pour présenter le logiciel libre à La Contre-Voie (on ne parle plus du tout des 4 libertés depuis au moins trois ans). pyg creuse par ailleurs la question de la nécessité du logiciel libre ici ou là ;
La création de la Hippocratic Licence (et ses dérivées) a peut-être aussi également contribué à remettre en question ce que nous attendons d’un numérique libre aujourd’hui.

Veut-on d’un logiciel « libre » au sens des quatre libertés de Stallman, qui approche la question uniquement sous des angles techniques et juridiques, ou d’un logiciel « libre » au sens libérateur / émancipateur (des personnes, de la société), qui prend aussi en compte des questions éthiques et sociales ?

Je suis conscient qu’on ne résoudra pas cette question dans l’immédiat. Mais une chose me semble à peu près sûre : tous les CHATONS n’ont pas la même définition de « logiciel libre », auquel cas il faut d’autres termes, d’autres référentiels pour expliciter ce qui nous rassemble.
Le moyen le plus simple que j’ai trouvé jusqu’à présent, c’est de ne plus utiliser une structure de référence qui va définir ce qu’est un logiciel libre à notre place (ex: la FSF, l’OSI ou la SPI) puisque tout le monde n’est pas d’accord sur cette définition et que pour moi, ça revient à poser la question de la couleur de l’abri à vélos.

Et oui, ça laisse place à plus d’interprétation et plus de débats dans les candidatures, et je pense que ce n’est pas un mal, car même si on est pas toujours d’accord sur les moyens, je pense qu’on est d’accord sur les idées

Cpm · Juin 27, 2023, 2:45

Non. La définition du logiciel libre a été fixée il y a quarante ans et n’a pas changé. On peut vouloir la critiquer, la compléter ou l’amender, mais ça n’a pas de sens de vouloir la nier. Et à nouveau concept, nouveau nom. Le meilleur exemple est l’open-source qui a trouvé un autre nom pour faire passer d’autres idées. Donc invitation à trouver un autre nom et d’en faire une définition différente. Sérieusement, évitons les confusions, changer le sens des mots rend impossible la communication, ça serait dommage.

Désolé mais cette phrase semble nier quarante années d’Histoire et de littérature conceptuelle. Depuis le début, le logiciel libre est un mouvement social qui lutte pour la liberté et la justice, promeut l’entraide, encourage le partage de la connaissance et est éminent émancipateur. Ce mouvement ne se limite pas à ses licences qui d’ailleurs ont évoluées dans le temps pour s’adapter aux nouveautés de l’informatique.
Références :

S’il faut d’autres termes alors pourquoi nier la définition historique ?
Ne faudrait-il pas inviter les chatons dans l’erreur à découvrir qu’une définition historique existe déjà ?

Sauf qu’historiquement, la définition a été faite avant nous donc quel sens cela a-t-il de la nier ça ?

Il semble que non. Et comment débattre sur des idées si les définitions sont floues voire différentes pour chacun ?

garthh · Juin 27, 2023, 5:57

Bonjour,

le CHATON doit utiliser autant que possible des logiciels libres sur son infrastructure ainsi que pour le traitement des données hébergées, et se doit de lister sur son site web tout logiciel utilisé qui contreviendrait à ce critère. La validité de ces exceptions est laissée à l’appréciation du collectif ;

Alors, jusqu’où va-t-on ? L’histoire de MongoDB par exemple est assez discutable, si l’OSI ne la reconnaît pas comme une licence libre, l’impact du changement de licence reste nul pour les CHATONS à mon sens. De mon point de vu, la licence de MongoDB est une licence libre.

Quels critères pour considérer qu’un logiciel « n’a pas d’alternative libre » ? Un cas, dans l’association, nous sommes bloqué sur le service pour faire des parties en ligne. A ce jour, les ténors du domaine sont des services tiers plus ou moins respectueux (transferts hors-UE, stockage des données sur des Cloud GAFAM…) et se distingue un logiciel « non-libre » appelé FoundryVTT qui est proposé sous forme d’une application JS hébergeant son serveur de jeu. Il peut être exécuté sur son poste, mais aussi sur un serveur. Les sources sont accessibles dès qu’on a payé le logiciel, mais il n’est pas diffusé sous licence libre un grand nombre de modélisation de systèmes de jeu sont diffusés sous licence libre (https://foundryvtt.com/article/license/). Le logiciel libre équivalent, Rolisteam, est inutilisable et plus ou moins abandonné… dans ce cas : prévoir que le CHATON dispose de la maîtrise totale des données de ses utilisateurs est je pense le pré requis le plus important. Il faudra donc que le candidat démontre qu’il est maître des données, qu’aucun transferts non maîtrisé existe (par ex, une exfiltration des données pour analyse sur un service tiers… bonjour Akismet de Wordpress) et qu’il n’existe pas d’alternatives open-sources cohérente et crédible à ce jour.

Après, est-ce qu’on tolère des services comme Teamspeak alors que pour le coup il y a pléthore de logiciels libres qui en font tout autant et aussi bien. Le risque… avec tout ça, on pourrait faire passer un Microsoft Office Online Server pour parfaitement clean et tolérable (qui même On Premise cause à papa sans cesse depuis le navigateur client… perdu pour la souvraineté numérique et le non-partage de données hors-UE).

le chaton ne fait pas la promotion des réseaux sociaux publicitaires et évite de mettre du contenu exclusif sur les réseaux sociaux publicitaires

Totalement, je pense que ce point de vue reste pour moi rédhibitoire. Par contre, la notion « réseau social publicitaire » me dérange. Il faudrait l’étendre et apporter plus de précision, sinon, le moindre « serveur Discord » ou « chaîne Youtube » pourrait devenir un point de communication tolérable pour un CHATONS. Pour rappel, Discord se vente de ne pas diffuser de publicité… mais appartient à Tencent et partage ses données avec ses financeurs (donc, Tencent). La diffusion prioritaire et systématique sur un espace libre et accessible doit être un pré requis « de base ».

Les conditions devraient être que les points de communication numérique ne doivent pas imposer à leur simple visiteur, la détention d’un compte pour accéder aux informations (Discord, Instagram, Facebook, LinkedIn où, même ceux qui n’impose pas la création d’un compte rapidement le suggère de façon très insistante) et n’expose aucune donnée personnelle du visiteur à la plateforme de diffusion autre que les données strictement nécessaires pour fournir le service (en gros, l’IP… le reste : pas de pub, pas de cookies tiers, par de pisteurs intersites, hoho, Youtube). Bref, aller causer CHATONS sur Facebook, ça permet de sensibiliser 2/3 de la population française, mais il serait quand même bien que l’info se trouve aussi ailleurs en intégralité. Disposer de points de communication sur le Fediverse devraient être une obligation.

Pour Osuny, la seule source d’information était LinkedIn au moment de mon vote. Si on juge que Facebook est l’enfer… LinkedIn est l’abîme sans fond menant directement aux sources du mal le plus absolu Par contre, je ne voie pas de mal à ce qu’un CHATON double exactement sa com’ sur LinkedIn et sur Mastodon (et si les afficionados de LinkedIn peuvent ne pas venir transformer Mastodon en LinkedIn2, c’est pas trop mal non plus… de toute façon, la grande majorité des chartes interdisent la pub et le démarchage… soit 99% des contenus de LinkedIn).

le chaton doit avoir un niveau de contrôle technique suffisant sur ses services et son infrastructure notamment pour garantir autant que possible la confidentialité des données hébergées ;

Ça, c’est mon quotidien pro de DPD d’un service de l’état qui a l’obligation de souveraineté numérique (doctrine Cloud au Centre et SecNumCloud). Je ne compte plus le nombre de sous-traitant qui nous explique qu’un simple DPA permet de transférer des données hors Union européenne. Je vais remettre ma casquette de militant : le point sur lequel le Privacy Shields a été invalidé par Schrems est l’accès aux données aux services de renseignements US… Cessons d’êtres hypocrites, le vrai problème reste l’alimentation du big data des annonceurs publicitaires totalement légal aux US (et je peux même mettre ma casquette de militant écolo : est-ce qu’on a encore la légitimité de rejeter du CO2 pour traiter des données publicitaires ?).

Donc, si un DPA avec AWS ou Azure donne au RT la possibilité d’être dédommagé et informé en cas d’accès aux données par les autorités administratives américaines, ça reste très cool sur la transmission de n’importe quelle données « anonymisée » (oui, enfin… un profil sans le nom, c’est pas de l’anonymat pour le RGPD) à un repreneur, un partenaire commercial ou toute société liée.

Installer son OS, chiffrer son HDD et être le seul à avoir le compte root reste la seule garantie à ce jour pour s’assurer que personne n’accède aux données… ou être hébergé en Europe chez un hébergeur qui est soumis aux mêmes lois que nous.

« garantir autant que possible la confidentialité des données hébergée » demandera à rédiger une grille d’évaluation très précise sur le sujet. Si vous avez besoin, je peux y contribuer.

Pour l’histoire du CDN « respectueux », je suis à fond pour ! Et, ça serait intéressant de commencer à réfléchir à des communs numérique : serveur TURN/STUN… et pourquoi pas des data centers mutualisés éco-responsables et low-tech ?

quentin · Juin 27, 2023, 9:29

Proposition pour une vraie et exigeante application du libre

Le problème du SaaS(S) : Aucun membre du collectif CHATONS n’est hébergeur dans le sens où il propose à la location des serveurs physiques. À la place, les membres du collectif CHATONS proposent du SaaS, Software as a Service, ou comme le souligne plus justement le projet GNU, du SaaSS, Service as a Software Substitute (la précision est importante). La Free Software Foundation et le Projet GNU sont très clairs sur ce point, en un slogan : « it’s just other people’s computer ».

sticker "there is no cloud, just other people's computer

With SaaSS, the server operator can change the software in use on the server. He ought to be able to do this, since it’s his computer; but the result is the same as using a proprietary application program with a universal back door: someone has the power to silently impose changes in how the user’s computing gets done.

SaaSS is equivalent to running proprietary software with spyware and a universal back door. It gives the server operator unjust power over the user, and that power is something we must resist.

La vieille question du contrôle des machines. On peut voir que le point sur le SaaS remue la vieille question du contrôle des machines. Là encore, je pense que pouvoir une démarche sur le libre sincère et juste, afin de ne pas dévoyer le concept de libre, il faut s’en remettre à ses tenants dont RMS. En 1982, il refusait de mettre un mot de passe sur son compte utilisateur. En 2012, il disait de même pour les WiFi. RMS a été très clair que d’avoir des systèmes avec des contrôles d’accès différenciés permettait à l’opérateur-ice de la machine de prendre le contrôle sur les usager-es, exactement de la même manière que le logiciel propriétaire cachant son code, permettait au développeur d’arracher du pouvoir sur ses usager-es.

https://www.oreilly.com/openbook/freedom/ch07.html

Pour 2012 je ne peux pas publier le lien car la vidéo est sur une plateforme privatrice.

On peut entendre ces propos aussi dans le docu « la bataille du libre » de Borel (bien qu’ici le terme « libre » est mal employé car étendu à l’agriculture et la médecine, ce qui n’a rien à voir comme la précisé RMS lors d’un échange question/réponse suite à une intervention à l’université Rennes 1 il y a quelques années de ça pendant ma thèse).

Des idées pour actualiser le problème. Bien entendu, tout comme aujourd’hui les personnes n’ont pas les connaissances pour relire et modifier le code source des logiciels qu’ils et elles utilisent, elles n’ont pas les connaissances pour opérer ces serveurs comme nous. C’est pourquoi nous devons avant tout permettre à ces personnes d’acquérir les connaissances techniques nécessaires pour être parfaitement autonomes sur ces usages, et ainsi créer un espace égalitaire où hacker hackeuses agissent sur un pied d’égalité, adaptant, relisant le logiciel pour leurs besoins. Afin de faciliter cette mission, le choix de logiciels et d’usages simples sera fait, car la complexité de ces derniers est un frein à l’appropriation collective des outils. Si l’appropriation collective n’est pas possible, alors il faudra se refuser à utiliser l’outil.

À noter qu’il n’y a rien d’extravagant, c’est, je crois, le parti pris qu’avait le hackerspace Le Reset, qui analysait la question sous l’angle du genre (aujourd’hui la technique est majoritairement masculine) alors que la FSF l’aborde sous la question individuelle. Le choix a été fait alors de créer un espace de transmission du savoir pour que des minorités de genre puissent monter leur propre services et échapper aux rapports de pouvoirs créés par la technologie. Dans ce hackerspace, les solutions/projets compliquées/complexes ont été volontairement écartées au profit de projet favorisant l’autonomie du collectif.

Les esprits les plus taquins noteront qu’elles se sont tenues à bonne distance des libristes pourtant à l’avant garde sur les rapports de pouvoirs que créer le logiciel et les ordinateurs. Probablement un malentendu

https://wiki.lereset.org/confpses2017

Enfin sur les questions de sécurité, chaque personne devrait être en mesure de gérer en autonomie, chez elle, ses données, et les chiffrer au besoin lorsqu’elle doit les communiquer, de sorte que les serveurs soient simplement des espaces d’échanges publiques : l’intérêt de les détourner serait alors très faible.

Cette mise en oeuvre n’a rien d’utopique : en plus du Reset, le contrôle sur le réseau peut se faire via des FAI associatifs. En ayant discuté avec un membre de tetaneutral, ils donnent très facilement l’accès root au réseau aux nouveaux membres, privilégiant l’apprentissage et la gestion collective à la sécurité/stabilité. Côté serveurs, le mouvement tildeverse qui consiste à partager une machine via SSH est un premier pas encourageant bien qu’imparfait : les usager-es n’ont pas le même niveau d’accès que les opérateur-ices. Ce pourrait bien sûr être un travail pour le collectif de lever ce rapport de pouvoir, par exemple en s’assurant une formation exigeante de ses usager-es en amont et une information légale quant à leurs responsabilités lorsqu’ils accèdent à un système d’information.

Ma conclusion. À la vue des différentes publications de la FSF/FSE/GNU, il me semble intenable de continuer à utiliser le terme « libre » au sein du collectif CHATONS : nous enfreignons bien trop de règles. J’appelle donc à une modification importante de la charte pour se mettre en conformité avec les différents textes et propos tenus par les tenants de ces différentes organisations ou à abandonner le terme au profit d’un autre, comme « communs numériques ».

Donc ma proposition de point :

En se revendiquant du libre, les CHATONS doivent prendre en compte les positions de la FSF et sans cesse adapter leurs pratiques.

critères requis :

Les usager-es d’un serveur CHATONS doivent tous-tes avoir l’accès root au serveur, doivent être en mesure d’en assurer l’administration, et surtout d’en inspecter le fonctionnement.

Les usager-es ont un droit d’accès physique à la machine et un droit d’inspection (par exemple lors de maintenances bi-annuelles).

Le CHATON a un processus pour s’assurer que ses usager-es aient un niveau de connaissance suffisant pour bénéficier des libertés du libre (le droit de lire et modifier le code en particulier).

Corollaire du point précédent : les choix techniques sont gardés simples afin que des inégalités ne se creusent pas entre usager-es du serveur. Entre autre, si une solution plus simple existe (en terme de code) pour remplir un usage, elle est privilégiée (exemple : pour partager un fichier, FTP - voire un dossier partagé en SSH sur le serveur - plutôt que Nextcloud, vim dans un tmux plutot que etherpad, etc.).

Le serveur est considéré comme un espace de communication et de partage et ne se substitue pas à un logiciel (exemple : bitwarden qui peut être remplacé par Keepass + une synchro manuelle)

neil · Juin 27, 2023, 11:36

Je pense que ta proposition répond aux exigences de certains CHATONS, et pourrait tout à fait se présenter comme une contre-proposition à cette révision.

Un point important m’interpelle dans ta proposition, c’est qu’elle pose comme nécessité un accès physique aux machines (pas seulement pour les admins CHATONS, mais également pour les usagèr·es), ce qui rendrait a minima 70% des CHATONS actuels non-conformes de facto. Elle semble par ailleurs aller dans le sens d’un durcissement des critères.
Comme défini dans la section « Portée » en début de thread :

Je t’invite donc à créer un thread séparé qui porterait sur cette contre-proposition.

Et concernant ta remarque sur le « libre » :

Mon parti pris, c’est que la FSF n’a pas le monopole du « libre », et que la définition qu’on lui donne n’est pas figée dans le marbre − tout comme la Charte. Il n’y a pas de « règles » autres que celles que nous nous imposons à nous-mêmes

neil · Juin 27, 2023, 12:46

Bonjour Garthh,

C’est une question difficile, d’autant plus que chaque structure a ses critères qui lui sont propres (ex: le support d’OpenID / LDAP, l’accessibilité, l’UI/UX…).

Et il y a les cas comme pour la candidature de RollenspielMonster où c’est une question de public : il hébergeait bel et bien un Mumble à côté de son TeamSpeak, mais tenait à héberger les deux pour permettre à son public (rôliste, et qui préférait TeamSpeak à Mumble) de basculer sur Discord, ce qui − selon l’admin − allait arriver s’il fermait son service. C’était dans une stratégie du « meilleur compromis », donc.

Il y a aussi le cas de Paheko qui est contraint d’utiliser AWS car aucune alternative plus éthique n’est viable (même OVH, à son échelle, serait tarifié 10 fois plus cher).

Je pense que la réponse à cette question, c’est d’apprécier la candidature au cas par cas et d’évaluer par nous-mêmes si le compromis est valable ou non lorsque le cas se présente, selon le rôle de la structure dans l’écosystème du libre, ses positions, ses idées, sa démarche, son modèle économique, sa bonne foi… Contrairement à la situation actuelle où si l’on suivrait la charte noir sur blanc, on appliquerait la clause « 100 % logiciel libre ou rien » et ces candidatures seraient systématiquement rejetées. (Cela vaut également pour un logiciel dont les sources ne sont accessibles qu’après avoir payé.)

Plusieurs choses m’interpellent aussi dans cette proposition de @ljf, déjà effectivement « réseaux sociaux publicitaires » n’est pas clair pour moi non plus, un réseau social désignant tout ce qui « nous met en relation », ça peut être un forum, une plateforme de diffusion de vidéos, un chat… un peu tout et n’importe quoi. Et le mot « publicitaire » ne précise pas assez ce que ça désigne, je trouve

Autre chose qui m’interpelle : c’est quoi, « faire la promotion » ? Selon la charte de la RAP dont ljf a tiré l’inspiration, indiquer notre présence sur ces réseaux dans notre site web ou sur nos supports de communication correspondrait à cette définition. Dans ce cas, je peux vous dire que tous les CHATONS qui ont un lien vers leur profil de réseau social (autre que Mastodon) sur leur site sont d’ores-et-déjà non conformes

Et ensuite, que faire des CHATONS qui souhaitent cibler des publics non-initiés ? Les CHATONS qui offrent des services aux personnes qui sont sur Mastodon (donc essentiellement des libristes) n’auront pas de problème à se conformer, mais dès que l’on souhaite atteindre un public « pas déjà libriste », il me semble assez obligatoire de passer par la case réseaux sociaux propriétaires (YouTube, Facebook, LinkedIn…).

Ce que tu suggères (et qui va dans le sens des suggestions de ljf) :

Je pense que le community management, c’est un métier à part entière, on ne peut pas écrire la même chose sur LinkedIn que sur Mastodon, il faut parler différemment, utiliser d’autres mots-clés, tout simplement parce que le public est différent. Pareil pour Instagram : poster sur ces réseaux requiert d’utiliser leurs codes de publication (peu de textes, beaucoup d’images). On ne peut pas juste mettre un bridge et c’est fini, il faut définir une stratégie de communication différente, etc.

Et c’est sans parler du temps à consacrer à ces réseaux sociaux : une stratégie de publication régulière, réfléchie et efficace sur cinq réseaux différents, c’est quasiment un temps plein consacré à ça. Si les CHATONS sont vraiment à destination des publics non initiés et pas des geeks libristes, ne devraient-ils pas justement privilégier les réseaux propriétaires aux réseaux libristes ? Je sais, ça fait peur et l’idée de poster sur facebook ne m’enchante pas le moins du monde, mais je pense que c’est fondamental d’aller chercher le public là où il est et je trouverai ça lamentable si nous en venons à refuser des candidatures sur ce critère.