[OSM-talk-fr] CGU de l'APIE, ODbL et OSM

[Charles Nepote]

Le 09/11/2010 15:28, Pieren a écrit :
> 2010/11/9 Charles Nepote <charles at nepote.org <mailto:charles at nepote.org>>
>
>     Comment a-t-on résolu ce problème pour les données du cadastre ?
>
>
> En demandant d'ajouter le millésime dans le tag "source" et en 
> l'attachant à chaque élément ajouté (les polylignes et les noeuds 
> isolés) en non dans les commentaires des changesets (possible mais les 
> commentaires ne sont pas accessibles dans la plupart des extractions).
>
> Plus généralement, je ne crois pas que la date de mise à jour soit le 
> problème principal. Même si on ne le précise pas dans un tag, il reste 
> aisé de retrouver la date de la contribution (dans l'historique de 
> l'élément lui-même). On peut ensuite en déduire la date de la source 
> (même s'il reste théoriquement possible d'importer des données 
> anciennes, la garantie n'étant jamais absolue (on peut aussi écrire 
> n'importe quelle date dans un tag source ou se tromper)).
Oui je suis couillon, je l'avais déjà vu à l'usage du (formidable) 
plug-in Cadastre de JOSM ;-)


> A mon avis, la clause qui pose le plus de problème concerne la 
> non-altération des données car l'OdBL ne fixe aucune limite dans ce 
> domaine (et pour cause, ça n'intéresse pas OSM).
>
> C'est pourquoi à mon avis, il nous faudra toujours une autorisation 
> explicite d'utiliser les données pour OSM avec ce type de CGU (ce qui 
> est le cas pour le cadastre ou Corine Land Cover).
>
> Pieren

En relisant la loi de 1978 à l'occasion de ton message je vois que 
l'article 12 précise : "*Sauf accord de l'administration*, la 
réutilisation des informations publiques est soumise à la condition que 
ces dernières ne soient pas altérées, que leur sens ne soit pas dénaturé 
et que leurs sources et la date de leur dernière mise à jour soient 
mentionnées". Ce qui veut donc dire en effet qu'une administration peut 
autoriser la non mention de la date de mise à jour et l'éventuelle 
dénaturation des données.

Du coup je vois trois options. Rêvons un peu.

1. OSM qui commence à avoir un certains poids, va négocier au coup par 
coup une autorisation explicite. Ce qui alourdi tout de même le process. 
Et qui est peut-être dangereux juridiquement pour les collectivités car 
la loi leur impose de ne pas faire de discrimination dans la 
réutilisation de leurs données : un acteur public qui l'autorise pour 
OSM, doit donc logiquement autoriser les mêmes conditions pour tous les 
autres. La voie la moins mauvaise actuellement ?

2. On demande à l'APIE s'ils peuvent envisager un autre modèle de CGU où 
ce point est explicitement mentionné : autorise à dénaturer les données. 
La difficulté étant peut-être que les collectivités publiques vont avoir 
peur d'ouvrir leurs données de cette manière pour tout un tas de raisons 
valables ou pas. Tel pourrait peut-être avoir peur d'avoir sa 
responsabilité engagée ou son image ternie dans le cas d'un sentier de 
randonnée dénaturé en autoroute (je caricature, hein). Là encore, j'en 
appelle à ceux qui ont suivi la discussion avec les personnels du 
Cadastre et de CLC : ce sujet là ne leur a pas posé de problème ?

3. On demande aux gens d'opendatacommons, auteurs de plusieurs licences 
type CC pour les données, dont l'ODbL, de pondre une licence équivalente 
à l'ODbL mais avec l'impossibilité de dénaturer les données et OSM 
décide de l'adopter. Je sais ce n'est pas simple et j'en vois sourire au 
fond. Mais Creative commons a bien produit une telle licence pour les 
contenus. Pourquoi ce manque chez opendatacommons ? Par ailleurs, je 
maitrise mal les impacts de ça sur OSM : peut-il y avoir des impacts 
négatifs ?

Pour le point 2, je suis régulièrement en contact avec les gens de 
l'APIE et je peux leur poser la question, mais, tant qu'à faire, 
j'aimerais bien préparer ma question et avoir des arguments intéressants.

Charles.

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20101109/7aeb18a4/attachment.htm>