[OSM-legal-talk] Regarding community guidelines for map layers
Michal Palenik
michal.palenik at freemap.sk
Wed Nov 5 08:41:38 UTC 2014
hi,
On Tue, Nov 04, 2014 at 07:46:26PM +0100, Frederik Ramm wrote:
> Hi,
>
> On 11/04/2014 04:47 PM, Preet wrote:
> > I don't understand how this falls under the share alike terms of the
> > odbl. If I have two separate databases with restaurant feature data (say
> > the first is from OSM, and the second is under a non-obdl compatible
> > license), and I combine the two to display restaurants in an
> > application, why would that require me to share the second database?
>
> But it would also in all likelihood lead to duplicate entries where your
> second database and OSM both have a certain feature.
>
> If this is not a problem for you, or if for example your renderer simply
> doesn't draw a second restaurant icon when one is already there, then
> good for you. You're simply drawing two completely independent databases
> on top of each other. You don't need to share your second database.
there seems to be a contradiction:
if your renderer/preprocessing alters one DB based on another (eg
removing elements from one, based on elements of the other one),
derivative DB kicks in. whether the DB are connected at preprocessing
stage or merely in cache of renderer does not matter. they are not
independent.
a complete different situation would be, if renderer just draws icons on
top of each other (eg using the second stage to draw bigger icons, which
will probably overwrite first stage icons). then the DB are independent.
>
> If, however, you make a *selection* from your second database, taking
> only those items that are not already in OSM, then that selection (not
> the whole second database) becomes a work derived from OSM - because OSM
> was used as a "mask" to produce it.
which I agree with
--
michal palenik
www.freemap.sk
www.oma.sk
More information about the legal-talk
mailing list