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

[Alex Barth]

On Thu, Feb 19, 2015 at 11:52 PM, Simon Poole <simon at poole.ch> wrote:

> >
> http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative
> >
> > 1. Why is the input data part of the Derivative Database?
>
> There is an underlying assumption that the input data will match, in the
> best case exactly, an object in the OSM dataset, and that you are
> extracting further information about it (aka its geographic location)
> from the OSM data.
>
> Note that in this model we are treating the input data as a key in to
> the geocoded dataset.
>
> Treating the geocoded results plus input data as a derivative DB
> sidesteps various issues. They have their roots in, on the one hand, the
> most popular OSM based geocoder not just returning a pair of coordinates
> and, on the other hand, us having no control over how geocoding is
> technically implemented. It further makes clear if that you are using
> more attributes to improve the geocoding that they are subject to the
> same terms.


Not sure I follow here. The "geocoded results plus input data" in and
itself would be in the most common cases not Substantial even by OSM's very
aggressive definition of what's Substantial (< 100 features OTOH).

So it depends on how you'd store the results returned by the geocoder and
whether you'd store the input data with it. Which brings us to point 2:

>> 2. This language is not explicit about Geocoding Results from other
>> databases that are stored in the same database. Would they be part of
>> the Derivative Database?

> I believe that is a not an issue as formulated. You would need a clear
> way of keeping the data separate. For lack of a better example: two
> tables: addresses geocoded with OSM, addresses geocoded with here, but
> IMHO labelling the geocoding source could be considered enough (given
> that you may want to provide dynamically displayed attribution you would
> likely want to do this in any case).

Now this interpretation together with the linked data concept of the same
Collective Database alternative (below) would mean that only data directly
retrieved from OSM would ever be covered by the ODbL. The ODbL would not
extend to any data added to the same database. Right?

> Any additional data that may be linked to this data, even sitting in the
same
> logical database table, is however not considered to be part of the
derivative
> database (instead it forms a collective database together with the
derivative
> database) and therefore, does not have to be shared under the ODbL.

http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20150309/39869315/attachment.html>