sent from a phone
> On 21. Dec 2019, at 03:22, Kathleen Lu wrote:
>
> Remember that it's a "substantial part...of the contents of a database" (in
> this case OSM), and one way would be a very very small part of OSM.
If “substantial“ has to be seen in relation to the size of the database it
sent from a phone
> On 21. Dec 2019, at 03:01, Kathleen Lu wrote:
>
> No, the guideline was explicitly about both individual results and
> aggregations. Individual results are insubstantial, so no ODbL obligations
> attach at all (attribution is one of the ODbL obligations).
while an indiv
20 Dec 2019, 17:03 by michal.pale...@freemap.sk:
> my rule of thumb proposal (from a long time age) was
> "1 day work of a semi experienced mapper"
>
> (which would take into account availability of aerial photos or other
> sources to import)
>
As in "output of mapping for entire day"
or "avera
This is an interesting question. I'm not sure what exactly one feature is.
But I would find it very hard to claim that a single way, even a complex
one, was "substantial" by itself. Remember that it's a "substantial
part...of the contents of a database" (in this case OSM), and one way would
be a ve
the guideline is about individual results, not about aggregations, for
> which the share alike provisions persist. From my interpretation this also
> implies that the attribution requirements persist for individual results,
> because otherwise it would not be clear that you cannot aggregate them. D
On Fri, Dec 20, 2019 at 11:34:12AM +0100, Christoph Hormann wrote:
> 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 d
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 thu
sent from a phone
> On 20. Dec 2019, at 08:04, 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.
and if you coun
20 Dec 2019, 01:13 by dieterdre...@gmail.com:
>
>
> sent from a phone
>
>> On 20. Dec 2019, at 00:16, Kathleen Lu via legal-talk
>> wrote:
>>
>> This is not what the Substantial Guideline says. It says that fewer than 100
>> features is "not Substantial". It also gives as an example "More th
sent from a phone
> On 20. Dec 2019, at 00:16, Kathleen Lu via legal-talk
> wrote:
>
> This is not what the Substantial Guideline says. It says that fewer than 100
> features is "not Substantial". It also gives as an example "More that 100
> Features only if the extraction is non-systematic
>
> “substantial” does not mean it has to be a certain percentage of the whole
> db, you can see this from the substantial guideline, which has fixed limits
> that are not growing with the db. “substantial” means it’s more than one or
> two features (OpenStreetMap-Foundation has declared they see a
sent from a phone
> On 17. Dec 2019, at 01:35, Kathleen Lu wrote:
>
>
>>
>> To create an accurate postcode polygon from point features you will need a
>> lot of them, so probably already a handful of them would be considered
>> substantial.
>
> This logic seems backwards. Since it would
sent from a phone
> On 17. Dec 2019, at 01:11, matthias.straetl...@buerotiger.de wrote:
>
> I think, that's a moralistic point of view. I'll neither collect a
> substantial part
> of the whole OSM database, nor you could proof that there was big investment
> made to
> collect the data. Since
it will contain a lot of postcode information from the original
> OpenStreetMap database, in adapted/translated form.
This doesn't seem correct to me. In the final set, each point will only
tell you yes/no whether it was in a particular postcode. That's not very
much info at all.
>
> To create a
> Gesendet: Dienstag, 17. Dezember 2019 um 01:00 Uhr
> Von: "Martin Koppenhoefer"
>
> it will contain a lot of postcode information from the original OpenStreetMap
> database,
> in adapted/translated form. Whether the amount is sufficient to be considered
> substantial
> will have to be evaluate
sent from a phone
> On 17. Dec 2019, at 00:04, Kathleen Lu wrote:
>
> But what that says is not just "create a new database" but one "that contains
> the whole or a substantial part of the original OSM database." His new
> database will contain very little if any of the original OSM database
But what that says is not just "create a new database" but one "that
contains the whole or a substantial part of the original OSM database." His
new database will contain very little if any of the original OSM database.
On Mon, Dec 16, 2019 at 2:48 PM Martin Koppenhoefer
wrote:
>
>
> sent from a
sent from a phone
>> On 16. Dec 2019, at 22:09, Kathleen Lu via legal-talk
>> wrote:
> That's what the guidelines are for!
> We can't cover every possible example because there are too many, but as I
> already said, I think your usecase is covered by the Geocoding Guideline.
> https://wiki.
> It is kind of unfortunate, because OSM as far as I am informed, wouldn't
> be interested in the specific dataset (of real estate prices) anyway.
>
> If it's not the type of data that OSM would be interested in, then why
doesn't it fall under the Collective Database Guideline?
the non-OSM data add
That's what the guidelines are for!
We can't cover every possible example because there are too many, but as I
already said, I think your usecase is covered by the Geocoding Guideline.
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline#The_Guideline
> Why doesn
> Gesendet: Montag, 16. Dezember 2019 um 17:03 Uhr
> Von: "Tom Lee via legal-talk"
>
> This is an admirable impulse, but it is worth emphasizing that those of
> us who participate on OSM listservs are a small and unrepresentative
> fraction of the project's 5.9 million registered users. Lists lik
> I was aware of this and just wanted to get a consensus by the data
creators: the users.
This is an admirable impulse, but it is worth emphasizing that those of us
who participate on OSM listservs are a small and unrepresentative fraction
of the project's 5.9 million registered users. Lists like
Am Mo., 16. Dez. 2019 um 16:03 Uhr schrieb <
matthias.straetl...@buerotiger.de>:
> Now, I neither can use your data, nor add my dataset to yours. A
> lose-lose-situation :-(
>
the problem is that "your dataset" is not yours, otherwise you could add
it, and you could also decide whether to use OS
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
Christoph.
> Gesendet: Montag, 16. Dezember 2019 um 12:03 Uhr
> Von: "Christoph Hormann"
>
> 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
Simon,
> Gesendet: Montag, 16. Dezember 2019 um 13:33 Uhr
> Von: "Simon Poole"
>
> Just to be clear: you asked a question on an unmoderated, publicly
> accessible mailing list on which everybody can voice their opinions
> however unfounded they are or not, and now you are unhappy with that you
>
under ODbL...".
Now, I neither can use your data, nor add my dataset to yours. A lose-lose-situation :-(
Gesendet: Montag, 16. Dezember 2019 um 10:34 Uhr
Von: "Nuno Caldeira"
An: "Licensing and other legal discussions."
Betreff: Re: [OSM-legal-talk] use OSM data to s
Just to be clear: you asked a question on an unmoderated, publicly
accessible mailing list on which everybody can voice their opinions
however unfounded they are or not, and now you are unhappy with that you
got a cacophony of conflicting opinions, which is exactly what you
should have expected.
T
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
enoug
that's unfair, it is free, you don't have to pay for it. it just has a
license, or else map companies would use our data
On Mon, 16 Dec 2019, 02:19 , wrote:
>
> I didn't expected OpenStreetMap to be such non-free and permissive :-(
>
___
legal-talk mai
Am Mo., 16. Dez. 2019 um 03:19 Uhr schrieb <
matthias.straetl...@buerotiger.de>:
> 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.
>
> I didn't expected OpenStreetMap to be such non-free and perm
> Von: "Christoph Hormann"
>
> 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 da
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, y
>
> 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_Guideli
Hi,
On 14.12.19 06:41, Mateusz Konieczny wrote:
> Can you point me to legal definition
> of "substantial part"?
There is none, hence:
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°0
On Thu, 12 Dec 2019 22:41 Kathleen Lu via legal-talk, <
legal-talk@openstreetmap.org> wrote:
> No, ODbL does not apply to any database that does not include OSM data.
> There are two reasons.
>
I would argue that the dataset here does include some OSM data, as it includes
(albeit limited) informa
13 Dec 2019, 19:28 by legal-talk@openstreetmap.org:
> Hi Frederik,
>
> Here's why I disagree. The meaning of "derived" in a colloquial sense and the
> definition of "Derivative Database" are not the same.
> While colloquially, it may be fair to interpret "derived" as "made from" or
> "could n
Nuno -
I do not see how Matthias's usecase qualifies as "AND you have *added to or
enhanced our data*" since the houses and flat and their prices are *not*
added to OSM houses or flats, but if this FAQ answer is misleading, we
should rewrite this FAQ answer to more accurate reflect ODbL.
On Fri, D
Hi Christoph,
I think that there is a premise to your list that I do not quite agree
with. ODbL says:
3.1 Subject to the terms and conditions of this License, the Licensor
grants to You a worldwide, royalty-free, non-exclusive, terminable (but
only under Section 9) license to Use the Database for
There are other writings about ODBL, but this one captures the issues
fairly well:
https://wiki.openstreetmap.org/wiki/ODbL_comments_from_Creative_Commons , a
more in depth treatment can be found in ' Safe to be Open: Study on the
protection of research data and recommendation for access and usage
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 Data
well
https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#The_OpenStreetMap_Geodata_Licence
Secondly, you *"Share Alike"*. If you do not make any changes to
OpenStreetMap data, then you are unlikely to have a "Share Alike"
obligation. But, if you _publicly distribute something tha
sent from a phone
> On 13. Dec 2019, at 19:56, Frederik Ramm wrote:
>
> I'll have to ponder this for a while, it changes some assumptions I had
> made. It would mean that, for example, a database that contains a count
> of all pubs in each municipality,
-> adaptation
> or a database that
Nuno - I think you are operating under the mistaken assumption that a
CC-BY-SA license would mean that uses such as Mattias's would require
sharealike.
Here's CC-BY-SA's definition of a Derivative Work:
*"Derivative Work"* means a work based upon the Work or upon the Work and
other pre-existing wo
these new Liberal interpretation of ODbL are funny. to bad it's not
documented what we wanted when we changed license. seems to be full of lies
https://wiki.osmfoundation.org/wiki/Licence/Historic/We_Are_Changing_The_License
*"This means that “good guys” are stopped from using our data but the “b
sent from a phone
> On 13. Dec 2019, at 19:32, matthias.straetl...@buerotiger.de wrote:
>
> So as soon I'm selecting any data using OSM polygons, it gets transformed OSM
> data?
> They're not even touching on the same layer, since it's a different feature
> type.
if you modify your data bas
Hi,
On 13.12.19 19:28, Kathleen Lu via legal-talk wrote:
> “Derivative Database” – Means a database based upon the Database, and
> includes any translation, adaptation, arrangement, modification, or any
> other alteration of the Database or of a Substantial part of the
> Contents.
Interesting. I
Hi Mateusz,
>> No, ODbL does not apply to any database that does not include OSM data.
> It is true but misleading to mention here as this database contains
> transformed OSM data.
So if I don't merge the postcodes, it's fine?
>> There is no OSM data in the secondary list so it is not a Deriva
Hi Frederik,
Here's why I disagree. The meaning of "derived" in a colloquial sense and
the definition of "Derivative Database" are not the same.
While colloquially, it may be fair to interpret "derived" as "made from" or
"could not have been made without", that is not the legal definition of
"Deri
m 19:25 Uhr
Von: "Lars-Daniel Weber"
An: legal-talk@openstreetmap.org
Betreff: Re: [OSM-legal-talk] use OSM data to select proprietary data
Please stop constructing such cases. This case clearly would have the intention of reproducing the OSM database.
My intention is the trivial use o
"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.
I
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 y
12 Dec 2019, 23:40 by legal-talk@openstreetmap.org:
> No, ODbL does not apply to any database that does not include OSM data.
It is true but misleading to mention here as this database contains transformed
OSM data.
> Can I use OSM data and OpenStreetMap-derived maps to verify my own data
witho
Kathleen,
On 12.12.19 23:40, Kathleen Lu via legal-talk wrote:
> No, ODbL does not apply to any database that does not include OSM data.
Are you sure about this? Let me give an example:
> If I understand your usecase correctly, Matthais, you are essentially
> checking your list against OSM bound
No, ODbL does not apply to any database that does not include OSM data.
There are two reasons.
First, this example is analogous to the FAQ here:
https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#Can_I_use_OSM_data_and_OpenStreetMap-derived_maps_to_verify_my_own_data_without_trigger
does contain derivate however,which means license applies
On Thu, 12 Dec 2019, 19:46 , wrote:
> > we are here to create more open data, not to feed proprietary data than
> is lock under their TOS.
>
> I want to apologize for my misunderstanding: my final product does not
> contain any OpenStreet
ty of websites displaying such prices, especially newspapers. All were based on Mapbox or Carto.
Gesendet: Donnerstag, 12. Dezember 2019 um 20:31 Uhr
Von: "Simon Poole"
An: legal-talk@openstreetmap.org
Betreff: Re: [OSM-legal-talk] use OSM data to select proprietary data
Yes, if a Deri
> we are here to create more open data, not to feed proprietary data than is
> lock under their TOS.
I want to apologize for my misunderstanding: my final product does not contain
any OpenStreetMap data.
___
legal-talk mailing list
legal-talk@openst
Yes, if a Derivative Database was created in the first place, and that
is not clear at all, see:
/“Derivative Database” – Means a database based upon the Database, and//
//includes any translation, adaptation, arrangement, modification, or any//
//other alteration of the Database or of a Substanti
Am Do., 12. Dez. 2019 um 19:53 Uhr schrieb <
matthias.straetl...@buerotiger.de>:
> But I neither want to merge OSM data or add it to my data. I just want to
> use it to
> select points of my dataset.
then it may eventually fall under the geocoding guideline:
https://wiki.osmfoundation.org/wiki/
https://opendatacommons.org/licenses/odbl/1.0/index.html
the license is quite clear and 4.2 applies to the case you mention. any use
of OSM data (over 100 nodes) combined with proprietary data results in more
open data under ODbL.
we are here to create more open data, not to feed proprietary data t
> From a practical point of view, boundaries in OSM rarely originate from
> surveys,
> you might be lucky to be able to identify the original source (most likely
> open data)
> which may have a more liberal license than ODbL (check the history and
> changeset
> source tags / object source tags).
Hi,
> when you write „number of boundaries“, you intend „boundary points“?
No, for example postcodes. I want to merge some of them to new polygons.
Regards,
Matthias
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.
Hi,
> In my NAL opinion, the result will be derived from OSM data and
> therefore inherits the ODbL license. This does, however, not mean that
> you have to publish it; but *if* you publish (or "publilcy use") it,
> then it has to be available under ODbL. If you just use it internally
> then it is
Am Do., 12. Dez. 2019 um 08:01 Uhr schrieb <
matthias.straetl...@buerotiger.de>:
> I want to use polygons (district boundaries) from OSM dataset to select
> points for a proprietary dataset.
>From a practical point of view, boundaries in OSM rarely originate from
surveys, you might be lucky to
sent from a phone
> On 12. Dec 2019, at 08:19, Frederik Ramm wrote:
>
> As an exception to the above, if the number of boundaries you use is
> less than 100 - an crucially this could be after the trivial alterations
> you mention - then the extract you are making is considered not to be
> subs
Hi,
On 12.12.19 07:59, matthias.straetl...@buerotiger.de wrote:
> I want to use polygons (district boundaries) from OSM dataset to select
> points for a proprietary dataset.
> The OSM dataset might be altered trivially (f.e. boundaries might be merged
> where needed).
> The proprietary data isn'
Dear IANALs,
I want to use polygons (district boundaries) from OSM dataset to select points
for a proprietary dataset.
The OSM dataset might be altered trivially (f.e. boundaries might be merged
where needed).
The proprietary data isn't allowed to be used freely and is incompatible with
ODBL.
68 matches
Mail list logo