Est-il acceptable de télécharger du contenu offensant sur GitHub? [fermé]

J'ai développé un vérificateur de contenu offensant pour mon site Web et je souhaite le publier sur GitHub . Cependant, le code source contient de nombreux contenus offensants, racistes et autrement méchants.

La source est entièrement documentée, mais je voulais votre avis sur s'il est acceptable de publier un tel travail sur GitHub ou de laisser le tableau de chaînes à l'imagination du lecteur?!

Je dois être en désaccord avec la solution ROT-13. Brouiller vos mots interdits simplement parce que leur vue pourrait offenser quelqu'un est une perte de temps.

Votre dictionnaire de mauvais mots / règles de mauvais mots devrait de toute façon provenir d'un fichier distinct (qui pourrait être chargé au moment de l'exécution ou incorporé en tant que ressource) . L'obscurcissement de ce fichier rend simplement plus difficile pour vous / les autres développeurs / vos utilisateurs de le modifier ou de résoudre les problèmes. En outre, si je voyais un fichier appelé "banned_words.txt" sur mon disque dur, je m'attendrais à ce qu'il contienne une liste de mots offensants.

"Tous les problèmes en informatique peuvent être résolus par un autre niveau d'indirection." ( par David Wheeler ).

Vos options ne se limitent pas à le télécharger ou non, si vous tenez compte du fait que vous pouvez encoder du contenu afin qu'il ne dérange pas les lecteurs.

• Par exemple, le simple passage à la lettre suivante (A à B, B à C, etc., avec Z passant à A pour terminer le codage) peut transformer les célèbres mots de quatre lettres en Gvdl totalement inoffensif . Tout ce dont vous avez besoin pour l'utiliser dans votre application serait de le reculer dans la direction opposée, vers les lettres précédentes , avec A en passant à Z.

Comme souligné dans les commentaires , une approche comme celle ci-dessus est utilisée dans le chiffrement de substitution de lettres ROT13 , connu pour son utilisation "comme moyen de cacher ... les matériaux offensants du regard occasionnel ..."

Dans un souci d'exhaustivité, envisagez également d'exécuter votre vérificateur sur un dictionnaire codé , afin de vous assurer que le codage choisi n'a pas accidentellement transformé un mot offensant en un autre.

_{Lorsque vous encodez des trucs comme ça, il est logique de revérifier, car on ne peut pas prédire les choses de manière fiable. Dans l'un de mes projets antérieurs, nous avons eu une panne de courrier assez grave lorsqu'un vérificateur mal configuré a commencé à découvrir du contenu offensant dans des séquences aléatoires de caractères (dans le contenu uuencodé des archives ZIP).}

Comparé au passage du texte brut, Gvdl s, l'encodage a un avantage substantiel en évitant complètement les problèmes juridiques et tous les risques et dépendances impliqués .

Pensez-y. Disons que des conditions de service particulières à un référentiel particulier autorisent mon contenu, très bien.

Mais, s'ils décident de changer le TOS ? Ou, si je décide de passer à un autre référentiel, ayant des termes incompatibles. Qu'est ce que je vais faire?

Notez par ailleurs que même être dans un référentiel "convivial", ici et maintenant, n'est toujours pas totalement sûr.

Et si quelqu'un ne peut pas télécharger mon contenu à cause d' un filtre Web étrange ? Suis-je disposé à répondre aux plaintes des utilisateurs et à expliquer comment réparer le filtre? Leur filtre ...

... Vous voyez, je préfère réfléchir à deux fois avant de décider de ne pas encoder. Et même si je décidais, je m'assurerais d'avoir une très, très bonne raison à cela.