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 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 

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?


> 10 июля 2016 г., в 1:23, Christoph Hormann <> написал(а):
> 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
> _______________________________________________
> legal-talk mailing list

legal-talk mailing list

Reply via email to