o 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&g
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 se
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
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
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 license
> 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
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
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
>
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"
> 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
> 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
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
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
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
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.
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
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
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
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
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
20 matches
Mail list logo
