Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Michal Palenik]

hi, 

On Sun, Sep 27, 2015 at 05:54:59PM -0400, Alex Barth wrote:
> > Turning this around, when do you think share-alike should apply in a
> > geocoding context?
> >
> 
> If you methodically use a geocoder to reverse engineer the OpenStreetMap
> database, share alike would kick in. "Reverse engineering OpenStreetMap"
> would need a better definition and it would have to cover two dimensions:
> 
> 1. Comprehensiveness (not just a "narrow extract" like addresses, buildings
> or businesses, but rather a comprehensive extract of the most important
> OpenStreetMap features together)

well, if you need just those features, then the extract is comprehensive.
by definition, there is no such thing as "narrow extract" which is not
comprehensive.

> 2. Geographic size (e. g. a country)
> We could establish these limits with an update to the community guidelines
> for what's Substantial.

the definition of unsubstantial I'd like to pass is something like "less
than a weekend work of semi experienced mapper". a country export (by
any definition) is far far more than substantial.

please.

michal

> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk


-- 
michal palenik
www.freemap.sk
www.oma.sk


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Tom Lee]

> In a way I would actually support [geocoding results being considered
non-substantive extracts] if geo-coding was a clearly and tightly defined
process, which, as I've pointed out earlier, it isn't.

Are you referring to this thread, Simon, or a larger conversation
elsewhere? If the latter, I'd e grateful for a link.

While I agree with you about the slipperiness of geocoding in the abstract,
as Alex points out it should be possible to narrow the scope within a
guideline. After all, when we license geocoding data from big proprietary
vendors, their lawyers, at least, feel it's possible to define geocoding
and to define unacceptable use in a way that protects their assets. Without
naming names or specific terms, I can point to this language from our TOS
as an example of how these requirements are passed along:

"You may not use geocoding results to develop a general database of
locations or addresses for any neighborhood, city, state, country, or other
such geographic region, or to develop any other general purpose digital map
database."

Naturally it would be preferable to work out a guideline that gives users
more freedom than proprietary vendors allow us to provide. But I think this
at least points in a useful direction (though of course the mechanism here
would be the non-substantive status of the geocoding product, not a bespoke
contractual provision).

On Mon, Sep 28, 2015 at 8:12 AM, Alex Barth  wrote:

>
> On Mon, Sep 28, 2015 at 5:10 AM, Simon Poole  wrote:
>
>> The later naturally makes the former unnecessary,  so we might as well
>> simply propose that geo-coding creates a non-substantive extract (which has
>> been suggested btw in a different forum and is in discussion in the LWG).
>>
>
> This would work.
>
>
>> In a way I would actually support this if geo-coding was a clearly and
>> tightly defined process, which, as I've pointed out earlier, it isn't.
>>
>
> We could work on a definition of geocoding for the purpose of a guideline
> though.
>
>
> ___
> 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

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Alex Barth]

On Mon, Sep 28, 2015 at 5:10 AM, Simon Poole  wrote:

> The later naturally makes the former unnecessary,  so we might as well
> simply propose that geo-coding creates a non-substantive extract (which has
> been suggested btw in a different forum and is in discussion in the LWG).
>

This would work.


> In a way I would actually support this if geo-coding was a clearly and
> tightly defined process, which, as I've pointed out earlier, it isn't.
>

We could work on a definition of geocoding for the purpose of a guideline
though.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Chris Hill]

On 27/09/15 22:54, Alex Barth wrote:


On Tue, Sep 22, 2015 at 7:38 PM, Paul Norman > wrote:


On 9/22/2015 4:26 PM, Alex Barth wrote:

Overall, I'd love to see us moving towards a share alike
interpretation that applies to "OSM as the map" and allows for
liberal intermingling of narrower data extracts. In plain
terms: to specifically _not_ extend the ODbL via share alike
to third party data elements intermingled with OSM data
elements of the same kind. E. g. mixing OSM and non-OSM
addresses should not extend ODbL to non-OSM addresses, mixing
OSM and non-OSM POIs should not extend the ODbL to non-OSM
POIs and so forth.


Turning this around, when do you think share-alike should apply in
a geocoding context?


If you methodically use a geocoder to reverse engineer the 
OpenStreetMap database, share alike would kick in. "Reverse 
engineering OpenStreetMap" would need a better definition and it would 
have to cover two dimensions:


1. Comprehensiveness (not just a "narrow extract" like addresses, 
buildings or businesses, but rather a comprehensive extract of the 
most important OpenStreetMap features together)

2. Geographic size (e. g. a country)

We could establish these limits with an update to the community 
guidelines for what's Substantial.



Nice try Alex, but no :-)

Your definitions are *way* too generous. I would say reverse engineering 
parts of the OSM database, such as just addresses can easily be 
substantive and therefore trigger share alike. I would say that the 
geographic size of a few streets would also be substantive and trigger 
share alike.


I know you want to move away from share alike but you won't do it by 
making a barn door definition like that IMHO.


--
Cheers, Chris
user: chillly


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Simon Poole]

I think you are clearly illustrating why we are wary of opening the can
of worms bending the definitions of the ODbL creates.

So now we not only have to take the leap of faith that geo-coding
creates a produced work*, we have to expand the definition of
substantive to allow essentially complete country extracts to be
non-substantive.

The later naturally makes the former unnecessary,  so we might as well
simply propose that geo-coding creates a non-substantive extract (which
has been suggested btw in a different forum and is in discussion in the
LWG).  In a way I would actually support this if geo-coding was a
clearly and tightly defined process, which, as I've pointed out earlier,
it isn't.

Simon

* I'm not convinced that this solves anything since derivative databases
used to produce a publicly used produced work are subject to SA


Am 27.09.2015 um 23:54 schrieb Alex Barth:
>
> On Tue, Sep 22, 2015 at 7:38 PM, Paul Norman  > wrote:
>
> On 9/22/2015 4:26 PM, Alex Barth wrote:
>
> Overall, I'd love to see us moving towards a share alike
> interpretation that applies to "OSM as the map" and allows for
> liberal intermingling of narrower data extracts. In plain
> terms: to specifically _not_ extend the ODbL via share alike
> to third party data elements intermingled with OSM data
> elements of the same kind. E. g. mixing OSM and non-OSM
> addresses should not extend ODbL to non-OSM addresses, mixing
> OSM and non-OSM POIs should not extend the ODbL to non-OSM
> POIs and so forth.
>
>
> Turning this around, when do you think share-alike should apply in
> a geocoding context?
>
>
> If you methodically use a geocoder to reverse engineer the
> OpenStreetMap database, share alike would kick in. "Reverse
> engineering OpenStreetMap" would need a better definition and it would
> have to cover two dimensions:
>
> 1. Comprehensiveness (not just a "narrow extract" like addresses,
> buildings or businesses, but rather a comprehensive extract of the
> most important OpenStreetMap features together)
> 2. Geographic size (e. g. a country)
>
> We could establish these limits with an update to the community
> guidelines for what's Substantial.
>
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Alex Barth]

On Tue, Sep 22, 2015 at 7:38 PM, Paul Norman  wrote:

> On 9/22/2015 4:26 PM, Alex Barth wrote:
>
>> Overall, I'd love to see us moving towards a share alike interpretation
>> that applies to "OSM as the map" and allows for liberal intermingling of
>> narrower data extracts. In plain terms: to specifically _not_ extend the
>> ODbL via share alike to third party data elements intermingled with OSM
>> data elements of the same kind. E. g. mixing OSM and non-OSM addresses
>> should not extend ODbL to non-OSM addresses, mixing OSM and non-OSM POIs
>> should not extend the ODbL to non-OSM POIs and so forth.
>>
>
> Turning this around, when do you think share-alike should apply in a
> geocoding context?
>

If you methodically use a geocoder to reverse engineer the OpenStreetMap
database, share alike would kick in. "Reverse engineering OpenStreetMap"
would need a better definition and it would have to cover two dimensions:

