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

Kathleen Lu kathleen.lu at mapbox.com
Mon Oct 7 18:55:11 UTC 2019


On Mon, Oct 7, 2019 at 11:16 AM Lars-Daniel Weber <Lars-Daniel.Weber at gmx.de>
wrote:

> From: "Kathleen Lu via legal-talk" <legal-talk at openstreetmap.org>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20191007/36006ab7/attachment.html>


More information about the legal-talk mailing list