Après quoi, il y aura un vote pour le concept général + un vote par exception (sauf celles déjà prévues par la charte).
Durant la phase d’amendement, si votre amendement ne fait l’objet d’aucune opposition à une intégration immédiate, il sera intégré en remplaçant la proposition initiale. Si par contre, il y a débat, il sera proposé à côté des autres solutions imaginées lors du vote.
Pour faciliter le repérage j’ai inclus des lettres de A à M pour les exceptions, mais vous pouvez proposer des amendements sur ce qui est autour aussi.
Vos amendements peuvent porter sur :
Une proposition totalement alternative (statu quo, pas de liste, etc.)
Une modification du processus décrit en Z
Un ajout d’exception
Une modification du texte d’une exception (sans supprimer la version originale donc en créant une seconde proposition)
MAIS pas de suppression d’une exception, puisque ce choix sera proposé systématiquement pour chaque exception lors du vote.
Les signalement de « chatons concernés » et les fautes d’orthographes sont à intégrer directement.
Pour proposer un amendement
éditer le message-wiki, ci-dessous, en cliquant sur le bouton et en ajoutant votre proposition par exemple « E2) l’usage d’outils sous licences SSPL ou BSL ».
Si besoin, vous pouvez commenter votre amendement en faisant un message sur ce fil avec pour titre « Amendement E2 » et uniquement votre argumentaire
Si vous voulez ouvrir un débat
Il peut être préférable de créer un fil dédié ou d’utiliser le fil d’annonce initial pour ne pas noyer les argumentaires d’amendements ou d’organiser une discussion orale dans le pire des cas. Les sujets chaud sont a priori D, E, F, H et J.
Liste d’exceptions autorisant l’usage de logiciels ou services propriétaires chez certains chatons
Cette page dresse la liste des exceptions, validées par le collectif CHATONS, autorisant dans certaines circonstances l’usage de logiciels ou services propriétaires chez certains chatons.
Rappel de l’article de la charte à ce sujet :
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.
À titre exceptionnel, le CHATON peut proposer un service basé sur un logiciel ou une plateforme propriétaire si aucune solution libre ne permet un fonctionnement acceptable du service. Dans ce cas, le CHATON se doit de lister sur son site web les logiciels ou plateformes propriétaires qu’il utilise.
La validité des exceptions est laissée à l’appréciation du collectif.
IMPORTANT: quelque soit la situation, le chaton doit être transparent sur ces questions vis à vis de ses utilisateurs et utilisatrices.
Le collectif autorise les exceptions suivantes :
A1) les services de métamoteurs de recherche sous licences libres faisant appel directement ou indirectement à des index de recherche propriétaires (comme Google, Bing ou Qwant), à condition que le métamoteur ne transmette aucune autre information que la recherche saisie par l’utilisateurice (ni son IP, ni un identifiant)
B1) les services de proxy sous licences libres (tel qu’invidious) permettant de consulter des contenus disponibles sur des plateformes propriétaires tout en limitant le pistage et la pub
chatons concernés : -
C1) les services de bridge de messageries instantanées sous licences libres (tel qu’arn-messager) permettant l’interopérabilité avec des systèmes de messageries instantanées propriétaires tout en limitant ou brouillant les métadonnées transmises utilisables.
chatons concernés : ARN (sans-nuage)
D1) l’usage de services anti-spam propriétaires comme akismet susceptible de collecter des données associées à des IP
chatons concernés : Framasoft
E1) l’usage de ces outils sous licence (e.g. SSPL, BSL): MongoDB, ElasticSearch, outils Hashicorp
* chatons concernés : Picasoft, Nebulae, Paquerette, Framasoft, IndieHosters, caracos, Libretic
F1) l’usage de service d’envois de mail propriétaire (hors GAFAM) lorsque la nature des mails ou le volume de mail à envoyer le nécessite pour être envoyé en interne ou par des prestataires plus proches du libre
G1) les **services sous licences libres qui envoient des mails **et qui sont de facto interopérables avec les services de mails propriétaires même s’ils ne limitent pas tellement les métadonnées transmises utilisables.
chatons concernés : Tous
H1) l’intégration avec les notifications push des GAFAM directe ou indirecte (eg. Apple Push ou Google FCM)
chatons concernés : tous les CHATONS proposant Matrix, ou ayant activé les notifications Mattermost ou Nextcloud : Deuxfleurs, Framasoft, Picasoft, ARN, ReflexLibre, CLUB1, caracos
NB: aucun chatons n’étant registraire, l’édition et l’hébergement des champs NS et glue records se font forcément sur ces services tiers, pour la plupart propriétaires. Les chatons concernés sont donc ceux qui hébergent leur zone DNS sur ces services.
J1) l’envoi de sauvegarde chiffrée (au préalable) vers des systèmes propriétaires (NAS, services tiers, etc.)
chatons concernés : Gozdata (OVH)
K1) l’usage d’API propriétaires d’envoi de SMS pour le monitoring
L1) l’usage de service de monitoring propriétaire tiers à condition qu’aucun accès aux données non publiques des hébergé⋅es ne leur soit possible
chatons concernés : CLUB1, IndieHoster
M1) l’usage de services de paiement propriétaire par carte bancaire, virement ou prélèvement
chatons concernés : Tous les chatons qui proposent du paiement en ligne en euros
O1) les outillages/scriptings développés par le chaton, spécifiques à son usage ou son infrastructure, afin d’assurer l’intégration ou l’opération de ses services
chatons concernés : Gozdata
Par ailleurs, il est rappelé que les pratiques suivantes sont autorisées par la charte directement :
l’usage de plateforme propriétaire pour communiquer tant que le chaton propose « un moyen de suivre ses actualités en dehors de plateformes propriétaires »
l’usage d’outils propriétaires sur les ordinateurs utilisés par les bénévoles ou salarié·es du chaton pour exécuter des missions pour le chaton (graphisme, comptabilité, os windows, etc.)
chatons concernés : Tous
l’usage de plateforme propriétaire comme forge logiciel
chatons concernés : CLUB1, caracos
l’usage de micro-logiciels propriétaires liés à du matériel (BIOS, firmware, pilotes, etc.)
chatons concernés : Tous
l’usage de services d’hébergement propriétaires tiers (comme OVH) tant que le chaton respecte les critères de contrôle, de confiance et de transparence de la section « Hébergeur » de la charte
chatons concernés : Tous sauf ARN, Hadoly, Deuxfleurs, CloudGirofle, CLUB1, Picasoft, caracos, Gozdata, Infini et les chatons auto-hébergés
Y1) l’usage de matériel réseau propriétaires (comme box opérateur, routeur non libre) tant qu’ils ne sont pas connus pour faire du DPI
Y2) l’usage de matériel réseau propriétaires (comme box opérateur, routeur non libre)
chatons concernés : Tous les chatons auto-hébergés qui utilisent un FAI commercial.
Z1) Les chatons peuvent par « décision autonome » s’ajouter parmi les chatons concernés par l’une de ces exceptions déjà listées. Tout ajout, retrait ou modification d’exception doit faire l’objet d’une décision extraordinaire du collectif CHATONS.
IMPORTANT : le collectif encourage quiconque souhaite œuvrer pour qu’une de ces exceptions ne soit plus nécessaire.
J’ai ajouté une nouvelle proposition d’exception (O1). Gozdata serait concerné dans la mesure où nous avons développé notre propre gestion de membres et que nous n’en avons pas publié le code.
Voici la réponse que j’ai fait à @ljf en message privé :
C’est une très bonne question, et la réponse n’est pas forcément binaire.
Pour ma part, il y a une grosse part de flemme. Effectivement le fait de ne pas publier est plus confortable (pas besoin de vérifier qu’on n’a pas laissé trainer des secrets, pas besoin d’adapter la manière dont on pousse le code).
Il y a aussi le fait qu’on ne s’est pas dit (peut-être à tord) que cela pouvait être utile à d’autres. Grosso-modo on a une base de données de membres, une gestion des inscriptions et des relances, un scraping des données HelloAsso pour automatiquement mapper les paiements, des appels à postfixadmin pour créer/désactiver les comptes, un webservice pour présenter les donneés, et un plugin roundcube pour afficher les informations du compte. Et même si cela fait beaucoup, j’ai du mal à voir comment cela pourrait être réutilisé.
Il y a aussi parmi nous une crainte que publier le code puisse avoir un impact en terme de sécu.
Objectivement la qualité de ce qu’on a fait pourrait être améliorée et je sais que j’ai pris des raccourcis dans le développement.
Maintenant je comprendrais que l’on considère que ce ne soit pas des justifications raisonnables pour motiver une exception.
Cela dit, de manière générale, indépendamment de notre gestion de membres, je pense que nous avons tous développé des outillages ou des intégrations diverses pour notre opération, qui sont spécifiques et qui n’ont pas forcément d’utilité à être publiés. C’est aussi dans ce sens que je faisais cette proposition, de manière à en discuter, et si besoin fixer le curseur.
exclusion des chatons auto-hébergés des service d’hébergement tiers
Proposition de l’amendement Y1 pour préciser le cas des chatons auto-hébergés avec un opérateur réseau commercial.
Explications:
Dans la clause sur l’hébergement tiers, l’hébergeur peut prendre la main sur la machine et la modifier, il faut donc faire confiance à l’hébergeur (normalement OVH et compagnie ne sont pas problématiques la dessus).
Dans les cas d’un chatons auto-hébergé personne ne peut prendre la main sur la machine (hors cambriolage etc…) mais ils passent souvent par une brique propriétaire très difficile a enlever: la box du FAI¹.
Ces deux cas me semblent suffisamment différents pour justifier deux points séparés.
¹ Les grands FAI commerciaux ne fournissent aucune des informations techniques nécessaires pour se débarrasser de la box, quand ils ne luttent pas activement contre.
@laurent, @sekil
Je ne comprends pas l’intérêt d’ajouter la section référencée O1. Ça me parait hors sujet, et je pense même que ça peut induire de la confusion quant à ce qu’il faut considérer comme important à faire dans le périmètre des logiciels dont nous voulons garantir les conditions de liberté pour les utilisateurs des services des chatons.
En effet, la mentionner comme exception suppose que la règle serait que de tels scripts devraient être des logiciels libres.
Or je ne vois pas pourquoi on devrait se sentir obligé de faire de ses outils et procédures internes des logiciels libres tant que ce sont des outils internes qui ne sont pas redistribués et qui ne concourent pas directement au service rendu aux utilisateurs du chaton.
Si un chaton crée son propre logiciel de gestion de ses adhérents, de sa compta, de son monitoring, ou que sais-je qui lui facilite la vie, que ça ne sert qu’à lui et que ça n’est pas redistribué, ça n’est ni un logiciel libre ni un logiciel privateur et ça ne concerne que lui.
Sinon c’est quoi la taille minimale du programme à partir de laquelle il faut commencer à penser la publication dudit programme sous licence libre comme la règle qui mérite cette exception ? 1000, 100, 10, 1 ligne ?
Juste pour un retour sur ce qui pourrait bloquer de notre côté si on fait une prochaine candidature pour Paheko.cloud :
On utilise BookMyName pour les DNS, après plusieurs incidents à gérer moi-même les DNS j’ai laissé tomber, y’a un moment où il faut accepter de lâcher du lest
PrinceXML qu’on utilise pour la génération de PDF, car rien de libre ne permet de générer des journaux comptables de plusieurs centaines de pages sans mettre à genoux le serveur On a contribué quelques centaines d’euros à Weasyprint (Python, peu de chances que ça devienne léger, mais pour générer des livres ça peut être un projet chouette) et DomPDF (PHP, qu’on propose aux gens auto-hébergés en mutualisé) et cherché en vain un dév PHP qui puisse passer quelques jours à améliorer les perfs de DomPDF (budget prévu de 3000 € pour 2-3 jours de taf).
Le code de Paheko.cloud qui permet la gestion des comptes d’associations n’est pas libre, mais ce code est progressivement intégré à Paheko
On passe toujours par AWS, j’aurais passé des tonnes d’heures sur cette problématique (alors qu’on paye actuellement moins de 10 € / mois chez AWS, donc clairement pas intéressant), mais notre nouveau prestataire d’hébergement ne peut finalement pas fournir ce service (après 9 mois de discussions), donc on va devoir passer par un AWS-like comme Tipimail. Il faut que je reprenne contact avec eux, ça va encore prendre du temps. C’est un effort en cours, mais dans tous les cas ça ne changera pas grand chose, on utilisera toujours un service proprio commercial pour l’envoi de mail
Sauvegardes chiffrées vers un prestataire : BorgBase. Leur plateforme n’est pas libre, mais ils financent Borgmatic et Pika Backup, développent Vorta, et incitent à donner à Borg quand on règle la facture chez eux… On peut dire qu’ils sont plus éthiques qu’un OVH ou Scaleway
Du coup je pense qu’à part AWS et Prince, on n’est pas très éloignés du reste des chatons, et le document actuel me semble correct.
Edit : je viens de voir que Tipimail a été racheté et les tarifs ont doublé, pour nos besoins on serait dans les 1300 € / an… au lieu de 70 € chez AWS… Outch.
Cette exception parait bizarre si tous les chatons qui utilisent des protocoles interopérables sont effectivement concernés. On ne peut évidement pas interdire un service interopérable d’échanger avec une implémentation non libre que l’on ne contrôle pas. Quand j’imagine la description de cette exception sur une page chatons ça me parait un peu ridicule :
permet à ses utilisateurs d’envoyer des e-mails aux utilisateurs de Gmail
À mon avis c’est aux utilisateurs de faire leur choix au moment où ils envoient leurs e-mails. Je pense que ça devrait pouvoir être déplacé dans la deuxième section et avec un texte un peu plus générique. Par exemple :
l’usage de services basés sur un protocole interopérable (ex : E-mail, Matrix, XMPP, etc.) qui peuvent donc de fait communiquer avec des instances externes non-libres.
J’avais vu ça comme une façon de visibiliser qu’en pratique on en envoie pléthore, des informations aux GAFAMs, par ce biais-là. En ce sens, j’aimerais bien que ce soit mieux détaché de Matrix et XMPP pour lesquels, en pratique, l’écosystème est majoritairement libre.
Pour autant, ce serait en effet ridicule d’en faire un encart sur la page de tous les chatons ^^
à ce compte la c’est pas que les mails qui posent problème, a partir du moment ou on utilise du http aussi (il y a bien de navigateurs proprio). Pour moi le fait de pouvoir recevoir du mail chez un utilisateur non libre c’est forcement un choix de l’utilisateur (il choisit ou il héberge son mail) a la limite ça peut concerner les CHATONS qui hébergent du mail pour leur utilisateurs et encore.
En permetant a l’utilisateur de recevoir ses mails n’importe ou on lui laisse la plus grande liberté possible. Apres c’est l’éternel débat entre la vision contaminante (GPL) et la vision « faite ce que vous voulez » (MIT)
l’usage de services d’hébergement propriétaires tiers (comme OVH) tant que le chaton respecte les critères de contrôle, de confiance et de transparence de la section « Hébergeur » de la charte → pour bastet l’hébergement est dans un centre de données en île-de-france, dans une baie c’est nos propres machines physiques, avec des IP publique sur les serveurs, cela fait quoi comme différence avec un auto-hébergement ?
Il me semble que c’est aussi considéré comme de l’auto-hébergement ça ?
Côté Picasoft on est dans des DCs associatifs, mais on a pas beaucoup plus la main que vous a priori, et on est dans la catégorie auto-hébergement il me semble.
Je dirais ça dépends si les disques sont dans la machine ou si ça fait appel à une baie de stockage ou d’autres types de stockage qui peuvent être regardé sans arrêter le service.
Mais je suis d’accord, dans le cas que tu cites, la présence de logiciel propriétaire est réduite comme pour l’auto-hébergement à la maison…
je ne suis vraiment pas sur que ça aille a l’encontre de la charte. j’ai proposé le Y1 en réaction au paragraphe précédent mais en y repensant je pense qu’il serait préférable de supprimer les deux. vous en pensez quoi ?
Du coup, justement ça ne va pas à l’encontre de la charte, puisqu’elle l’autorise déjà (même si c’est assez implicite pour l’aspect matériel propriétaire…)
J’ai ajouté un Y2 pour supprimer la mention au DPI, car c’est difficile de le savoir, et de toutes façon, en France, les boites noires de 2015 peuvent être chez n’importe quel opérateur et iels ne pourront rien dire sans risquer de la prison.
et en ajoutant votre proposition par exemple « E2) l’usage d’outils sous licences SSPL ou BSL ».
permet à ses utilisateurs d’envoyer des e-mails aux utilisateurs de Gmail