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

[Jake Wasserman]

On Thu, Jul 24, 2014 at 5:03 PM, Alex Barth <alex at mapbox.com> wrote:

> Taking a step back, is the above use case not one we'd like to support
> without triggering share alike? I'm directing my question to everyone, not
> just Paul who's taken the time to review my example above.
>

Thanks for taking the time to bring this forward.

I agree that geocoded private data must be allowed to stay private. At a
minimum, we need to find a way to say actively reverse engineering the
database can trigger share alike, but the ability to reverse engineer it
does not.

A lot of the responses here just say to not cross the Substantial
threshold. That feels like a total cop out - an argument saying OSM and its
users should remain small and insubstantial... which doesn't seem to align
with our goals.

The fact that we’re scaring away well-intentioned users is sad.

What else can we do to help this cause?

-Jake



On Fri, Jul 25, 2014 at 5:39 AM, Simon Poole <simon at poole.ch> wrote:

>
>
> Am 24.07.2014 23:03, schrieb Alex Barth:
> ...
> > Taking a step back, is the above use case not one we'd like to support
> > without triggering share alike? I'm directing my question to everyone,
> > not just Paul who's taken the time to review my example above.
>
> IMHO the example is slightly flawed as to illustrating things that we
> wouldn't want to be affected by share alike.
>
> I expect if you ask a wider audience, the answer is likely to be: yes,
> we would like (aka "it is in the spirit of the ODbL") the store
> locations to be freely available and potentially to be added to the OSM
> data, given that this is classical OSM content.
>
> Most of the discussions around this issue in the past have revolved
> around additional meta data present in the geocoded database (for
> example lets say the list of employees at that location) and if -that-
> would be effected by share alike. And I expect that you would likely
> find a majority of the community which would same it is fair game for
> that to remain unaffected.
>
> Naturally this is just my gut feeling on the sentiments of the wider OSM
> community.
>
> Back to the general issue of the proposed guideline.
>
> As I've said before, I'm not convinced that trying to better define and
> clarify the issue by invoking the "produced work" clauses will lead to a
> satisfactory result. I would suggest that at least a comparison (for all
> your use cases) with a model based on "the information that is used for
> geocoding is subject to share alike, but nothing else" (which has been
> suggested in this discussion and previously a number of times).
>
> If you apply this to your above example, the addresses would be subject
> to SA (however no further information), and while potentially one could
> infer that these are likely the addresses of the store locations, no
> further information would needed to be disclosed*. Net effect
> essentially the same in practical terms as in your proposal, but without
> invoking produced work magic.
>
> Such a model has a further advantage that it makes trying to nail down
> the technicalities of at least forward geocoding less painful. For
> example the fact that the geocoder that you use in the examples actually
> returns object geometries aka the actual OSM objects in question.
>
> Simon
>
>
>
> _______________________________________________
> 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/20140725/82bb76d3/attachment.html>