Re: [OSM-legal-talk] Changeset Comments Copyright
On Wednesday 23 September 2020, Martin Koppenhoefer wrote: > > GITNE's point was not about changeset data, it was about changeset > discussions. I agree there is no doubt that changesets are part of > the geodatabase (at least for me), but for changeset comments it > seems the situation isn't so clear, it could be seen as an edge case > (either way could be defended by arguments), athough I agree that > through linking it to the changeset_id it is within the geodatabase. I see - yes, that is slightly different in nature - though i think all of the arguments i gave in principle still apply (including in particular that the OSMF publishes the changeset discussions under ODbL as well). The main difference i think is that contributions to changeset discussions have a higher likeliness to in themselves be subject to copyright (and not just database protection). -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Changeset Comments Copyright
On Wednesday 23 September 2020, GITNE wrote: > [...] However, I am unsure > whether this your opinion or legal assessment? Because a legal > assessment is actually what I would like to know. You will only ever get opinions here (often colored by interests and what people want to be true) and never a binding legal assessment you can rely on. What you wrote so far has not been very convincing. That changeset data is distributed separately from other parts of our database is not an argument against it being covered by the contributor terms. Frequent discussion in the OSM community that certain information (like source tags) make more sense to be recorded in changeset tags than in individual features (and accordingly that they can still be connected to the features when recorded in that form) OTOH supports the view that changeset tags are covered by the constributor terms and that the mapper community regards them as such. In any case - the OSMF is distributing changeset data under the ODbL: https://planet.openstreetmap.org/replication/changesets/ and there are a lot of third party services that use this data in their services (like various QA tools, for example achavi) so if you have an issue with that in principle picking out Slack specifically is not really appropriate. (that is all under the assumption that Slack is using the data in compliance with the ODbL - which i don't know) -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] use OSM data to select proprietary data
On Friday 20 December 2019, Mateusz Konieczny wrote: > > Obviously, both nodes, ways and > relations should be counted. > > Otherwise one would be able to > temporarily create one relation, > that would include all data (s)he > wish to use and export this. The "100 Features" limit as a rule of thumb for substantiality was not really well thought through. IMO a data volume limit would make more sense - which would probably make sense to position somewhere between 1kB (approximately equivalent to a hundred untagged nodes) and 5kB (addresses, buildings etc.) Talking about compact binary data representation here of course, not raw OSM XML and no lossy compression. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] use OSM data to select proprietary data
On Monday 16 December 2019, matthias.straetl...@buerotiger.de wrote: > > > > The usual view is that share-alike provisions do not make something > > non-free or non-open because they are meant to protect and extend > > the freedom and only constrain users of truly non-free data. But > > anyone can have a different opinion on that of course. > > Sorry to say this, but I don't feel like you want to protect your > data. It feels like you want to grab all the data, your data comes > into contact with. "Viral" is the right term here - do you know the > Borg? :-) There is a long history of discussion about the benefits of viral/share-alike licenses in the open data/free software movement. In OSM we have had this discussion extensively before the license change. I tried to provide a bit of insight about why we have share-alike but people here in general are fairly reluctant to reiterate that discussion because it rarely brings any new insights. Apart from the mentioned importance of share-alike for the social contract between mappers and data users it is also doubtful that OSM would still exist as a single homogeneous project as we know it today if in 2012 we would have chosen a non-share-alike license. It is very likely that OSM would have split off several proprietary forks with which corporate data users would have tried to distinguish themselves from the competition by creating improved versions of the OSM database adding proprietary data without feeding it back into the openly licensed public database. Please keep in mind that the image of a viral license is partly misleading because everyone has the free choice to not use the data and not 'be infected' while a biological virus does not typically give you that freedom. > > Both share-alike and attribution play an important role in OSM in > > the social contract between mappers and data users. In return for > > being able to use the results of the work of the mappers for free, > > data users are required to share improvements of the data or the > > results of producing something of additional value in combination > > with other data under open license terms. > > If attribution would pay a role, than "(c) Non-Free data, selected by > using OSM data ..." would be possible. That might be an idea for > future license drafts. The viewpoint communicated by Kathleen would mean data sets partly derived from OSM through spatial operations without containing substantial amounts of the original data in original form (that is essentially the case we are talking about here in abstract form) would require neither share-alike nor attribution since they are neither a Derivative Database, a Collective Database nor a Produced Work. So while your willingness to attribute is admirable this kind of attribution for mixed and processed data without share-alike is not something that the ODbL considers a separate scenario. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] use OSM data to select proprietary data
On Monday 16 December 2019, matthias.straetl...@buerotiger.de wrote: > > Okay, I'll canceld all plans to use OpenStreetMap for this task. > I've contacted several commercial data providers and hope to get > offers tomorrow. In general (not necessarily specifically in your case - i don't know enough about it to make that assessment) i think this is a good approach if you have troubles with the share-alike provisions of the ODbL. If you want or need to keep a proprietary data set proprietary it is natural that you have limitations in using it together with open data with a viral license. This is definitely a better approach than trying to find loopholes in the license with brute force and wishful thinking. Even if that is possible and you can present an interpretation of the wording of the ODbL that supports your use case without share-alike this was clearly not the intention of the OSM community when adopting the ODbL to do so. You need to be aware of course that the big corporate data users will keep looking for loopholes - real or imagined - to achieve a competitive advantage. Like in the tale of the frog and the scorpion: It is in their nature. So if you respect the spirit of share-alike in the ODbL you will always be potentially at a competitive disadvantages to the corporate data users who simply don't give a damn. The even better approach is of course to adopt the spirit of open data and use OSM data together with other data sources embracing share-alike. Unfortunately so far the OSMF has not provided much guidance on how to correctly do that, i.e. how to share share-alike data sets practically. The LWG unfortunately currently focuses on guidance on how to avoid share-alike and attribution as much as possible. > I didn't expected OpenStreetMap to be such non-free and permissive > :-( The usual view is that share-alike provisions do not make something non-free or non-open because they are meant to protect and extend the freedom and only constrain users of truly non-free data. But anyone can have a different opinion on that of course. Both share-alike and attribution play an important role in OSM in the social contract between mappers and data users. In return for being able to use the results of the work of the mappers for free, data users are required to share improvements of the data or the results of producing something of additional value in combination with other data under open license terms. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] use OSM data to select proprietary data
On Saturday 14 December 2019, matthias.straetl...@buerotiger.de wrote: > > existing OSMF community guidelines suggest spatial operations like > > ST_Difference() and ST_Intersection() yield Derivative Databases > > that are subject to share-alike. > > Let's take the Collective Database Guideline, you've mentioned: > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Coll >ective_Database_Guideline_Guideline > > "Technically a reference between non-OSM and OSM data can be by a > database key or any other method of identifying a specific OSM or > non-OSM element that may be used with a database join." > > So actually, I just need to create a collective database, put the > non-free data in one table and OSM data in another. For table > joining, I'm using ST_Intersects() and I'm fine? No, the quoted guideline says that share-alike does not apply if OSM data and non-OSM data *do not* reference each other and in specific other cases. None of these cases covers references through spatial relationships. The idea that your process of intersecting non-OSM data with OSM based admin polygons results in a collective database is not realistic. To me this kind of operation would be a textbook example of something generating a derivative database - you combine OSM data with non-OSM data to generate something of additional value compared to either of these data sets alone. This is exactly the kind of scenario share-alike is meant for and why it was chosen as license for OSM. But there are of course fairly strong economic interests for this not being subject to share-alike so people think of ways to interpret the ODbL accordingly. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] use OSM data to select proprietary data
On Friday 13 December 2019, Frederik Ramm wrote: > > I had until now assumed that such works would definitely fall under > the ODbL but you are right, they don't really fit the "Derivative > Database" definition. My reading of the ODbL has always been that something is either 1) the original Database (or substantial parts of it) 2) a Derivative Database 3) a Collective Database 4) a Produced Work or if something is neither of these it would be either 5) something that is not protected by law at all so free to use independent of the license terms (like insubstantial extracts of data). 6) something the ODbL does not grant any rights for and therefore cannot be legally used by the user based on the ODbL. So my question would always be if someone considers certain things not to be a Derivative Database which of the five other above cases applies instead. I would kind of assume that for case (5) there are probably already some court rulings available for to what extent EU database protection applies to set operations of different databases since this is nothing specific to spatial databases but also is relevant for many other types of data. As i already wrote in https://lists.openstreetmap.org/pipermail/talk/2019-November/083535.html existing OSMF community guidelines suggest spatial operations like ST_Difference() and ST_Intersection() yield Derivative Databases that are subject to share-alike. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Licensing question
On Tuesday 06 August 2019, Kathleen Lu via legal-talk wrote: > > If a user misuses a produced work, that is the fault of the user > > (and > > perhaps a breach of the license by the user), not the work producer. > I don't this is a slippery slope, but rather a principled decision. > But the guideline is what it is, and I suppose you could lobby the > Board to change it, but I personally would view such a change as > unwise. Well - to stay within the metaphor - if the downhill location is considered desirable a slippery slope might be most welcome. The ability to decide at will if share-alike applies in a certain use case or not and avoiding responsibilities as much as possible are of course generally highly desirable features for an interpretation of the ODbL from the perspective of some creators of derived works. For guarding the social contract between mappers and data users that OSM is built on and depends on however the situation looks very different. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Licensing question
On Friday 02 August 2019, Tom Lee via legal-talk wrote: > [...] If you > replace "pixels" with "triangles", the exact same thing can be said > of the 3D objects being rendered here for use by the Flight Gear > simulator. And if you replace 'pixel' with node the exact same thing can be said about an OSM file. The idea to bind the legal concept of produced works and derivative databases to certain file formats is - though popular - not a very reasonable approach. There is no problem encoding any geometry from the OSM database in a raster image file. > The official guideline on this question can be found here: > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Prod >uced_Work_-_Guideline -- > > [...] If the published > result of your project is intended for the extraction of the original > data, then it is a database and not a Produced Work. [...] The ODbL is very interesting in so far that although the distinction between produced works and derivative databases is central to it, it does not actually explicitly define what a produced work is. It essentially just says that anything derived from ODbL data that is not a derivative/collective database is a produced work. The produced work guideline goes down the slippery slope of trying to define a produced work though the intention of the creator. This was always a highly questionable approach. Not only because intention in general is hard to determine objectively but also because the ODbL does not require the creator of a produced work to put any contraints on how the produced work is used so the intention of the creator does not have any bearing on how users actually use this work. The ODbL defines 'Database' (and thereby derivative/collective database) in the following form: "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" which is clearly based on the nature of the work and its suitability for access "by electronic or other means". Inversely the same applies to the nature of a produced work. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Licensing question
To avoid you drawing the wrong conclusions based on the (rather abstract) explanations made by others - based on a quick look at the documentation on http://wiki.flightgear.org/Osm2city.py https://osm2city.readthedocs.io/en/latest/ that tool seems mainly a geometry data conversion program for OSM data - not unlike tools used routinely for cartographic applications like osm2pgsql etc. The output of this tool is in most cases likely a derivative database or a collective database depending on how much intermingling of OSM data with other data is happening. If for example extruded building geometries based on OSM polygons are textured with texture images from other sources that is quite clearly a collective database. If you generate guessed building geometries based on non-OSM landuse data as explained on: https://osm2city.readthedocs.io/en/latest/how_it_works.html#chapter-howto-generate-would-be-buildings-label (which is an interesting feature by the way) and combine this with OSM based buildings that would be a derivative database. For distinguishing between a produced work and a derivative database a useful approach is to see if the way you use the data is more in a database-like fashion or more in the form of a finished product ready for human consumption. The scene geometry for a 3d rendering is quite clearly more database-like in its use. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] OSM for training ML machines
On Wednesday 10 April 2019, althio wrote: > > You may have skipped parts of my message, so excuse me if I repeat a > few lines. You quoted only two sentences and I slightly wonder if you > genuinely read the whole. I am sorry if i left the impression that i was specifically criticizing your ideas - i was more referring to the general course of the discussion towards a rather mechanical exegesis of the ODbL based on a simplistic view of how algorithms work as a mechanical process converting well defined input data into well defined output data. > [...] > I don't think my original message can be read as "sweepingly declare > any output of algorithms as having no copyright connection". I did not mean to imply that - but since your line of reasoning only covers this case it is to be expected that people assume this is the only relevant case. > [...] > > My final two cents: > Take the Geocoding guideline, replace "Geocoding" by "Machine > Learning" and this is, in my humble opinion, an acceptable first > draft for discussion. But as far as i understand you, you up-front want to declare the "database" behind the Machine Learning, i.e. the adaptive part of the algorithms that gets modified through training, to be a produced work and therefore not subject to share-alike. If not i don't see the practical usefulness in applying the geocoding guideline to this in analogy because while for geocoding the individual result is a frequent practical use case Machine Learning and similar algorithms are mostly used to produce bulk results which are usually substantial in terms of database law. As far as the Horizontal Layers guideline and the concept of produced works in general is concerned - the only consistent view of these concepts is IMO to consider them to be limited exclusively to cases when you are talking about things produced for and used only for direct human consumption. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] OSM for training ML machines
On Wednesday 10 April 2019, althio wrote: > > A typical "learned" model, based on a ML algorithm and a substantial > extract of OSM data: > That seems like a Produced Work to me. > > Hence... > [...] Maybe i have not been clear enough with my comment - approaching this matter based on gut feeling and wishful thinking (seems like...) without considering the practical effects is a very bad idea. You can design 'learning' algorithms to essentially replicate the training data so to just sweepingly declare any output of algorithms as having no copyright connection to training data is a recipe for desaster (if you subscribe to the spirit of the OdbL) or a recipe for success (if your goal is to abolish share-alike and attribution through the back door - which of course many corporate OSM data users would find highly desirable). And as also said concentrating exclusively on the produced work vs. derivative database is not really helpful, in particular since we have established a long time ago that using a produced work to reconstruct semantic information of substantial volume will not set you free of the requirements of the ODbL regarding derivative databases. So even if you have a basis for considering the algorithm trained with OSM data a produced work, that does not mean that the output of this algorithm, which might be data of exactly the same type as in the OSM database, is not a derivative database. If you need an example: Take a translator for geographic names trained using OSM data. This translator in practical use will spit out names or name components identical to those from the OSM database (if it does not it'd be pretty useless). These names - in sufficient volume - evidently form a derivative database IMO - even if they are not the result of a literal copy but result from 'knowledge' encoded in a neural network. When considering this subject, maybe think of it less as a question of copying data, think of it more as a process of mimicry. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] OSM for training ML machines
On Tuesday 09 April 2019, Frederik Ramm wrote: > > is it a community consensus that, when someone uses OSM to train > their machine learning "black box", the internal data structures > built during learning constitute a derivative database? Or are there > people who argue that somehow the "black box" can ingest OSM data at > will and still remain 100% intellectual property of its operator? > > Further, assuming that we have a system that has ingested OSM by deep > learning and we say that this means its internal database is ODbL, > what would this mean for the output later produced by the same > machine? I see two underlying questions in this that are both not really specific to OSM and the ODbL: * does training a neural network or some other kind of self learning/self adjusting algorithm create a derivative work of the training data. * under what circumstances does running/applying an algorithm (which is not commonly understood to produce a derivative work of the algorithm itself) disseminate so much of itself in its output (the extreme case of this being a self replicating program) that its output needs to be considered a derivative work of the algorithm itself. I find both of these to be fascinating and significant questions but as said before i suppose there is already significant literature on this so it might not make that much sense to contemplate how the OSM community would like the anwsers to these questions to be in isolation without looking how this is seen elsewhere. What makes things more complicated in the OSM case is the distinction between produced work and derivative database. That is indeed a question we need to discuss in the OSM community specifically. But it does not really make sense to start this discussion before having some kind of consensus on the more fundamental questions mentioned before. And i'd like to in that context quote myself with something i said here last June: > And yes, we probably need a broader discussion on the topic of > analytic use of OSM data, in particular in the context of 'big data', > and how this relates to the ODbL. It seems to me opinions on this > are too much based on wishful thinking and too little aim to form a > consistent framework that supports desirable and harmless use cases > but does not create loopholes against the spirit of the license. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] License clarification
On Thursday 07 June 2018, althio wrote: > > I would then interpret the requirements as: > Use: Attribution is required. > Horizontal layers / Collective Database: Share Alike is not required. This is what i mentioned in my first reply with "If what you do is just masking the water areas in visualizations of your data the answer to that is clearly no." The Horizontal Map Layers Guideline however only applies if you render maps and combine different data sources in the rendering process. It does not apply if you do analysis combining different data sources and render a map from a new data set created from this analysis or extract quantitative information from it. How Andrew's use case falls into this depends on the specifics of the process. And yes, we probably need a broader discussion on the topic of analytic use of OSM data, in particular in the context of 'big data', and how this relates to the ODbL. It seems to me opinions on this are too much based on wishful thinking and too little aim to form a consistent framework that supports desirable and harmless use cases but does not create loopholes against the spirit of the license. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] License clarification
On Thursday 07 June 2018, Kathleen Lu wrote: > The way I understand the use, the OSM data is used to identify areas > that are to be discarded. Data in those areas are discarded. Thus, > the OSM data is not kept either, and no OSM data in the final > dataset. Thus, there is no derivative database containing OSM data. If that was the case there would be no need for attribution either, right? The idea that you can produce a data set using both OSM and non-OSM data in a meaningful way without there being either a collective or a derivative database seems fundamentally at odds with the basic concept of the ODbL. The only way this could fly from my point of view would be if you could argue the use of OSM data is insubstantial - for which i see no basis in either law or the Substantial Guideline: https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] License clarification
On Wednesday 06 June 2018, Andrew Pon wrote: > [...] > > Given that we are using open street maps to just remove pixels at an > early stage of processing, would we be able to just put a statement > in our written reports saying that open street maps was used in this > masking process, or would we have to make our final displacement > database freely available? Two things are important here IMO: * in any case attribution will be required for any public use of the data in the form required by the ODbL unless you can argue that use of OSM data is insubstantial. * if you would need to make available your data set under an open license depends on if there is a derivative database containing both OSM and non-OSM data somewhere in your process. If what you do is just masking the water areas in visualizations of your data the answer to that is clearly no. But if you mask the data early in a more elaborate process and do further processing afterwards based on a data set that is an inseparable combination of both data sources the situation is not that clear. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data
On Saturday 13 January 2018, Paul Norman wrote: > > Has anyone requested the derivative database their produced work is > based on? It'd give us their interpretation. As said i have contacted the author (primarily regarding attribution - which he promised to improve - and has partly already done). I also mentioned the share-alike issue - but the author thinks this is fine as it is and i am not really in a position to claim it is not. He also said he cannot provide the Google roads data itself since the Google terms do not allow this (obviously). Part of the problem is also they are using Google Earth Engine - which i am not familiar with and which probably makes many of the data processing steps fairly opaque so the authors might not be fully aware of what actually happens in detail 'under the hood'. I suppose if you pressure the authors into providing more intermediate data you might get separate raster maps for the OSM roads and the Google roads. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data
On Saturday 13 January 2018, Kathleen Lu wrote: > Your example doesn't work. Even if you could render > "distance-to-water" > > this way, you wouldn't get a set proprietary data based lakes + OSM > lakes, you would get a visualization of one massive complicated body > of water that included all oceans, rivers, streams, etc. (at the > database level, it would still be a bunch of data values, not a big > polygon, plus the OSM polygons). This doesn't sound minor to me at > all, as that's a lot of data to process (leaving aside that you'd > have to have a distance-to-water API to pull from, which would not be > easy to get). This is stuff i do for a living so believe me if i say - if that's all that is standing between you and combining OSM data with proprietary data sets without share-alike that is a piece of cake. Yes, labels and other non-geometry information would be a problem - but there is plenty of geometry-only data in OSM and geometry only applications (like the example we are discussing) for which this applies. To summarize the results and be clear - also for my own business purposes - could i get clarification for the LWG that "primary feature" in the collective database guideline, in line with Kathleen's interpretation, can be based on a technical distinction, i.e. two features with the same meaning (both roads or both lakes) are considered different primary features depending on if they are described in explicit form (like linestring or polygon) or implicit form (like distance function)? -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data
On Friday 12 January 2018, Kathleen Lu wrote: > Your analysis does not follow. > > The researcher's description says: "These datasets were each > allocated a speed or speeds of travel in terms of time to cross each > pixel of that type. The datasets were then combined to produce a > 'friction surface'; a map where every pixel is allocated a nominal > overall speed of travel based on the types occurring within that > pixel." > > Thus, the "friction map" is calculated from first an assignment of a > "speed to cross" property value to each road, railway, etc. This was > a property value one added by the researchers, not one already in > OSM. Thus, these principles from the collective database apply: > > [...] My argument has nothing to do with the property (which could for the purpose of this simply be a constant value for all roads, i.e. a property containing no information at all). My argument is about the geometry information. The friction map combines road geometries from OSM and Google road geometry information. I see no way it can be argued that this combination of road geometry data which is rendered into the friction map is a collective database. None of the four criteria of the collective database guideline is met (unless of course you postulate that OSM roads are a different type of feature than Google roads). You can also look at it from a different perspective: If the mentioned use is compatible with the ODbL without share alike that would create a completely fool proof way of circumventing share-alike in map rendering. Example: You want to render a map with lakes supplementing the incomplete lake data from OSM with proprietary data from elsewhere. So what you do is: * you take the lake geometries from OSM (equivalent to the OSM roads) * you create a distance-to-water function/API for you proprietary lake dataset (equivalent to the Google distance-to-road API) * you render both the OSM (based on the polygon geometries) and the proprietary data based lakes (based on the distance function) into your map (equivalent to the rendering of the friction map) * you enjoy your map showing lakes from both OSM and proprietary data without share-alike. Yes, depending on how you want to style your lakes doing so based on a distance function can be challenging - but that is just a minor hurdle. Note from a business perspective as a data user i would not really mind if the above scenario was acceptable but as said it would practically mean the end of share-alike for map rendering applications - and that is likely not what the mappers who voted to adopt the ODbL had in mind. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data
On Friday 12 January 2018, Rory McCann wrote: > As near as I can see, the only data they are distributing (publicly) > is the 2 GeoTIFF files in the "map.ox.ac.uk" page. The question is: > Is a GeoTIFF file created like this from OSM data which has been > mixed with other data, a Produced Work, or a Derived Database? No, that is not significant - see 4.4c of the ODbL: Derivative Databases and Produced Works. A Derivative Database is Publicly Used and so must comply with Section 4.4. if a Produced Work created from the Derivative Database is Publicly Used. So the question is only if there is a derivative database involved in the production of the GeoTIFF, not if the GeoTIFF itself is a derivative database. My view would be that the aggregation of data from the OSM database and the Google roads data when creating the raster map constitutes a derivative database even if the two data sets are not physically merged into a common table because this happens on the fly. See: https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline "Technically a reference between non-OSM and OSM data can be by a database key or any other method of identifying a specific OSM or non-OSM element that may be used with a database join." So if for the purpose of creating the raster map you query all OSM roads within each pixel, determine which Google roads are within a pixel size distance of the pixel center (or something like that) and calculate the minimum friction value of those this is technically "a reference between non-OSM and OSM data" IMO. > *But* (possibly stupid question time) I'm reading the ODbL and it > (Sec 4.6) only requires that you make the derived database available > *or* the original scripts, and original contents. By releasing the > GeoTiff file(s) they've fulfilled Sec 4.6(a), no? No, the GeoTIFF is quite clearly a produced work as per the ODbL: "a work (such as an image, audiovisual material, text, or sounds) resulting from using the whole or a Substantial part of the Contents (via a search or other query) from this Database, a Derivative Database, or this Database as part of a Collective Database." And the produced work guideline: https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline "The published result of your project is either a Produced Worked or a Derivative Database within the meaning of the ODbL. If the published result of your project is intended for the extraction of the original data, then it is a database and not a Produced Work." One point you could argue is that you could produce the friction map by separately rasterizing the OSM and Google roads data and then merge what is already a produced work with a minimum operator on the two raster files. Since the raster is already a produced work you could argue that the ODbL does not apply then. But on the other hand you could argue (as you already did in your mail) that once you use a produced work in a database-like fashion it becomes a derivative database again - the same way as if you trace features from a rendered OSM map. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data
On Thursday 11 January 2018, Kathleen Lu wrote: > > I don't have access to the locked Nature article, but the description > from the first link suggests that they are using a derivative > statistic calculated from the Google road network instead of the > network itself: "The game-changing improvement underpinning this work > is the first-ever, global-scale synthesis of two leading roads > datasets – Open Street Map <https://www.openstreetmap.org/> (OSM) > data and distance-to-roads data derived from the Google roads > database > <https://developers.google.com/maps/documentation/roads/intro>..." > "Distance-to-roads data" sounds like a data type that is not in OSM > (they might have been able to calculate it from OSM, but evidently > chose not to), which would be an example of non-sharealike use under > the Collective Database Guideline: > > [...] Then you have probably misunderstood what they are doing. They are using OSM road data and Google road data to generate what they call a "friction surface" which is essentially a raster map indicating how fast you can move at every point of the map - faster on roads, slower elsewhere depending on relief and landcover. This friction map you can download on: https://map.ox.ac.uk/wp-content/uploads/accessibility/friction_surface_2015_v1.0.zip You can see in that map that they are using OSM road data and that they are also using data that is not in OSM. Based on this friction map they are doing the accessability calculations. Of course it is possible that the OSM road data and the Google road data is available in different forms originally - as you write the wording indicates they have proximity information on the Google roads and not the actual geometry. But they merge it to generate the friction map, for that it does not matter in what form the roads data exists, and i don't really see how you can argue this creates a collective database and not a derivative database - because if that is not a derivative database (combining two incomplete data sets to create a more complete data set to use) what is? > (And frankly, I can't see Google cooperating with this project if > there were sharealike implications for their proprietary data, so I > have to assume that their lawyers vetted the use and confirmed they > datasets were used together as a Collective Database.) I have considered that but since Google does not carry any legal responsibility in that this does not seem like a valid argument - on the contrary: If they have doubt about the legality of this kind of data use this is the perfect trial balloon to test how far you can go. And if Oxford University gets screwed over this that is not their problem. If not and this kind of data combination becomes widely accepted this would OTOH open the door for a lot of applications that would depend on circumventing share-alike. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] Interesting use case of combining OSM with proprietary data
Today i stumbled across this: https://map.ox.ac.uk/research-project/accessibility_to_cities/ http://dx.doi.org/doi:10.1038/nature25181 https://explorer.earthengine.google.com/#detail/Oxford%2FMAP%2Faccessibility_to_cities_2015_v1_0 Apart from partly insufficient attribution (which i already contacted the author about) this is an interesting case example of combining OSM with proprietary data sets i would like to hear some opinions about. What is done here is combining road information (and some other data) from OSM and proprietary data sources (Google) into a raster map (made available as 'friction surface' under the first link above) and doing further processing, analysis and map rendering based on that and publishing the result. My interpretation of the ODbL here is that this is a share-alike case that would require the combined data sources to be made available. But you could probably also look at it differently. I would like to hear opinions on this. In particular if you think that is legally possible without share alike how this interpretation looks like. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] question about collective databases
On Monday 27 February 2017, Tobias Wendorff wrote: > > http://opendata.blattspinat.com/ > -> Zuordnung von Landkreisen zu Postleitzahlen > (translation: "assignment of rural district to postal codes") > > The user released the final dataset under ODbL and gave this > attribution: > "ODbL © 2017 OpenStreetMap Contributers & © GeoBasis-DE / BKG 2015 > (Daten verändert)" (last two words mean: "data has been changed"). > > Let's say, he didn't make any analysis to the OSM data to fix missing > data, which would result in "Horizontal Layers" case. Is the result > a simple collective database? I am not sure about the relevance of your question here. The data set you refer to is licensed under ODbL which is permissible for OSM data both in a collective database and a derivative database (or a produced work for that matter). -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Imagery CC-BY-NC 4.0 + OSM Specific allowance
On Saturday 21 January 2017, Blake Girardot HOT/OSM wrote: > > However care should be taken that the mapper is in a solid > > situation when using the data independent of the question if > > his/her work actually makes it into the main OSM database. In the > > past this has often been a problem with specific permissions for > > restricted access data. License terms or terms of use of a service > > should not require mappers to take additional legal risks. > > I do not understand what you saying here. Could you explain this a > bit more please? In the past there have been some pretty hairy license terms used on propriatary images that were offered for use for mapping in OSM by their owners - in particular i was thinking about: http://imagery.openstreetmap.fr/airbus-ds/Web%20Licence%20for%20Non-Commercial%20Use%20with%20OSM.pdf Significant parts of such terms are likely not really enforcable anyway but if they were this would have quite significant implications on the mapper using such images and possibly even on the OSM data user - in this case think for example about offline use of the imagery (would clash with the internet user concept) or use of OSM data in production of terrain models (would clash with the exclusion of those from derivative works). If the image owner wants to license it under CC-BY-NC anyway independent of OSM, a workable approach could be to waive rights on digitized data (as Simon suggested) and waive the NC clause for activities that are related to the process of digitizing data for use in OSM. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Imagery CC-BY-NC 4.0 + OSM Specific allowance
On Saturday 21 January 2017, Blake Girardot HOT/OSM wrote: > > We are working with an imagery provider who is going to release some > of their imagery under cc-by-nc 4.0, and with a specific allowance > for it to be used for digitizing into OSM. Our general aim should be to get image providers to release their imagery as open data. If that fails we can of course also use images with any other license if this license specifically allows the use in OSM. However care should be taken that the mapper is in a solid situation when using the data independent of the question if his/her work actually makes it into the main OSM database. In the past this has often been a problem with specific permissions for restricted access data. License terms or terms of use of a service should not require mappers to take additional legal risks. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Series of maps for Angola
On Friday 20 January 2017, Marcus Love wrote: > I was > thinking, that if I use OSM as a background, that I could edit the > language polygons that we have to follow along OSM admin boundaries > where they coincide. However, if I do that, would it then make those > polygons that I've edited a 'derivative database'? Probably yes, this depends on the extent to which you make use of OSM data in your proprietary data set. See also: http://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline If you'd just adjust your polygons at a handful of places to fix major mismatches that would normally be considered insubstantial. > If that isn't possible to adapt our language polygons to OSM admin > boundaries without it becoming a derivative database, then we would > use another source for the admin boundaries. Is it possible to use an > OSM background and turn off/toggle the admin boundaries for the > basemap? Otherwise, we will have language boundaries which will be > slightly off the OSM admin boundaries, and wouldn't look that great > and might be confusing on the map. If you render an OSM based map without OSM based admin boundaries and add admin boundaries from a different source you have no derivative database, see: http://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Horizontal_Map_Layers_-_Guideline Note however in such a map you would then simply have other mismatches, i.e. between the admin boundaries and OSM based basemap features instead of between the admin boundaries and your special thematic layer. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Using copyrighted data to locate objects in bing (and trace over bing)
On Thursday 25 August 2016, Bjoern Hassler wrote: > > Suppose I have a list of GPS points of airports (one per airport), > derived from publicly available paper (copyrighted) maps. Suppose > there is no issue with sui generis rights in that list, but that > there was no special permission to create that list (and thus the > list is not rights cleared as such, but only used personally). I > would think that: [...] I am not sure if you are engaging in a theoretical thought exercise or if you are trying to solve a practical problem. In the former case you probably will not get much reaction here. In the latter case you would need to be more specific about what data you are considering using, who produced this data and under what terms of use it has been made available to you. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] osm-carto license
On Thursday 25 August 2016, Martin Koppenhoefer wrote: > > In the style sheet the license is indicated as CC0: > https://github.com/gravitystorm/openstreetmap-carto/blob/master/LICEN >SE.txt > > But on the website it says that the "cartography" is licensed ccbysa: > http://www.openstreetmap.org/copyright > > "The cartography in our map tiles, and our documentation, are > licensed under the Creative Commons Attribution-ShareAlike 2.0 > license (CC BY-SA)." Cartography is data combined with the generic styling rules. Since the rendered tiles are therefore subject to the style license (think of icons, patterns etc. for example) as well as the data license the CC-By-SA makes a lot of sense since it implicitly includes the ODbL attribution requirements. Most other licenses for the tiles would require a special clause for that. The style itself however does not require attribution when used with non-OSM data since it is CC0. You can still render tiles using the standard style and OSM data yourself and distribute them under something other than CC-By-SA as long as you comply with the ODbL. But if you use those rendered by the OSMF servers they are CC-By-SA. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] attributive data enrichment using OSM
On Monday 25 July 2016, Stefan Jäger wrote: > > "Viral aspects" like Martin puts it, sound a bit like a disease :-) The connotation of the term 'viral' has changed quite a bit. Viral marketing for example has - at least for those initiating it - a quite positive appeal. > However, If I understand Ilya correctly, the Odbl only applies to > data that is made publicly available. That, in turn, means, any data > put together using also OSM data, that is not publicly accessible, > but only in internal networks, can be produced? The ODbL applies to all OSM data everywhere - however the share-alike requirements of the ODbL only apply if the data is publicly 'conveyed'. Keep in mind though that this includes any produced works (like map renderings or other illustrations created using the data) - if a derivative database is used in producing such illustrations this database is subject to the share-alike requirements. And note if you (as indicated in your initial inquiry) intend to license this derivative database or a produced work to a third party that is already a public process under the ODbL. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?
On Friday 22 July 2016, Ilya Zverev wrote: > > Wait that doesn't seem right. You cannot violate guidelines because > they are examples and explanations, not restrictions or a law. And > then, when the guidelines say a dataset "may be" considered > derivative, it doesn't say it is derivative (or otherwise). You > cannot violate a text that says "may be", except by mathematically > proving it is wrong either way. The guidelines are interpretations of the practical meaning of the license and therefore you can do things with the OSM data that 'violate the guidelines' in the sense that they are something the guidelines say is not covered by the license. If this interpretation is correct or not can be a matter of opinion of course. > If I didn't care about the views of the community, I wouldn't > continue this discussion. I want to either convince you or other > people that it's okay to put proprietary data on top of the OSM data, > or learn the reasons why this leads to a derivative database, > requiring to open the proprietary part. In the latter case we at > maps.me, of course, would need to simplify our data processing. I did not say or imply you don't care about the views of the community, i just said that if you do something that according to your interpretation is covered by the license but contradicts the interpretation in the community guidlines that would communicate a lack of care for the views of the community. > I guess that falls down to the definition of "intermingling". That's > the word I don't understand in technical sense. Is any intermingling > bad, or there is a good kind of intermingling? Neither in my example > not anywhere else do I make a derivative database, as I believe. Does > the process of intermingling lead to derivative database in any case? OK - i try to be clearer: If you use ODbL data in combination with proprietary data - no matter in what form this data comes in - these two data sets form either a collective database or a derivative database in terms of the ODbL. If it can be regarded as a collective database depends on the question if the ODbL part of that combination and the proprietary part are independent databases. As i have already explained your modified ODbL part (the hotels with some of them removed) is only intended and only useful in combination with the other, non-ODbL part and the combination does not work with the non-modified data which clearly disqualifies it from being independent and as a result the combination would be a derivative database. And since you objected to use of these terms - yes, intent and usefulness are significant regarding the question of independence of the databases. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] attributive data enrichment using OSM
On Friday 22 July 2016, Stefan Jäger wrote: > [...] > > I have read the text here: > https://wiki.openstreetmap.org/wiki/Open_Data_License/Horizontal_Laye >rs_-_Guideline in particular the last paragraph "Combining OSM data > with proprietary data?" ... The Horizontal Layers guideline is about producing rendered maps, not about producing data sets. You might find more helpful information in the Collective Database guideline: http://wiki.osmfoundation.org/wiki/License/Community_Guidelines/Collective_Database_Guideline_Guideline -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?
On Friday 22 July 2016, Ilya Zverev wrote: > You are starting to derive the licensing terms from intentions, and > not the actual process or usage. Which basically says, if the > community accepts this way of judging: however you use our data, if > we don't like what you do with it, you would have to stop. And that > is definitely not a FOSS license, and not only maps.me would have to > stop using OSM, because there would be a chance that any data user > might suddenly find out that odbl favours the provider. It's like > "this data must be used only for good and not evil": while fun, > legally dangerous. I have not argued in any such direction, it seems however with the above you are trying here to bring the usual FUD argument that the OSM community has to follow a lenient interpretation of the license - otherwise no one can use OSM data out of fear of violating the license, which is obviously nonsense. So please once more: lets concentrate on this specific use case and the question how this fits into the rules of OSM data use. I tried to follow your view and explained why i think this is ultimately non-consistent and would lead to a situation that is not consistent with various aspects of the license and the community guidelines. I would expect you to argue those points and not the general righteousness of my approach. > It seems to me, you are considering the Collective Database Guideline > to be the law, No but it tells you something about how the OSMF and the OSM community view the license. If you do something that violates the guidelines (which i have not said you do) but trust it is OK by the letter of the license (which i have not said it is) then you have to keep in mind that by doing that you communicate that you don't care about the views and the wishes of the community. Also note from a legal standpoint the community guidelines are not meaningless, especially if we are talking about uses that take place after a guideline has been published and the licensee is aware of the content of the guideline (which probably can be said to apply here). Licenses are contracts and at least here in Germany the basis of all contracts is agreement between the contact partners on something. No agreement - no contract. So if the OSMF as one contract partner in the license contract has clearly communicated publicly and beforehand through the community guidelines that from their side some use is definitely not part of the agreement that is a strong indicator on the nature and the limits of the license contract in any legal disagreement. But note this is a layman's view of course and IANAL. > [...] It defines what is a collective database, but > does not define the contrary: if a data set is not covered by the > guideline, it doesn't automatically become derivative. But neither does it become collective. And if you re-read my last mail - i clearly made the argument based on the license itself that it would be difficult to argue that your modified OSM hotel database with select hotels removed is an independent database because it is specifically intended to be used in combination with another proprietary database and the derivation from the original data (removal of features) only makes sense for use in this combination. And classification as a collective database requires the individual databases to be independent. > Consider a simpler experiment. I remove nodes based on an obscure > algorithm. I then publish the rest of the database and a list of > removed nodes under an open license. Do I have to open the algorithm? You never have to open any algorithms, publishing the methods used is just a possible alternative to publishing the derivative database and it can only be used if this method can be used by anyone to reconstruct the derivative database from the original data (like when you use a random number generator to remove random features). But if you intermingle ODbL and proprietary data into a derivative database publishing only the algorithm used for that is meaningless since to reproduce the results you need the proprietary data as well. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?
On Sunday 10 July 2016, Ilya Zverev wrote: > > Let's consider another use case. An application that shows OSM map, > and on top of it shows 1 mln of user points. A users has an option to > hide the OSM map underneath proprietary points, with a radius of 1 > km. Does in that moment when a user clickes the options, the combined > map become derivative? Because the application removes parts of OSM > map based on proprietary data, which means, by your implications, > that that creates an inseparable references. I would keep it on the level of combining proprietary data and OSM data for the same feature type because this is what you do and this is also what is best documented in the guidelines and related discussion. As i see it you acknowledge that there is such a combination of different data sets but since you have a reverse case in comparison to the examples given in the guidelines they do not apply and you somehow read the license itself to support your use case. I think this is an interesting viewpoint although i see little chance of this becoming a widely accepted interpretation. It depends on the idea that when generating your produced work or publicly using the two data sets in combination you have a Collective Database and no Derivative Database. This is going to be really hard to argue since you just modified one of the databases you combine for the obvious purpose of using it in combination. Removing hotel POIs from OSM only makes sense if you use it in combination with your other data set - the de-duplicated OSM part of your alleged Collective Database is therefore clearly not an independent database. If you think through this scenario somewhat further it would essentially mean share-alike to be ineffective in de-duplication cases. Since de-duplication is generally only possible in cases where both data sets have a roughly comparable quality level (though not necessary the same level of completeness) it will hardly ever matter from a practical viewpoint which data set you remove duplicates from. So if one direction was possible without share-alike the guidelines would essentially be irrelevant because they'd only distinguish between those cases where you have to de-duplicate in one direction and those where you can combine data sets freely without share-alike. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?
On Saturday 09 July 2016, Ilya Zverev wrote: > > Christoph, please read my last post again: we use all of the > booking.com data, not just hotels that are missing. We are not > altering the proprietary data in any way. Just removing some data > from OSM, and that portion of the data is published, obviously under > the ODbL. I read what you wrote and i think i understand pretty well what you do. From my perspective it is as Simon put it: > In summary both guidelines in this use scenario boil down to > prohibiting de-duplication (of any kind). Now you can of course disagree with that assessment but so far you have not brought up any convincing argument for that. Just because your exact use case is not mentioned in the Horizontal Layers guideline does not mean it does not apply in analogy. It does not matter if you use proprietary data to add features missing in OSM data or if you use OSM data to add features missing in proprietary data - the license as i read it is symmetric in that matter. What i was trying to do is point out ways how you could continue doing what you do (i.e. show both data from booking.com and from OSM in a single application). -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?
On Saturday 09 July 2016, Christoph Hormann wrote: > > I think this is a fairly clear case for the Horizontal Layers > guideline To avoid ambiguity: I of course meant a case where the guideline says share-alike applies. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] MAPS.ME combining OSM data and non-OSM data?
On Friday 08 July 2016, Ilya Zverev wrote: > > If the LWG decides we are violating the license (and explains how, > maybe producing another guidelines), we will remove all OSM hotels > from our data. But for now I don't see how it's different from > removing just some of the hotels. I think this is a fairly clear case for the Horizontal Layers guideline and Simon also made a statement in that direction. Of course as always this is a matter of interpretation. I would also suggest to keep in mind that in principle this is exactly the kind of case share-alike was created for - the OSM database is missing some hotels and some other database contains them and the intention is that you need to make available that other data or the merger of the two data sets for inclusion in OSM if you want to use them in combination. If your use of the booking.com data is not about hotels missing from OSM but only about the additional info booking.com provides (link to booking page and other metadata for example) the new collective database guideline gives you another option: you can match this metadata with the OSM POIs and use them together without share-alike. You however must not show any hotels that are not in OSM then or make their coordinates available under compatible license. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Australian Government Data from data.gov.au
On Thursday 30 June 2016, Tobias Wendorff wrote: > > Tons of others? There aren't many datasources, which will be CC-BY or > equal. You can bet that once this was implemented every marginally narcissistic mapper would stop genuine mapping and start releasing his/her work under CC-BY... Like most of the other suggestions to change the license this would mean abolishing the basic social contract behind OSM. > But okay, let's convince the authorities to bury their "BY" somewhere > on our osm.org page :) Last time i checked i was able to vote for the authorities of my choosing... Otherwise - if they don't want their data in OSM - their loss. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Australian Government Data from data.gov.au
On Thursday 30 June 2016, Martin Koppenhoefer wrote: > > it isn't easy to do this properly, you would have to analyse the data > and make judgements. A script could do it, but it would have to be a > very complex analysis and you would have to put a lot of judgement > into the rules of this script. Two different scripts would likely > make different judgements. No matter how you do this - you would make it impossible to show a world map based on OSM data since the screen would be completely filled with attributions and no space left for a map to display. It would also be extremely unfair towards the normal individual mappers because their attribution (which is currently the main one behind 'OpenStreetMap Contributors') would be buried among tons of others. The whole idea to me seems completely impractical. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
On Thursday 09 June 2016, Simon Poole wrote: > > > > But we are happy with uses that invoke share-alike as well, aren't > > we? > > Basically the issue is that the guidelines are essentially "safe > harbour" statements, "we are ok if you do X", to provide a more > secure and stable environment for users of our data. This is a desirable goal but don't forget there is another side to that - if i as an entrepreneur consider contributing to the OSM database it could be important for me that my contributions cannot be used by the competition against my interests. Share-alike might play a significant role in such consideration. So having pro-share-alike safe harbour statements might be equally important. > They do not claim to be the only possible interpretation of the ODbL > and they do not claim that use that is outside of the guidelines is > automatically incompatible with the ODbL. We do however believe that > the guidelines can be reasonably assumed to be covered by the ODbL > and making these statements or clarifications if you so wish is > within our rights as licensor. > > Giving non-trivial (aka concrete business use cases) negative > examples not only has the danger of essentially by fiat declaring > something "illegal" were no case has been made and that we've not > been able to look at in detail To me honest - i think this approach (avoiding clear statements about one side of the line while making such about the other side) is highly problematic. From a business standpoint it is often more important to have a definite legal framework than to have it shaped in a certain way. If you know something you want to do is definitely legal that is very good. If you definitely know something is not allowed that is usually OK as well. But if you think something is probably not legal but are wrong about it and the competition uses this idea to their advantage while you don't this is really bad. Of course the OSMF cannot produce legal certainty in either direction but at any level of certainty making one-sided statements is a two-sided sword. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
On Thursday 09 June 2016, Simon Poole wrote: > I can understand the desire for a negative example, but: > > - this is documentation of use that we are happy with, not of the > opposite. But we are happy with uses that invoke share-alike as well, aren't we? > - as the preamble says there may be other ODbL compliant ways that to > not invoke share-alike to combine datasets outside of those detailed > in the guideline. > > - using a contrived non-trivial negative example has the "it is > definitely going to happen" problem that it will be seen as a ruling > in use cases which are not on our table and of which we don't know > the details. I try to avoid getting again into a discussion on the guideline itself here (i voiced my concerns previously - no need to do this again at this point). In any case it would be the first single sided guideline that does not draw a line between two fields of data use. And as i read the text of the guideline it implies certain limits, for example "non-OSM data completely replaces a particular type of geometry or data" implies the situation is different in some way if it does not completely replace and "uses either all OSM data or no OSM data for that property" implies that a data mixture in properties changes the situation. In other words: having precisely formulated points in parameter space but not having limits defined in relation to these points looks odd. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] FYI Collective Database Guideline
On Thursday 09 June 2016, Simon Poole wrote: > > The LWG has just forwarded the text of > http://wiki.openstreetmap.org/wiki/Collective_Database_Guideline to > the OSMF board for approval and publishing as definite guidance from > the OSMF. IIRC it was already noted by others that the lack of an example where share-alike applies kind of makes the whole thing appear unbalanced and endangers meeting the purpose to clarify 'where the line is drawn'. Independent of the actual content adding a non-trivial counter-example would IMO significantly improve practical usefulness and understanding of the guideline. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] licenses suitable for import
On Sunday 20 March 2016, Tobias Wendorff wrote: > [...] In Germany, manual generalized data by human > cartographers are protected by copyrigh - courts have already proofed > this. This is not really related to the topic here but to prevent possible misconceptions about the German legal system: Data is never protected by copyright in Germany. Graphical representations of data can be copyright protected of course but this depends on the level of individuality present (the term used in the law is 'persönliche geistige Schöpfungen'). To my knowledge there has been no court decision or other serious legal assessment claiming copyright (in contrast to database rights) on pre-graphical geodata representations under German copyright law. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ECJ confirmed 96/9/EG for printed maps
On Sunday 13 March 2016, Tobias Wendorff wrote: > > I don't know, if this thematic has already been discussed on this > list, but European Court of Justice (ECJ) has confirmed the > classification as a database for (printed) topographic maps (see EuZW > 2015, 955). Yet the commentaries can't foresee the consequences, but > publishers are happy to see a stronger proction of their maps and > data. I don't think there has ever been any serious doubt that printed maps can be databases. I also don't see any immediate consequences of this for the ODbL and OSM coming from that. It has long been a widely accepted notion that if you use an ODbL produced work as a database, i.e. you extract semantic information from it and use it in a database-like way, you are subject to the derivative/collective database regulations of the ODbL, meaning you cannot whitewash ODbL data from share-alike by generating a produced work and reverse engineering data from it again. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] share-alike on generalized data?
On Sunday 07 February 2016, Tobias Wendorff wrote: > > Just to make it clear: > Only streets will be derived from OpenStreetMap data, all other data > are from a proprietary LMA dataset. But the generalization tool > creates an interaction between both datasets. So the LMA dataset will > become part of the / a derived database, won't it? Yes. Note this works in both ways, if you use OSM street data to modify proprietary landuse data this landuse data will be subject to share-alike. Likewise if you use the landuse data to modify the OSM street data the modified street data is to be shared. The latter might be permissible by your proprietary license, the former is probably not. > So actually, I'd need to create a changefile (like OSC) between the > original proprietary dataset and the derived dataset, which has > interacted with OpenStreetMap during generalization process. Do I > only need to release this changefile? No, whatever you release must be usable by others to reproduce what you did, at least as far as data is intermixed. If you for example also have proprietary POIs in your map which are not modified with OSM information these do not need to be made available of course. So if you release a changefile that contains changes to proprietary data which itself is not openly available this is useless and irrelevant for share-alike. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Use of data from the EU GMES/Copernicus programme
Since there do not seem to be any more objections or comments on the matter i am going to add this to the contributors page so people can use the data where it seems useful. I have no specific use cases at the moment but over time it will probably be of interest to add some Sentinel-2 imagery to the osmim (http://maps.imagico.de/#osmim). -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] share-alike on generalized data?
On Saturday 06 February 2016, Tobias Wendorff wrote: > > Since this process includes an (automatic processed) interaction > between foreign and OpenStreetMap data, share-alike might step in. The relevant question here is if during this process you generate a derivative database containing both OSM and proprietary data. If you do you'd need to share this database. > Since the process of generalization doesn't make the quality of > OpenStreetMap data any better (f.e. higher position error), the > results won't be useful at all or could even have a bad effect, > if they get imported back into OpenStreetMap. From my perspective this is not relevant - first because usefulness is a subjective assessment and second because the ODbL share-alike provisions are not about usefulness, they are about giving something back in case the ODbL data is useful for you in connection with other data. But in your specific use case i see no real problem. If you move the OSM street data to match your other information you can easily make available the modified street data. If you do it the other way round modifying other data using OSM data things are more tricky. But you can try to avoid that. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Use of data from the EU GMES/Copernicus programme
On Wednesday 27 January 2016, Frederik Ramm wrote: > > It is my understanding that by listing Copernicus data sources on > > the contributors wiki page OSM would satisfy the requirements of > > the EU regulation to inform the public about the data source. > > Perhaps you can explain your reasoning a bit more. I read: > > "The intellectual property of any Derivative Works made by the User > belongs to the User. However he shall mark such Derivative Works > as follows, whenever sharing, publishing, distributing or in any > other way making them available to others: “contains Copernicus data > (year of reception)”." That cited paragraph is from the old terms and conditions that were originally put up with the first Sentinel-1 data in 2014. This document is still accessible but it is not linked any more (you can't even find it through Google seach apparently). The newer, currently linked terms and conditions are strictly based on the EU regulation and no more include any contraints regarding derivative works. My guess is (but this is really a wild guess) that with the original terms some prospective data users approached the EU commission asking for the terms to not be more restrictive than what was mandated by the regulation and this is exactly what happened then. Regulation 1159/2013 gives conditions regarding data use in article 7 and 8 which essentially boils down to a single requirement: "When distributing or communicating GMES dedicated data and GMES service information to the public, users shall inform the public of the source of that data and information." As i see it the question here can only be if the obligation to "inform the public" is fulfilled by listing on the contributors page. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Use of data from the EU GMES/Copernicus programme
Not sure if i should interpret the lack of respone as agreement to my assessment that the data may be used as a source for OSM mapping with a notice on the contributors page. If there are opinions to the contrary please speak up. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] Use of data from the EU GMES/Copernicus programme
Hello, I thought I'd bring this up here since sooner or later use of this data is likely going to be of interest for OSM. Short background: The EU Copernicus programme (http://www.copernicus.eu) is an EU publicly financed earth observation program that produces various types of geodata and makes some of this, primarily satellite imagery (Sentinel satellites) but also secondary data resulting from further processing and other sources, available to the public. Conditions of use are based on an EU regulation[1] which is the basis of the terms and conditions for data use like in case of Sentinel satellite data[2]. It is my understanding that by listing Copernicus data sources on the contributors wiki page OSM would satisfy the requirements of the EU regulation to inform the public about the data source. Note in contrast to the various attribution licenses this regulation specifically does not require you to make sure downstream data users also do the same (this was part of the terms earlier[3] but it seems to have been specifically removed). None the less i wanted to put this up for discussion here before adding this to the contributors page and thereby implying use of this data is OK. [1] http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32013R1159&from=EN [2] https://scihub.copernicus.eu/twiki/pub/SciHubWebPortal/TermsConditions/Sentinel_Data_Terms_and_Conditions.pdf [3] https://scihub.copernicus.eu/twiki/pub/SciHubWebPortal/TermsConditions/TC_Sentinel_Data_31072014.pdf -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Proposed Collective Database Guideline (was Meta-Data Guideline)
On Thursday 05 November 2015, Simon Poole wrote: > > The text can be found here > https://wiki.openstreetmap.org/wiki/Collective_Database_Guideline Looks good. Two observations: - The second example could possibly use clarification that it applies when road classification is solely based on traffic data and not if it is a compound rating based on traffic data and OSM road classes. In principle this is clear but emphasizing the boundary between collective and derivative here might help. - You now point out the possibility to use this guideline in combination with regional cuts by referring to 'a regional cut'. This is good but reminds me that the regional cuts guideline could use some clarification. Right now it allows an arbitrary number of cuts as long as they meet a somewhat fuzzy size criterion. This is essentially not well suited for the declared purpose to avoid cherry-picking. I still think the blanket permission to selectively replace individual attributes with proprietary data is questionable. It might be difficult to exploit this in a way that harms OSM on a larger scale but there is a clear risk here IMO. I admit it is difficult to draw a different line that is generally understandable, universally applicable and objective. I especially see this as a problem in areas where 'big data' techniques are going to allow more consistent, reliable and up-to-date assessment of certain properties for certain applications than manual assessment. OSM of course deliberately focusses on manual data acquisition and this is something that will always be important but in quite a few areas of application i see the difference in practical value between this data alone and after supplementing it with automatically acquired data is rapidly increasing and the OSM community (and of course also the larger open data community) needs to ask itself if it wants to leave this whole field to proprietary data providers. -- Christoph Hormann http://www.imagico.de/ ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
