Re: [OSM-legal-talk] Geocoding as produced work

[Simon Poole]

Come on Alex.

If you accidentally publicly use a produced work or a derivative
database that is linked somehow with sensitive data and if somebody
actually asks you for the underlying data and if for legal (privacy) or
business reasons you can't hand out the non-OSM data part (lots of ifs),
you are in violation of the licence terms and you cease to have a
licence for the OSM derived data in question. However you can reinstate
your rights under the licence by rectifying the situation (stopping to
use the data publicly), which shouldn't be an issue since, as you
stipulate, the use is accidental.

Simon

Am 24.09.2015 um 00:32 schrieb Alex Barth:
>
> On Wed, Sep 23, 2015 at 4:22 PM, Simon Poole  > wrote:
>
> it might actually force
> such a service provider to differentiate between geo-coding for public
> vs in-house use.
>
>
> This suggestion has come up before and I'd like to flag that this is
> impractical. No organization would and should take the risk that a
> potential future (accidental) publication of a private OpenStreetMap
> based work could jeopardize sensitive data. The risk is significant as
> even the publication of a Produced Work can bring the share alike
> stipulations of the ODbL to bear.
>
>
>
> ___
> 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] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Eugene Alvin Villar]

On 9/23/15, Tom Lee  wrote:
>>
>> I mean, nobody cares about a single on-the-fly geocoding result (this
>> easily falls under the "substantial" guideline) but if you repeatedly
>> query an ODbL database with the aim of retrieving from it, say, a
>> million lat-lon pairs to store in your own database, then how in the
>> world could this new database ever be *not* a derivative? Even if you
>> were to define a single geocoding result as a produced work, combining a
>> large number of them in a database would still get you a derived
>> database again.
>
>
> Can't the same argument apply to tiles? If you used tiles to recreate the
> OSM database (say, by tracing road geometry or by OCRing feature names) and
> then republishing under a different license, you would clearly be violating
> the ODbL.
>
> It seems as though the same approach can apply to geocoding: locate
> features to your heart's content, but if you use the results to create a
> general purpose geographic database that substitutes for/competes with OSM,
> you'll be in violation of the license.

A geocoding result is substantially different from a map tile. A
single geocoded result is arguably a single piece of data that is most
probably devoid of any copyright and by itself does not have any
database rights, while a map tile is a creative work that is clearly
copyrighted.

If you have multiple geocoded results, and if those results are
organized in a manner that enabled individual access, then you already
have a database (in the legal sense). I really cannot see how such can
be considered as a Produced Work when it is clearly a Derivative
Database when a source database was used to help produce the results.

Sets of map tiles, on the other hand, are not automatically a database
and because they are primarily creative works are considered Produced
Works. Just like a photo of a storefront may have embedded trademarks
in it, a map tile may have embedded data from a database in it too. It
is only when you extract the trademark from the photo, or the data
from the map tiles that you may possibly infringe on IP rights. Note
that the operative word here is 'extract'. No such extraction occurs
with geocoded results—they are pure data already.

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

Re: [OSM-legal-talk] Geocoding as produced work

[Rob Myers]

I don't understand this objection. If a company accidentally publishes 
something that's a problem with their procedures, not any license (free or 
proprietary).

On 23 September 2015 15:32:06 GMT-07:00, Alex Barth  wrote:
>On Wed, Sep 23, 2015 at 4:22 PM, Simon Poole  wrote:
>
>> it might actually force
>> such a service provider to differentiate between geo-coding for
>public
>> vs in-house use.
>>
>
>This suggestion has come up before and I'd like to flag that this is
>impractical. No organization would and should take the risk that a
>potential future (accidental) publication of a private OpenStreetMap
>based
>work could jeopardize sensitive data. The risk is significant as even
>the
>publication of a Produced Work can bring the share alike stipulations
>of
>the ODbL to bear.
>
>
>
>
>___
>legal-talk mailing list
>legal-talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/legal-talk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Geocoding as produced work

[Alex Barth]

On Wed, Sep 23, 2015 at 4:22 PM, Simon Poole  wrote:

> it might actually force
> such a service provider to differentiate between geo-coding for public
> vs in-house use.
>

This suggestion has come up before and I'd like to flag that this is
impractical. No organization would and should take the risk that a
potential future (accidental) publication of a private OpenStreetMap based
work could jeopardize sensitive data. The risk is significant as even the
publication of a Produced Work can bring the share alike stipulations of
the ODbL to bear.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Geocoding as produced work

