Re: [OSM-legal-talk] ODbL: Where do we stand regarding collective/derivative databases
On Tue, Jul 28, 2009 at 9:56 AM, Dave Stubbs wrote: > On Tue, Jul 28, 2009 at 2:54 AM, Frederik Ramm 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
Re: [OSM-legal-talk] ODbL: Where do we stand regarding collective/derivative databases
On Tue, Jul 28, 2009 at 2:54 AM, Frederik Ramm 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? Dave ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL: Where do we stand regarding collective/derivative databases
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? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL: Where do we stand regarding collective/derivative databases
On 7/27/09, Frederik Ramm wrote: > generally good progress on ODbL; many things have been cleared up > and we will soon be at a point where the proposal for a license change > is not some cloudy abstract thing any longer but a very concrete > proposal that people can evaluate. i'm glad you think so :-) > After the LWG has made an effort to resolve the questions about what is > substantial and what is a derived work, in my eyes there's one big issue > that remains, and that is "what is a derivative database". 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. > To recap, my understanding is that if I produce (+publish) works based > on a derivative database that I have created then I have to make that > database available, fully, under ODbL. If I, on the other hand, produce > works based on a collective database that is half ODbL and half > proprietary, then I only have to make the ODbL part available. Is that > everyone else's reading as well? it's my understanding also. > Let us look at someone who mixes OpenStreetMap and Navteq data. Say I > produce map tiles (clearly a produced work, no?) where all the streets > come from Navteq, but all the footways come from OpenStreetMap. There > are a number of ways to do this, all leading to the exact same result, > and nobody from the outside can see which of 1,2,3 I am using: > > 1. Configure my Mapnik tile generator so that it accesses two different > postgis databases - one containing Navteq and one containing OSM - to > produce merged map tiles. or, equally, configure two different mapnik instances to produce two different tilesets (one with a transparent background) and composite the two in a later postprocessing stage. > 2. Pour OSM and Navteq data into the same postgis instance but have > different tables (e.g. planet_osm_roads and navteq_roads) which are > joined by Mapnik's SELECT statement. > > 3. Extract all footway geometries from OSM and insert them into my > postgis database containing Navteq street data, then run Mapnik on the > resulting database. > > The way I read the license, option 1 would be definitely ok, option 3 > would definitely lead to my having to release the Navteq data, and > option 2 would be somewhere in between (probably ok until unknown to me, > Matt comes along and makes Mapnik internally create temporary tables on > the fly for better performance in which case I'd be creating temporary > derivative databases without even noticing...) > > Evil business genius that I am, I would of course claim to be doing 1 > even when doing 3 and nobody would have the right to challenge me, > right? Which would ultimately mean that: i'd say that if 1 were technically plausible, then what's the real difference between that and 2 or 3? > "If there is any conceivable way that a produced work could have been > created by using a collective rather than a derivative database, then > only the ODbL licensed part of the data source has to be released." > > This is becoming interesting, we're very much into real-world business > scenarios now. There are lots of people who'd shy away from using OSM > outright but if they could use a Navteq basemap and sprinkle that with > any additional detail that OSM might have that would be just great for > them. indeed, so your use-case with navteq roads and OSM footways wouldn't require the navteq data to be opened. unless you don't like the way the navteq and OSM data don't quite match up; the point at which you alter the OSM/navteq data to match up, then 1, 2 and 3 become inconceivable and the navteq data must be released (along with the whole/diffs to OSM data). it gets more difficult when we consider the collision detection in mapnik - does the fact that an item isn't rendered in one layer because it would occlude a previously rendered item constitute a derivative database inside mapnik, or is it simply part of the creative process of produced works? > Let us look at someone who has a Navteq and an OSM data base, and runs a > comparing analysis which results in *removing* all features from the OSM > database which were also in Navteq. He clearly creates a derivative > database but one which has no data added, just data deleted. He now > employs technique #1 from above to merge the Navteq data set and the > reduced OSM data set into one that contains the "best of both worlds". > Since he is clearly operating on a collective database, he only has to > release the derived OSM database under ODbL - the value of which is > almost zero to the community since it has no data added (the only thing > you can do with it is find out which of OSM's features are present in > Navteq as well). > > Is everything I write here correct and compatible with what others are > thinking? Is there some lawyer opinion on cases like this documented > somewhere in the vast depths
Re: [OSM-legal-talk] ODbL: Where do we stand regarding collective/derivative databases
Hi, Frederik Ramm wrote: > He now > employs technique #1 from above to merge the Navteq data set and the > reduced OSM data set into one that contains the "best of both worlds". I meant that he employs technique #1 to create a produced work from the Navteq and the reduced OSM data set - not that he actually merges them, that's the whole point of course. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] ODbL: Where do we stand regarding collective/derivative databases
Hi, generally good progress on ODbL; many things have been cleared up and we will soon be at a point where the proposal for a license change is not some cloudy abstract thing any longer but a very concrete proposal that people can evaluate. After the LWG has made an effort to resolve the questions about what is substantial and what is a derived work, in my eyes there's one big issue that remains, and that is "what is a derivative database". To recap, my understanding is that if I produce (+publish) works based on a derivative database that I have created then I have to make that database available, fully, under ODbL. If I, on the other hand, produce works based on a collective database that is half ODbL and half proprietary, then I only have to make the ODbL part available. Is that everyone else's reading as well? Let us look at someone who mixes OpenStreetMap and Navteq data. Say I produce map tiles (clearly a produced work, no?) where all the streets come from Navteq, but all the footways come from OpenStreetMap. There are a number of ways to do this, all leading to the exact same result, and nobody from the outside can see which of 1,2,3 I am using: 1. Configure my Mapnik tile generator so that it accesses two different postgis databases - one containing Navteq and one containing OSM - to produce merged map tiles. 2. Pour OSM and Navteq data into the same postgis instance but have different tables (e.g. planet_osm_roads and navteq_roads) which are joined by Mapnik's SELECT statement. 3. Extract all footway geometries from OSM and insert them into my postgis database containing Navteq street data, then run Mapnik on the resulting database. The way I read the license, option 1 would be definitely ok, option 3 would definitely lead to my having to release the Navteq data, and option 2 would be somewhere in between (probably ok until unknown to me, Matt comes along and makes Mapnik internally create temporary tables on the fly for better performance in which case I'd be creating temporary derivative databases without even noticing...) Evil business genius that I am, I would of course claim to be doing 1 even when doing 3 and nobody would have the right to challenge me, right? Which would ultimately mean that: "If there is any conceivable way that a produced work could have been created by using a collective rather than a derivative database, then only the ODbL licensed part of the data source has to be released." This is becoming interesting, we're very much into real-world business scenarios now. There are lots of people who'd shy away from using OSM outright but if they could use a Navteq basemap and sprinkle that with any additional detail that OSM might have that would be just great for them. Let us look at someone who has a Navteq and an OSM data base, and runs a comparing analysis which results in *removing* all features from the OSM database which were also in Navteq. He clearly creates a derivative database but one which has no data added, just data deleted. He now employs technique #1 from above to merge the Navteq data set and the reduced OSM data set into one that contains the "best of both worlds". Since he is clearly operating on a collective database, he only has to release the derived OSM database under ODbL - the value of which is almost zero to the community since it has no data added (the only thing you can do with it is find out which of OSM's features are present in Navteq as well). Is everything I write here correct and compatible with what others are thinking? Is there some lawyer opinion on cases like this documented somewhere in the vast depths of our Wiki and LWG minutes? (I'm just trying to determine what exactly ODbL mandates - not trying to find out what would be desirable in an ideal world.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
