<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 12 Dec 2019 22:41 Kathleen Lu via legal-talk, <<a href="mailto:legal-talk@openstreetmap.org">legal-talk@openstreetmap.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>No, ODbL does not apply to any database that does not include OSM data. There are two reasons.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">I would argue that the dataset here does include some OSM data, as it </span><span style="font-family:sans-serif;font-size:12.8px">includes (albeit limited) information about the regions enclosed by </span><span style="font-family:sans-serif;font-size:12.8px">certain features in OSM. Regardless of that though, I would use the </span><span style="font-family:sans-serif;font-size:12.8px">following reasoning, involving a chain of derivative databases, to </span><span style="font-family:sans-serif;font-size:12.8px">argue that final databases could be subject to ODbL even if they don't directly </span><span style="font-family:sans-serif;font-size:12.8px">contain any OSM data, if OSM data has been used in their creation.</span><br style="font-family:sans-serif;font-size:12.8px"><br style="font-family:sans-serif;font-size:12.8px"><span style="font-family:sans-serif;font-size:12.8px">At some point in the process of deriving the new dataset here, an OSM </span><span style="font-family:sans-serif;font-size:12.8px">extract and some proprietary data were combined into a database. To </span><span style="font-family:sans-serif;font-size:12.8px">start with, these would be independent parts, and so the combined </span><span style="font-family:sans-serif;font-size:12.8px">database would be a Collective Database, and so not subject to ODbL.</span><br style="font-family:sans-serif;font-size:12.8px"><span style="font-family:sans-serif;font-size:12.8px">However, I would argue that the moment you run a query that combines </span><span style="font-family:sans-serif;font-size:12.8px">both parts of the database in a non-trivial way, those parts can no </span><span style="font-family:sans-serif;font-size:12.8px">longer be said to be "independent", and hence they cannot be part of a</span><br style="font-family:sans-serif;font-size:12.8px"><span style="font-family:sans-serif;font-size:12.8px">Collective Database. The combined OSM extract, proprietary data, and </span><span style="font-family:sans-serif;font-size:12.8px">the output from the query are now a derivative database, and hence </span><span style="font-family:sans-serif;font-size:12.8px">subject to ODbL, thanks to the presence of the OSM data. The data </span><span style="font-family:sans-serif;font-size:12.8px">published is then a substantial extract from this derivative database,</span><br style="font-family:sans-serif;font-size:12.8px"><span style="font-family:sans-serif;font-size:12.8px">and is thus is a derivative of the derivative. This makes it also </span><span style="font-family:sans-serif;font-size:12.8px">subject to ODbL.</span><br></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px"><br></span></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">Robert.</span></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>