1. Comprehensiveness (not just a "narrow extract" like addresses, buildings
or businesses, but rather a comprehensive extract of the most important
OpenStreetMap features together)
2. Geographic size (e. g. a country)

We could establish these limits with an update to the community guidelines
for what's Substantial.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Frederik Ramm]

Hi,

On 09/24/2015 06:52 PM, Stephan Knauss wrote:
> If a printed map is a database

A printed map is not a database for us; the German court opinion you
quote has been mentioned in the run-up to the license change but it
didn't convince us.

A database has to consist of things "arranged in a systematic or
methodical way and individually accessible by electronic or other
means". While it is obviously possible for a court to stretch this
definition to printed maps, most people find the idea absurd.

> (refer to Landgericht München I, 21 O
> 14294/00) and we treat it as a produced work, why can't another database
> not be a produced work as well? For example a database used for routing
> or a database used for (reverse)geocoding.

A database that you create by repeatedly extracting snippets of
information from OSM - the results of your geocoding query - is
*clearly* a database according to the "arranged in a systematic or
methodical way..." definition.

Your logic seems to be that essentially because a court somewhere has
once said that 1 = 0 in some cases, anything goes!

> I'm out from this legal discussion. And I recommend all not having any
> degree of legals and experience with database right also not to
> participate in this discussion any more. It's all opinions. But for
> legal discussions opinions don't count much (maybe unless you are the
> judge).

I don't think that we should switch off our rational thinking just
because there are people with a law degree.

But you are right in that this discussion goes much too far into the
"what would a lawyer say" direction. We don't need that - the subject is
quite appropriately "When *should* ODbL apply to Geocoding". If we as a
project find an answer to that, then we can let lawyers fix (or
interpret) the license so that it delivers what we want.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Stephan Knauss]

Frederik Ramm writes:


geocoding results seem like
a produced work to me. I believe that I am decorating other open data
with the results of a geocoder that contains sufficient art to make it
not derived, but produced.


Our usual definition of produced work doesn't look at how much art there
is, but whether something is a database.


If a printed map is a database (refer to Landgericht München I, 21 O  
14294/00) and we treat it as a produced work, why can't another database  
not be a produced work as well? For example a database used for routing or  
a database used for (reverse)geocoding.


ODBL defines it as:
“Produced Work” – a work (such as an image, audiovisual material, text, or  
sounds) resulting from using the whole or a Substantial part of the  
Contents (via a search or other query) from this Database, a Derivative  
Database, or this Database as part of a Collective Database.


It gives examples of works, but IMHO does not limit it to such.
So if you produce a database by using the whole or a substantial part of  
the contents then you have a produced work.


If you copy extensive listings of job offers from a newspaper you did not  
violate database rights (München 6 U 2812/00). If you copy the music charts  
listing, you did (München 29 U 4008/02).


The nuances of when something is a database and when not is much different  
in a legal sense than what the typical technician would assume.


I'm out from this legal discussion. And I recommend all not having any  
degree of legals and experience with database right also not to participate  
in this discussion any more. It's all opinions. But for legal discussions  
opinions don't count much (maybe unless you are the judge).



Stephan

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Martin Koppenhoefer]

sent from a phone

> Am 24.09.2015 um 11:23 schrieb Frederik Ramm :
> 
> 
> I would hesitate to apply this rule for making a selection that can not
> be repeated ("select reverse geocoding results for this non-public list
> of coordinates and store them in my non-public derived database").


I had understood that a database containing the list of coordinates would have 
to be made public (on request), just not what they were standing for/how they 
were gathered.



> 
> Whether something is useful to us or not is not a factor in determining
> where ODbL share-alike applies. This is not great - I'd love a license
> that forces people to share stuff we're interested in and ignores
> everything else. But it is hard to put that in lawyerese ;)


it would also open a can of worms to get to a definition of what is stuff we 
are interested in.


cheers 
Martin 
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Frederik Ramm]

Hi,

On 09/24/2015 10:17 AM, Martin Koppenhoefer wrote:
>> and another with exactly these coordinates and their
>> OSM reverse geocoding result, and that you join them when displaying,
>> and make the OSM result database available under ODbL on request
> 
> Does he even have to? Isn't this covered by the trivial transformations rule? 

I think the trivial transformations rule would cover use cases where a
selection is made from OSM intrinsic properties ("everything with the
tag X"). This can easily be repeated by everyone.

I would hesitate to apply this rule for making a selection that can not
be repeated ("select reverse geocoding results for this non-public list
of coordinates and store them in my non-public derived database").

The case where the selection criteria are external to OSM, but publicly
available, is somewhere in between. I would always recommend erring on
the side of caution.

> In particular he doesn't add anything to OSM that isn't already in it, so 
> there's nothing to share that would be useful to us.

Whether something is useful to us or not is not a factor in determining
where ODbL share-alike applies. This is not great - I'd love a license
that forces people to share stuff we're interested in and ignores
everything else. But it is hard to put that in lawyerese ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Simon Poole]

My understanding of the trivial transformation guideline is that the
data in the nominatim instance would fall under it (so you are not
obliged to supply somebody that  asks with a dump of your nominatim
database or your osm2pgsql rendering database etc etc, you can simply
point to the original data), not necessarily results extracted from it.

Some effort was spent during discussion of a potential metadata
guideline to use usefulness and/or interestingness as a criteria for
when SA applies, however that is IMHO a hopeless dead end, so yes
sometimes SA is going to be attached to stuff that nobody is ever going
to want to reuse.

Simon

Am 24.09.2015 um 10:17 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> Am 24.09.2015 um 10:00 schrieb Frederik Ramm :
>>
>> and another with exactly these coordinates and their
>> OSM reverse geocoding result, and that you join them when displaying,
>> and make the OSM result database available under ODbL on request
>
> Does he even have to? Isn't this covered by the trivial transformations rule? 
> It might be technically complex, but as he used Nominatim, which is available 
> as open source for everyone, the mere application of an unmodified Nominatim 
> seems trivial.
>
> In particular he doesn't add anything to OSM that isn't already in it, so 
> there's nothing to share that would be useful to us.
>
> cheers 
> Martin 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk




signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Martin Koppenhoefer]

sent from a phone

> Am 24.09.2015 um 10:00 schrieb Frederik Ramm :
> 
> and another with exactly these coordinates and their
> OSM reverse geocoding result, and that you join them when displaying,
> and make the OSM result database available under ODbL on request


Does he even have to? Isn't this covered by the trivial transformations rule? 
It might be technically complex, but as he used Nominatim, which is available 
as open source for everyone, the mere application of an unmodified Nominatim 
seems trivial.

In particular he doesn't add anything to OSM that isn't already in it, so 
there's nothing to share that would be useful to us.

cheers 
Martin 
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Frederik Ramm]

Randy,

On 09/23/2015 07:18 PM, Randy Meech wrote:
> 3. The database you have created is partly derived from OSM (as far as
> "this address is at location lon=x, lat=y" is concerned).
> 
> Actually I mis-spoke a bit (sorry, it was several years ago). The
> lat/lngs are actually from state agencies, although I did reverse
> geocoding with Nominatim and store the results in the database.

So you're not using the OSM-derived part for any computation ("which one
is nearest"), but just as an additional display for the user.

In your use case, you could conceivably do the reverse geocoding on the
fly when the user clicks on "view details", rather than do it for all
addresses in advance. Then your database would never contain anything
from OSM.

If your use case were, as I first assumed, that you needed the OSM
coordinates to even offer your service (compute distances), then
on-the-fly would not be an option, technically.

Not that this is particularly relevant in terms of the license but I
think it is an interesting distinction between the two use cases.

> geocoding results seem like
> a produced work to me. I believe that I am decorating other open data
> with the results of a geocoder that contains sufficient art to make it
> not derived, but produced.