[Tom Lee]

Thanks, Steve, for pushing this in a productive direction; and apologies to
you, Simon for letting my frustration through.

I should emphasize: I don't think that I'm suggesting a license change at
all, and I don't mean to suggest that sharealike is broadly impractical.
I'm suggesting that a guidance be issued that clarifies how geocoding
relates to the license. And I'm suggesting that treating geocoding results
as a produced work would not pose risk to OSM; would not cost it data;
would offer advantages to some users; and would create new incentives for
improving the map.

Steve is right to point out that other businesses have decided to take the
risk that ODbL's implications for geocoding results will never be enforced.
Or they're just using the data without worrying about compliance at all. I
think it's unfortunate to dismiss this issue solely because there aren't
more actors willing to work on a clear and ethical path forward.

> however it’s also hard to see who would pay for OSM geocoding in the
first place when there’s almost no data compared to proprietary maps

This speaks to Alex's point about the need to enable iterative uses of the
data, where open data supplements proprietary sources (here's an example:
https://www.mapbox.com/blog/austrian-open-address-data/ ). The name you
chose for this problem is apt. OSM has become a wonderfully powerful tool
for the use cases it's friendly toward, like rendering tiles and routing.
OSM is relatively inflexible toward geocoding, and consequently it is not a
great tool for it. Yet.

At any rate, I can assure you that we have customers today with use cases
that could be served exclusively by OSM data--reverse place-level permanent
geocoding is top of the list. And there are many more who could benefit
from OSM data supplementing the quality of our results.


On Wed, Sep 23, 2015 at 5:33 PM, Steve Coast  wrote:

>
> Steve Coast http://stevecoast.com/ +14087310937
>
> On Sep 23, 2015, at 11:22 PM, Simon Poole  wrote:
>
> Now obviously it does limit in some aspects the T&Cs an OSM based
> geo-coding service can use for its business and it might actually force
> such a service provider to differentiate between geo-coding for public
> vs in-house use.  But then it isn't as if you are completely free to do
> what you want with a lot of other data sources either.
>
>
> Another good point: If the OSM license has some edge case problem, it’s
> still far better than proprietary licenses which are the alternative.
>
> I’m calling it "edge case” if the SNIFF TEST in my prior email is not met,
> maybe it’s just as well to call it the “EDGE CASE TEST”, which is similar
> if not identical to the MANY TEST.
>
> Just trying to pull the discussion toward black & white tests which we can
> actually pass or fail, happy to see other suggestions.
>
> Best
>
> Steve
>
> ___
> 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] Geocoding as produced work

[Michal Palenik]

I am in complete agreement with Simon.

to stress on the topic of geocoding political party donors (example), if
you don't plan to publish their individual addresses, you must not
geocode their individual specific addresses, but rather a city level
address only. 


michal

On Wed, Sep 23, 2015 at 10:22:09PM +0200, Simon Poole wrote:
> 
> 
> Am 23.09.2015 um 21:28 schrieb Tom Lee:
> > I confess that I'm not sure what to say to this. You're asserting that
> > running a geocoding business with ODbL attaching to the results is no
> > big deal, that "all the use cases you can think of" seem fine. Mapbox
> > is _actually running_ a geocoding business and telling you that we
> > would like to use OSM in it but can't sell a geocoding service that
> > has ODbL attached to the results.
> 
> No, I'm saying that for a overwhelming majority of use cases in which
> the geo-coding are used publicly the ODbL does not cause the privacy
> problems you were alluring too. Nor does it cause any problem for in
> house use at all.
> 
> Now obviously it does limit in some aspects the T&Cs an OSM based
> geo-coding service can use for its business and it might actually force
> such a service provider to differentiate between geo-coding for public
> vs in-house use.  But then it isn't as if you are completely free to do
> what you want with a lot of other data sources either. 
> 
> >
> > And no one has yet offered any examples by which ODbL attaching to
> > geocoding results has led to contributions that improved OSM. Or
> > contributions at all (the prospect of Randy's tide station data
> > notwithstanding).
> Getting back failed addresses for QA would be a start.
> 
> But the more important point is that we are not at liberty to simply
> declare by fiat that bulk geo-coding does not create a derivative
> database. The underlying problem is that geo-coding is not a clearly
> defined process, it is at best a loose concept. I doubt that anybody
> would have issue classifiying geo-coding addresses in the US to states
> (your initial example)  as a produced work, on the other hand extracting
> building entrances with attached addresses is clearly a one-to-one
> copying out of OSM, both however are "geo-coding".
> 
> Most actual use cases are going to be somewhere in between and the last
> couple of years of discussion on this topic have clearly shown that we
> will not make any progress except if we base a geo-coding guideline on
> principles that are as far as possible independent of the actual mechanics.
> 
> >
> > I realize you'll disagree, but I'm left with the same sense of what's
> > achievable and desirable for a geocoding guidance. Enable more
> > geocoding. Protect OSM's assets. Abandon the impractical goal of
> > compelling users to share their results.
> >
> I don't think there is an election going on any time soon, so please
> tone down the rhetoric. It's simply the case that we have the licence we
> have and at least for the immediate future we have to live with it and
> give our data consumers guidance in the current frame work, not in a
> make believe better world.  
> 
> Simon
> 



