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

[Frederik Ramm]

Hi,

Dair Grant wrote:
> It may be I have misunderstood how this is intended to apply, but I think
> both 4.6a and 4.6b end up making derivative databases (effectively any
> mechanical processing of the original content whatsoever, IMO) problematic.
> 
> In many cases, generating "a file containing all of the alterations" will be
> at least as much work as making the derivative database available (leaving
> aside that publishing these alterations may reveal some proprietary
> information, making it less likely for OSM data to be used).

I think it was RichardF who, long ago, suggested that we could perhaps 
amend 4.6 by something like

c. An algorithm or computer program, or reference to a publicly 
available algorithm or computer program, that performs the alterations

I'm sure some details about this would need to be hammered out, but this 
could be a way for the publisher to say "I used osm2pgsql for this" 
rather than actually having to provide osm2pgsql's output.

This could, however, still touch on someone's business secrets when he 
has a very clever way of arranging OSM data that allows him to, for 
example, create faster, bigger, better, more tiles than the competition.

We might need to introduce an entirely new section somewhere that says 
something like

"For the purpose of this license, any modification to a database that 
does not add original content but only transforms existing content 
algorithmically is not considered a derived database."

In a way, something like this is already implicit because everyone 
assumes that copying the database from one media to another will not 
constitute a derived database even though, for example through the 
characteristics of the underlying file system, the arrangement of data 
will change. We would basically say that running osm2pgsql on your data, 
or creating an index, or lowercasing all tags, is not different from 
unzipping the planet or copying the planet from a FAT32 onto an ISO9660 
file system. (I'm sure the license must provide for this not 
constituting a derived database... or does it?)

Bye
Frederik

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