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

[Frederik Ramm]

Hi,

    I have read the lawyer notes on our use cases

http://wiki.openstreetmap.org/wiki/Open_Data_License/Use_Cases

and I am very concerned about a few of them; in fact so concerned as to 
say that if this cannot be clarified further then the license is going 
to fail.

(In some cases the lawyer's response reads like "I don't understand 
this, please explain" - direct question to the license team: who of you 
has done this, or is planning to do this, or are we simply ignoring the 
cases where the lawyers did not understand it first time? We cannot 
possibly ask people to vote based on a document where our legal counsel 
said "sorry I cannot answer this", can we?)


My major concerns are, at the moment:

"Including OSM data in a hand-made map"
---------------------------------------

In this use case we look at a graphic designer who makes a map using 
something like Acrobat, and my assumption until now was that while any 
improved OSM data has to be shared back, the Acrobat file - roughly 
speaking, anything that comes *after* the rendering stage - will be the 
Produced Work that need not be shared.

The legal counsel now says something else which is neither flesh nor fish.

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

If this is not a question that a lawyer can answer, then it is us who 
need to give this answer, and this answer has to be included in anything 
we ask people to vote for or against - because it makes a *hell* of a 
lot of difference where in the above chain the "Database" ceases to 
exist and the "Produced Work" comes into existence.

"Having to grant access to pgsql data base"
-------------------------------------------

In this use case we look at someone who does nothing more than taking 
OSM data and rearranging it according to fixed rules, e.g. by running it 
through osm2pgsql. The question we face is: Does this create a derived 
database to which access has to be granted because of the share-alike 
element of the license, or is it sufficient to say "this is just the 
planet file run through osm2pgsql"?

The lawyer's answer is: "Need clarification here. From my reading, this 
example would seem to constitute a Derivative Database under the ODbL."

Again, is someone following this up, or do you want me to ring up the 
lawyer myself? If this is not clarified, then this could mean that 
anyone running osm2pgsql importing minutely data updates would possibly 
have to make available a ''psql dump of the whole planet'' for any 
snapshot time where someone cares to request it. This would mean that 
for example our own tile server could not continue importing minutely 
diffs because it cannot make the matching data available. It would also 
have serious implications for other similar services, like the CloudMade 
tiles. Handing out the data in OSM XML format would, if transformation 
constitutes a derivative database, not be sufficient; the contents of 
the PostGIS tables would have to be made available.

This is impractical and extremely undesirable but if even now our own 
legal counsel is not sure and says this is likely going to be a derived 
database case, then I must honestly say: We haven't got very far yet. 
The problem with the old license, the problem we're trying to solve 
mainly, is that there were so many unresolved issues, that a strict 
reading of the license could bring down most services overnight and 
everyone depended on a relaxed reading. If things like the above are not 
made very very clear and leave any room for interpretation then the new 
license, again, has the potential to wreck many legitimate uses when 
read strictly.

Bye
Frederik

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