On 28 November 2011 21:55, 80n <80n...@gmail.com> wrote: > On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm <frede...@remote.org>wrote: > >> I could render a map from OSM and then render something else on top of >> it, say a commercially acquired set of hotel POIs. That would clearly be a >> Produced Work; I could point anyone asking for the source data to the >> planet file and the rendering rule, and keep the hotel POIs to myself. >> > > This is an overlay on top of a Produced Work. Whether it's produced by > layers at the browser end or by compositing two separate images doesn't > seem to be materially different. >
I agree. > I could also remove all hotels from my OSM copy and add in the commercial >> hotels instead, then render a map from it. Unless the commercial dataset is >> missing data, the resulting map could look 100% identical to the map from >> the first process, but this time I would be required to release the hotel >> dataset because it is part of the derived database used to create the >> produced work. >> > > Leaving aside the step about removing content for the moment, I don't see > how this is materially different from the first example. You've simply > overlaid your hotels on top of the OSM data. I don't think the mechanics > of how you achieved this are, from a legal perspective, important. Any > process can be considered as a series of inputs to a black box and some > outputs. If the inputs are the same (an OSM database and a set of POIs) > and the output is the same (a map with an overlay of the POIs) then it > shouldn't matter whether it was achieved using a complex machine or monkeys > with typewriters. > 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. 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. 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. I am interested in exploring this further with the aim of finding good >> community norms, nailing down the problem cases, and making the >> introduction of ODbL for OSM a success. >> > > I'm interested in finding out where the weaknesses in ODbL are and > ensuring that they are understood. Version 1 of anything is likely to have > imperfections and it would be better to find them sooner rather than > later. A working version of ODbL is the goal I would aim for. > In the discussion a few months ago, not everyone agreed on where the line is. -- James
_______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
