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

[Jonathan Harley]

On 28/11/11 23:59, James Livingston wrote:
> On 28 November 2011 21:55, 80n <80n80n at gmail.com 
> <mailto:80n80n at gmail.com>> wrote:
>
>     On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm
>     <frederik at remote.org <mailto: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.
>

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.

Of course if Frederik did remove hotels from the OSM dataset as he 
described above, then that's clearly a derivative database which he 
would have to share.

>
> 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.

>
> 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.


Jonathan.

-- 
Jonathan Harley    :     Managing Director     :     SpiffyMap Ltd

Email: md at spiffymap.com   Phone: 0845 313 8457   www.spiffymap.com
Post: The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