On Tue, Jul 28, 2009 at 9:56 AM, Dave Stubbs<osm.l...@randomjunk.co.uk> wrote: > On Tue, Jul 28, 2009 at 2:54 AM, Frederik Ramm <frede...@remote.org> wrote: >> >> Hi, >> >> Matt Amos wrote: >> > LWG cannot entirely resolve these questions, as they need open >> > discussion and community consensus (which we obviously can't provide >> > on our own). even then, final interpretation is up to the courts. >> >> Of course. >> >> Thanks for your comments, I especially liked the a(b(X)@c(Y)) part which >> is a nice structure to think about this. >> >> But about my Navteq+OSM example, you said that >> > my reading would be that the deletions from the OSM data are a >> > derivative database of both the OSM data and the navteq data and that >> > the combination of navteq + (OSM - derivative) constitutes a public >> > use of that derivative database, requiring the release of the navteq >> > data. >> >> Now if I loaded my Navteq database into postgis and created a buffer >> around every object, generating one giant buffer area multipolygon for >> the whole world, then I could use that to subtract data from my OSM data >> base and would then only have to publish the giant multipolygon under >> ODbL (because that was mixed with OSM data) and not the original Navteq >> data. >> >> So this means I'd have to get permission from Navteq to release the >> giant buffer multipolygon under ODbL but if that is granted, I could >> continue with my OSM-enhanced Navteq tiles plan, and OSM would gain >> precious little from having access to the Navteq buffer multipolygon. >> Right? >> > > Do you even have to go that far? The Navteq multipolygon isn't actually part > of the resulting derivative database, it's just part of the algorithm to get > there. Assuming the result is just a shrunk version of the OSM DB I'd have > thought the only thing you had to release in this case was the alterations > made to the OSM DB -- ie: a list of the bits you deleted. We'd be within our > rights to try and reconstruct the multipolygon from those deletions, but you > wouldn't have to actually release it? > > or put another way: if I do o...@navteq = DD (where @ is some function that > combines the datasets), there's no circumstance in which I have to release > Navteq. My obligation is to release DD under ODbL (I can hand out the DD-OSM > diff). This happens to entitle anybody else to attempt to reconstruct as > much of Navteq as possible. > > The ODbL says I have to release changes, it doesn't say I have to tell you > why I'm making them. > > Is that remotely the right reading?
hmm... i think you may be right. i guess it depends on how it's done. if the merging is done by clipping out OSM data then maybe at most the polygon would need to be released, but maybe not even that. if the merging is done by matching (e.g: roadmatcher) then there's an argument that the database of matches is also a derivative database (which gets used to make the final derivative database) and would require the release of (maybe only some) navteq data... a very specific example may help: if i wanted to take navteq's list of petrol stations and merge it with OSM's - always preferring navteq's then i guess it would be simple to delete those in OSM which are close (fsvo close) to navteq's and then render the two superimposed by method #1. i think this fits your argument above - i can't see any reason why ODbL wouldn't be satisfied by the release of just the deleted items. taking it further, if i wanted to join those petrol stations to a routable network, or put them into a geocoding database... i think you might get away with the geocoding example if, like rendering, your geocoding search was independently performed on both the navteq and OSM lists of points and composited. routing... may be different. i can't, off the top of my head, think of any sensible way to keep the two datasets separate and still useful for those purposes... my head hurts now. cheers, matt _______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
