Re: [OSM-legal-talk] Updated geocoding community guideline proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/07/14 04:38 PM, Jake Wasserman wrote: > > I agree that geocoded private data must be allowed to stay > private. The ODbL goes to great lengths to explain that it only covers publicly released data. > 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. OK. But we also need to find a way of saying that if that ability leads to that result then there isn't a defence of being surprised. > 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. That's something of a conceptual slippage. OSM and its users should become large and substantial (as it were...). Non-free exploitation of the resulting data should not. > The fact that we’re scaring away well-intentioned users is sad. Well-intentioned users don't want to circumvent the license in order to recreate substantial sections of it for non-free use. By definition. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJT00kHAAoJECciMUAZd2dZRncH/1R2YvZg8/N+6mCBtEW6HJvw znnCYeYgaK88fRVAvqpZ7bdXQBb9yN0Tbx/Xewoop6dZEp4XSMO4EezciM4kS341 e3mm6XuUiJy+3zYL+qBxjSE/zPmMI/fINM0wR3Tc3w3yT/cU61stSd6ux2bwFNJJ Aa7C0kgkXfV2ItSbBBH6GN0PWkMC4+1fkVe4fEnbgWrT6tF3KlSF4+cKmIALuMc3 ACEyVJUgKCiy4UXXXPF6oRn031gF5GgkXIMnLChLE5HL4DlCWTlLCNPvLIz2N9T6 WKKIp+4hsEs1J5a7Rv5Akl6aE7QVHeA1+YzCYB/dAXe13o0hBa+HY3tPzNaTMzA= =Nqb5 -END PGP SIGNATURE- ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
On Thu, Jul 24, 2014 at 5:03 PM, Alex Barth 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 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@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] Updated geocoding community guideline proposal
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 signature.asc Description: OpenPGP digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
