Re: [OSM-legal-talk] Regarding community guidelines for map layers
On Thu, Nov 06, 2014 at 08:23:20AM -0800, Matt Morrow wrote: there seems to be a contradiction: if your renderer/preprocessing alters one DB based on another (eg removing elements from one, based on elements of the other one), derivative DB kicks in. whether the DB are connected at preprocessing stage or merely in cache of renderer does not matter. they are not independent. a complete different situation would be, if renderer just draws icons on top of each other (eg using the second stage to draw bigger icons, which will probably overwrite first stage icons). then the DB are independent. That is in contradiction to the Open Data License/Use Cases page. Can one freely arrange data within a Collective Database as appropriate for the application When a programmer is working with OSM and data from other sources and thereby creates a Collective Database they will want to be free to arrange the combined data in the most appropriate form for their purpose. We believe that this should be allowed so long as merged database itself is not being published. (answer) The non-OSM parts of a collective database do not need to be published. this refers to the fact, that how databases are stored on disk does not determine whether it is collective or derivative. saying if it's a collective DB, you can store both parts in one SQL database. it does not matter. it does not say anything about whether a produced work is based on collective or derivative DB. http://wiki.openstreetmap.org/wiki/Open_Data_License/Use_Cases#Can_one_freely_arrange_data_within_a_Collective_Database_as_appropriate_for_the_application Matt ___ 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] Regarding community guidelines for map layers
Matt Morrow wrote: That is in contradiction to the Open Data License/Use Cases page. Please don't use that page. As per the preamble: This wiki page was used for discussion and development of the move to the Open Database License. It is not legal advice, and is likely to be inaccurate or incomplete. Please do not use this page as a reference for what you can or can't do. Richard -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Regarding-community-guidelines-for-map-layers-tp5823067p5823518.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Regarding community guidelines for map layers
there seems to be a contradiction: if your renderer/preprocessing alters one DB based on another (eg removing elements from one, based on elements of the other one), derivative DB kicks in. whether the DB are connected at preprocessing stage or merely in cache of renderer does not matter. they are not independent. a complete different situation would be, if renderer just draws icons on top of each other (eg using the second stage to draw bigger icons, which will probably overwrite first stage icons). then the DB are independent. That is in contradiction to the Open Data License/Use Cases page. Can one freely arrange data within a Collective Database as appropriate for the application When a programmer is working with OSM and data from other sources and thereby creates a Collective Database they will want to be free to arrange the combined data in the most appropriate form for their purpose. We believe that this should be allowed so long as merged database itself is not being published. (answer) The non-OSM parts of a collective database do not need to be published. http://wiki.openstreetmap.org/wiki/Open_Data_License/Use_Cases#Can_one_freely_arrange_data_within_a_Collective_Database_as_appropriate_for_the_application Matt ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Regarding community guidelines for map layers
hi, On Tue, Nov 04, 2014 at 07:46:26PM +0100, Frederik Ramm wrote: Hi, On 11/04/2014 04:47 PM, Preet wrote: I don't understand how this falls under the share alike terms of the odbl. If I have two separate databases with restaurant feature data (say the first is from OSM, and the second is under a non-obdl compatible license), and I combine the two to display restaurants in an application, why would that require me to share the second database? But it would also in all likelihood lead to duplicate entries where your second database and OSM both have a certain feature. If this is not a problem for you, or if for example your renderer simply doesn't draw a second restaurant icon when one is already there, then good for you. You're simply drawing two completely independent databases on top of each other. You don't need to share your second database. there seems to be a contradiction: if your renderer/preprocessing alters one DB based on another (eg removing elements from one, based on elements of the other one), derivative DB kicks in. whether the DB are connected at preprocessing stage or merely in cache of renderer does not matter. they are not independent. a complete different situation would be, if renderer just draws icons on top of each other (eg using the second stage to draw bigger icons, which will probably overwrite first stage icons). then the DB are independent. If, however, you make a *selection* from your second database, taking only those items that are not already in OSM, then that selection (not the whole second database) becomes a work derived from OSM - because OSM was used as a mask to produce it. which I agree with -- michal palenik www.freemap.sk www.oma.sk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] Regarding community guidelines for map layers
Hi, The community guidelines for map layers [1] states: If there are restaurants in the OpenStreetMap layer and you add additional restaurants in another layer, but you include only those restaurants not present in the OpenStreetMap layer so that the restaurant layers will complement each other, then the layers for this feature are interacting and the restaurants added in your non-OpenStreetMap layer must be shared I don't understand how this falls under the share alike terms of the odbl. If I have two separate databases with restaurant feature data (say the first is from OSM, and the second is under a non-obdl compatible license), and I combine the two to display restaurants in an application, why would that require me to share the second database? Aren't two separate databases an example of collective databases? Is the argument that selectively deciding what to show in a produced work from a 'closed' database by comparing against an odbl licensed database somehow imposes that the closed database must also be odbl? Or maybe that if the type of data in two separate databases is 'close enough', they constitute a single database? Preet [1] - http://www.osmfoundation.org/wiki/License/Community_Guidelines/Horizontal_Map_Layers_-_Guideline ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Regarding community guidelines for map layers
Hi, On 11/04/2014 04:47 PM, Preet wrote: I don't understand how this falls under the share alike terms of the odbl. If I have two separate databases with restaurant feature data (say the first is from OSM, and the second is under a non-obdl compatible license), and I combine the two to display restaurants in an application, why would that require me to share the second database? It doesn't require you to share the second database. But it would also in all likelihood lead to duplicate entries where your second database and OSM both have a certain feature. If this is not a problem for you, or if for example your renderer simply doesn't draw a second restaurant icon when one is already there, then good for you. You're simply drawing two completely independent databases on top of each other. You don't need to share your second database. If, however, you make a *selection* from your second database, taking only those items that are not already in OSM, then that selection (not the whole second database) becomes a work derived from OSM - because OSM was used as a mask to produce it. Is the argument that selectively deciding what to show in a produced work from a 'closed' database by comparing against an odbl licensed database somehow imposes that the closed database must also be odbl? Not the closed database, only the selection made from the closed database with the help of ODbL-licensed data. 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
