Re: [OSM-legal-talk] OdbL: Section 4.6, Does data/methods have to be released on public Produced Work?

2020-10-19 Thread Lars-Daniel Weber via legal-talk
Dear Kathleen,

thanks for your response.

> Even assuming the polygons are from a Derivative Database, I don't see a 
> reason for the data to be released under
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Trivial_Transformations_-_Guideline

The process doesn't seem to be trivial, since the edges of many polygons go 
across areas, where no OSM elements could have been used as a reference. So OSM 
dataset has either been changed or augmented using 3rd party reference 
(knowledge, imagery, data etc.) to create the product. Those changes are 
share-alike by ODbL.

The Derivative Database cleary has to be under OdbL. While the creation method 
might be trivial, the amount of data used for the creation is neither trivial 
in terms of investment or nor quantity: They've used millions of OSM nodes 
(ways, areas etc.) in Germany to create it.

> Why would the polygons, which appear to be simply algorithmically combined 
> OSM data, be of interest?

I don't think the ODbL cares what's in interest of OSM (the "O" in ODbL is not 
"OSM"). This is just an additional "wish" by the OSM community. Also, the 
addition polgons, which I have mentioned, might be in interesting of OSM, since 
they might show a change in landuse, which isn't part of OSM now.

Sincerely,
Lars-Daniel


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


[OSM-legal-talk] OdbL: Section 4.6, Does data/methods have to be released on public Produced Work?

2020-10-16 Thread Lars-Daniel Weber via legal-talk
Hi there,

https://www.wohnlagenkarte.de/ displays location quality of residential areas. 
Those residential areas haven been produced using OSM data; the polygon area 
results from at least three surrounding paths and streets.

Since the polygons are derived from OSM data and released in public, I've asked 
the owner to release the database OR the method to create the database 
according to ODbL v1.0, section 4.6 - of course without the values of location 
quality. He denied. He doesn't see a reason to release the data, which the 
Produced Work is based on.

In my opinion, they've created a Derivative Database using their polygons and 
they're publishing a Produced Work (the tiles) in public. So section 4.6 
applies here - doesn't it?

Sincerely,
Lars-Daniel


___
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

2019-12-13 Thread Lars-Daniel Weber
Please stop constructing such cases. This case clearly would have the intention of reproducing the OSM database.

My intention is the trivial use of OpenStreetMap. A normal process in the GIS world.

 




Gesendet: Freitag, 13. Dezember 2019 um 10:44 Uhr
Von: "Mateusz Konieczny" 
An: "Licensing and other legal discussions." 
Betreff: Re: [OSM-legal-talk] use OSM data to select proprietary data


 

 

 

13 Dec 2019, 09:48 by frede...@remote.org:


I end up with a database of "streets that have at least one pub". This

database does not include OSM data.

 

In my eyes, though, it is still *derived* from OSM data. It is the

result of an algorithmic process that has made use of OSM data; if you

will, the OSM data residue is in the name/description of my new

database: "roads with pubs". It is derived from OSM; it could not have

been made without OSM.


Or more extreme.

 

(1) I create database of points on the grid of 0.1 cm.

(2) I create two list, first contains what according to OSM is on land,

second contains what according to OSM data is water

(3) I claim that both lists are not ODBL licenced.

 

Are you going to claim that also this one is legally sound, and not Mapbox-tier

"attribution hidden behind mystery meat "(i)" navigation

fulfills ODBL attribution requirement" swindle?
___ 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

2019-10-14 Thread Lars-Daniel Weber

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

2019-10-14 Thread Lars-Daniel Weber
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


[OSM-legal-talk] conflicting statements in Community Guidelines

2019-10-14 Thread Lars-Daniel Weber
Hi again,

sorry for creating another topic, it's somehow related, but somehow different.

Community Guideline "Horizontal Map Layers" doesn't allow to cherry-pick 
features within the same layer from a proprietary dataset to complete missing 
data in OSM without triggering share-alike.

Community Guideline "Geocoding" allows cherry-picking as quoted here:

> The OSM-based Geocoding Results are an insubstantial extract or
> contain no OSM data and thus do not trigger share-alike obligations
> and can be stored together with the non-OSM-based Geocoding Results
> with no impact on the non-OSM-based Geocoding results, so long as the
> aggregated collection of results does not contain the whole or a
> substantial part of the OSM database. The cloud-based Geocoder is,
> however, required to credit OpenStreetMap as described in Section 4.3
> of the ODbL.

Let's say, you're picking 5,000 restaurants, which is clearly a insubstantial 
part of all restaurants in planet file. For 4,000 items, you'll get coordinates 
from the proprietary dataset, for the other 1,000 items you can pick 
coordinates from OSM. It won't trigger share alike, it's insubstantial and can 
be stored together.

Isn't that a violation of "Horizontal Map Layers", since it's on the same layer?

Confused,
Lars-Daniel



___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] map drawn based on OSM tiles

2019-10-14 Thread Lars-Daniel Weber

According to community guideline for "Geocoding", I'm not using original OSM data in my new map at all. Since I've drawn lines from paper drawn on an Produced Work of OSM data, I don't have any of the original OSM elements in my final dataset, which are in the OSM dataset.

 

So, I just need to credit OpenStreetMap as decribed in Section 4.3 of the ODbL, since it's a Produced Work.

 

 

> Users of a navigation application send an address search query to a
> cloud-based Geocoder. The Geocoder has access to two separate map
> databases, one of which contains solely OSM data. The other database
> contains non-OSM data. If the address is accurately found in the OSM
> database, the location is sent back to the navigation application. If
> the address is not found in the OSM database, then the other database is
> searched, and that result is returned. (The same example applies when
> the third party database is searched before the OSM database or when
> they are searched concurrently.) The OSM-based Geocoding Results are an
> insubstantial extract or contain no OSM data and thus do not trigger
> share-alike obligations and can be stored together with the
> non-OSM-based Geocoding Results with no impact on the non-OSM-based
> Geocoding results, so long as the aggregated collection of results does
> not contain the whole or a substantial part of the OSM database. The
> cloud-based Geocoder is, however, required to credit OpenStreetMap as
> described in Section 4.3 of the ODbL.

 

Gesendet: Montag, 07. Oktober 2019 um 20:05 Uhr
Von: "Kathleen Lu" 
An: "Licensing and other legal discussions." 
Cc: "Lars-Daniel Weber" 
Betreff: Re: [OSM-legal-talk] map drawn based on OSM tiles


> Thus, assuming the shapefiles are essentially the equivalent of

> simplified OSM border shapefiles, the shapefiles are covered by ODbL.

Actually, it's like 40% OSM borders (hard borders, like roads, rivers, topography and administrative stuff) and 60% own borders, which don't appear in OSM. BUt those borders wouldn't make OSM any better, since they're specific for the current task.
 

My view would be the OSM borders are ODbL. Just because it's one shapefile doesn't mean all of the data in the shapefile has to be under one license. If the other borders are not border types that are in OSM that you have traced, ODbL does not implicate them per the Collective Database Guideline.

 

> Now, it sounds like you're not tracing very much, so it's possible that
> you have traced fewer than 100 features in which case your tracing is
> insubstantial
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline

Actually, I've traced more than 100 features, but the "extraction is non-systematic and clearly based on your own qualitative criteria" - okay, not on my one, but on the one who draw the overlay with the pen.
 
It's possible that your extraction is insubstantial, though I can't say definitively. But I don't think that you need a definitive answer on whether it's insubstantial, since if your usecase is as a filter to select POIs, then you can do that whether the borders make up a substantial extract or not, and you are willing to provide attribution anyway, so you do not need to conclusively avoid ODbL.






___
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

2019-10-14 Thread Lars-Daniel Weber

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

2019-10-14 Thread Lars-Daniel Weber
> 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

2019-10-14 Thread Lars-Daniel Weber
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

2019-10-10 Thread Lars-Daniel Weber
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

2019-10-08 Thread Lars-Daniel Weber
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

2019-10-08 Thread Lars-Daniel Weber
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

2019-10-07 Thread Lars-Daniel Weber
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] map drawn based on OSM tiles

2019-10-07 Thread Lars-Daniel Weber via legal-talk
From: "Kathleen Lu via legal-talk" 
> So if what is extracted is solely what was in the database, then the 
> extraction is not
> material that the tile license covered (the tile license cannot actually
> change the license of the data, which is ODbL, as that would be
> impermissible under ODbL). 

Yeah, that's why I assumed, too.

> Thus, assuming the shapefiles are essentially the equivalent of
> simplified OSM border shapefiles, the shapefiles are covered by ODbL.

Actually, it's like 40% OSM borders (hard borders, like roads, rivers, 
topography and administrative stuff) and 60% own borders, which don't appear in 
OSM. BUt those borders wouldn't make OSM any better, since they're specific for 
the current task.

> Now, it sounds like you're not tracing very much, so it's possible that
> you have traced fewer than 100 features in which case your tracing is
> insubstantial
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline

Actually, I've traced more than 100 features, but the "extraction is 
non-systematic and clearly based on your own qualitative criteria" - okay, not 
on my one, but on the one who draw the overlay with the pen.

But what does this result in? Sorry for asking... it's a real life problem, not 
a constructed one.

And please remember the other question I've asked. I haven't found an answer on 
the web or the OSM boards.

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] map drawn based on OSM tiles

2019-10-07 Thread Lars-Daniel Weber
From: "Simon Poole" 
> I'm not ruling out the first interpretation either and potentially both
> licenses would have to apply in full (which isn't possible without
> conflict).

I would like to clarify once again that I really do want to attribute OSM. But 
it's damn difficult for me to find out under which license my work falls.
I know lots of people, loading OSM tiles in QGIS and draw stuff on it. So I'm 
pretty confused that there aren't any guidelines discussed.

> But if the shape files are simply used for display purposes as a
> tendency I would find that they are still being used as a produced work
> as per
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline
> Which from the ODbL pov requires attribution and a pointer back to the
> data source, which you can provide without being in conflict with CC
> BY-SA terms that you would have to adhere to.

No, the shapefile will be used for further geoprocessing: selection of POI, 
which are non-free, but fall into the border I've digitized upon the OSM 
background map.

Would you recommend
1. to use another datasource as background map or
2. draw all borders on an OSM extract once again?

Since neither the drawing, nor my digitalization uses OSM data, I'm really 
asking myself if it's not a trivial act at all?
Wouldn't "Drawn on OSM tiles in CC-BY-SA 2.0, based on OSM data in ODbL" be 
enough as attribution?

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] map drawn based on OSM tiles

2019-10-06 Thread Lars-Daniel Weber
Hi Simon,

From: "Simon Poole" 
> Are you really doing this (applies to your 2nd question too) or are you
> dealing in hypotheticals? As this would seem to be a rather roundabout
> way to get shapefiles from OSM data it just seems to be rather unlikely.

I'm really doing this but I'm *not* getting shapefiles from OSM data, I'm 
getting a shapefile from lines, someone has drawn as an overlay on a printed 
map produced by OSM data.

Here's the whole story: someone has sent me areas drawn by hand on a printed 
OSM map (OSM standard style) with a (tick) black pen. I've scanned the map, 
georeferenced it in QGIS based on OSM data and digitized the marker. I've also 
played with QGIS color settings to only see the black pen and not the map on a 
white background (was easier to draw that way). The accuracy is aweful, but 
fine for the task the borders are needed for. Those lines often areas, where 
OSM doesn't have any borders (f.e. crossing a forest or field diagonally) and 
they never accurately follow a line on the printed map.

> In any case you are creating a derivative of a CC BY-SA 2.0 licensed
> work which requires all derivatives to be licensed on CC BY-SA 2.0 terms
> (that are far more restrictive than the ODbL).

I thought, whenever you re-digitize OSM data from a printed map, it would get 
ODbL again. According to current ruling by European Court of Justice, a printed 
map is just a database (it has been judged for a German topographical map in 
small scale).

