LO et ODbL c'est vraiment kif-kif au niveau droit: attribution/paternité nécessaire dans les deux cas, distribution libre, modification libre, absence de responsabilité de l'auteur sur les copies ou modifications (et LO comme ODbL est aussi explicitement compatibles pour l'import unidirectionnel vers du GPL ou LGPL, mais pas vers le domaine public ou CC0, du fait de la disparition de l'attribution obligatoire ni même MIT/BSD). L'importe LO ou ODbL vers CCBYSA reste possible aussi (heureusement sinon on n'a pas de fonds de cartes) car il y a préservation de l'attribution/paternité (et toujours le même déni de responsabilité). Mais LO est un peu plus libéral que ODbL concernant l'importe vers une base de données (car ODbL ajoute une restriction sur le droit adhoc des bases de données concernant la création d'aggrégats de contenus: en loi française, cette aggrégation n'est pas une "oeuvre dérivée" mais une oeuvre par elle-même couvrant non pas les données importées elles-mêmes, mais le travail d'agrégation et d'indexation du contenu global venant d'une ou plusieurs autres sources ; LO, tout comme GPLv2 ou LGPLv2, mais pas GPLv3 ou LGPLv3 qui ont des clauses concernant aussi le droit adhoc des brevets et bases de données, ne restreint pas ce droit. LO permet donc une appropriation au sein d'une base propriétaire non redistribuable (ce que font l'IGN ou la Poste par exemple), même si les droits d'auteurs sont préservés concernant l'attribution, alors que ODbL implique que la base agrégée contenant une quantité significative de données doit disposer des libertés de redistribution. LO est donc un mauvais choix si on tient à garder *aussi* le droit de redistribution des bases dérivées (effet viral). ODbL a un un effet viral sur les bases dérivées et c'est pour ça que c'est peu soutenu par les grosses administrations françaises : avec LO, tout le monde peut utiliser les bases, les modifier et les redistribuer en conservant la paternité, mais LO permet à ces bases dérivées d'ajouter une clause propriétaire si la modification de la base agrège d'autres données en quantité significativement suffisante. Pour les petites agences ayant peu de données à ajouter, leur propre apprort dans les bases dérivées n'est pas significativement suffisant et donc LO n'est pas justifiable pour elles (elles n'ont sans doute pas les moyens de maintenir ensuite une version propriétaire avec assez de données dont elles seraient l'auteur dans la masse des données "virales" issues de l'ODbL ou CCBYSA, et nombre de ces petites créations sont amenées à changer d'administration du fait des réformes continuelles faisant des fusion/scissions entre elles; on ne peut que leur conseiller plutôt ODbL que LO, qui sera utile cependant pour les créations majoritairement issues de leurs propres travaux, mais que d'autres peuvent importer et intégrer vers ODbL mais pas réexporter en LO sans vérifier la source de chaque info extraite). En conséquence on ne peut pas exporter ODbL vers LO mais l'inverse est tout à fait possible. Ceux qui ont intégré des données LO dans une base ODbL ont de toute façon gardé la paternité: si on veut reprendre en licence LO, la paternité permet d'en connaitre les sources, et donc de redemander à ces sources de fournir leurs données LO (plus simpel que vérifier chaque données de la base ODBL où elles ont été agrégées. Faire une publication en double licence LO/ODBL n'est pas stupide non plus: l'auteur n'a pas à gérer des demandes pour reprendre les données LO extraites de la base ODBL. Mais c'est toute la difficulté aussi pour la synchronisation par exemple entre BAN (type LO) et BANO (type ODBL): les adresses saisies dans OSM ne sont pas facilement exploitables dans une base LO, on doit gérer un suivi élément par élément dans BANO pour continuer à faire le tri de ce qui vient déjà en LO (BAN). en revanche aucune difficulté pour importer la BAN dans BANO (qui peut tout accepter mais est en licence multiple pour des raisons de facilité) et OSM (moins pratique à suivre, il faut un outil dédié).
Le mer. 1 avr. 2020 à 15:09, <[email protected]> a écrit : > Sur le nom agrégé "Contributeurs OpenStreetMap" ou "OpenStreetMap", pas de > soucis. > > Par contre comme il s'agit d'un extrait significatif d'OpenStreetMap", en > toute logique oui, ça doit être ODbL. > > Par contre avec une requête Overpass vous pouvez récupérer les derniers > contributeurs d'un objet et raisonnablement les données :covid19 sont des > données entrées par ces contributeurs et vous pouvez leur demander le OK > pour la double licence LO/ODbL. > > Personnellement ça ne me dérange pas de vous la donner. > > Peut-être que OpenStreetMap France peut se permettre de la donner au nom > des contributeurs. > > Et pourquoi ne pas distribuer en ODbL ? Pour une concaténation de données > figurant typiquement dans une base de données, ça ne semble pas stupide. > > Autre possibilité : vous entrez les données dans OSM, puis les extrayez, > comme ça la question de la licence ne se pose pas ;-). > > Ou une double licence en précisant pour chaque objet LO ou ODbL. > > Jean-Yvon > > > Le 01/04/2020 à 13:30, GUIMARD Jean-Charles - > [email protected] a écrit : > > Bonjour, > > > > Je suis en train d’agréger différents flux de données qui permettent > d’enrichir la connaissance des lieux ouverts, des commerces, maraîchers, > etc. suivant le mode de commande et de retrait des marchandises (drive, > livraison, sur place), en indiquant les communes couvertes par la > livraison. Cela couvrira le territoire de l’eurométropole de Strasbourg et > sera accessible sur https://data.strasbourg.eu > > > > La donnée que nous allons agréger sera diffusée en Licence ouverte V2 > Etalab. Je compte indiquer pour chaque établissement, la source initiale de > l’information. > > > > Il y a des sources collaboratives comme une mymaps dont le propriétaire > est d’accord pour que les données soient redistribuées en opendata. > > Il y aura certainement des sources institutionnelles comme celle la CCI ou > la CMA. > > > > La source OSM avec la démarche « ça reste ouvert » est bien sûr une source > très intéressante. Si j’indique dans le jeu de données agrégé, la source > initiale « OSM » quand il s’agit d’une remontée d’info réalisée par un > contributeur « OSM », suis-je autorisé à l’inclure dans le jeu de données > plus général qui sera diffusé en licence ouverte ? La licence OSM ne > viendra pas « contaminer » la licence ouverte de ce jeu de données ? > > > > Bonne journée. > > > > > *Jean-Charles GUIMARD Responsable du département Usages* > > *Equipe projet Smart-data* > > *Ville et Eurométropole de Strasbourg* > *Direction Urbanisme et Territoires · Service Géomatique* > 1 parc de l'Étoile 67076 Strasbourg Cedex > > Téléphone : *+33 (0)3 68 98 50 00* > Poste : 80413 > Fax : *+33 (0)3 88 43 60 49* > > [image: http://www.site.strasbourg.eu/signature/banner_strasbourg.jpg] > <http://www.strasbourg.eu/>[image: > http://www.site.strasbourg.eu/signature/picto_fb.jpg] > <https://www.facebook.com/strasbourg.eu>[image: > http://www.site.strasbourg.eu/signature/picto_twitter.jpg] > <https://twitter.com/strasbourg>[image: > http://www.site.strasbourg.eu/signature/picto_dm.jpg] > <http://www.dailymotion.com/VilledeStrasbourg> > > > > > > > Ce message est établi à usage exclusif de son destinataire. > Toute utilisation ou diffusion, partielle ou totale, doit être > préalablement autorisée. > > Tout message électronique est susceptible d'altération et son intégrité ne > peut être assurée. > L'expéditeur décline toute responsabilité au titre de ce message s'il a > été modifié ou falsifié. > > Si vous n'êtes pas destinataire de ce message, merci de le détruire et > d'avertir l'expéditeur. > > Ville et Eurométropole de Strasbourg > > _______________________________________________ > Talk-fr mailing > [email protected]https://lists.openstreetmap.org/listinfo/talk-fr > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