> ___
> 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] Geocoding as produced work

[Steve Coast]

Steve Coast http://stevecoast.com/  +14087310937

> On Sep 23, 2015, at 11:22 PM, Simon Poole  wrote:
> 
> Now obviously it does limit in some aspects the T&Cs an OSM based
> geo-coding service can use for its business and it might actually force
> such a service provider to differentiate between geo-coding for public
> vs in-house use.  But then it isn't as if you are completely free to do
> what you want with a lot of other data sources either. 

Another good point: If the OSM license has some edge case problem, it’s still 
far better than proprietary licenses which are the alternative.

I’m calling it "edge case” if the SNIFF TEST in my prior email is not met, 
maybe it’s just as well to call it the “EDGE CASE TEST”, which is similar if 
not identical to the MANY TEST.

Just trying to pull the discussion toward black & white tests which we can 
actually pass or fail, happy to see other suggestions.

Best

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

Re: [OSM-legal-talk] Geocoding as produced work

[Steve Coast]

> On Sep 23, 2015, at 10:28 PM, Tom Lee  wrote:
> 
> I confess that I'm not sure what to say to this. You're asserting that 
> running a geocoding business with ODbL attaching to the results is no big 
> deal, that "all the use cases you can think of" seem fine. Mapbox is 
> _actually running_ a geocoding business and telling you that we would like to 
> use OSM in it but can't sell a geocoding service that has ODbL attached to 
> the results. 

That’s a fait point, however on the other hand, there are many other businesses 
who’re also actually running who don’t have these issues. There are now 
hundreds of businesses big and small using OSM seriously, who’ve had legal 
people look at it. Why aren’t they all here independently complaining about 
this?

If it’s that just one early business is running in to this first, then we 
should wait and see if others come along independently and also have this 
issue. However it looks unlikely as there are many others already, including 
two or three other VC-backed companies with double-digit raises.

For reference, call this the SNIFF TEST.

> And no one has yet offered any examples by which ODbL attaching to geocoding 
> results has led to contributions that improved OSM. Or contributions at all 
> (the prospect of Randy's tide station data notwithstanding).

Another fair point, however it’s also hard to see who would pay for OSM 
geocoding in the first place when there’s almost no data compared to 
proprietary maps. Do we have any examples of these people waiting to pay for 
data that doesn’t exist?

Or, would they only start contributing data in to OSM if we changed the 
license? If we’re positing that a) they exist and b) they would start 
contributing with a license change then this is a chicken and egg situation. 
Either we could change the license and they start contributing (chicken) (which 
is difficult to do), or, given the levels of passion on this mailing list it 
may be far, far easier for them to start this contribution first and then we 
think about changing the license (egg). It would also demonstrate both the 
existence and their contribution (and faith) whereas the other way around 
(chicken) we’d demonstrate people willing to pay for it, but they may not start 
contributing data after we change the license.

I’ll call this the CHICKEN OR EGG TEST.

If we could pass the SNIFF TEST and the CHICKEN OR EGG TEST with real data I 
think I’d be convinced along with a lot of people here. We all want OSM to be 
the best map of the world and have the most uses/users. Or most of us do :-)

> I realize you'll disagree, but I'm left with the same sense of what's 
> achievable and desirable for a geocoding guidance. Enable more geocoding. 
> Protect OSM's assets. Abandon the impractical goal of compelling users to 
> share their results.

