Pour rappel, chaque écart vis à vis de l’idéal devra d’après la nouvelle proposition:
- Faire l’objet d’une information vis à vis des utilisateurices et des chatons
- Être acceptée par le collectif (si il s’agit de l’usage d’une dépendance non libre)
Sauf que sur ce forum on a discuté de nombreuses fois sur l’incohérence du critère root. Etre root ne signifie pas avoir un système auditable, ou une garantie de maîtrise totale. Beaucoup de chatons sont sur des VPS dont les disques peuvent techniquement être consultés par le fournisseur du VPS…
Du coup, il y a peu de différence avec un mutualisé web ou une location de container docker.
Par ailleurs, selon le modèle de menace du public hébergé, on peut vouloir des garanties de différents niveaux. Au final, nous sommes plusieurs à penser qu’à ce jour un VPS peut convenir pour le modèle de menace du grand public (ça pourrait changer un jour).
Le mécanisme de portée est devenue profondément injuste car de plus en plus dur. On a donc des chatons historiques qui n’ont pas été trop embêtés, ni même audités, quand d’autres se prennent parfois des exigences hors chartes de la part des auditeurices… Par ailleurs, une grande partie des chatons ne respectent pas 100% de la charte actuelle, c’est aussi important de ne pas mentir aux utilisateurices (cf les exemples plus bas).
Par ailleurs, nous parlons de réviser la charte sur ces points depuis le camps CHATONS 2022. Il y a aussi plein d’autres sujets à traiter. Par exemple, il y aurait plein d’autres choses à revoir dans la charte (cf atelier du camps CHATONS 2022), si on passe 6 mois sur chaque partie de la charte, on a pas fini (de ne rien faire de concret).
Des exemples pour y voir plus clair
Avec cette nouvelle charte (si elle est votée), le collectif pourrait être amené à se prononcer pour ou contre différents cas qui coincent un peu (ou beaucoup) avec la charte actuelle:
- un hébergeur qui utilise Amazon web service pour envoyer des dizaines de milliers de mails
- un hébergeur qui déploie un soft qui utilise une dépendance proprio pour générer des PDF correctement
- un hébergeur qui déploie des solutions basées sur des services tiers proprio, dont il cherche à protéger les utilisateurices (instance searx, bridge whatsapp, instance invidious ou nitter)
- un hébergeur qui utilise un logiciel de comptabilité proprio pour son usage interne
- un hébergeur qui utilise le plugin propriétaire pour l’accessibilité dans onlyoffice
- un hébergeur qui déploie un service qui a changé de licence (genre wekan avec mongodb qui n’est plus sous licence libre ou la recherche nextcloud avec elasticsearch…)
- un hébergeur qui anime une communauté et propose teamspeak au lieu de mumble (+ une foule de services libres) car il n’a pas trouvé comment migrer sa communauté
- un hébergeur qui utilise un soft sous licence libre mais qui utilise le droit des marques pour restreindre les usages (collabora online ou onlyoffice)
- un hébergeur qui déploie un logiciel qui de version en version transvase des fonctionnalités de la version libre vers la version proprio.
Sur la bienveillance
A partir du moment où la bienveillance entre chaton et la bienveillance avec les utilisateurices sont toutes les 2 en requis, j’estime qu’il n’y a pas de hiérarchisation.
Je pense qu’on peut être dans la bienveillance tout en signalant à un chaton ses écarts (sans nécessiter de l’engueuler d’ailleurs). Si il est vraiment malveillant pour ses utilisateurices, dans ce cas on peut choisir de l’exclure. (paradoxe de la tolérance)