On Thu, Jul 24, 2014 at 5:03 PM, Alex Barth <[email protected]> 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 <[email protected]> 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 > [email protected] > https://lists.openstreetmap.org/listinfo/legal-talk > >
_______________________________________________ legal-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/legal-talk
