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 frede...@remote.org ## N49°00'09" E008°23'33" _______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
