On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm <frede...@remote.org> wrote:
> Hi, > > > On 11/28/11 11:58, 80n wrote: > >> That's a very fine line you are trying to draw. >> > > Yes, I agree it is difficult. I think that it is entirely possible to > arrive at an identical end product through different processes, where one > process has different license implications than the other. > > For example: > > 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 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. > Same thing with your reply to my "pencil" example - depending on how > exactly you update your produced work, you might or might not have to > release a database. > If this were to be possible then it would be a very undesirable flaw. The intent of ODbL was to protect OSMs database and ensure share-alike. If it can be circumvented then it fails one of its main purposes. > > 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.
_______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk