|
I'm unclear on what I have to redistribute, and when, when combining data from OSM and other sources. I have some data that I need to keep private/non-open, and don't want to accidentally convert it to the Open DB License. For example, if I have a list of lat/lon locations, then use OSM data to reverse geocode them and store that reverse geocode data, is that a derivative work? What about if I keep the data in separate tables, or separate databases entirely, but use some sort of identifier, (like a foreign key in a relational DB), to say "this is the ID of the lat/lon for the data I reverse geocoded"? It would seem that the two situations likely are derivative works, but I'm not 100% sure. How separate do data sets have to be to be a collective DB, not a Derivative DB? For example, if I have some data, (say, my reverse geocoded lat/lon list, which I'm assuming is a derivative DB), and I have some private data, if I store both in the same MySQL/Oracle/whatever DB, does my private data become Open DB Licensed? A large part of my private data is POIs. If I geocode them using OSM data, would they become Open DB Licensed? I know I've been wordy - thanks for the help. I read through the Legal FAQ page & want to be even more clear on what I can & can't do with OSM data. |
|
The ODbL is new for us all and we don't have a lot of practical experience with it yet. In some areas it will probably take a while until a common reading is established. One thing that is clear though is that when ODbL talks of databases, it always talks of the concept, and never of the manifestation. This means that whether your two databases reside in different buildings, or on the same computer but different database engines, or in the same engine but different tables, or even in the same table, does not make a difference for the "derivative database" question; whether one is a derivative of the other depends on what you do with it, not how you store it. Two databases A and B are clearly collective if nothing in database A has been affected by anything in database B and vice versa. For example, if you have two databases with POIs, one from OSM and one private, and you draw them both onto a map tile, then you're clearly utilising a collective database to make your tile. I think that the current interpretation of the ODbL is that pure object IDs can never constitute a substantial extract so if you have your private list of POIs and in there you have a column "osm_node_id" that points to an OSM object, that would still be considered ok and you would not be required to release your private database. Geocoding, specifically, is complex issue and there isn't a clear answer yet. Initial legal advice suggested it would make your database a derivative database (see wiki). This is also the position the Legal Working Group has been leaning towards in the meetings where the matter was discussed (meeting minutes 01 May, 08 May, 15 May, see also concept paper). I expect further discussion on that in the near future. 1
Thanks. I had figured the ODbL refers to databases conceptually, but I wanted to be clear. I hope that you're right about an "osm_node_id" column in my private database not making it a derivative database, because if it does make it a derivative database, it'll be a pain, (and computationally expensive), to de-dupe my data when actually rendering it, (assuming I use a couple of different map layers to stay compliant).
(01 Oct '12, 17:18)
jbeales
1
I'll look through the links you provided on geocoding. On one hand geocoding is simply an alternative representation of data I already have, since both address data & geocode data indicate a location on the earth, so it shouldn't be a derivative work. On the other hand it takes more than an address to figure out what the geocode is, so it should be a derivative work.
(01 Oct '12, 17:20)
jbeales
I too plan to create a collective database and the definition of what is collective and what is derivative is crucial. If the use of osm_id is fine (and I don't see why it wouldn't be as it's difficult to create a relational database without a key) then I will be happy!
(03 Oct '12, 10:45)
RichardOwen2000
|
