Sorry I'm not commenting everything, but just the parts I find important. (See below)
> 22 июля 2016 г., в 1:35, Christoph Hormann <chris_horm...@gmx.de> написал(а): > > But neither does it become collective. And if you re-read my last > mail - i clearly made the argument based on the license itself that it > would be difficult to argue that your modified OSM hotel database with > select hotels removed is an independent database because it is > specifically intended to be used in combination with another > proprietary database and the derivation from the original data (removal > of features) only makes sense for use in this combination. And > classification as a collective database requires the individual > databases to be independent. I see you using the words "intended to be used" and "makes sense for use". They caught my eye because there was a discussion recently in a russian open data initiative group about requirements to state purposes for which open data is downloaded, which came to me as absurd. Because if a publisher chooses which intentions are right and which are wrong, that means the data is not open. I was not bringing FUD earlier, I was trying to illustrate the consequences of bringing additional non-specific clauses to an open license. For me, your mentions of intended use seem like extra restrictions that weren't mentioned anywhere before. > If you do something that violates the guidelines > (which i have not said you do) but trust it is OK by the letter of the > license (which i have not said it is) then you have to keep in mind > that by doing that you communicate that you don't care about the views > and the wishes of the community. Wait that doesn't seem right. You cannot violate guidelines because they are examples and explanations, not restrictions or a law. And then, when the guidelines say a dataset "may be" considered derivative, it doesn't say it is derivative (or otherwise). You cannot violate a text that says "may be", except by mathematically proving it is wrong either way. If I didn't care about the views of the community, I wouldn't continue this discussion. I want to either convince you or other people that it's okay to put proprietary data on top of the OSM data, or learn the reasons why this leads to a derivative database, requiring to open the proprietary part. In the latter case we at maps.me, of course, would need to simplify our data processing. > >> 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? > > You never have to open any algorithms, publishing the methods used is > just a possible alternative to publishing the derivative database and > it can only be used if this method can be used by anyone to reconstruct > the derivative database from the original data (like when you use a > random number generator to remove random features). But if you > intermingle ODbL and proprietary data into a derivative database > publishing only the algorithm used for that is meaningless since to > reproduce the results you need the proprietary data as well. In the example I don't mention any proprietary data. I may be using a proprietary algorithm, using some proprietary number generator, but in the end I get these two datasets: the database and a list of what I removed. First you are saying I don't need to publish the algorithm, since it's just an alternative, but then you start mentioning a need to publish both the algorithm and all the third-party data it uses (which it may or may not have used, you don't know). I guess that falls down to the definition of "intermingling". That's the word I don't understand in technical sense. Is any intermingling bad, or there is a good kind of intermingling? Neither in my example not anywhere else do I make a derivative database, as I believe. Does the process of intermingling lead to derivative database in any case? IZ _______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
