[OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset

Kathleen Lu kathleen.lu at mapbox.com
Mon Oct 7 17:48:03 UTC 2019

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
(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 <Lars-Daniel.Weber at gmx.de>

> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20191007/0b47bb12/attachment.html>

More information about the legal-talk mailing list