Re: [OSM-legal-talk] ODbL and publishing source data
Eugene Alvin Villar seav80@... writes: Taking this argument to its logical conclusion, every digital file is a database of bytes Yes, I suggest that legally speaking this is likely to be the case. Certainly any digital file that is in a documented, structured file format with certain fields in certain positions has just as strong a claim to being a 'database' as, say, the OSM planet file. The European definition of a database is a collection of independent works, data or other materials arranged in a systematic or methodical way and individually accessible by electronic or other means. Individual pixels comprising a typical image (say a PNG map tile) are not independent works. Each pixel cannot stand on its own and aren't useful unless considered together with its neighboring pixels to form an image. That makes some sense but you are implicitly taking the individual pixel as the level of granularity. If you took the OSM planet file as your example once again, you could state that neither the individual co-ordinate numbers like 50.1234, nor individual tag strings like 'highway', have any independent existence. They must stand together with other data items to form a complete object such as a node, which even then may not have much meaning without others. Richard F. noted that audiovisual works... as such are not databases. I imagine it is an open question whether this means photographs and other pictorial images, and whether it applies to images with a defined schema such as heatmaps (which can equally well be considered as a database of co-ordinates mapped to values) or to diagrams and maps with a defined schema and a strict correspondence between pixel co-ordinates and geographical position. (I also note that as such is a weasel phrase which European law may wiggle through, as with the exclusion of computer programs as such from patentability.) In general I think that introducing the concept of database into licensing causes more problems than it solves, and tends to muddle more than it clarifies, but that's just my opinion. -- Ed Avis e...@waniasset.com ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] Community norms (was: ODbL and publishing source data)
Frederik Ramm frederik@... writes: I am interested in exploring this further with the aim of finding good community norms, nailing down the problem cases, and making the introduction of ODbL for OSM a success. I think you have to be careful about going too far with community norms. They may give the misleading impression that copyright holders have endorsed them so that they are legal statements of what you can do with the map, but this is not the case. Also, the contributor terms permit distribution under ODbL, not 'ODbL with community norms', so it would not be within OSMF's mandate under the CTs to introduce additional material to the licence, however well- intentioned. Community norms can serve to narrow the permission (as in: although X may be permissible according to the letter of the law, we don't feel it fits the spirit) but they cannot state anything with authority where the underlying legal situation is unclear. More to the point, would it not be better to fix up ambiguities in a new version of the ODbL? Migrating to it later would be pretty painless since the licence is forward-compatible. -- Ed Avis e...@waniasset.com ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Community norms
Hi, On 11/29/11 11:49, Ed Avis wrote: I think you have to be careful about going too far with community norms. Of course. They must not introduce new material, but they can be used to clarify areas where things aren't crystal clear. Community norms can serve to narrow the permission (as in: although X may be permissible according to the letter of the law, we don't feel it fits the spirit) but they cannot state anything with authority where the underlying legal situation is unclear. OSMF is the holder of the database rights; while OSMF may not be able to state anything with authority they can certainly say we guarantee that we will not sue you if you adhere to the following. Which is good enough. More to the point, would it not be better to fix up ambiguities in a new version of the ODbL? Migrating to it later would be pretty painless since the licence is forward-compatible. Yes, certainly. Any community norms we set up should be considered an input to possible future versions of ODbL. We have to be clear, however, that ODbL is not specifically intended for our situation, so the ODbL authors may decide not to include things that are too specific. For example, our community guideline about what is and isn't substantial uses a spatial definition that will certainly not apply to all ODbL licensed datasets. Bye Frederik ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL and publishing source data
On Tue, Nov 29, 2011 at 6:42 PM, Ed Avis e...@waniasset.com wrote: The European definition of a database is a collection of independent works, data or other materials arranged in a systematic or methodical way and individually accessible by electronic or other means. Individual pixels comprising a typical image (say a PNG map tile) are not independent works. Each pixel cannot stand on its own and aren't useful unless considered together with its neighboring pixels to form an image. That makes some sense but you are implicitly taking the individual pixel as the level of granularity. If you took the OSM planet file as your example once again, you could state that neither the individual co-ordinate numbers like 50.1234, nor individual tag strings like 'highway', have any independent existence. They must stand together with other data items to form a complete object such as a node, which even then may not have much meaning without others. The difference is that for the OSM database, you can construct a systematic level of granularity where individual objects at that granularity are individually useful. Certainly, individual tags or individual pairs of coordinates are not generally useful but a collection of tagged POIs, ways, and relations are each individually useful. Whereas for a *typical* image consisting of a matrix of pixels, there's no level of granularity that would make individual objects generally useful, whether those objects are single pixels, or rows of pixels, or columns of pixels, or tiles of 8x8 pixels. You have to take the image as a whole to make sense of it. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL and publishing source data
On 28/11/11 23:59, James Livingston wrote: On 28 November 2011 21:55, 80n 80n...@gmail.com mailto:80n...@gmail.com wrote: On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm frede...@remote.org mailto:frede...@remote.org wrote: I could render a map from OSM and then render something else on top of it, say a commercially acquired set of hotel POIs. That would clearly be a Produced Work; I could point anyone asking for the source data to the planet file and the rendering rule, and keep the hotel POIs to myself. This is an overlay on top of a Produced Work. Whether it's produced by layers at the browser end or by compositing two separate images doesn't seem to be materially different. I agree. I could also remove all hotels from my OSM copy and add in the commercial hotels instead, then render a map from it. Unless the commercial dataset is missing data, the resulting map could look 100% identical to the map from the first process, but this time I would be required to release the hotel dataset because it is part of the derived database used to create the produced work. Leaving aside the step about removing content for the moment, I don't see how this is materially different from the first example. You've simply overlaid your hotels on top of the OSM data. I don't think the mechanics of how you achieved this are, from a legal perspective, important. Any process can be considered as a series of inputs to a black box and some outputs. If the inputs are the same (an OSM database and a set of POIs) and the output is the same (a map with an overlay of the POIs) then it shouldn't matter whether it was achieved using a complex machine or monkeys with typewriters. Depending on the rendering, it may not be the same. The placements of name text can depend on other data so it's not on top of something else, or POIs can be hidden if there are too many in a given area. In the first case (or combining layers in the browser), the rendering of OSM data cannot depend on the location of your hotels, and the rendering of hotel names can't easily depend on what else is on the map. In the second case (combining data before rendering) collisions can be avoided or the resulting map altered. Yes, but it's only the produced work, the rendering, which is altered. You probably don't need to make changes to the OSM data to acheive this. So the OSM data and other data could remain independent. If they do, then the mechanism for combining (and computer/s on which it happens) is indeed irrelevant. Of course if Frederik did remove hotels from the OSM dataset as he described above, then that's clearly a derivative database which he would have to share. This was discussed on legal-talk a few months ago, and my opinion was that it depended on whether you could produce the same output by merging separately-rendered Produced works. If you can get _identical_ output by merging layers on the browser side, then it's okay to the merging on the server side. However if you can't get identical results by merging the rendered output, then you've obviously combined the databases prior to rendering. Not necessarily. For example, the rendering might depend on what order data is rendered. But the data being rendered would remain independent of each other; it may be only the rendered result which varied. And that's a produced work, not a database. Having two instances of say Postgres and having one program that reads both and renders is still creating a derived database, even if it is only in the memory of the rendering program. It might create a derivative database, or it might not; it would depend on the algorithm. If the OSM data remain unmodified, then it could be creating a collective database, which is explicitly not a derivative database. 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] Community norms
Frederik Ramm frederik@... writes: OSMF is the holder of the database rights; while OSMF may not be able to state anything with authority they can certainly say we guarantee that we will not sue you if you adhere to the following. Which is good enough. I think that database right is only a small part of the picture, copyright being at least as important (if the legal advice I got from Francis Davey relating to European law is correct). Note that there is sui generis database right, and separate from that there is database copyright. Database copyright is not owned by the OSMF. -- Ed Avis e...@waniasset.com ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL and publishing source data
Eugene Alvin Villar seav80@... writes: The European definition of a database is a collection of independent works, data or other materials arranged in a systematic or methodical way and individually accessible by electronic or other means. Which really, really should be the end of this. A PNG doesn't fit this description as its intent is to encode a single complete image and the pixels are not independent. Likewise PNG and SVG. Place them in a systematic or methodical collection and you have a database of images. But this is separate from their contents. If I place a travel photo of mine into a PNG and then print it out, I have not gained a database right. Likewise if I autotrace it to SVG before printing it. There is a single work, arbitrarily encoded. No database right. - Rob. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Copyprotection for OSM based material
On 26/11/11 23:43, Nic Roets wrote: Rob, I'm not sure what you mean. So I'm going to give a simple example. Suppose someone has a table with museums and their capabilities. He then combines it with OSM to create a map. If the capabilities is something opaque like type1 and type2, then the resultant map can be useless to us. (Reverse engineering is not reliable). It's possible that an exact definition of type1 and type2 exist, but requiring the person to publish it may be too intrusive. For example it could involve some statistical scoring process like Page Rank (which involves processing every web page on the Internet). If the only way the database can function is with data not included in it, then the database is incomplete and not the source of the produced work. (IMO.) It's also possible that type1 can be completely subjective e.g. the person thinks that the paintings in the museum are beautiful. That's a definition right there. :-) So I really can't see how useful source data can have a water tight, yet practical definition. It can however state that obfuscation or don't wanna aren't sufficient reasons for something not being a derivative database. :-) - Rob. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL and publishing source data
2011/11/29 Rob Myers r...@robmyers.org: A PNG doesn't fit this description as its intent is to encode a single complete image and the pixels are not independent. Likewise PNG and SVG. Place them in a systematic or methodical collection and you have a database of images. But this is separate from their contents. If I place a travel photo of mine into a PNG and then print it out, I have not gained a database right. IMHO there is a difference between a travel photo and a map rendering. This is a jpeg: http://www.tnooz.com/wp-content/uploads/2011/02/ITA-QR-code-1.jpg cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL and publishing source data
On 30 November 2011 01:03, Jonathan Harley j...@spiffymap.net wrote: On 28/11/11 23:59, James Livingston wrote: Depending on the rendering, it may not be the same. The placements of name text can depend on other data so it's not on top of something else, or POIs can be hidden if there are too many in a given area. In the first case (or combining layers in the browser), the rendering of OSM data cannot depend on the location of your hotels, and the rendering of hotel names can't easily depend on what else is on the map. In the second case (combining data before rendering) collisions can be avoided or the resulting map altered. Yes, but it's only the produced work, the rendering, which is altered. You probably don't need to make changes to the OSM data to acheive this. So the OSM data and other data could remain independent. If they do, then the mechanism for combining (and computer/s on which it happens) is indeed irrelevant. While that's true, you are combining the two datasource together prior to rendering. Say I created some local postgres database tabled and loaded OSM data into it, and then loaded data from another source into it too. What I have is now a database derived from both OSM and the other source. If I then rendered that data to create a Produced Work, would my combined database not be a Derived Database? This was discussed on legal-talk a few months ago, and my opinion was that it depended on whether you could produce the same output by merging separately-rendered Produced works. If you can get _identical_ output by merging layers on the browser side, then it's okay to the merging on the server side. However if you can't get identical results by merging the rendered output, then you've obviously combined the databases prior to rendering. Not necessarily. For example, the rendering might depend on what order data is rendered. But the data being rendered would remain independent of each other; it may be only the rendered result which varied. And that's a produced work, not a database. Can you get the same result by rendering the first dataset (creating a Produced Work), rendering the second dataset (creating another produced work, if it's ODbL too) and then combining the output? If so, they're definitely independent. You can render the second dataset first if you like provided you combine them in the right order. If the rendering of the second output depends on the first dataset, the Produced Work created from the second dataset is not independent of of the first dataset. I guess it's possible the rendering algorithm for the second dataset could use the Produced Work from the first rather than the first dataset directly, which may be okay except that it's arguable whether you are reverse engineering part of the first database. Having two instances of say Postgres and having one program that reads both and renders is still creating a derived database, even if it is only in the memory of the rendering program. It might create a derivative database, or it might not; it would depend on the algorithm. If the OSM data remain unmodified, then it could be creating a collective database, which is explicitly not a derivative database. I guess that's the a question: if you write a program that reads data from two sources and uses both to produce it's output, are the temporary in-memory data structures considered derived or collective for the purposes of copyright and database right law? The answer probably depends on how the program is implemented, but given that we won't know the implementation, how can we ever determine whether someone's Produced Work requires them to release their database? If we say we can't determine that, aren't we essentially saying that it's impossible to enforce that part of the ODbL? -- James ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