It’s a frustrating discussion all around, but we should avoid calling 
ShareAlike impractical since it will just cause more froth. Let’s agree at 
least on the spirit of the license, which I think you’re trying to do.

Best

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

Re: [OSM-legal-talk] Geocoding as produced work

[Simon Poole]

Am 23.09.2015 um 21:28 schrieb Tom Lee:
> I confess that I'm not sure what to say to this. You're asserting that
> running a geocoding business with ODbL attaching to the results is no
> big deal, that "all the use cases you can think of" seem fine. Mapbox
> is _actually running_ a geocoding business and telling you that we
> would like to use OSM in it but can't sell a geocoding service that
> has ODbL attached to the results.

No, I'm saying that for a overwhelming majority of use cases in which
the geo-coding are used publicly the ODbL does not cause the privacy
problems you were alluring too. Nor does it cause any problem for in
house use at all.

Now obviously it does limit in some aspects the T&Cs an OSM based
geo-coding service can use for its business and it might actually force
such a service provider to differentiate between geo-coding for public
vs in-house use.  But then it isn't as if you are completely free to do
what you want with a lot of other data sources either. 

>
> And no one has yet offered any examples by which ODbL attaching to
> geocoding results has led to contributions that improved OSM. Or
> contributions at all (the prospect of Randy's tide station data
> notwithstanding).
Getting back failed addresses for QA would be a start.

But the more important point is that we are not at liberty to simply
declare by fiat that bulk geo-coding does not create a derivative
database. The underlying problem is that geo-coding is not a clearly
defined process, it is at best a loose concept. I doubt that anybody
would have issue classifiying geo-coding addresses in the US to states
(your initial example)  as a produced work, on the other hand extracting
building entrances with attached addresses is clearly a one-to-one
copying out of OSM, both however are "geo-coding".

Most actual use cases are going to be somewhere in between and the last
couple of years of discussion on this topic have clearly shown that we
will not make any progress except if we base a geo-coding guideline on
principles that are as far as possible independent of the actual mechanics.

>
> I realize you'll disagree, but I'm left with the same sense of what's
> achievable and desirable for a geocoding guidance. Enable more
> geocoding. Protect OSM's assets. Abandon the impractical goal of
> compelling users to share their results.
>
I don't think there is an election going on any time soon, so please
tone down the rhetoric. It's simply the case that we have the licence we
have and at least for the immediate future we have to live with it and
give our data consumers guidance in the current frame work, not in a
make believe better world.  

Simon



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] Geocoding as produced work

[Tom Lee]

I confess that I'm not sure what to say to this. You're asserting that
running a geocoding business with ODbL attaching to the results is no big
deal, that "all the use cases you can think of" seem fine. Mapbox is
_actually running_ a geocoding business and telling you that we would like
to use OSM in it but can't sell a geocoding service that has ODbL attached
to the results.

And no one has yet offered any examples by which ODbL attaching to
geocoding results has led to contributions that improved OSM. Or
contributions at all (the prospect of Randy's tide station data
notwithstanding).

I realize you'll disagree, but I'm left with the same sense of what's
achievable and desirable for a geocoding guidance. Enable more geocoding.
Protect OSM's assets. Abandon the impractical goal of compelling users to
share their results.

On Wed, Sep 23, 2015 at 2:26 PM, Simon Poole  wrote:

>
>
> Am 23.09.2015 um 19:16 schrieb Tom Lee:
> > I'm not sure what basis there is for thinking a service provider will
> > necessarily reuse clients' data. Maybe!
> Not "maybe" but dead certain, see for example geocoder.ca and I hope you
> don't really believe that google doesn't reuse the data you submit to
> its geo-coding API.
>
> > That's not my experience, but I can imagine how it might be useful. I
> > hope you'll agree that data security and stewardship is a trickier
> > thing to implement within an open project made up of volunteers than
> > it is in an organization with contract employees.
> >
> > To point b: if the addresses remain associated with the entity doing
> > the geocoding, as I think you're proposing, problematic linkages
> > remain possible. Consider how Brendan Eich's career ended at Mozilla.
> > That case involved campaign finance records, but a political
> > organization's geocoded membership database could easily achieve the
> > same result, even with just addresses.
> >
> > Anyway even if the organization->address linkage were to be removed,
> > organizations who comply with EU Safe Harbour privacy requirements
> > (and, I assume, the EU privacy provisions from which they're derived)
> > could not share users' address data with a third party in this manner*.
> >
>
> You are getting slightly carried away: we are talking about SA
> obligations for data derived from OSM that is publicly used, which in in
> the vast vast majority of cases will not have any relevant
> data-protection issues at all. A typical use case would be a company
> geo-coding the addresses of its dealerships for display on a map,
> 4square geo-coding its locations and similar. NOT an insurance
> geo-coding the addresses of its customers and publishing them.
>
> The very legislation you are referring to would in general strongly
> limit any use of location information associated with individuals in the
> first place and it may be that that is actually a rare use case which
> will never be possible to cover with OSM.
>
> > Put bluntly: expecting data back from geocoding users is not workable
> > and never has been. Maintaining the hope that someday it will produce
> > useful contributions merely leads to some noncompliance and lots and
> > lots of deadweight loss. It's a shame, and is inhibiting useful work
> > being accomplished both outside of OSM and within it.
> >
> > Tom
> >
> > * Partner and vendors can receive data from complying organizations,
> > but the relationship must be disclosed and users must be given the
> > right to delete data about them. Partner organizations also have to
> > complete certification procedures (including things like HR training),
> > and may not pass the data on further, as OSM presumably would want to
> > under sharealike.
> >
> See above, all the relevant larger scale use cases which I can think of
> that touch private data of individuals do not involve publishing the
> location information and OSM can be used for that NOW without any fear
> at all of share-alike. Matter of fact you are even better of with OSM
> than with any service provider, because you can actually do it in house
> and don't have to disclose the information to a third party with all the
> involved paper work (yes I've actually signed such contracts and they
> are a pain).
>
> Simon
>
>
> ___
> 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] Geocoding as produced work

[Simon Poole]

Am 23.09.2015 um 19:16 schrieb Tom Lee:
> I'm not sure what basis there is for thinking a service provider will
> necessarily reuse clients' data. Maybe!
Not "maybe" but dead certain, see for example geocoder.ca and I hope you
don't really believe that google doesn't reuse the data you submit to
its geo-coding API.

> That's not my experience, but I can imagine how it might be useful. I
> hope you'll agree that data security and stewardship is a trickier
> thing to implement within an open project made up of volunteers than
> it is in an organization with contract employees.
>
> To point b: if the addresses remain associated with the entity doing
> the geocoding, as I think you're proposing, problematic linkages
> remain possible. Consider how Brendan Eich's career ended at Mozilla.
> That case involved campaign finance records, but a political
> organization's geocoded membership database could easily achieve the
> same result, even with just addresses.
>
> Anyway even if the organization->address linkage were to be removed,
> organizations who comply with EU Safe Harbour privacy requirements
> (and, I assume, the EU privacy provisions from which they're derived)
> could not share users' address data with a third party in this manner*.
>

You are getting slightly carried away: we are talking about SA
obligations for data derived from OSM that is publicly used, which in in
the vast vast majority of cases will not have any relevant
data-protection issues at all. A typical use case would be a company
geo-coding the addresses of its dealerships for display on a map,
4square geo-coding its locations and similar. NOT an insurance
geo-coding the addresses of its customers and publishing them.

The very legislation you are referring to would in general strongly
limit any use of location information associated with individuals in the
first place and it may be that that is actually a rare use case which
will never be possible to cover with OSM.

> Put bluntly: expecting data back from geocoding users is not workable
> and never has been. Maintaining the hope that someday it will produce
> useful contributions merely leads to some noncompliance and lots and
> lots of deadweight loss. It's a shame, and is inhibiting useful work
> being accomplished both outside of OSM and within it.
>
> Tom
>
> * Partner and vendors can receive data from complying organizations,
> but the relationship must be disclosed and users must be given the
> right to delete data about them. Partner organizations also have to
> complete certification procedures (including things like HR training),
> and may not pass the data on further, as OSM presumably would want to
> under sharealike.
>
See above, all the relevant larger scale use cases which I can think of
that touch private data of individuals do not involve publishing the
location information and OSM can be used for that NOW without any fear
at all of share-alike. Matter of fact you are even better of with OSM
than with any service provider, because you can actually do it in house
and don't have to disclose the information to a third party with all the
involved paper work (yes I've actually signed such contracts and they
are a pain).  

Simon



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] Geocoding as produced work

