Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
On Sun, Mar 01, 2009 at 10:35:21AM +0100, Frederik Ramm wrote: Simon Ward wrote: 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. So be it. Do you have any suggestion on how to achieve this technically? For such a large amount of data, not much if you actually had to redistribute the entire data yourself, but see below. ODbL already defines derivatives, produced works and collective databases separately, and is much more permissive for the latter two. Distribute a derived database, share it please. This is not about the distribution of a derived database; if I already have the database in a form that can be distributed, then sharing it is trivial. My question is about the distribution of a Produced Work and whether or not the underlying derived database needs to be made available even if it does not have any value added. Then you you have more than one thing here: * A derivative database, consisting of the original database imported into PostGIS. * A produced work, consisting of the derivative database and other elements. To make the exampe clear: http://c.tile.openstreetmap.org/7/63/42.png would, under the new license, be a Produced Work. It is based on nothing more than is available at planet.openstreetmap.org, imported into a PostGIS database which is updated once a minute. […] our own tile server would have to be scaled back to once-a-day updates because we could not possibly produce the PostGIS dumps once an hour. If your tileserver also provides the ability to directly query the derivative database, then I think you should be obliged to distribute the database. If you just have a tile browser, then probably not. It gets more difficult when you start providing things like place name searching: Is that still acceptably a produced work, or are you providing access to the database? I would err towards providing the database. If you do have to offer the derived database, you may not have to worry about providing frequent dumps. The licence specifically allows for distributing the whole database, or simply a file containing the alterations made. It doesn’t say how the differences should be encoded, so I think it’s reasonable to document that you used osm2pgsql, osmosis, or other, and exactly how you used it (command line arguments, inputs, etc). Richard has already commented on the relevant this part of the license (4.6(b))[1]. [1]: http://www.co-ment.net/text/844/ This does bring up some other questions though: What if the software doesn’t produce predictable results each time it is run? This could possibly be solved by extending the software to produce a trace of operations that it or another tool could process to perform exactly the same transformation of the database. This could become quite large though, so we’re back to distributing large amounts of data with frequent updates. In case you used an old version of the software that may no longer be distributed by the authors but could produce different results, should you provide the exact software you used? Can you just specify how you import the original database, and how each diff is imported, or do you have to document the whole process of importing and provding minutely updates? Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
Frederik Ramm wrote: I'm surprised that nobody else seems to see a problem in this. Am I perhaps barking up some completely imaginary tree? Not at all; I am still reading through the draft, and have exactly the same concern. 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). That is not always practical, and if all my transformations are destructive then I don't think it's even useful (compared to simply making a copy of the original database available, to ensure the source data is never lost if openstreetmap.org goes away). I'm not sure what format a file containing all of the alterations would take. Does this mean a machine-readable list of the exact transformations that were performed, or simply a human-readable summary of the transformations made? If I map our fixed point lat/lons to 32-bit floats, I will create a derivative database (32-bit floats can't represent all integers exactly, so I've lost some information and can't go back). Do I need to publish exactly which floating point value each integer was mapped to, or simply say I converted all lat/lons to floats? The latter makes more sense, but do I also need to specify that they're IEEE floats and which of the four IEEE rounding modes were used? I don't have a better phrasing for 4.6b, but I would like to allow alterations to be specified as: - A literal set of transformations to apply (e.g., a lookup table or code that could be executed to apply the transform). - A human-readable set of instructions that are reasonable Introducing reasonable means I can have my lawyer argue with yours over whether convert to floats is a reasonable summary or not, and not have to worry about being sued because I used an unusual rounding mode like round-to-infinity and forgot to mention it. It also means you can publish imported into PostGIS using this schema as your alteration, and not have to provide the literal derivative database created by your particular version of PostGIS when run on a specific platform/OS. -dair ___ d...@refnum.com http://www.refnum.com/ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
2009/3/1 Andy Allan gravityst...@gmail.com: On Sun, Mar 1, 2009 at 10:04 AM, Frederik Ramm frede...@remote.org wrote: I'm surprised that nobody else seems to see a problem in this. Am I perhaps barking up some completely imaginary tree? Nope, not at all, I'm exceptionally concerned about the implications on the cyclemap db. I'm combining PD SRTM data and OSM data, and as far as I'm concerned making both original sources available should be sufficient. That way every piece of geographic data used in the cyclemap is available. Being forced to offer a postgis dump would suck massively. And never mind for me - I've got the time and energy to deal with it if needs be. But it'll also suck for people doing things like my public transport experiments - as soon as you put up a picture of one of your experiments all of a sudden you'll have some guy demanding a dump of your postgis db. Seems overkill, and like you say, the intention should be to make the geographic data available, not the specific instance of (perhaps processed) data. Yes, for instance this page would just not exist under that interpretation: http://dev.openstreetmap.org/~random/progress/?region=northamerica There's no way I'd have bothered... and dev doesn't have a big enough hard disk anyway :-) Dave ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
Rob Myers r...@robmyers.org wrote: With the GPL, the right to request the source is attached to receiving and using the binary. Withe the AGPL it is attached to being a user of the service. You can't just wander by and say hey! please can I have the source?, you have to be a user of the binary. (In practice people just pop the source on an FTP server, but that's less onerous than having to make minute-by-minute snapshots of OSM available.) That touches on two of the Big Unexploded Lawyerbombs of the AGPL:- 1. are you still a user of the service if the service only says Access Denied to you? 2. if you pop the source on an FTP server, does that mean the service must stop if that FTP server is down? I don't know if either of those are concerns for the OSM licence. Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
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 frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
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
Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
On Sat, Feb 28, 2009 at 10:58:04PM +0100, Frederik Ramm wrote: 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. It’s a database, derived from the original. To me it’s a derived database. It does need clarifying to say just that. 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. So be it. 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. ODbL already defines derivatives, produced works and collective databases separately, and is much more permissive for the latter two. Distribute a derived database, share it please. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
Simon Ward si...@... writes: The lawyer's answer is: Need clarification here. From my reading, this example would seem to constitute a Derivative Database under the ODbL. It’s a database, derived from the original. To me it’s a derived database. It does need clarifying to say just that. 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. So be it. I agree that logically this is OK. It is a database, derived from the original. I feel still that it is unreasonable to say that this kind of just imported and hardly any modified dataset really is markable different from the original. I do regularly import some osm data into PostGIS and reproject it inside the database. Would it be enough to tell where to download the original OSM data and what script to run, or should I really make a dump from my imported and reprojected database tables if someone requests? The result would be identical. Where actually goes the limit between database and something else? I believe that if I convert the data from osm format directly into ESRI Shapefiles then I do not have a database, or do I? But if I let ArcGIS to store the shapefile data into its own personal geodatabase, then I would have a derived database again? How about if I store some attributes from osm data into Excel vs. Access, the latter forms obviously a derived database while the first doesn't? ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
