On Friday 22 July 2016, Ilya Zverev wrote:
> 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.
I have not argued in any such direction, it seems however with the above
you are trying here to bring the usual FUD argument that the OSM
community has to follow a lenient interpretation of the license -
otherwise no one can use OSM data out of fear of violating the license,
which is obviously nonsense.
So please once more: lets concentrate on this specific use case and the
question how this fits into the rules of OSM data use. I tried to
follow your view and explained why i think this is ultimately
non-consistent and would lead to a situation that is not consistent
with various aspects of the license and the community guidelines. I
would expect you to argue those points and not the general
righteousness of my approach.
> It seems to me, you are considering the Collective Database Guideline
> to be the law,
No but it tells you something about how the OSMF and the OSM community
view the license. 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.
Also note from a legal standpoint the community guidelines are not
meaningless, especially if we are talking about uses that take place
after a guideline has been published and the licensee is aware of the
content of the guideline (which probably can be said to apply here).
Licenses are contracts and at least here in Germany the basis of all
contracts is agreement between the contact partners on something. No
agreement - no contract. So if the OSMF as one contract partner in the
license contract has clearly communicated publicly and beforehand
through the community guidelines that from their side some use is
definitely not part of the agreement that is a strong indicator on the
nature and the limits of the license contract in any legal
But note this is a layman's view of course and IANAL.
> [...] 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.
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.
> 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.
legal-talk mailing list