Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
sent from a phone > On 7. Oct 2019, at 19:48, Kathleen Lu via legal-talk > wrote: > > In my view, if you are keeping the two zip codes in different columns and not > removing duplicates, then essentially what you have is one property that is > "OSM ZIP" and one property that is "proprietary ZIP", and they are two > different properties that are not used to improve each other, so it is a > collective database per > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline As I read the collective db guideline, you cannot have both, the ZIP codes from your proprietary database and those from OpenStreetMap, in the same database matched to the same objects. It says “add or replace” a property (we do agree the ZIP codes are a property and not a primary feature?). If you keep both ZIP codes in your db, it implies you need both columns, which implies you are somehow mixing them at some point (or you could drop the proprietary ZIP codes, as you won’t need them) Cheers Martin ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
On Mon, Oct 7, 2019 at 11:16 AM Lars-Daniel Weber wrote: > From: "Kathleen Lu via legal-talk" > > In my view, if you are keeping the two zip codes in different columns > > and not removing duplicates, then essentially what you have is one > > property that is "OSM ZIP" and one property that is "proprietary ZIP", > > and they are two different properties that are not used to improve each > > other, so it is a collective database per > > > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline > > Okay, thanks for clarification. Then the specific column is under ODbL and > the other columns can be proprietary. > But I need to tell others, not to compare both ZIPs datasets and get "the > best of both worlds", right? > > Exactly > > (However, I am doubtful that the ZIPs would be considered > > nonsubstantial, since that definition is not based on how many columns > > of OSM is used.) > > Ah okay, there's the 100 features directive in OSM, which I didn't know > about. > > The 100 features is *one way* (that is relatively easy to understand) but not the only way for an extraction to be insubstantial. However, that said, I would be doubtful that, for example, an extraction of all ZIPs in OSM could be insubstantial. Where the line is has not been conclusively established. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
From: "Kathleen Lu via legal-talk" > In my view, if you are keeping the two zip codes in different columns > and not removing duplicates, then essentially what you have is one > property that is "OSM ZIP" and one property that is "proprietary ZIP", > and they are two different properties that are not used to improve each > other, so it is a collective database per > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline Okay, thanks for clarification. Then the specific column is under ODbL and the other columns can be proprietary. But I need to tell others, not to compare both ZIPs datasets and get "the best of both worlds", right? > (However, I am doubtful that the ZIPs would be considered > nonsubstantial, since that definition is not based on how many columns > of OSM is used.) Ah okay, there's the 100 features directive in OSM, which I didn't know about. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] map drawn based on OSM tiles
> Thus, assuming the shapefiles are essentially the equivalent of > > simplified OSM border shapefiles, the shapefiles are covered by ODbL. > > Actually, it's like 40% OSM borders (hard borders, like roads, rivers, > topography and administrative stuff) and 60% own borders, which don't > appear in OSM. BUt those borders wouldn't make OSM any better, since > they're specific for the current task. > > My view would be the OSM borders are ODbL. Just because it's one shapefile doesn't mean all of the data in the shapefile has to be under one license. If the other borders are not border types that are in OSM that you have traced, ODbL does not implicate them per the Collective Database Guideline. > > Now, it sounds like you're not tracing very much, so it's possible that > > you have traced fewer than 100 features in which case your tracing is > > insubstantial > > > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline > > Actually, I've traced more than 100 features, but the "extraction is > non-systematic and clearly based on your own qualitative criteria" - okay, > not on my one, but on the one who draw the overlay with the pen. > > It's possible that your extraction is insubstantial, though I can't say definitively. But I don't think that you need a definitive answer on whether it's insubstantial, since if your usecase is as a filter to select POIs, then you can do that whether the borders make up a substantial extract or not, and you are willing to provide attribution anyway, so you do not need to conclusively avoid ODbL. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] map drawn based on OSM tiles
From: "Kathleen Lu via legal-talk" > So if what is extracted is solely what was in the database, then the > extraction is not > material that the tile license covered (the tile license cannot actually > change the license of the data, which is ODbL, as that would be > impermissible under ODbL). Yeah, that's why I assumed, too. > Thus, assuming the shapefiles are essentially the equivalent of > simplified OSM border shapefiles, the shapefiles are covered by ODbL. Actually, it's like 40% OSM borders (hard borders, like roads, rivers, topography and administrative stuff) and 60% own borders, which don't appear in OSM. BUt those borders wouldn't make OSM any better, since they're specific for the current task. > Now, it sounds like you're not tracing very much, so it's possible that > you have traced fewer than 100 features in which case your tracing is > insubstantial > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline Actually, I've traced more than 100 features, but the "extraction is non-systematic and clearly based on your own qualitative criteria" - okay, not on my one, but on the one who draw the overlay with the pen. But what does this result in? Sorry for asking... it's a real life problem, not a constructed one. And please remember the other question I've asked. I haven't found an answer on the web or the OSM boards. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
In my view, if you are keeping the two zip codes in different columns and not removing duplicates, then essentially what you have is one property that is "OSM ZIP" and one property that is "proprietary ZIP", and they are two different properties that are not used to improve each other, so it is a collective database per https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline (However, I am doubtful that the ZIPs would be considered nonsubstantial, since that definition is not based on how many columns of OSM is used.) On Sun, Oct 6, 2019 at 6:09 AM Lars-Daniel Weber wrote: > Dear users, > > I'm often intersecting geodata with a license, which is in a > non-ODbL-compatible license, with OSM data to enrich this data. Normally, > I'm doing this for internal (private) use only, but I want to publish such > a dataset now. > > For example, I'm getting postal ZIP codes from OSM and add these to other > POI data. I'm keeping the original ZIP codes from the source and the ZIP > codes from OSM and I'm not completing the ZIP codes by each other - they > don't interact, I'm not removing duplicates and they're in two different > columns. Of course, ZIP codes don't seem to be a substantial part, but the > data is related by each other, since I've intersected (joined) both > datasets. > > Is the joined result a "Collective Database" or a "Produced Work", since > it only contains a non-substantial part (only one string column) from OSM? > > Sincerely yours, > Lars-Daniel > > > > ___ > legal-talk mailing list > legal-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/legal-talk > ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] map drawn based on OSM tiles
In my mind, the tile license (CC-BY-SA) sits on top of the database license, as the license to a produced work by the OSMF. So if what is extracted is solely what was in the database, then the extraction is not material that the tile license covered (the tile license cannot actually change the license of the data, which is ODbL, as that would be impermissible under ODbL). This is the same principle, that if you use a CC-BY song in a music video that is licensed as CC-BY-SA, and then someone comes along and rips the song from the music video, the song is still CC-BY, not CC-BY-SA. Thus, assuming the shapefiles are essentially the equivalent of simplified OSM border shapefiles, the shapefiles are covered by ODbL. Now, it sounds like you're not tracing very much, so it's possible that you have traced fewer than 100 features in which case your tracing is insubstantial https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline On Mon, Oct 7, 2019 at 8:08 AM Lars-Daniel Weber wrote: > From: "Simon Poole" > > I'm not ruling out the first interpretation either and potentially both > > licenses would have to apply in full (which isn't possible without > > conflict). > > I would like to clarify once again that I really do want to attribute OSM. > But it's damn difficult for me to find out under which license my work > falls. > I know lots of people, loading OSM tiles in QGIS and draw stuff on it. So > I'm pretty confused that there aren't any guidelines discussed. > > > But if the shape files are simply used for display purposes as a > > tendency I would find that they are still being used as a produced work > > as per > > > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline > > Which from the ODbL pov requires attribution and a pointer back to the > > data source, which you can provide without being in conflict with CC > > BY-SA terms that you would have to adhere to. > > No, the shapefile will be used for further geoprocessing: selection of > POI, which are non-free, but fall into the border I've digitized upon the > OSM background map. > > Would you recommend > 1. to use another datasource as background map or > 2. draw all borders on an OSM extract once again? > > Since neither the drawing, nor my digitalization uses OSM data, I'm really > asking myself if it's not a trivial act at all? > Wouldn't "Drawn on OSM tiles in CC-BY-SA 2.0, based on OSM data in ODbL" > be enough as attribution? > > ___ > legal-talk mailing list > legal-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/legal-talk > ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] map drawn based on OSM tiles
From: "Simon Poole" > I'm not ruling out the first interpretation either and potentially both > licenses would have to apply in full (which isn't possible without > conflict). I would like to clarify once again that I really do want to attribute OSM. But it's damn difficult for me to find out under which license my work falls. I know lots of people, loading OSM tiles in QGIS and draw stuff on it. So I'm pretty confused that there aren't any guidelines discussed. > But if the shape files are simply used for display purposes as a > tendency I would find that they are still being used as a produced work > as per > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline > Which from the ODbL pov requires attribution and a pointer back to the > data source, which you can provide without being in conflict with CC > BY-SA terms that you would have to adhere to. No, the shapefile will be used for further geoprocessing: selection of POI, which are non-free, but fall into the border I've digitized upon the OSM background map. Would you recommend 1. to use another datasource as background map or 2. draw all borders on an OSM extract once again? Since neither the drawing, nor my digitalization uses OSM data, I'm really asking myself if it's not a trivial act at all? Wouldn't "Drawn on OSM tiles in CC-BY-SA 2.0, based on OSM data in ODbL" be enough as attribution? ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] map drawn based on OSM tiles
Am 07.10.2019 um 01:23 schrieb Lars-Daniel Weber: > I thought, whenever you re-digitize OSM data from a printed map, it would get > ODbL again. According to current ruling by European Court of Justice, a > printed map is just a database (it has been judged for a German topographical > map in small scale). > > So if I had freely drawn the borders based on extract of OSM (with the paper > on the desk), it would fall under ODbL? > I'm not ruling out the first interpretation either and potentially both licenses would have to apply in full (which isn't possible without conflict). But if the shape files are simply used for display purposes as a tendency I would find that they are still being used as a produced work as per https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline Which from the ODbL pov requires attribution and a pointer back to the data source, which you can provide without being in conflict with CC BY-SA terms that you would have to adhere to. signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
