Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Jonathan Harley wrote: > Really I'm at a loss to see the point of the share-alike clause (4.4). > I can't think of a use-case for OSM where processing the database > doesn't reduce the amount of information. The canonical case, often cited by those who say OSM needs a share-alike licence, is to prevent commercial map providers taking the data we have and they don't (e.g. footpaths), adding it to the data they have but we don't (e.g. complete road network), and not giving us anything back. IRMFI, not because I believe it myself. :) cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Exception-in-Open-Data-License-Community-Guidelines-for-temporary-file-tp6504201p6532530.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
On 29/06/11 19:56, Frederik Ramm wrote: Hi, James Livingston wrote: If I use software that builds an in-memory data structure which you believe to be a database in order to make a produced work, how would you suggest that I fulfil my obligation to make such derived database available on request? I have absolutely no idea. It's one of the many things I don't know about how the produced works part of the ODbL will work in practice. Thinking about this more, the problem would only occur if you have a black-box software wich might or might not create a database internally, and the thing that falls out of the black box is a produced work that you will publicly use. Because then, and only then, will you have to share the derived database upon which the produced work is based. If, on the other hand, out of the black box comes a derived database, then you can simply share *that* database and nobody cares what happened in the black box, because you only have to share the last in a chain of derived databases that leads to a produced work, right? I think that's right - that's the only one which you're publicly using. Really I'm at a loss to see the point of the share-alike clause (4.4). I can't think of a use-case for OSM where processing the database doesn't reduce the amount of information. When you want to render geodata, it typically involves discarding most of the metadata, getting rid of points from ways, and transforming lat/long to cartesian co-ordinates in a projection. The resulting database is always going to have a lot less information than the original, and be difficult or impossible to translate back into OSM (without the OSM IDs or original lat/long). So what's the point of the huge burden of being required to make it available on request? Who benefits? Jonathan. -- Jonathan Harley: Managing Director : SpiffyMap Ltd Email: m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com Post: The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Hi, Richard Fairhurst wrote: The Directive says a database [snip Richard's quote and replace mine from http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31996L0009:EN:HTML] "Article 1 Scope 1. This Directive concerns the legal protection of databases in any form. 2. For the purposes of this Directive, 'database` shall mean a collection of independent works, data or other materials arranged in a systematic or methodical way and individually accessible by electronic or other means." I would say that a list of 65536 colour values (the "data"), arranged in a systematic way in 256 columns and 256 rows, and individually accessible by a PNG reader, certainly sounds like a database according to this defintion? I'm just speculating here but if I had a rendering engine that would transform the OSM planet file into a giant bitmap (colour values arranged, etc.), I would not be surprised if I could get away with sharing this bitmap as a derived database under ODbL. I guess someone who printed it out would then create a produced work, but me? Not a lawyer here either, and frankly if we took the position that every map tile was indeed a database, then a lot of the advantages we see in ODbL would crumble. But, as Kai suggested, in some situations it may actually make things easier for you if you could say "this PNG file is a database"; and the current community norm does seem to allow a lot of interpretation. Ok, so my PNG file was "intended" to extract the data. It didn't work out in the end but the intention was there... ) 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] Exception in Open Data License/Community Guidelines for temporary file
Frederik Ramm wrote: > If, on the other hand, out of the black box comes a derived database, > then you can simply share *that* database and nobody cares what > happened in the black box, because you only have to share the last > in a chain of derived databases that leads to a produced work, right? I would be interested to hear the view of someone wise who knows about these things, because I'm not convinced that ODbL mandates publishing the source (or diff) in every single circumstance. If your interim derived database is a fairly trivial transformation, as I suspect many will be, then your changes aren't quantitatively Substantial; therefore ODbL's provisions may not apply; therefore you may not have to publish the derivative. And yes, as Jonathan Harley says, the diff requirement can also be fulfilled by providing an algorithm. (I don't think that ODbL requires all the components of the algorithm need be open source, FWIW.) I am really really really not a lawyer. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Exception-in-Open-Data-License-Community-Guidelines-for-temporary-file-tp6504201p6530822.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Frederik Ramm wrote: > I've been thinking about that. It would certainly be within the > legal definition of a database to call a PNG file a database. Not sure which legal definition you're looking at, but there's never such a thing as "certainly" where the EU Database Directive is concerned. :) The Directive says a database "should be understood to include literary, artistic, musical or other collections of works or collections of other material such as texts, sound, images, numbers, facts, and data; whereas it should cover collections of independent works, data or other materials which are systematically or methodically arranged and can be individually accessed; whereas this means that a recording or an audiovisual, cinematographic, literary or musical work as such does not fall within the scope of this Directive". The map data in a rendered PNG file cannot be individually accessed, except by means of "reverse engineering", which by its nature means "recreating a database where there isn't one". This is, of course, a spectrum, and there will doubtless be things that could be classed as either Derivative Databases or Produced Works. But that's not to say you can call anything you like a Derivative, and a PNG map seems to me to be very definitely at the Produced Work end of the spectrum. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Exception-in-Open-Data-License-Community-Guidelines-for-temporary-file-tp6504201p6530770.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Kai Krueger wrote: > Am I allowed to declare my png mapnik tile as a "derived database", stick an > ODbL label on it an be done with it? > > Then I don't have to reverse engineer my render to figure out if or if not > it produces an internal database and worry about having to maintaining a > snapshot of that database for ever and what legal consequences there might > be if my dog eats the backup, etc. I'd be back to the simplicity of > CC-BY-SA, i.e. that all obligations of the licenses are met within the work > I hand out itself and have no additional work (or worries) beyond producing > the product in the first place. +1, I couldn't have expressed this better. For many use cases, it's a massive burden that you need to hand out other things besides the product you originally wanted to produce. The worst part is, of course, that nobody seems to be able to tell you with any certainty what these "things" are. But even without that uncertainty, it's often just plain impractical: Right now, Joe Mapper can download a 3D renderer/viewer (= use case which is relevant for me personally), load an .osm file to have a virtual landscape generated, fly around a bit, hit PrtSc to take a snapshot of his carefully-mapped home town and proudly publish it on his blog, make it available on gnome-look.org as a desktop background or whatever. The requirement to publish the image with a CC-BY-SA label attached seems perfectly reasonable and easy to comply with. But with ODbL, he suddenly might have to publish the "temporary database" that the 3D renderer created in the process. He will not even understand what he needs to do, and if he did, he'd have a hard time uploading that x00 MB binary blob to gnome-look.org alongside with his desktop background. And nobody would want it anyway! -- Tobias Knerr ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Hi, Kai Krueger wrote: If, on the other hand, out of the black box comes a derived database, then you can simply share *that* database and nobody cares what happened in the black box, because you only have to share the last in a chain of derived databases that leads to a produced work, right? Am I allowed to declare my png mapnik tile as a "derived database", stick an ODbL label on it an be done with it? I've been thinking about that. It would certainly be within the legal definition of a database to call a PNG file a database. This would mean that the producer of a map tile has a choice - either declare your map tile to be ODbL, lose the ability to license your map tile differently, but not have to share any databases behind it; or choose to declare your map tile a produced work that you can license in a different way but then you have to share the database behind it. Our community norm currently says it is a database if it was intended to extract the data... some time in the past someone said "it is a database if you say it is one". Maybe that wasn't so bad after all. 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] Exception in Open Data License/Community Guidelines for temporary file
Frederik Ramm wrote: > > If, on the other hand, out of the black box comes a derived database, > then you can simply share *that* database and nobody cares what happened > in the black box, because you only have to share the last in a chain of > derived databases that leads to a produced work, right? > Am I allowed to declare my png mapnik tile as a "derived database", stick an ODbL label on it an be done with it? Then I don't have to reverse engineer my render to figure out if or if not it produces an internal database and worry about having to maintaining a snapshot of that database for ever and what legal consequences there might be if my dog eats the backup, etc. I'd be back to the simplicity of CC-BY-SA, i.e. that all obligations of the licenses are met within the work I hand out itself and have no additional work (or worries) beyond producing the product in the first place. -- View this message in context: http://gis.638310.n2.nabble.com/Exception-in-Open-Data-License-Community-Guidelines-for-temporary-file-tp6504201p6530357.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
>>> If I use software that builds an in-memory data structure which you >>> believe to be a database in order to make a produced work, how >>> would you suggest that I fulfil my obligation to make such derived >>> database available on request? >> >> I have absolutely no idea. It's one of the many things I don't know >> about how the produced works part of the ODbL will work in practice. >Thinking about this more, the problem would only occur if you have a black-box >software wich might or might not create a database internally, and the thing >that falls out of the black box is a >produced work that you will publicly use. > >Because then, and only then, will you have to share the derived database upon >which the produced work is based. No, this happens with all software, regardless of the software license. Who is reading the source code of a free software just to know if creates internal database? ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Hi, James Livingston wrote: If I use software that builds an in-memory data structure which you believe to be a database in order to make a produced work, how would you suggest that I fulfil my obligation to make such derived database available on request? I have absolutely no idea. It's one of the many things I don't know about how the produced works part of the ODbL will work in practice. Thinking about this more, the problem would only occur if you have a black-box software wich might or might not create a database internally, and the thing that falls out of the black box is a produced work that you will publicly use. Because then, and only then, will you have to share the derived database upon which the produced work is based. If, on the other hand, out of the black box comes a derived database, then you can simply share *that* database and nobody cares what happened in the black box, because you only have to share the last in a chain of derived databases that leads to a produced work, right? 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] Exception in Open Data License/Community Guidelines for temporary file
On 29/06/11 11:02, James Livingston wrote: To your point, what happens when someone loads a .osm file into JOSM? First, I'd claim that a .osm file is a database. Obviously not a relational database that gets handled by SQL-using software, but still a database. I'd also claim that the in-memory data structures of JOSM form a database too. The ODbL saud "Database - A collection of material (the Contents) arranged in a systematic or methodical way and individually accessible by electronic or other means offered under the terms of this License". I think the data structures JOSM uses to view and edit certainly qualifies. I agree - I would say any data structures would qualify. No program can do anything useful without data arranged in a systematic or methodical way. A hash table or linked list are just as systematic as relational tables. As you say, ODbL (and the EU database directive) uses the term much more widely than to mean things you can query with some dialect of SQL. On 29/06/2011, at 4:25 PM, Frederik Ramm wrote: If I use software that builds an in-memory data structure which you believe to be a database in order to make a produced work, how would you suggest that I fulfil my obligation to make such derived database available on request? In ODbL you have an obligation to EITHER make the database available, OR the "method" used to make it - so you could make your software's source code available on request, if it's yours to do that with - or if it's open source. That lets JOSM, Mapnik etc off the hook from having to distribute copies of their internal derived databases. If it's someone else's proprietary software (as ThomasB suggested), then you probably can't publish either the source code or the database. So one interpretation would be that, in that case you simply can't use data from OSM with that software. (Assuming that the results of the software are substantially from OSM and that you want to share them.) However, since ODbL fails to define what it means by "method", you might take a broader interpretation and tell the requester "my method was to use software X". I don't know if this would stand up in court, but then again, I very much doubt that demands for a derived database which has been deleted would either. Jonathan -- Jonathan Harley: Managing Director : SpiffyMap Ltd Email: m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com Post: The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
On 29/06/2011, at 4:25 PM, Frederik Ramm wrote: > On 06/29/11 05:21, James Livingston wrote: >> I don't think it would be treated differently, because I believe that an >> in-memory data structure would still be a database (in the ODbL and >> database right sense of "database"). I don't see how the storage >> mechanism makes a difference. > > Would you therefore say that before I can use proprietary software to process > an ODbL data set, I would have to request from the software provider a legal > statement about whether or not it does create a database internally? That's a slightly different point, what I was trying to say was that if you have something in memory that doesn't qualify as a database, then it won't magically become a database if it happens to be swapped to disk. Conversely, if you have something that is a database, it doesn't stop being a database because you load it into memory. Being a structured representation of data makes it a database, not where the bits happen to be. To your point, what happens when someone loads a .osm file into JOSM? First, I'd claim that a .osm file is a database. Obviously not a relational database that gets handled by SQL-using software, but still a database. I'd also claim that the in-memory data structures of JOSM form a database too. The ODbL saud "Database - A collection of material (the Contents) arranged in a systematic or methodical way and individually accessible by electronic or other means offered under the terms of this License". I think the data structures JOSM uses to view and edit certainly qualifies. If you immediately saved it back to a file after loading, it would go Database (on disk) -> Database (in JOSM memory) -> Database (on disk), not Database -> Non-database -> Database. The data stored in the in-memory database is equivalent to the on-disk one, but it's still there. I would think that the vast majority of software that does useful work will need to create a temporary database to do so. I've never looked how Mapnik is implemented, but I assume it creates a bunch of data as it goes about what POIs and labels it is rendering where, so the map doesn't get too crowded. Is that a derived (temporary) database? > If I use software that builds an in-memory data structure which you believe > to be a database in order to make a produced work, how would you suggest that > I fulfil my obligation to make such derived database available on request? I have absolutely no idea. It's one of the many things I don't know about how the produced works part of the ODbL will work in practice. -- James ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Hi, On 06/29/11 05:21, James Livingston wrote: I don't think it would be treated differently, because I believe that an in-memory data structure would still be a database (in the ODbL and database right sense of "database"). I don't see how the storage mechanism makes a difference. Would you therefore say that before I can use proprietary software to process an ODbL data set, I would have to request from the software provider a legal statement about whether or not it does create a database internally? If I use software that builds an in-memory data structure which you believe to be a database in order to make a produced work, how would you suggest that I fulfil my obligation to make such derived database available on request? Bye Frederik ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
On 23 June 2011 03:29, Frederik Ramm wrote: > In today's operating systems, whether something is in a file or in memory > is a boundary that might easily get blurred. It would be kind of strange if > one algorithm that chooses to build a giant data structure in memory (using, > for example, a lot of swap space) would be treated differently from another > algorithm that does exactly the same, but writes its data out to a temporary > file (which might be a database). > I don't think it would be treated differently, because I believe that an in-memory data structure would still be a database (in the ODbL and database right sense of "database"). I don't see how the storage mechanism makes a difference. -- James ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
Hi, On 06/22/11 15:18, ThomasB wrote: My point is that a user of software, and this is not limited to Garmin map software, may not know what a software does in the background i.e. if it is creating a (temporary) Derivative Database, a Collective Database or whatever. Yes. The software might well be proprietary, and so the user would not have a chance to really know. In today's operating systems, whether something is in a file or in memory is a boundary that might easily get blurred. It would be kind of strange if one algorithm that chooses to build a giant data structure in memory (using, for example, a lot of swap space) would be treated differently from another algorithm that does exactly the same, but writes its data out to a temporary file (which might be a database). I think that your attempt at solving this problem is a bit complicated but I don't have a brilliant idea either. We might just have to live with the fact that the same end product, created using different paths, may result in different ODbL requirements. Bye Frederik ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file
- Original Message - From: "ThomasB" To: Sent: Wednesday, June 22, 2011 2:18 PM Subject: [OSM-legal-talk] Exception in Open Data License/Community Guidelines for temporary file Dear Legal-list, My question applies to all kind of software that process OSM data but I am using Garmin maps as a popular example. Generating Garmin maps with contours is pretty easy and sometimes completely GUI driven. You select an OSM file, click a button and get a Garmin map. I have distributed such maps sometimes (for free) to some interested people who asked me. First thing to note, is that it is my understanding that the "OSM file" you refer to above is also a "derivate database". In the background it downloads SRTM data from cgiar.org (Consultative Group on International Agricultural Research) and seeds that data into the OSM data. I think technically they are added as normal osm-ways with specials tags for the renderer. The cgiar data is non-commercial only (cc-by-sa-nc) licensed. The final Garmin map is rendered from a temporary file that contains both datasets and would constitute a Derivative Database. My point is that a user of software, and this is not limited to Garmin map software, may not know what a software does in the background i.e. if it is creating a (temporary) Derivative Database, a Collective Database or whatever. It is unrealistic that a user of software browses through the directories and check the content of the files there, particularly if the file exist only a short time during the process. So applying the ODbL rules to software generated temporary files would lead me to the conclusion that the solution is "don't ask, don't mind". Although I personally could live with that I am not sure if it wouldn't be better to sort it out. The Trivial Transformations Guideline or Community Guidelines could be a good place to make it easier. I am neither a license expert nor a lawyer. From a practical point of view I would wish a clarification like: /"Temporary software generated files used for the generation of a Produced Work or a Derivative Database that i) contain data from OSM, ii) may contain data from other (licensed) sources, iii) are only created and used for the purpose of the generation of one Produced Work or one Derivative Database, iv) will not be used for any purpose thereafter, v) will not be distributed or made publicly available do not constitute a derivative database, collective database or produced work"/ But I am not sure about any other (unwanted) implication it may have. As far as I can see, ignoring your specific example, and genearlising, the "unwanted implication" of your clarification above would be that as long as someone deleted the derivate database they had created they could then claim it was "temporary" and therefore sidestep the requirements of the ODbL to distribute it. To avoid this you would thenhave to start defining "temporary" etc. Regards David Kind regards Thomas -- View this message in context: http://gis.638310.n2.nabble.com/Exception-in-Open-Data-License-Community-Guidelines-for-temporary-file-tp6504201p6504201.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk