
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><span></span></div><div dir="ltr"><br><br><div id="AppleMailSignature" dir="ltr">sent from a phone</div><div dir="ltr"><br>On 7. Oct 2019, at 19:48, Kathleen Lu via legal-talk <<a href="mailto:legal-talk@openstreetmap.org">legal-talk@openstreetmap.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr">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 <a href="https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline">https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline</a></div></blockquote><br><div><br></div><div>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)</div><div><br></div><div>Cheers Martin </div></div></body></html>