[OSM-legal-talk] Lawyer responses to use cases, major problems

Frederik Ramm frederik at remote.org
Sun Mar 1 22:01:33 GMT 2009


Hi,

Frederik Ramm wrote:
> We need to clarify this once and for all: Where exactly in the following 
> typical rendering chain does the thing cease to be a database in our 
> definition?
> 
> * download (section of) OSM data
> * make changes to OSM data
> * render OSM data into vector graphics format (say SVG)
> * make changes to SVG file (say using Inkscape)
> * render SVG file into bitmap
> * make changes to bitmap

Let me explain why I think that this is so important, and please correct 
me if you have a different interpretation than I have.

ODbL says you have to share a derived database if you publish it. You do 
*not* have to share the full chain of derived databases that led you 
from the planet file to your final derived database, just the latest one 
that you publish.

If you create and publish a Produced Work, then you have to share the 
derived database on which it is built.

This means that in any case, only *one* database from the above chain 
will have to be published.

If we, say that no item in the above list is a "Produced Work", i.e. 
even a bitmap is still a database, then the person running the above 
process will *only* have to publish and share the bitmap and *not* his 
improved OSM database.

If we say that the vector graphics is still a database but the rendering 
of a bitmap makes it into a produced work, then the publisher of the 
bitmap need not share the bitmap, and neither his improved OSM database, 
but (only) the vector graphics.

If we say that the database is lost and a Produced Work created when 
rendering the vector graphics from the OSM database, then neither the 
vector graphics nor the bitmap need be shared, but the modified OSM 
database has to be.

Obviously a shared bitmap without the OSM data behind it is rather 
worthless to us... it is better than nothing of course, but the shared 
bitmap is what CC-BY-SA gives us today.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"




More information about the legal-talk mailing list