[Tom Lee]

I'm not sure what basis there is for thinking a service provider will
necessarily reuse clients' data. Maybe! That's not my experience, but I can
imagine how it might be useful. I hope you'll agree that data security and
stewardship is a trickier thing to implement within an open project made up
of volunteers than it is in an organization with contract employees.

To point b: if the addresses remain associated with the entity doing the
geocoding, as I think you're proposing, problematic linkages remain
possible. Consider how Brendan Eich's career ended at Mozilla. That case
involved campaign finance records, but a political organization's geocoded
membership database could easily achieve the same result, even with just
addresses.

Anyway even if the organization->address linkage were to be removed,
organizations who comply with EU Safe Harbour privacy requirements (and, I
assume, the EU privacy provisions from which they're derived) could not
share users' address data with a third party in this manner*.

Put bluntly: expecting data back from geocoding users is not workable and
never has been. Maintaining the hope that someday it will produce useful
contributions merely leads to some noncompliance and lots and lots of
deadweight loss. It's a shame, and is inhibiting useful work being
accomplished both outside of OSM and within it.

Tom

* Partner and vendors can receive data from complying organizations, but
the relationship must be disclosed and users must be given the right to
delete data about them. Partner organizations also have to complete
certification procedures (including things like HR training), and may not
pass the data on further, as OSM presumably would want to under sharealike.



On Wed, Sep 23, 2015 at 10:39 AM, Simon Poole  wrote:

>
>
> Am 23.09.2015 um 15:32 schrieb Tom Lee:
>
> why wouldn't you want to provide OSM with a list of addresses that you
>> tried to geo-code (successfully and non-successfully)
>
>
> To use an extreme but hopefully illustrative example, consider the queries
> used to create the thematic map on this page:
>
>
> Naturally you fail to mention that
>
> a) whatever service provider did the geo-coding of the above data
> undoubtedly used the data for the same purposes as OSM would (and likely a
> lot more)
>
> and
>
> b)  in my proposal I specifically address the issue of providing the
> geo-coded addresses anonymously
>
> Simon
>
> PS: just to avoid confusion we are talking about addresses without any
> attached personal information (names etc), so the data protection issue is
> sole the linkage between who is doing the geo-coding and the address.
>
> ___
> 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] Geocoding as produced work

[Simon Poole]

Am 23.09.2015 um 15:32 schrieb Tom Lee:
>
> why wouldn't you want to provide OSM with a list of addresses that
> you tried to geo-code (successfully and non-successfully)
>
>
> To use an extreme but hopefully illustrative example, consider the
> queries used to create the thematic map on this page:
>
>
Naturally you fail to mention that

a) whatever service provider did the geo-coding of the above data
undoubtedly used the data for the same purposes as OSM would (and likely
a lot more)

and

b)  in my proposal I specifically address the issue of providing the
geo-coded addresses anonymously

Simon

PS: just to avoid confusion we are talking about addresses without any
attached personal information (names etc), so the data protection issue
is sole the linkage between who is doing the geo-coding and the address.


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] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Tom Lee]

>
> why wouldn't you want to provide OSM with a list of addresses that you
> tried to geo-code (successfully and non-successfully)


To use an extreme but hopefully illustrative example, consider the queries
used to create the thematic map on this page:

http://www.huffingtonpost.com/2014/10/09/men-killing-women-domesti_n_5927140.html

I'm sure you can imagine similar scenarios related to sales leads,
potential hires, the healthcare industry or other forms of geographic
information that are sensitive for personal or professional reasons.

More generally, geocoding services that produce a product that has ongoing
licensing obligations--e.g. the user must attend to how the result
intermingles with their other data--will always be a hard sell. I realize
that this may not be of much concern to everyone here, but I do think that
more use of OSM for geocoding will spur improvements in various classes of
under-mapped data (addresses, most obviously).

On Wed, Sep 23, 2015 at 4:01 AM, Simon Poole  wrote:

