[OSM-legal-talk] ODbL and publishing source data

James Livingston lists at sunsetutopia.com
Mon Nov 28 23:59:36 GMT 2011


On 28 November 2011 21:55, 80n <80n80n at gmail.com> wrote:

> On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm <frederik at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20111129/81efeada/attachment-0001.html>


More information about the legal-talk mailing list