On 30 November 2011 01:03, Jonathan Harley <j...@spiffymap.net> wrote:
> On 28/11/11 23:59, James Livingston wrote: > >> Depending on the rendering, it may not be the same. The placements of >> name text can depend on other data so it's not on top of something else, or >> POIs can be hidden if there are too many in a given area. >> >> In the first case (or combining layers in the browser), the rendering of >> OSM data cannot depend on the location of your hotels, and the rendering of >> hotel names can't easily depend on what else is on the map. In the second >> case (combining data before rendering) collisions can be avoided or the >> resulting map altered. >> > > Yes, but it's only the produced work, the rendering, which is altered. You > probably don't need to make changes to the OSM data to acheive this. > So the OSM data and other data could remain independent. If they do, then > the mechanism for combining (and computer/s on which it happens) is indeed > irrelevant. > While that's true, you are combining the two datasource together prior to rendering. Say I created some local postgres database tabled and loaded OSM data into it, and then loaded data from another source into it too. What I have is now a database derived from both OSM and the other source. If I then rendered that data to create a Produced Work, would my combined database not be a Derived Database? > >> This was discussed on legal-talk a few months ago, and my opinion was >> that it depended on whether you could produce the same output by merging >> separately-rendered Produced works. If you can get _identical_ output by >> merging layers on the browser side, then it's okay to the merging on the >> server side. However if you can't get identical results by merging the >> rendered output, then you've obviously combined the databases prior to >> rendering. >> > > Not necessarily. For example, the rendering might depend on what order > data is rendered. But the data being rendered would remain independent of > each other; it may be only the rendered result which varied. And that's a > produced work, not a database. > Can you get the same result by rendering the first dataset (creating a Produced Work), rendering the second dataset (creating another produced work, if it's ODbL too) and then combining the output? If so, they're definitely independent. You can render the second dataset first if you like provided you combine them in the right order. If the rendering of the second output depends on the first dataset, the Produced Work created from the second dataset is not independent of of the first dataset. I guess it's possible the rendering algorithm for the second dataset could use the Produced Work from the first rather than the first dataset directly, which may be okay except that it's arguable whether you are reverse engineering part of the first database. > > >> Having two instances of say Postgres and having one program that reads >> both and renders is still creating a derived database, even if it is only >> in the memory of the rendering program. >> >> > It might create a derivative database, or it might not; it would depend on > the algorithm. If the OSM data remain unmodified, then it could be creating > a collective database, which is explicitly not a derivative database. > I guess that's the a question: if you write a program that reads data from two sources and uses both to produce it's output, are the temporary in-memory data structures considered derived or collective for the purposes of copyright and database right law? The answer probably depends on how the program is implemented, but given that we won't know the implementation, how can we ever determine whether someone's Produced Work requires them to release their database? If we say we can't determine that, aren't we essentially saying that it's impossible to enforce that part of the ODbL? -- James
_______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk