Talk:Open Data License/Metadata Layers - Guideline
Primary key linking
Just a thought about the primary key linking and the "extra_node_tags" table: Would something of the following help define this any more clearl?. For a database not to be considered derivative when linking through the primary key, the non osm-db has to be able to be self contained. I.e. if the link to OSM were cut, it would still constitute a sensible database and be able to perform is primary intent. So a restaurant guide would work, as even without the link to OSM, the restaurant guide would be fully functional, just not be able to highlight the address as easily. The extra_node_tags table presumably wouldn't pass this criterion, as without the main_node_tags_table, the database is of limited use. Amm 19:02, 10 June 2010 (UTC)
Problem with uncertainty
From the main page: "However, this would almost certainly present a moving target and could be indistinct. It's possible this would discourage people from using the data for fear that their linked data could become "interesting" at some future point, and have to be released."
I want to +1/support this point, and elaborate on it a bit. We (Wikimedia) are building something for the long run; we can't decide to use a data source, integrate it throughout Wikipedia and other Wikimedia projects, and then have someone decide "oh, this is now interesting to us, you have to switch from CC to ODbL or stop using the information". We need clear, stable guidelines on what is and isn't permissible, or we're going to have problems using/integrating with OSM in the long run. And relative to other potential users, we're extremely flexible :) Based on my past corporate experience, this sort of thing as described here would be extremely off-putting for any corporate users who wanted to use or interoperate with OSM data. -LuisVilla (WMF) (talk) 18:36, 18 September 2013 (UTC)
Support from the text?
It might be helpful for the "interestingness" criteria to explain why/how it is supported in the text of the license; or, if it is not supported by the text of the license, to explain how enforcement would work (for example, some large number of rights holders have agreed to enforce this principle, or...) —LuisVilla (WMF) (talk) 16:21, 28 April 2014 (UTC)
A possible way out
I firmly believe that the route to resolving a lot of the grey areas in our interpretation of the licence goes via nailing this down in a reasonable way. As can be seen from above trying to define this via "interestingness" is a dead end because too variable and too subjective. What about simply codifying what we really want?
Suggested text:
A database containing one or more datasets derived from OpenStreetMap data and other sources is considered an ODbL collective database if one of the following conditions are fulfilled by the database elements from other sources:
- the elements do not contain references to OpenStreetMap original or derived elements
- the elements that contain references to OpenStreetMap elements do not replace or modify existing attributes or geometry of the referenced OpenStreetMap original (non-derived) elements.
For the purpose of this guideline
- a reference can be a primary or composite database key or any other method of identifying a specific OpenStreetMap derived element.
- adding additional attributes by means of such a reference is not considered modifying the existing attributes of the referenced OpenStreetMap element.
- refering from an OpenStreetMap derived element to an element from an other source in the database is considered equivalent to a reference in the other direction.
This is quite a mouthful but would seem to be fully compatible with our guidelines up to now and solve a number of Gordian knots.
SimonPoole (talk) 12:18, 26 June 2015 (UTC)