Re: [OSM-legal-talk] [Talk-us] press from SOTM US
I personally can't see enough wiggle room both in the ODbL and the CTs to make any dataset generated by geocoding and/or reverse geocoding anything else than a derivative database. It is just the ODbL working as intended. We went through a lot of effort to get from a broken to a functional licence that is appropriate for the subject matter and we shouldn't be unhappy with the fact that our licence now works (even though I like many others, would have preferred a more liberal licence). We don't have any exact information on the position of the community, but I would suspect that we have substantial support for strong share a like provisions and that getting a 2/3 majority for relaxed terms would be big challenge (I would like to remind everybody that we lost a number of quite large mappers during the licence change process due to the ODbL being a sell out to commercial interests and not SA enough). The only way out that I could see to avoid infection of propriety information is, along the lines of the suggestion by the LWG, to only geocode address information and use the address information as a key to look up such propriety information on the fly, the address DB itself being subject to ODbL terms. This however wouldn't help in the reverse geocoding use case (example: user clicks on a map to locate a bar and we return an address, the dataset of such addresses and any associated information would probably always be tainted). Simon ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] CTs, procedure to change of the license
During the license change from cc-by-sa to ODbL the issue was raised that 3 weeks for an active contributor to respond to a voting for a license change was not sufficient and IIRR the response was that this would be dealt with later. What is the view on this? How can this detail be changed, and what would be a reasonable time span for an active contributor to respond? My suggestion would be 2 months or 60 days. cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] CTs, procedure to change of the license
I found the thread: http://gis.19327.n5.nabble.com/OSM-legal-talk-CT-time-period-for-reply-to-a-new-license-change-active-contributor-td5270119.html basically what Michael Collinson wrote makes sense: - In the case of a major license change, there would be a run up of at least several months of publicity and discussion before the final formal vote announcement. - Our general objective in the CTs is to leave future generations as much flexibility as possible while preserving overall project goals. - The CTs do not stop such a formal announcement and vote opening to be made much earlier. I certainly agree that 6-8 weeks is reasonable should we ever go through a big change again. - There may be ocassions when a small but vital change needs to be made if a problem/loop-hole is found with the current license. Hence three weeks ... two weeks for someone to be on holiday and one week for them to get organised and vote. cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] CTs, procedure to change of the license
Hello Martin and all others, thanks for opening the CT discussion. I have expressed significant concerns about it more times already and I keep uncomfortable with it wording and way it has been established On Thursday 25 October 2012 15:31:10 Martin Koppenhoefer wrote: I found the thread: http://gis.19327.n5.nabble.com/OSM-legal-talk-CT-time-period-for-reply-to-a -new-license-change-active-contributor-td5270119.html basically what Michael Collinson wrote makes sense: - In the case of a major license change, there would be a run up of at least several months of publicity and discussion before the final formal vote announcement. - Our general objective in the CTs is to leave future generations as much flexibility as possible while preserving overall project goals. - The CTs do not stop such a formal announcement and vote opening to be made much earlier. I certainly agree that 6-8 weeks is reasonable should we ever go through a big change again. - There may be ocassions when a small but vital change needs to be made if a problem/loop-hole is found with the current license. Hence three weeks ... two weeks for someone to be on holiday and one week for them to get organised and vote. I would personally vote for two months. I know people who go for expeditions for long time and I think that their contributions can be of high value and should not lost right to vote because they are not connected to the Net every day. The minimal period for change discussion should be defined as well. The open topic is who controls the Contributions Terms changes. It is OSMF or have other OSM contributors right to control future of their work and the project? I would prefer if even Contributions Terms changes require at least some community approval. I am not sure if definition of the active OSM contributor in CT is not too strict as well. Again you can do great job by checking the state and found that there is no need to do modification or only upload traces to the database to allow future refinement. I would prefer (still) to have an option to mark my contributions to be available under CC-BY-SA in addition to ODbL because of long, long (many years) lack of willingness to communicate above questions from OSMF side and to be sure that project would not be locked in dead end in the future. I expect that same fear and bad feeling lead many people to dismiss ODbL for their work. The result is quit significant damage in the map data. Even in areas which I have contributed to and due to long time left already, I cannot repair them from my memory and my traces only and would have to go these tracks, hiking paths again. Not so bad, I would visit these areas in any case, but seeing unneeded destruction hurts. Best wishes, Pavel Pisa ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-us] press from SOTM US
I'd hate to see us give up here, there is too much at stake. The open questions around geocoding are doing OSM a disservice just as CC-BY-SA did. This is from a commercial community member's perspective just as an individual's, assuming we all want a better open map. Opening OSM to geocoding would be one of the main drivers for getting better boundary data and better addresses. Depending on your read of the license, right now OSM's terms on geocoding are potentially stricter than Google's or Navteq's. I'd love to work with whoever is interested on wording a clarification statement and figuring out the process on how to decide on it. On Oct 25, 2012, at 2:36 AM, Simon Poole si...@poole.ch wrote: I personally can't see enough wiggle room both in the ODbL and the CTs to make any dataset generated by geocoding and/or reverse geocoding anything else than a derivative database. It is just the ODbL working as intended. We went through a lot of effort to get from a broken to a functional licence that is appropriate for the subject matter and we shouldn't be unhappy with the fact that our licence now works (even though I like many others, would have preferred a more liberal licence). We don't have any exact information on the position of the community, but I would suspect that we have substantial support for strong share a like provisions and that getting a 2/3 majority for relaxed terms would be big challenge (I would like to remind everybody that we lost a number of quite large mappers during the licence change process due to the ODbL being a sell out to commercial interests and not SA enough). The only way out that I could see to avoid infection of propriety information is, along the lines of the suggestion by the LWG, to only geocode address information and use the address information as a key to look up such propriety information on the fly, the address DB itself being subject to ODbL terms. This however wouldn't help in the reverse geocoding use case (example: user clicks on a map to locate a bar and we return an address, the dataset of such addresses and any associated information would probably always be tainted). Simon ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-us] press from SOTM US
I don't see the issue with companies complying with like-for-like. There is some logistical burden, but that could be offloaded by geocoding services. There's something to explain, but there's something to explain with OSM anyhow. OSM is open for geocoding, that can be worked out. I don't see the other side of the argument here yet, why sharing back only geocoded strings is a problem. I disagree that reverse-geocoding infects an entire database. That needs some clarification. Google's geocoding terms are not even defined, and it's likely legally than anything significantly geocoded using GMaps is property of Google. -Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron From: Alex Barth a...@mapbox.com To: Licensing and other legal discussions. legal-talk@openstreetmap.org Sent: Thursday, October 25, 2012 11:06 AM Subject: Re: [OSM-legal-talk] [Talk-us] press from SOTM US I'd hate to see us give up here, there is too much at stake. The open questions around geocoding are doing OSM a disservice just as CC-BY-SA did. This is from a commercial community member's perspective just as an individual's, assuming we all want a better open map. Opening OSM to geocoding would be one of the main drivers for getting better boundary data and better addresses. Depending on your read of the license, right now OSM's terms on geocoding are potentially stricter than Google's or Navteq's. I'd love to work with whoever is interested on wording a clarification statement and figuring out the process on how to decide on it. On Oct 25, 2012, at 2:36 AM, Simon Poole si...@poole.ch wrote: I personally can't see enough wiggle room both in the ODbL and the CTs to make any dataset generated by geocoding and/or reverse geocoding anything else than a derivative database. It is just the ODbL working as intended. We went through a lot of effort to get from a broken to a functional licence that is appropriate for the subject matter and we shouldn't be unhappy with the fact that our licence now works (even though I like many others, would have preferred a more liberal licence). We don't have any exact information on the position of the community, but I would suspect that we have substantial support for strong share a like provisions and that getting a 2/3 majority for relaxed terms would be big challenge (I would like to remind everybody that we lost a number of quite large mappers during the licence change process due to the ODbL being a sell out to commercial interests and not SA enough). The only way out that I could see to avoid infection of propriety information is, along the lines of the suggestion by the LWG, to only geocode address information and use the address information as a key to look up such propriety information on the fly, the address DB itself being subject to ODbL terms. This however wouldn't help in the reverse geocoding use case (example: user clicks on a map to locate a bar and we return an address, the dataset of such addresses and any associated information would probably always be tainted). Simon ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-us] press from SOTM US
Hi, On 25.10.2012 17:30, Mikel Maron wrote: I don't see the issue with companies complying with like-for-like. There is some logistical burden, but that could be offloaded by geocoding services. +1 - I think we're all (including LWG) still waiting for concrete use case where somebody says: This is how I want to use OSM for geocoding, this is what I believe the ODbL would mean for me, and this is why it is unacceptable for my business. I don't know if it has already been said, but there is a *vast* amount of use cases where we need on-the-fly geocoding - user enters address and is zoomed to location - which are totally unproblematic as no derived database is even created. In many other use cases I can think of, the ODbL's requirement may mean an inconvenience and may mean that users can't be just as secretive as they would like to be, but still sufficiently secretive as not to hurt their business. I'm willing to hear concrete examples but I think that talk of giving up and too much at stake sound like OSM was unsuitable for geocoding which in my opinion it clearly isn't! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-us] press from SOTM US
geocoding patient data, client data, suppliers data, members data With this kind of sensitive private data, the database would not be redistributed, hence not invoking share-alike. * Mikel Maron * +14152835207 @mikel s:mikelmaron From: Alex Barth a...@mapbox.com To: Licensing and other legal discussions. legal-talk@openstreetmap.org Sent: Thursday, October 25, 2012 2:43 PM Subject: Re: [OSM-legal-talk] [Talk-us] press from SOTM US +1 for examples. I'm working on pulling some together. The like for like principle overlooks that data submitted to geocoders can be sensitive for privacy or IP reasons. Think of geocoding patient data, client data, suppliers data, members data in a scenario where a geocoder is only used for a single client. Definitely a scenario where we as MapBox would be able to offer an OSM based solution. On Oct 25, 2012, at 2:04 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 25.10.2012 17:30, Mikel Maron wrote: I don't see the issue with companies complying with like-for-like. There is some logistical burden, but that could be offloaded by geocoding services. +1 - I think we're all (including LWG) still waiting for concrete use case where somebody says: This is how I want to use OSM for geocoding, this is what I believe the ODbL would mean for me, and this is why it is unacceptable for my business. I don't know if it has already been said, but there is a *vast* amount of use cases where we need on-the-fly geocoding - user enters address and is zoomed to location - which are totally unproblematic as no derived database is even created. In many other use cases I can think of, the ODbL's requirement may mean an inconvenience and may mean that users can't be just as secretive as they would like to be, but still sufficiently secretive as not to hurt their business. I'm willing to hear concrete examples but I think that talk of giving up and too much at stake sound like OSM was unsuitable for geocoding which in my opinion it clearly isn't! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-us] press from SOTM US
On Oct 25, 2012, at 2:43 PM, Alex Barth a...@mapbox.com wrote: +1 for examples. I'm working on pulling some together. The like for like principle overlooks that data submitted to geocoders can be sensitive for privacy or IP reasons. Think of geocoding patient data, client data, suppliers data, members data in a scenario where a geocoder is only used for a single client. Definitely a scenario where we as MapBox would be able to offer an OSM based solution. The last sentence should be: Definitely a scenario where we as MapBox would _love to_ be able to offer an OSM based solution. On Oct 25, 2012, at 2:04 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 25.10.2012 17:30, Mikel Maron wrote: I don't see the issue with companies complying with like-for-like. There is some logistical burden, but that could be offloaded by geocoding services. +1 - I think we're all (including LWG) still waiting for concrete use case where somebody says: This is how I want to use OSM for geocoding, this is what I believe the ODbL would mean for me, and this is why it is unacceptable for my business. I don't know if it has already been said, but there is a *vast* amount of use cases where we need on-the-fly geocoding - user enters address and is zoomed to location - which are totally unproblematic as no derived database is even created. In many other use cases I can think of, the ODbL's requirement may mean an inconvenience and may mean that users can't be just as secretive as they would like to be, but still sufficiently secretive as not to hurt their business. I'm willing to hear concrete examples but I think that talk of giving up and too much at stake sound like OSM was unsuitable for geocoding which in my opinion it clearly isn't! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-us] press from SOTM US
And this is where SA gets really hairy. It's entirely possible and actually quite common that part of a database that contains private data is public. E. g. public facing web sites that are powered from a Salesforce DB through a private API. Again, we need real-world examples. Working on this. On Oct 25, 2012, at 2:46 PM, Mikel Maron mikel_ma...@yahoo.com wrote: geocoding patient data, client data, suppliers data, members data With this kind of sensitive private data, the database would not be redistributed, hence not invoking share-alike. * Mikel Maron * +14152835207 @mikel s:mikelmaron From: Alex Barth a...@mapbox.com To: Licensing and other legal discussions. legal-talk@openstreetmap.org Sent: Thursday, October 25, 2012 2:43 PM Subject: Re: [OSM-legal-talk] [Talk-us] press from SOTM US +1 for examples. I'm working on pulling some together. The like for like principle overlooks that data submitted to geocoders can be sensitive for privacy or IP reasons. Think of geocoding patient data, client data, suppliers data, members data in a scenario where a geocoder is only used for a single client. Definitely a scenario where we as MapBox would be able to offer an OSM based solution. On Oct 25, 2012, at 2:04 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 25.10.2012 17:30, Mikel Maron wrote: I don't see the issue with companies complying with like-for-like. There is some logistical burden, but that could be offloaded by geocoding services. +1 - I think we're all (including LWG) still waiting for concrete use case where somebody says: This is how I want to use OSM for geocoding, this is what I believe the ODbL would mean for me, and this is why it is unacceptable for my business. I don't know if it has already been said, but there is a *vast* amount of use cases where we need on-the-fly geocoding - user enters address and is zoomed to location - which are totally unproblematic as no derived database is even created. In many other use cases I can think of, the ODbL's requirement may mean an inconvenience and may mean that users can't be just as secretive as they would like to be, but still sufficiently secretive as not to hurt their business. I'm willing to hear concrete examples but I think that talk of giving up and too much at stake sound like OSM was unsuitable for geocoding which in my opinion it clearly isn't! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-us] press from SOTM US
On Fri, Oct 26, 2012 at 4:12 AM, Alex Barth a...@mapbox.com wrote: And this is where SA gets really hairy. It's entirely possible and actually quite common that part of a database that contains private data is public. E. g. public facing web sites that are powered from a Salesforce DB through a private API. Again, we need real-world examples. Working on this. Please take note that the legal term database* is different from the technical term database. Just because one website's data is in just one PostgreSQL or MySQL database doesn't mean that this whole database needs to be licensed under ODbL. * According to the European Database Directive, a database is a collection of independent works, data or other materials arranged in a systematic or methodical way and individually accessible by electronic or other means. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
