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 <lars-daniel.we...@gmx.de>
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

Reply via email to