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
[3]
http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline
On Mon, Aug 25, 2014 at 12:53 AM, Eugene Alvin Villar sea...@gmail.com
wrote:
On Mon, Aug 25, 2014 at 12:08 PM, Alex Barth a...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk
