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
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
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 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, 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
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, 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
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
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
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
On 23 June 2011 03:29, Frederik Ramm frede...@remote.org 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
- Original Message - From: ThomasB toba0...@yahoo.de To: legal-talk@openstreetmap.org 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
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