>
>
> Am 23.09.2015 um 01:26 schrieb Alex Barth:
> > ..
> >
> > The Fairhurst Doctrine won't get us all the way on geocoding. It still
> > leaves open what happens in scenarios where elements of the same kind
> > in third party databases are geocoded with OSM data and others with
> > third party data. This is a highly relevant scenario as OSM data
> > particularly for geocoding (addresses, POIs) is usually not complete
> > enough. The ability to use OSM for geocoding and "backfill" it with
> > (non-license-compatible) third party data is exactly what would would
> > make a gradual adoption of OSM possible.
> >
> > .
>
> This is obviously off topic as it has little to do with comments and
> input on the proposed guideline (and the proposed guideline has nothing
> directly to do with geo-coding), however I'm curious: why wouldn't you
> want to provide OSM with a list of addresses that you tried to geo-code
> (successfully and non-successfully), for example as proposed in:
>
> http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#The_Failover_Issue_and_Publishing_Derived_Datasets
>
> Simon
>
>
> ___
> 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] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Tom Lee]

>
> I mean, nobody cares about a single on-the-fly geocoding result (this
> easily falls under the "substantial" guideline) but if you repeatedly
> query an ODbL database with the aim of retrieving from it, say, a
> million lat-lon pairs to store in your own database, then how in the
> world could this new database ever be *not* a derivative? Even if you
> were to define a single geocoding result as a produced work, combining a
> large number of them in a database would still get you a derived
> database again.


Can't the same argument apply to tiles? If you used tiles to recreate the
OSM database (say, by tracing road geometry or by OCRing feature names) and
then republishing under a different license, you would clearly be violating
the ODbL.

It seems as though the same approach can apply to geocoding: locate
features to your heart's content, but if you use the results to create a
general purpose geographic database that substitutes for/competes with OSM,
you'll be in violation of the license.


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

> Hi,
>
> On 09/23/2015 01:26 AM, Alex Barth wrote:
> > This could be well done within the confines of the ODbL by endorsing the
> > "Geocoding is Produced Work"
> > guideline
> https://lists.openstreetmap.org/pipermail/legal-talk/2014-July/007900.html
>
> Frankly, even if I was of the opinion that it would be desirable for the
> ODbL to not apply to geocoding, I don't think that "Geocoding is
> Produced Work" could ever fly, legally, at least in countries that have
> a sui generis database law.
>
> I mean, nobody cares about a single on-the-fly geocoding result (this
> easily falls under the "substantial" guideline) but if you repeatedly
> query an ODbL database with the aim of retrieving from it, say, a
> million lat-lon pairs to store in your own database, then how in the
> world could this new database ever be *not* a derivative? Even if you
> were to define a single geocoding result as a produced work, combining a
> large number of them in a database would still get you a derived
> database again.
>
> 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
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Simon Poole]

Am 23.09.2015 um 01:26 schrieb Alex Barth:
> ..
>
> The Fairhurst Doctrine won't get us all the way on geocoding. It still
> leaves open what happens in scenarios where elements of the same kind
> in third party databases are geocoded with OSM data and others with
> third party data. This is a highly relevant scenario as OSM data
> particularly for geocoding (addresses, POIs) is usually not complete
> enough. The ability to use OSM for geocoding and "backfill" it with
> (non-license-compatible) third party data is exactly what would would
> make a gradual adoption of OSM possible.
>
> .

This is obviously off topic as it has little to do with comments and
input on the proposed guideline (and the proposed guideline has nothing
directly to do with geo-coding), however I'm curious: why wouldn't you
want to provide OSM with a list of addresses that you tried to geo-code
(successfully and non-successfully), for example as proposed in:
http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#The_Failover_Issue_and_Publishing_Derived_Datasets

Simon



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] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Frederik Ramm]

Hi,

On 09/23/2015 01:26 AM, Alex Barth wrote:
> This could be well done within the confines of the ODbL by endorsing the
> "Geocoding is Produced Work"
> guideline 
> https://lists.openstreetmap.org/pipermail/legal-talk/2014-July/007900.html

Frankly, even if I was of the opinion that it would be desirable for the
ODbL to not apply to geocoding, I don't think that "Geocoding is
Produced Work" could ever fly, legally, at least in countries that have
a sui generis database law.

I mean, nobody cares about a single on-the-fly geocoding result (this
easily falls under the "substantial" guideline) but if you repeatedly
query an ODbL database with the aim of retrieving from it, say, a
million lat-lon pairs to store in your own database, then how in the
world could this new database ever be *not* a derivative? Even if you
were to define a single geocoding result as a produced work, combining a
large number of them in a database would still get you a derived
database again.

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