Our usual definition of produced work doesn't look at how much art there
is, but whether something is a database. If we did ask "how much art is
there", I'd be tempted to say there's considerably more art in reverse
geocding than there is in forward geocoding.

> Curious about others' thoughts here -- I do think this is an important
> topic to figure out and I'm happy to be a guinea pig for this.

If you came to me with your use case and asked "what would you have me
do to be sure I don't run afoul of the license", I would recommend that
you have two databases or two database tables, one with your POIs and
their coordinates, and another with exactly these coordinates and their
OSM reverse geocoding result, and that you join them when displaying,
and make the OSM result database available under ODbL on request. I
would also tell you that it is very unlikely for anyone to request the
data in the first place.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Randy Meech]

On Wed, Sep 23, 2015 at 2:01 AM Frederik Ramm  wrote:

> Hi,
>
> On 09/23/2015 04:49 AM, Randy Meech wrote:
> > I used the MapQuest Nominatim
> > service to geocode and/or reverse geocode all the global tide stations
> > used in the app. What would the community have me do?
>
> As a step one, and before we discuss the potential licensing
> consequences, would you agree that
>
> 1. What you have created to power your app is a database.
>

Yes


> 2. The database you have created is partly derived from a non-OSM source
> (as far as the "there is a tide station at this address" is concerned).
>

Yes, most of the data is from non-OSM sources. Just the results of reverse
geocodes are from Nominatim/OSM.


> 3. The database you have created is partly derived from OSM (as far as
> "this address is at location lon=x, lat=y" is concerned).
>

Actually I mis-spoke a bit (sorry, it was several years ago). The lat/lngs
are actually from state agencies, although I did reverse geocoding with
Nominatim and store the results in the database.


> Is there any doubt about any of these three statements either on your
> side or anyone else's?
>

So again, I don't really care about publishing this under ODbL, but to
argue the point, I'm not sure I agree with the third statement. If I had
taken raw OSM data and derived something from it, I would agree with this.
But -- to Alex's overall point -- the geocoding results seem like a
produced work to me. I believe that I am decorating other open data with
the results of a geocoder that contains sufficient art to make it not
derived, but produced.

Curious about others' thoughts here -- I do think this is an important
topic to figure out and I'm happy to be a guinea pig for this.

-Randy
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Frederik Ramm]

Hi,

On 09/23/2015 04:49 AM, Randy Meech wrote:
> I used the MapQuest Nominatim
> service to geocode and/or reverse geocode all the global tide stations
> used in the app. What would the community have me do? 

As a step one, and before we discuss the potential licensing
consequences, would you agree that

1. What you have created to power your app is a database.

2. The database you have created is partly derived from a non-OSM source
(as far as the "there is a tide station at this address" is concerned).

3. The database you have created is partly derived from OSM (as far as
"this address is at location lon=x, lat=y" is concerned).

Is there any doubt about any of these three statements either on your
side or anyone else's?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Randy Meech]

On Tue, Sep 22, 2015 at 9:43 PM Tom Lee  wrote:

> If more people can run geocoding services built on OSM data, more people
> will have an incentive to improve the map in order to improve their
> results. I'm not merely speculating: I spend most of my time working on the
> Mapbox geocoder these days. If, when a user reports a missing small town
> boundary for a reverse geocode, I could fix the problem by adding the
> boundary to OSM, I would be delighted.
>

Totally agreed on this. When we set up the free Nominatim service at
MapQuest years ago, part of the thesis (besides utilizing spare compute
power freed up by declining AOL dial-up customers ;) was to create a large
group of developers who would use the services and improve the data, an
effort that I believe was successful. I've heard many anecdotes of
individuals and teams doing just as Tom suggests -- fixing the data to
improve their geocoding results.

We talk of OSM as a community of individuals, but some of those individuals
are in companies and working on projects that need geocoding -- they can
improve the data in non-automated ways just like anyone else & should be
encouraged by clarity on the license.

