[OSM-talk-fr] soucis avec un contributeur en Vaucluse

[Philippe Verdy]

Le 7 novembre 2012 20:01, sly (sylvain letuffe) <liste at letuffe.org> a écrit :
> Le mercredi 07 novembre 2012 19:38:33, f.dos.santos at free.fr a écrit :
>> Pour supprimer les infos nominatives y compris de l'historique.
>
> Là, comme ça, c'est triste à dire, mais il me semble que compte tenu de la
> difficulté à censurer l'historique,

Faux, quelle difficulté ? La fonctionnalité existe déjà et est même
abondamment utilisée !

> il me semble peu probable qu'ils le fassent.
>
>> C'est l'exemple parfait de réutilisation du mécanisme du "redaction bot".

Effectivement car le RedactionBot sait masquer des éléments de
l'historique et c'est d'ailleurs ce qu'il a fait (il n'a pas fait de
suppression réellement, mais a rendu ces données inaccessibles pour
qu'elles ne soient plus diffusées publiquement), en utilisant une API
avec un accès privilégié et authentifié.

Un tel mécanisme de masquage existe aussi dans MediaWiki.

Dans les deux cas il faut un compte administrateur habilité pour
rendre un élément invisible dans l'historique (sans pour autant avoir
besoin de modifier directement dans la base de données avec un accès
SQL direct, ce qui n'est normalement utilisé que pour des opérations
très précises de réparation et maintenance de la base de données,
directement par quelques administrateurs systèmes désignés par la
Fondation qui ont le devoir de limiter très strictement leurs
opérations, ou alors de ne faire des suppressions physiques QUE suite
à un ordre imposé, ou résoudre des problèmes techniques tels que des
doublons empêchant la génération d'un index unique, sachant aussi que
s'agissant des violations de lois d'auteur ou d'autres règles légales
comme la protection de la vie privée dans les éléments publiés, la loi
peut imposer à la Fondation de conserver des traces à disposition des
autorités judiciaires au cas où elle recevrait des plaintes de
victimes de ces violations), mais pas pour un bot qui interviendrait
hors des période de sauvegarde pour archivage.

Ce n'est que lorsque les données pour les archives légales sont
sauvegardées ailleurs (sur un support inaccessible au public) que la
base de données peut éventuellement être purgée des infos masquées (et
la consultation des archives reste alors une opération privilégiée) :

Cela pourrait être fait dans l'actuelle base il me semble sur les
données CC-BY-SA non compatibles ODBL et sur leurs contributeurs,
maintenant que ces données ont été toutes sauvegardées dans une
archive contenant les données CC-BY-SA, afin de se prévenir d'un
éventuel retour parasite de ces anciennes données, mais pour l'instant
on en est encore à l'étape masquage, car certaines des données
masquées n'étaient en fait pas la propriété de ceux qui les ont
importées, mais d'une source qui a été reconnue comme compatible ODBL,
et on assiste à quelques "résurrections" de données par endroit (après
avoir obtenu un accord de la source initiale)

Mais au lieu de les "ressusciter" des données par démasquage, on
pourrait procéder par réimportation depuis les anciennes archives,
avec les mêmes règles que pour les importations de données provenant
d'une autre base, donc avec aussi des fusions et une supervision
humaine (une fois qu'un extrait intéressant et compatible de
l'ancienne base archivée sera rendue disponible à une telle
réimportation, en ayant toutefois modifié l'indication de la véritable
source autorisée, et non la source de l'ancien contributeur qui
n'était pas titulaire des droits et n'a pas pu concéder lui-même une
licence valide sur ces données).