Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
The additional guidelines are OSM-specific: https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines On Mon, Oct 14, 2019 at 4:58 PM Lars-Daniel Weber wrote: > Sorry, this was a typo. Of course I mean houses in both cases: > > Let's say you're creating a map of Western, taking houses from OSM in > Germany and houses from proprietary data from all other countries, since > OSM is incomplete here. Isn't this a mixture on the same layer? > > Also, when starting from a Planet file, there are no regional cuts. > > Are those guidelines additional rules to the ODbL? I thought, ODbL is a > generic databank license and not OSM specific. > > > *Gesendet:* Montag, 14. Oktober 2019 um 19:57 Uhr > *Von:* "Kathleen Lu via legal-talk" > *An:* "Licensing and other legal discussions." < > legal-talk@openstreetmap.org> > *Cc:* "Kathleen Lu" > *Betreff:* Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible > licensed dataset > The reference to countries come from the Regional Cuts Guideline (and then > the later Collective Database Guideline), in case that was not clear. > I don't see how roads and houses (do you mean building footprints?) would > be "mixture on the same layer" or why the layer matters since they're > different data types... > > On Mon, Oct 14, 2019 at 8:33 AM Lars-Daniel Weber < > lars-daniel.we...@gmx.de> wrote: > >> From: "Kathleen Lu via legal-talk" >> > Lars-Daniel already said that they are kept in separate columns and not >> > de-duplicated. There is no requirement that, in order to function as a >> > Collective Database, data types may not be used together to create a >> > Produced Work. To the contrary, the guidance is that the most axiomatic >> > Produced Work, a global map, may be created from multiple Collective >> > Databases consisting of different data types and/or different countries. >> >> Hmm... but doesn't this violate "Horizontal Layers" Guideline? >> >> Let's say you're creating a map of Western, taking roads from OSM in >> Germany and houses from proprietary data from all other countries, since >> OSM is incomplete here. Isn't this a mixture on the same layer? >> >> I think, there's no difference in this guideline between small and large >> scale. >> >> >> >> >> ___ >> legal-talk mailing list >> legal-talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/legal-talk > > ___ legal-talk mailing list > legal-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/legal-talk > ___ > legal-talk mailing list > legal-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/legal-talk > ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
Sorry, this was a typo. Of course I mean houses in both cases: Let's say you're creating a map of Western, taking houses from OSM in Germany and houses from proprietary data from all other countries, since OSM is incomplete here. Isn't this a mixture on the same layer? Also, when starting from a Planet file, there are no regional cuts. Are those guidelines additional rules to the ODbL? I thought, ODbL is a generic databank license and not OSM specific. Gesendet: Montag, 14. Oktober 2019 um 19:57 Uhr Von: "Kathleen Lu via legal-talk" An: "Licensing and other legal discussions." Cc: "Kathleen Lu" Betreff: Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset The reference to countries come from the Regional Cuts Guideline (and then the later Collective Database Guideline), in case that was not clear. I don't see how roads and houses (do you mean building footprints?) would be "mixture on the same layer" or why the layer matters since they're different data types... On Mon, Oct 14, 2019 at 8:33 AM Lars-Daniel Weber <lars-daniel.we...@gmx.de> wrote: From: "Kathleen Lu via legal-talk" <legal-talk@openstreetmap.org> > Lars-Daniel already said that they are kept in separate columns and not > de-duplicated. There is no requirement that, in order to function as a > Collective Database, data types may not be used together to create a > Produced Work. To the contrary, the guidance is that the most axiomatic > Produced Work, a global map, may be created from multiple Collective > Databases consisting of different data types and/or different countries. Hmm... but doesn't this violate "Horizontal Layers" Guideline? Let's say you're creating a map of Western, taking roads from OSM in Germany and houses from proprietary data from all other countries, since OSM is incomplete here. Isn't this a mixture on the same layer? I think, there's no difference in this guideline between small and large scale. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
The reference to countries come from the Regional Cuts Guideline (and then the later Collective Database Guideline), in case that was not clear. I don't see how roads and houses (do you mean building footprints?) would be "mixture on the same layer" or why the layer matters since they're different data types... On Mon, Oct 14, 2019 at 8:33 AM Lars-Daniel Weber wrote: > From: "Kathleen Lu via legal-talk" > > Lars-Daniel already said that they are kept in separate columns and not > > de-duplicated. There is no requirement that, in order to function as a > > Collective Database, data types may not be used together to create a > > Produced Work. To the contrary, the guidance is that the most axiomatic > > Produced Work, a global map, may be created from multiple Collective > > Databases consisting of different data types and/or different countries. > > Hmm... but doesn't this violate "Horizontal Layers" Guideline? > > Let's say you're creating a map of Western, taking roads from OSM in > Germany and houses from proprietary data from all other countries, since > OSM is incomplete here. Isn't this a mixture on the same layer? > > I think, there's no difference in this guideline between small and large > scale. > > > > > ___ > legal-talk mailing list > legal-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/legal-talk > ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
From: "Kathleen Lu via legal-talk" > Lars-Daniel already said that they are kept in separate columns and not > de-duplicated. There is no requirement that, in order to function as a > Collective Database, data types may not be used together to create a > Produced Work. To the contrary, the guidance is that the most axiomatic > Produced Work, a global map, may be created from multiple Collective > Databases consisting of different data types and/or different countries. Hmm... but doesn't this violate "Horizontal Layers" Guideline? Let's say you're creating a map of Western, taking roads from OSM in Germany and houses from proprietary data from all other countries, since OSM is incomplete here. Isn't this a mixture on the same layer? I think, there's no difference in this guideline between small and large scale. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
I totally have to agree with this. Gesendet: Donnerstag, 10. Oktober 2019 um 23:24 Uhr Von: "Kathleen Lu via legal-talk" An: "Licensing and other legal discussions." Cc: "Kathleen Lu" Betreff: Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset > Extracting than 100 elements (non repeatable) from the databse accounts > for substantial. The licence doesn't say this at all. The ODbL defines substantial as: “Substantial” – Means substantial in terms of quantity or quality or a combination of both. The repeated and systematic Extraction or Re-utilisation of insubstantial parts of the Contents may amount to the Extraction or Re-utilisation of a Substantial part of the Contents. The interpretation that OSMF has put forward is that it is NOT substantial if an extraction has: - Less than 100 Features. - More that 100 Features only if the extraction is non-systematic and clearly based on your own qualitative criteria for example an extract of all the the locations of restaurants you have visited for a personal map to share with friends or use the locations of a selection of historic buildings as an adjunct in a book you are writing, we would regard that as non Substantial. The systematic extraction of all eating places within an area or at all castles within an area would be considered to be systematic. - The features relating to an area of up to 1,000 inhabitants which can be a small densely populated area such as a European village or can be a large sparsely-populated area for example a section of the Australian bush with few Features. This does NOT mean than if your extraction ticks up to 101 features, it's definitively substantial (this wouldn't make any sense under copyright law either). Rather it means that it's out of the scope of what the OSMF has given its view on. Cost is a relevant factor in database protection law, which is one of the rights covered by the licence. First, a database is not protected unless there has been "substantial investment" in its making. Second, while users are prohibited from extracting substantial parts of the database without permission (aka a licence), users are affirmatively allowed by the law to extract insubstantial parts (and the database owner actually cannot prevent it). The precise amount that is considered "substantial" is not defined. Rather "A lawful user of a database which is made available to the public in whatever manner may not perform acts which conflict with normal exploitation of the database or unreasonably prejudice the legitimate interests of the maker of the database." Considerations of cost would be a factor for a court to consider in determining this. As for copyright law, I disagree with Tom's statement that "Copyright law does come into effect much earlier than database protection." Copyright law typically protects 1) the contents of a database *if* they are individually copyrightable, a difficult proposition with geodata, and 2) the arrangement and selection of a database, particularly creative choices. It would appear entirely possible, especially when we're dealing with a database of facts, for an extraction to be substantial but copy nothing copyrightable. Imagine, for example, the *random* extraction of 25% of the contents of a database. All that said, I am still of the opinion that it is not necessary to find the exact line here, because the original use Lars-Daniel proposed was one of a collective database so long as the two sets of ZIP properties were kept in separate columns, which he appeared quite comfortable with. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
> Extracting than 100 elements (non repeatable) from the databse accounts for >substantial. That's not correct. I can extract as many as I want. It's just not allowed that thew newly created database contains a substantial part of the OSM database. When I create 100 databases containing 100 features each, it's different to 1 database containing 10,000 features. The first case isn't substatial, the second one might be. > Costs has nothing to do with the license. That's not correct. The database directive is all about protecting the investment, the database creator has invested into creating the database - no matter, what he has invested in creating the data, since this is covered by copyright of the elements in the database. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
From: "Martin Koppenhoefer" > "substantial investment" is not the same as monetary cost. The human time > that is > needed to collect and arrange the data is also an investment. Creating the items is *not* covered by the database directive. The amount of time needed to collect them actually is. The creation is protected by the the database content's license or the normal copyright. > are kept in separate columns and are not used in combination/both to create a > produced work? Yes and yes. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
Cost is a relevant factor in database protection law, which is one of the >> rights covered by the licence. First, a database is not protected unless >> there has been "substantial investment" in its making. >> > > > > "substantial investment" is not the same as monetary cost. The human time > that is needed to collect and arrange the data is also an investment. > > Of course they are not equivalent, and human time is another type of investment. However, cost still remains a relevant factor of consideration. > >> >> All that said, I am still of the opinion that it is not necessary to find >> the exact line here, because the original use Lars-Daniel proposed was one >> of a collective database so long as the two sets of ZIP properties were >> kept in separate columns, which he appeared quite comfortable with. >> > > > > are kept in separate columns and are not used in combination/both to > create a produced work? > > Lars-Daniel already said that they are kept in separate columns and not de-duplicated. There is no requirement that, in order to function as a Collective Database, data types may not be used together to create a Produced Work. To the contrary, the guidance is that the most axiomatic Produced Work, a global map, may be created from multiple Collective Databases consisting of different data types and/or different countries. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
Am Do., 10. Okt. 2019 um 23:25 Uhr schrieb Kathleen Lu via legal-talk < legal-talk@openstreetmap.org>: > Cost is a relevant factor in database protection law, which is one of the > rights covered by the licence. First, a database is not protected unless > there has been "substantial investment" in its making. > "substantial investment" is not the same as monetary cost. The human time that is needed to collect and arrange the data is also an investment. > > All that said, I am still of the opinion that it is not necessary to find > the exact line here, because the original use Lars-Daniel proposed was one > of a collective database so long as the two sets of ZIP properties were > kept in separate columns, which he appeared quite comfortable with. > are kept in separate columns and are not used in combination/both to create a produced work? Cheers Martin ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
> Extracting than 100 elements (non repeatable) from the databse accounts > > for substantial. > The licence doesn't say this at all. The ODbL defines substantial as: “Substantial” – Means substantial in terms of quantity or quality or a combination of both. The repeated and systematic Extraction or Re-utilisation of insubstantial parts of the Contents may amount to the Extraction or Re-utilisation of a Substantial part of the Contents. The interpretation that OSMF has put forward is that it is NOT substantial if an extraction has: - Less than 100 Features. - More that 100 Features only if the extraction is non-systematic and clearly based on your own qualitative criteria for example an extract of all the the locations of restaurants you have visited for a personal map to share with friends or use the locations of a selection of historic buildings as an adjunct in a book you are writing, we would regard that as non Substantial. The systematic extraction of all eating places within an area or at all castles within an area would be considered to be systematic. - The features relating to an area of up to 1,000 inhabitants which can be a small densely populated area such as a European village or can be a large sparsely-populated area for example a section of the Australian bush with few Features. This does NOT mean than if your extraction ticks up to 101 features, it's definitively substantial (this wouldn't make any sense under copyright law either). Rather it means that it's out of the scope of what the OSMF has given its view on. Cost is a relevant factor in database protection law, which is one of the rights covered by the licence. First, a database is not protected unless there has been "substantial investment" in its making. Second, while users are prohibited from extracting substantial parts of the database without permission (aka a licence), users are affirmatively allowed by the law to extract insubstantial parts (and the database owner actually cannot prevent it). The precise amount that is considered "substantial" is not defined. Rather "A lawful user of a database which is made available to the public in whatever manner may not perform acts which conflict with normal exploitation of the database or unreasonably prejudice the legitimate interests of the maker of the database." Considerations of cost would be a factor for a court to consider in determining this. As for copyright law, I disagree with Tom's statement that "Copyright law does come into effect much earlier than database protection." Copyright law typically protects 1) the contents of a database *if* they are individually copyrightable, a difficult proposition with geodata, and 2) the arrangement and selection of a database, particularly creative choices. It would appear entirely possible, especially when we're dealing with a database of facts, for an extraction to be substantial but copy nothing copyrightable. Imagine, for example, the *random* extraction of 25% of the contents of a database. All that said, I am still of the opinion that it is not necessary to find the exact line here, because the original use Lars-Daniel proposed was one of a collective database so long as the two sets of ZIP properties were kept in separate columns, which he appeared quite comfortable with. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
> Extracting than 100 elements (non repeatable) from the databse accounts > for substantial. While someone might easily disagree, I would, however, agree with that. By taking a little piece from a huge database, one cannot deny a database to be a substantial investment as a whole. That way you can cherry pick your way to huge chunks of said database piece by piece, argueing nobody ever took any piece which constituted a substantial investment. That argument about the vast number of postal codes in comparison escapes me. > Costs has nothing to do with the license. I also agree. Copyright law does come into effect much earlier than database protection. Cheers Tom ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
Extracting than 100 elements (non repeatable) from the databse accounts for substantial. Costs has nothing to do with the license. https://opendatacommons.org/licenses/odbl/1.0/index.html Às 20:20 de 10/10/2019, Lars-Daniel Weber escreveu: First of all, thanks for your answer. I had a long talk with a lawyer about this topic today. He wasn't into geodata, but new about the database directive. From: "Tom Hummel" First, I consider the zip code (as in addr:postcode=/feature/) a primary feature, although it is generally considered an “additional property”, as in ¹. My reason would be that I don’t see any meaningful distinction for the purposes of identifying wether a database can be called collective or not. A feature being called primary or additional doesn’t seem to bear any meaning towards being substantial or non-substantial either. He said this: The database policy does not know about "primary features" or "additional properties". It defines a substantial part in such a way that the extracted part has a large part of the costs (investment) the generation/collection, maintenance, care of the entire database takes. So when collecting all the nodes for a zip code takes 1,000 users and one ear of effort, it might be substantial. However, as we all know, this is not the case. They're just part of the big planet database and vary in quality and effort all over the world. So extracting the zip codes for a small extract of the huge planet file, isn't substantial at all. This is because the maintenance, care and provision of the postal codes costs no more or less than the maintenance, care and provision of the other elements. Also measured by the number of elements, the zip codes only make up a small part (actually, this doesn't matter, since the investment is the important thing). He didn't write it up, but he came to the conclusion that the database directive wouldn't come into play here at all. In comparison to the whole planet, the zip codes for my extract are trivial and not touching the investment, the OSM community or the database holder are affording. Saying this, this non-substantial extract doesn't fall under ODbL, but is simple DbCL. Like results of geocoding, which is also part of the Community Guidelines. What do you think? Sorry, I didn't even think about this before asking the lawyer :-( ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
First of all, thanks for your answer. I had a long talk with a lawyer about this topic today. He wasn't into geodata, but new about the database directive. From: "Tom Hummel" > First, I consider the zip code (as in addr:postcode=/feature/) a primary > feature, although it is generally considered an “additional property”, > as in ¹. My reason would be that I don’t see any meaningful distinction > for the purposes of identifying wether a database can be called > collective or not. A feature being called primary or additional doesn’t > seem to bear any meaning towards being substantial or non-substantial > either. He said this: The database policy does not know about "primary features" or "additional properties". It defines a substantial part in such a way that the extracted part has a large part of the costs (investment) the generation/collection, maintenance, care of the entire database takes. So when collecting all the nodes for a zip code takes 1,000 users and one ear of effort, it might be substantial. However, as we all know, this is not the case. They're just part of the big planet database and vary in quality and effort all over the world. So extracting the zip codes for a small extract of the huge planet file, isn't substantial at all. This is because the maintenance, care and provision of the postal codes costs no more or less than the maintenance, care and provision of the other elements. Also measured by the number of elements, the zip codes only make up a small part (actually, this doesn't matter, since the investment is the important thing). He didn't write it up, but he came to the conclusion that the database directive wouldn't come into play here at all. In comparison to the whole planet, the zip codes for my extract are trivial and not touching the investment, the OSM community or the database holder are affording. Saying this, this non-substantial extract doesn't fall under ODbL, but is simple DbCL. Like results of geocoding, which is also part of the Community Guidelines. What do you think? Sorry, I didn't even think about this before asking the lawyer :-( ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
Hi, please excuse the TOFU. let’s not jump to conclusions that fast. First, I consider the zip code (as in addr:postcode=/feature/) a primary feature, although it is generally considered an “additional property”, as in ¹. My reason would be that I don’t see any meaningful distinction for the purposes of identifying wether a database can be called collective or not. A feature being called primary or additional doesn’t seem to bear any meaning towards being substantial or non-substantial either. A 2nd reason would be that the definition of “Collective Database” in section 1.0 “Definitions”² of the license doesn’t seem to rely on that as well. It merely asks the part to be in unmodified form. Thus the part has to be unmodified in content as well as in form within the new collective database. Obviously your parts somehow reference each other, the POI identifier somehow needs some reference to the corresponding postal code. Therefor #1 of the “when-clause ” does not apply. Although I claim clause #4 applies. Your proprietary database /adds/ a property of a feature (postal codes) and uses all of its data. You don’t seem to mix or complement, but instead keep all records of both collections intact and discrete. Therefor the parts are unmodified as to content as well as form. Complementing both by each other would mean you would change their respective content, by not not copying some zip codes; complementing would also mean changing their arrangement. From what you are telling us, I understand, you don’t plan to do this at all. The last example on the guideline page explicitly states that removing duplicate objects is one crucial step towards a derivative database. The example probably wants to demonstrate how two datasets cease to be complete and separate and thus become indiscernable and therefor something different and new. Referencing the contents of two collections by means of mixing, complementing and rearranging obviously changes the parts with the result that the former parts are not easily discernible afterwards. Because of this, I believe you would benefit from the collective database clause, excluding the proprietary data from being subject to the ODbL share-alike terms. Perhaps you should find scheme that makes it easy for you to adhere to the demands of the ODbL. Of course you also would have to develop some means of attribution to the OSM-derived-works of your database. But that is another process not concerning the database. If your work may be considered commercial I strongly suggest some legal consultation. Mixing databases is obviously no trivial business at all. I sincerely hope I’m not too far out with this one. Cheers Tom > From: "Martin Koppenhoefer" > > As I read the collective db guideline, you cannot have both, the ZIP > > codes from your proprietary database and those from OpenStreetMap, > > in the same database matched to the same objects. It says “add or > > replace” a property (we do agree the ZIP codes are a property and > > not a primary feature?). If you keep both ZIP codes in your db, it > > implies you need both columns, which implies you are somehow mixing > > them at some point (or you could drop the proprietary ZIP codes, as > > you won’t need them) > > Wow, that's way more strict than all proprietary license I know of. > All those details should be make much more prominent to users. I know > users mixing data like this all the time, by attributing the OSM > column for internal and external use. They don't know that they're > doing an illegal thing :-( > > I think, I'll not use OSM data for this dataset, even if it's more > complete than the proprietary one. ¹ https://wiki.openstreetmap.org/wiki/Map_Features#Additional_properties ² https://www.opendatacommons.org/licenses/odbl/1.0/index.html ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
From: "Kathleen Lu via legal-talk" > However, that said, I would be doubtful that, for example, an extraction > of all ZIPs in OSM could be insubstantial. Where the line is has not > been conclusively established. I've extracted 273 ZIP codes, while there are more than 8000 in Germany. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
From: "Martin Koppenhoefer" > As I read the collective db guideline, you cannot have both, the ZIP > codes from your proprietary database and those from OpenStreetMap, in > the same database matched to the same objects. It says “add or replace” > a property (we do agree the ZIP codes are a property and not a primary > feature?). If you keep both ZIP codes in your db, it implies you need > both columns, which implies you are somehow mixing them at some point > (or you could drop the proprietary ZIP codes, as you won’t need them) Wow, that's way more strict than all proprietary license I know of. All those details should be make much more prominent to users. I know users mixing data like this all the time, by attributing the OSM column for internal and external use. They don't know that they're doing an illegal thing :-( I think, I'll not use OSM data for this dataset, even if it's more complete than the proprietary one. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
sent from a phone > On 7. Oct 2019, at 19:48, Kathleen Lu via legal-talk > wrote: > > In my view, if you are keeping the two zip codes in different columns and not > removing duplicates, then essentially what you have is one property that is > "OSM ZIP" and one property that is "proprietary ZIP", and they are two > different properties that are not used to improve each other, so it is a > collective database per > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline As I read the collective db guideline, you cannot have both, the ZIP codes from your proprietary database and those from OpenStreetMap, in the same database matched to the same objects. It says “add or replace” a property (we do agree the ZIP codes are a property and not a primary feature?). If you keep both ZIP codes in your db, it implies you need both columns, which implies you are somehow mixing them at some point (or you could drop the proprietary ZIP codes, as you won’t need them) Cheers Martin ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
On Mon, Oct 7, 2019 at 11:16 AM Lars-Daniel Weber wrote: > From: "Kathleen Lu via legal-talk" > > In my view, if you are keeping the two zip codes in different columns > > and not removing duplicates, then essentially what you have is one > > property that is "OSM ZIP" and one property that is "proprietary ZIP", > > and they are two different properties that are not used to improve each > > other, so it is a collective database per > > > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline > > Okay, thanks for clarification. Then the specific column is under ODbL and > the other columns can be proprietary. > But I need to tell others, not to compare both ZIPs datasets and get "the > best of both worlds", right? > > Exactly > > (However, I am doubtful that the ZIPs would be considered > > nonsubstantial, since that definition is not based on how many columns > > of OSM is used.) > > Ah okay, there's the 100 features directive in OSM, which I didn't know > about. > > The 100 features is *one way* (that is relatively easy to understand) but not the only way for an extraction to be insubstantial. However, that said, I would be doubtful that, for example, an extraction of all ZIPs in OSM could be insubstantial. Where the line is has not been conclusively established. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
From: "Kathleen Lu via legal-talk" > In my view, if you are keeping the two zip codes in different columns > and not removing duplicates, then essentially what you have is one > property that is "OSM ZIP" and one property that is "proprietary ZIP", > and they are two different properties that are not used to improve each > other, so it is a collective database per > https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline Okay, thanks for clarification. Then the specific column is under ODbL and the other columns can be proprietary. But I need to tell others, not to compare both ZIPs datasets and get "the best of both worlds", right? > (However, I am doubtful that the ZIPs would be considered > nonsubstantial, since that definition is not based on how many columns > of OSM is used.) Ah okay, there's the 100 features directive in OSM, which I didn't know about. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
In my view, if you are keeping the two zip codes in different columns and not removing duplicates, then essentially what you have is one property that is "OSM ZIP" and one property that is "proprietary ZIP", and they are two different properties that are not used to improve each other, so it is a collective database per https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline (However, I am doubtful that the ZIPs would be considered nonsubstantial, since that definition is not based on how many columns of OSM is used.) On Sun, Oct 6, 2019 at 6:09 AM Lars-Daniel Weber wrote: > Dear users, > > I'm often intersecting geodata with a license, which is in a > non-ODbL-compatible license, with OSM data to enrich this data. Normally, > I'm doing this for internal (private) use only, but I want to publish such > a dataset now. > > For example, I'm getting postal ZIP codes from OSM and add these to other > POI data. I'm keeping the original ZIP codes from the source and the ZIP > codes from OSM and I'm not completing the ZIP codes by each other - they > don't interact, I'm not removing duplicates and they're in two different > columns. Of course, ZIP codes don't seem to be a substantial part, but the > data is related by each other, since I've intersected (joined) both > datasets. > > Is the joined result a "Collective Database" or a "Produced Work", since > it only contains a non-substantial part (only one string column) from OSM? > > Sincerely yours, > Lars-Daniel > > > > ___ > legal-talk mailing list > legal-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/legal-talk > ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
[OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
Dear users, I'm often intersecting geodata with a license, which is in a non-ODbL-compatible license, with OSM data to enrich this data. Normally, I'm doing this for internal (private) use only, but I want to publish such a dataset now. For example, I'm getting postal ZIP codes from OSM and add these to other POI data. I'm keeping the original ZIP codes from the source and the ZIP codes from OSM and I'm not completing the ZIP codes by each other - they don't interact, I'm not removing duplicates and they're in two different columns. Of course, ZIP codes don't seem to be a substantial part, but the data is related by each other, since I've intersected (joined) both datasets. Is the joined result a "Collective Database" or a "Produced Work", since it only contains a non-substantial part (only one string column) from OSM? Sincerely yours, Lars-Daniel ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
