Re: [OSM-legal-talk] use OSM data to select proprietary data
On Saturday 14 December 2019, matthias.straetl...@buerotiger.de wrote: > > existing OSMF community guidelines suggest spatial operations like > > ST_Difference() and ST_Intersection() yield Derivative Databases > > that are subject to share-alike. > > Let's take the Collective Database Guideline, you've mentioned: > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Coll >ective_Database_Guideline_Guideline > > "Technically a reference between non-OSM and OSM data can be by a > database key or any other method of identifying a specific OSM or > non-OSM element that may be used with a database join." > > So actually, I just need to create a collective database, put the > non-free data in one table and OSM data in another. For table > joining, I'm using ST_Intersects() and I'm fine? No, the quoted guideline says that share-alike does not apply if OSM data and non-OSM data *do not* reference each other and in specific other cases. None of these cases covers references through spatial relationships. The idea that your process of intersecting non-OSM data with OSM based admin polygons results in a collective database is not realistic. To me this kind of operation would be a textbook example of something generating a derivative database - you combine OSM data with non-OSM data to generate something of additional value compared to either of these data sets alone. This is exactly the kind of scenario share-alike is meant for and why it was chosen as license for OSM. But there are of course fairly strong economic interests for this not being subject to share-alike so people think of ways to interpret the ODbL accordingly. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] use OSM data to select proprietary data
> > existing OSMF community guidelines suggest spatial operations like > ST_Difference() and ST_Intersection() yield Derivative Databases that > are subject to share-alike. Let's take the Collective Database Guideline, you've mentioned: https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline "Technically a reference between non-OSM and OSM data can be by a database key or any other method of identifying a specific OSM or non-OSM element that may be used with a database join." So actually, I just need to create a collective database, put the non-free data in one table and OSM data in another. For table joining, I'm using ST_Intersects() and I'm fine? Confusing. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] use OSM data to select proprietary data
Hi, On 14.12.19 06:41, Mateusz Konieczny wrote: > Can you point me to legal definition > of "substantial part"? There is none, hence: https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline 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
Re: [OSM-legal-talk] use OSM data to select proprietary data
On Thu, 12 Dec 2019 22:41 Kathleen Lu via legal-talk, < legal-talk@openstreetmap.org> wrote: > No, ODbL does not apply to any database that does not include OSM data. > There are two reasons. > I would argue that the dataset here does include some OSM data, as it includes (albeit limited) information about the regions enclosed by certain features in OSM. Regardless of that though, I would use the following reasoning, involving a chain of derivative databases, to argue that final databases could be subject to ODbL even if they don't directly contain any OSM data, if OSM data has been used in their creation. At some point in the process of deriving the new dataset here, an OSM extract and some proprietary data were combined into a database. To start with, these would be independent parts, and so the combined database would be a Collective Database, and so not subject to ODbL. However, I would argue that the moment you run a query that combines both parts of the database in a non-trivial way, those parts can no longer be said to be "independent", and hence they cannot be part of a Collective Database. The combined OSM extract, proprietary data, and the output from the query are now a derivative database, and hence subject to ODbL, thanks to the presence of the OSM data. The data published is then a substantial extract from this derivative database, and is thus is a derivative of the derivative. This makes it also subject to ODbL. Robert. > ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