So if I had freely drawn the borders based on extract of OSM (with the paper on 
the desk), it would fall under ODbL?

Sincerely yours,
Lars-Daniel


> Gesendet: Montag, 07. Oktober 2019 um 00:45 Uhr
> Von: "Simon Poole" 
> An: legal-talk@openstreetmap.org
> Betreff: Re: [OSM-legal-talk] map drawn based on OSM tiles
>
> Are you really doing this (applies to your 2nd question too) or are you
> dealing in hypotheticals? As this would seem to be a rather roundabout
> way to get shapefiles from OSM data it just seems to be rather unlikely.
>
> In any case you are creating a derivative of a CC BY-SA 2.0 licensed
> work which requires all derivatives to be licensed on CC BY-SA 2.0 terms
> (that are far more restrictive than the ODbL).
>
> Am 06.10.2019 um 15:05 schrieb Lars-Daniel Weber:
> > Dear users,
> >
> > I've drawn a map based on the official OpenStreetMap tiles, which are 
> > licensed under CC-BY-SA 2.0 using QGIS. The result is stored as a 
> > shapefile. The shapefile should be published to students to work with it. 
> > It might be printed and shared otherwise.
> >
> > Most of the time during the drawing, I've oriented myself on elements 
> > existing in OSM (rivers, streets etc.), but sometimes I've divided areas by 
> > own knowledge or by own needs. The resulting shapefile doesn't contain OSM 
> > data (nothing got extracted) and it doesn't have the quality to contribute 
> > back to OSM (I've generalized the geometries by hand).
> >
> > Is this a "produced work"? Can I release the shapefile under my own 
> > license, but attribute each element as "based on OpenStreetMap"? What 
> > license shall I point to? Since it's not directly based on the ODbL data 
> > (it's based on the rendered style), will data extracted from the map from 
> > others fall under ODbL again?
> >
> > 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
>

___
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

2019-10-06 Thread Lars-Daniel Weber
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


[OSM-legal-talk] map drawn based on OSM tiles

2019-10-06 Thread Lars-Daniel Weber
Dear users,

I've drawn a map based on the official OpenStreetMap tiles, which are licensed 
under CC-BY-SA 2.0 using QGIS. The result is stored as a shapefile. The 
shapefile should be published to students to work with it. It might be printed 
and shared otherwise.

Most of the time during the drawing, I've oriented myself on elements existing 
in OSM (rivers, streets etc.), but sometimes I've divided areas by own 
knowledge or by own needs. The resulting shapefile doesn't contain OSM data 
(nothing got extracted) and it doesn't have the quality to contribute back to 
OSM (I've generalized the geometries by hand).

Is this a "produced work"? Can I release the shapefile under my own license, 
but attribute each element as "based on OpenStreetMap"? What license shall I 
point to? Since it's not directly based on the ODbL data (it's based on the 
rendered style), will data extracted from the map from others fall under ODbL 
again?

Sincerely yours,
Lars-Daniel

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] question regarding produced work

2015-11-19 Thread Lars-Daniel Weber
Frederik Ramm wrote on Donnerstag, 19. November 2015 um 13:46 Uhr:
>
> I would have a stronger opinion if it were a case where external data is
> mixed with OSM to create an "added value" product - but if someone just
> mangles the OSM data a bit, I'm tempted to view that as part of the
> rendering.
 
The guidelines say that you need even to release the steps to create
a derived database (or share the diff or share the database itself).

So it's not done by saying: "download the raw data".
That's against the license.
 
> You said that you have made several requests to the site operator to
> hand over the data. Has *any* of them been a polite request where you
> did not express your assumed entitlement to receive it ("Dear XXX could
> I perhaps have a copy of the data"), or have they been like ("Hello XXX
> your data is ODbL hence you must give it to me") from the start?

I've read some discussions about this on IRC. My request was about a
small "how to get the result" as described before. 

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] question regarding produced work

2015-11-18 Thread Lars-Daniel Weber
Three days are gone and still no discussion about this topic.
I think, nobody is really interested in discovering license violations and 
penalize the violators.

Why do we have ODbL at all, if all we do is to discuss about the license itself 
or tell guys to write the correct attributation?

ODbL is more than an attribuation on a website!

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] question regarding produced work

