[OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?

[Ilya Zverev]

You are starting to derive the licensing terms from intentions, and not the actual process or usage. Which basically says, if the community accepts this way of judging: however you use our data, if we don't like what you do with it, you would have to stop. And that is definitely not a FOSS license, and not only maps.me would have to stop using OSM, because there would be a chance that any data user might suddenly find out that odbl favours the provider. It's like "this data must be used only for good and not evil": while fun, legally dangerous.

It seems to me, you are considering the Collective Database Guideline to be the law, disregarding the actual ODbL and the words "may be" that follow the de-duplication use case. "Endorsed by the Board" is not equal to "Is a part of the license". "Primary feature" definition is not a part of ODbL, it was introduced to give better understanding of the guideline topic. It defines what is a collective database, but does not define the contrary: if a data set is not covered by the guideline, it doesn't automatically become derivative.

Consider a simpler experiment. I remove nodes based on an obscure algorithm. I then publish the rest of the database and a list of removed nodes under an open license. Do I have to open the algorithm?

IZ

> 10 июля 2016 г., в 1:23, Christoph Hormann <chris_hormann at gmx.de> написал(а):
> 
> On Sunday 10 July 2016, Ilya Zverev wrote:
>> 
>> Let's consider another use case. An application that shows OSM map,
>> and on top of it shows 1 mln of user points. A users has an option to
>> hide the OSM map underneath proprietary points, with a radius of 1
>> km. Does in that moment when a user clickes the options, the combined
>> map become derivative? Because the application removes parts of OSM
>> map based on proprietary data, which means, by your implications,
>> that that creates an inseparable references.
> 
> I would keep it on the level of combining proprietary data and OSM data 
> for the same feature type because this is what you do and this is also 
> what is best documented in the guidelines and related discussion.
> 
> As i see it you acknowledge that there is such a combination of 
> different data sets but since you have a reverse case in comparison to 
> the examples given in the guidelines they do not apply and you somehow 
> read the license itself to support your use case.
> 
> I think this is an interesting viewpoint although i see little chance of 
> this becoming a widely accepted interpretation.  It depends on the idea 
> that when generating your produced work or publicly using the two data 
> sets in combination you have a Collective Database and no Derivative 
> Database.  This is going to be really hard to argue since you just 
> modified one of the databases you combine for the obvious purpose of 
> using it in combination.  Removing hotel POIs from OSM only makes sense 
> if you use it in combination with your other data set - the 
> de-duplicated OSM part of your alleged Collective Database is therefore 
> clearly not an independent database.
> 
> If you think through this scenario somewhat further it would essentially 
> mean share-alike to be ineffective in de-duplication cases.  Since 
> de-duplication is generally only possible in cases where both data sets 
> have a roughly comparable quality level (though not necessary the same 
> level of completeness) it will hardly ever matter from a practical 
> viewpoint which data set you remove duplicates from.  So if one 
> direction was possible without share-alike the guidelines would 
> essentially be irrelevant because they'd only distinguish between those 
> cases where you have to de-duplicate in one direction and those where 
> you can combine data sets freely without share-alike.
> 
> -- 
> Christoph Hormann
> http://www.imagico.de/
> 
> _______________________________________________
> legal-talk mailing list
> legal-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk