<div dir="ltr"><div>Picking up on Paul's offer to help along the discussion here [1]. Also copying Steve here as he's renewed his call for better addressing in OpenStreetMap - which I entirely agree with [2].</div><div><br></div><div>Feedback from this thread is incorporated on the wiki [2] - thanks particularly to Frederik for this work. However, we have two competing visions for how to interpret geocoding. Column 1 of the wiki page interprets the information queried from OpenStreetMap in a typical geocoding request as Produced Work, thus not extending share alike provisions to geocoded data. Column 2 interprets the content pulled from OpenStreetMap in a geocoding process as a Derivative Database but the database this content is inserted to as a Collective Database.</div><div><br></div><div>Column 1 entirely enables permanent geocoding with OpenStreetMap data from a legal perspective.</div><div><br></div><div>Column 2 doesn't enable permanent geocoding by extending share alike provisions to the part of a database that contains OSM derived geocodes. This interpretation would impede the important fall back use case where a geocoder uses OpenStreetMap data - and where OpenStreetMap data is not sufficient - proprietary data as a fallback. In such scenarios both OpenStreetMap data (e. g. lat/lon's) and proprietary data would wind up in the same database to be licensed under the ODbL. It would also impede use cases where data is expected to be relicensed.</div><div><br></div><div>For making OpenStreetMap viable as a geocoding database, we'll want a permissive reading of our license - no matter what we opine on share alike for the larger database. Of course, enabling permanent geocoding isn't the end-all-be-all strategy for making OpenStreetMap an awesome geocoding database - but it's an important incentive that we can't do without. Having more people use OpenStreetMap as a geocoding database will give us better admin polygons, better place data and better addresses. The opportunity is huge, none of the proprietary data providers provide reasonable terms for _permanent_ geocoding - making everyone look for alternatives. OpenStreetMap should be that alternative.</div><div><br></div><div>Would love suggestions on how to proceed on taking a decision here.<br></div><div><br></div><div>[1] <a href="https://lists.openstreetmap.org/pipermail/talk/2014-October/071153.html">https://lists.openstreetmap.org/pipermail/talk/2014-October/071153.html</a><br></div><div>[2] <a href="https://lists.openstreetmap.org/pipermail/talk/2014-October/071135.html">https://lists.openstreetmap.org/pipermail/talk/2014-October/071135.html</a></div><div>[3] <a href="http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline">http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 12:53 AM, Eugene Alvin Villar <span dir="ltr"><<a href="mailto:seav80@gmail.com" target="_blank">seav80@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 25, 2014 at 12:08 PM, Alex Barth <span dir="ltr"><<a href="mailto:alex@mapbox.com" target="_blank">alex@mapbox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">How would the Collective Database approach work if the OSM Database must remain unmodified to be part of a Collective Database?<br><br>The definition of Collective Database seems to be tailored to use cases where the OpenStreetMap database *in unmodified form* is part of a larger database. I can't quite conjure up a real world example, but the ODbL is pretty clear about this:<br>


<br>> “Collective Database” – Means this Database in unmodified form as part of a collection of independent databases in themselves that together are assembled into a collective whole. A work that constitutes a Collective Database will not be considered a Derivative Database. - See more at: <a href="http://opendatacommons.org/licenses/odbl/1-0/#sthash.mDtnZAPO.dpuf" target="_blank">http://opendatacommons.org/licenses/odbl/1-0/#sthash.mDtnZAPO.dpuf</a><br>
</div></blockquote></div><br></div></span><div class="gmail_extra">The "this Database in unmodified form" means the particular database that is licensed under ODbL. It can be the OSM database itself, or any database derived from the OSM database that must in itself be licensed under ODbL.<br>
<br></div><div class="gmail_extra">So if you did any transformations on the OSM database (ex., converted it into a form suitable for a geocoder), the transformed database is licensed under the ODbL. You can either publish this transformed database or provide the software used to create the transformed database to comply with the license of the source OSM database.<br>
<br></div><div class="gmail_extra">Then, this geocoder database can become part of the collective database.<br></div></div>
<br>_______________________________________________<br>
legal-talk mailing list<br>
<a href="mailto:legal-talk@openstreetmap.org">legal-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/legal-talk" target="_blank">https://lists.openstreetmap.org/listinfo/legal-talk</a><br>
<br></blockquote></div><br></div>