2015-11-16 Thread Lars-Daniel Weber
Dear Simon!

Simon Poole wrote on Montag, 16. November 2015 um 12:40 Uhr:
> Lars, is there any indication that the site uses for the map anything
> else than existing OSM data?

It's heavily post-processed OpenStreetMap data, f.e. buffers, results of 
spatial analysis etc.
There is no external data involved.

> Note that we do not require trivial transformations of OSM data to be
> published as long as the original data is available (for very obvious
> reasons). See
> http://wiki.osmfoundation.org/wiki/License/Community_Guidelines/Trivial_Transformations_-_Guideline

It's not trivial in terms of "normal" spatial algorithms, which can be found in 
GEOS, Postgres etc.

Sincere regards,
Lars-Daniel Weber

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


[OSM-legal-talk] question regarding produced work

2015-11-16 Thread Lars-Daniel Weber
Dear Ladies and Gentlemen!

The website "http://öpnvkarte.de/; is based on OpenStreetMap data, licensed 
under ODbL. It shows produced work (rendered tile images, style licensed under 
CC-BY-SA 2.0) as defined in section 1.0 of ODbL.

Since there is a Publicly Use of a Derivative Database, the author should 
release a machine readable form of data, as described in section 4.6. Upon 
request, the author didn't answer several requests by several people.

What's next correct step to do? Shall I contact the provider of the OSM 
database and inform him about the user? I think, there are some steps described 
in section 9.

Sincere regards,
Lars-Daniel Weber

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


[OSM-legal-talk] When does a produced work has to be share-alike?

2015-03-29 Thread Lars-Daniel Weber
Hi.

ODbL don't want produced works to be share-alike, but wants the underlying 
database to be.
So what's the deal when I'm strictly separating ODbL licensed data from data 
under another license?

In Illustrator, I could load a SVG created by qGIS with OSM data. I could only 
*link* to this SVG only without embedding it. So it's in a complete seperate 
file / XML DB, which can't or doesn't have to be edited. Now I could add other 
layers with my own streets or even with data under a properity license. When 
storing the new file, the OSM-data doesn't get changed anymore.

Sure, I have to release the SVG file or the workflow under share-alike, that's 
fine so far. But when I press export to PDF, will this be an intermidiate 
database, which also has to be share-alike? This simply wouldn't be possible 
pecause of the use of non-free data. In my eyes, the only solution could be to 
find a printers' shop, which directly printers from Illustrator to T-Shirts... 
But why does ODbL do this to users of the data?

I think, ODbL harms the actual use of its data with other datasources. Nearly 
all commercial spatial data under a properity license allows you to mix the 
data when you give the right credits (f.e. rivers: (C) A. Corp, streets: (C) 
B. Corp). ODbL forces you to release your data mashed-up. That's way too strict 
and doesn't have to do anything with being open, but with being free.

I hope, anyone is still active in this mailing-list...

Best regards,
Lars-Daniel

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


[OSM-legal-talk] redraw from CC-BY-SA tiles and ODbL data

2014-12-31 Thread Lars-Daniel Weber
Dear Ladies and Gentlemen!

I've written a small tool in OpenLayers, which shows the official OSM tiles 
from the OSM server.
The imagery/drawing is CC-BY-SA and the data in ODbL - that's fine that far.

But my tool can draw on those images: you can enter POIs, draw ways and other 
things.
You can't select any OSM data (you can't click on a way or something).
You can export coordinates and GPX/KML files from those new objects.

Are these objects to be released in ODbL and have they to be given back to the 
community?
Since the CC-BY-SA tiles might have some generalisation (smoothing, selection), 
this license also has to be encountered.

Best regards,
Lars-Daniel Weber

___
legal-talk mailing list
legal-t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk