• [^] # Re: Pour les projets open-source

    Posté par . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 3.

    Il faut bien, à un moment ou à un autre, qu'on puisse t'identifier, ne serait-ce que pour appliquer les droits que t'autorise la licence libre utilisée.

    Ça ne veut pas dire que le nom doit être public. Les écrivains qui écrivent sous pseudonyme touchent leurs droits d'auteur, parce que l'éditeur peut faire le lien.

    De toutes manières, je ne comprends pas ce que tu veux dire. Les licences libres ne donnent pas de droits aux auteurs, mais aux utilisateurs. Du coup, pourquoi aurais-tu besoin de connaitre les auteurs? Au pire, si les auteurs veulent te poursuivre parce que tu ne respectes pas la licence, ils ont besoin de prouver qu'ils sont les auteurs du code, ce qui peut être fait de beaucoup de manières, et pas seulement parce que leur email figure en haut des fichiers...

    Quoi qu'il en soit, en contribuant, tu as donné ton accord pour que l'identité que tu as donnée soit publique.

    Pas de problème avec ça, du moment que cet accord est révocable.

    vous imaginez ? "bonjour l'urssaf, supprimez toutes mes données personnelles siouplait"

    Non, mais le problème, c'est que ces informations sont publiques. À ma connaissance, l'URSAFF ne publie pas les informations personnelles.

    J'imagine aussi que c'est impossible de retirer des informations personnelles tant qu'on utilise un service qui en a besoin. Typiquement, les infos personnelles disponibles par whois sont indispensables pour l'identification du propriétaire d'un nom de domaine ; tant que tu possèdes ce nom de domaine, j'imagine qu'il est absurde de demander le retrait de tes infos personnelles. Par contre, il n'y a plus de raison de les conserver dès que tu ne payes plus.

    J'ai l'impression qu'un bon compromis serait la possibilité de retirer les infos personnelles d'un dépôt Git à partir du moment où la personne l'a demandée. Les noms/emails restent dans l'historique du dépôt, bien sûr, parce que c'est impossible techniquement de faire autrement (*), mais ces infos restent enfouies dans l'historique, ce qui rend leur déterrage accidentel asssez peu probable.

    (*) J'imagine d'ailleurs qu'il serait tout à fait possible de faire évoluer le logiciel de gestion de version pour gérer ce cas, par exemple en marquant des commits comme "synonymes" (éventuellement, en imposant que les seules différences entre les commits synonymes sont dans les commentaires, mais dans le détail, on s'en fout), et de rediriger de manière transparente toutes les requêtes sur les commits masqués vers le commit synonyme non-masqué. Bien sûr, on perd évidemment l'exactitude de l'historique (c'est exactement ce qu'on veut), et il faut faire confiance au "masqueur" sur la synonymie, mais l'opération laisse une trace (donc on ne peut pas "nettoyer" en douce un historique).