[OSM-legal-talk] Updated geocoding community guideline proposal

Alex Barth alex at mapbox.com
Mon Oct 27 23:47:47 UTC 2014

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].

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.

Column 1 entirely enables permanent geocoding with OpenStreetMap data from
a legal perspective.

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.

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.

Would love suggestions on how to proceed on taking a decision here.

[1] https://lists.openstreetmap.org/pipermail/talk/2014-October/071153.html
[2] https://lists.openstreetmap.org/pipermail/talk/2014-October/071135.html

On Mon, Aug 25, 2014 at 12:53 AM, Eugene Alvin Villar <seav80 at gmail.com>

> On Mon, Aug 25, 2014 at 12:08 PM, Alex Barth <alex at mapbox.com> wrote:
>> How would the Collective Database approach work if the OSM Database must
>> remain unmodified to be part of a Collective Database?
>> 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:
>> > “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:
>> http://opendatacommons.org/licenses/odbl/1-0/#sthash.mDtnZAPO.dpuf
> 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.
> 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.
> Then, this geocoder database can become part of the collective database.
> _______________________________________________
> 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/20141027/6177f25b/attachment.html>

More information about the legal-talk mailing list