We never worried about what people did with our Nominatim service, we
passed along the license and let people do what they wanted. I wonder how
many companies are in a licensing grey area now as a result, and I also
wonder how much it really matters in the end.

For example -- I have a side project I built years ago called Tides Near
Me. It's the most popular tides app in the iTunes & Google Play stores, and
also has a decent web presence. I used the MapQuest Nominatim service to
geocode and/or reverse geocode all the global tide stations used in the
app. What would the community have me do? I'm actually curious, let's use
this as a litmus test, what should I do with this database? What do we
want? Personally, because I haven't improved any OSM-relevant data that I'm
not sharing back, I don't see how it would benefit anyone to open this (but
I also wouldn't really care about opening it). What do you think I should
do and why?

-Randy
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Tom Lee]

> Turning this around, when do you think share-alike should apply in a geocoding
context?

I think there are two goals that a successful geocoding guidance should
meet:

1. Enable greater use of OSM data for geocoding, including scenarios in
which sharealike provisions must not be applied (e.g. geocoding personally
identifiable or sensitive business information)

2. Protect the integrity of the OSM project and its sharealike requirements
-- i.e., don't open a backdoor by which the project can be copied without
ODbL attaching.

At the risk of putting words in others' mouths, I've seen some people argue
that a third goal should be met: compelling geocoding users to share the
results of their geocodes. It's sometimes suggested that this could be a
valuable source of POIs.

I don't think this is a workable goal for a guidance. Even if it did induce
people to contribute data back (rather than simply avoiding OSM geocoding),
it seems unrealistic to expect the community to figure out how to establish
that there are no other IP rights at play, nor to shepherd each
contribution through the import process.

But more to the point, this is the wrong theory of action for how geocoding
can compel people to improve the map. If more people can run geocoding
services built on OSM data, more people will have an incentive to improve
the map in order to improve their results. I'm not merely speculating: I
spend most of my time working on the Mapbox geocoder these days. If, when a
user reports a missing small town boundary for a reverse geocode, I could
fix the problem by adding the boundary to OSM, I would be delighted. As
things stand, I need to correct these errors by pursuing a much more
complicated process with a proprietary data vendor.

Tom
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Rob Myers]

On 2015-09-22 16:38, Paul Norman wrote:

I'm trimming the cc list and taking this to a new thread, since it's
independent of the metadata guideline.

On 9/22/2015 4:26 PM, Alex Barth wrote:
Overall, I'd love to see us moving towards a share alike 
interpretation that applies to "OSM as the map" and allows for liberal 
intermingling of narrower data extracts. In plain terms: to 
specifically _not_ extend the ODbL via share alike to third party data 
elements intermingled with OSM data elements of the same kind. E. g. 
mixing OSM and non-OSM addresses should not extend ODbL to non-OSM 
addresses, mixing OSM and non-OSM POIs should not extend the ODbL to 
non-OSM POIs and so forth.


It's that time again! :-)


Turning this around, when do you think share-alike should apply in a
geocoding context?


As with any other context, and as described by the license, when a 
substantial portion of the database is copied.


- Rob.


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Paul Norman]

On 9/22/2015 4:38 PM, Paul Norman wrote:
I'm trimming the cc list and taking this to a new thread, since it's 
independent of the metadata guideline.


On 9/22/2015 4:26 PM, Alex Barth wrote:
Overall, I'd love to see us moving towards a share alike 
interpretation that applies to "OSM as the map" and allows for 
liberal intermingling of narrower data extracts. In plain terms: to 
specifically _not_ extend the ODbL via share alike to third party 
data elements intermingled with OSM data elements of the same kind. 
E. g. mixing OSM and non-OSM addresses should not extend ODbL to 
non-OSM addresses, mixing OSM and non-OSM POIs should not extend the 
ODbL to non-OSM POIs and so forth.


Turning this around, when do you think share-alike should apply in a 
geocoding context?


I realized after sending that it's more appropriate to say "when do you 
think share-alike does apply", not "should apply".


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk