Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Tom Lee]

Frederik. I think it's a bit ungenerous to suggest that getting open
address data into OSM constitutes "hijacking" the project. This kind of
data is obviously useful to many people. It's also obviously relevant to
OSM, as the project already contains and even renders it in its base style.
And of course Mapbox has paid mappers who help to maintain and improve the
data we rely upon. I'm not sure why there's a presumption that we're hoping
to "free ride."

OpenStreetMap is the premiere open geodata project, and the logical hub for
new open geodata initiatives. The world will be a better place if it
continues to grow and support more needs and ideas. That's the beauty of an
open project. After all, if you are happy with the dataset as it is,
downloading a snapshot is easily done.

Martin: Italy is a very interesting case for open address data. Apologies
if you already know this, but: open data exists for census tract
geometries; and for address strings joined to the census tract ID. What
remains to be done is assigning the address strings in each tract to
rooftops. This is obviously an enormous task, but it's a great example of
why address data (and geocoding) belongs in OSM: the iD editor, paired with
a microtasking tool and open imagery, would be a great way to put those
points in their correct locations.


On Tue, Oct 13, 2015 at 3:08 PM, Frederik Ramm  wrote:

> Hi,
>
> On 10/13/2015 06:12 PM, Tom Lee wrote:
> > Obviously, not all of those 200M points belong in OSM. But many of them
> > do. OpenAddresses does not have the toolchain or community needed to
> > improve and maintain that data.
>
> ...
>
> > I want to do that work once in OSM, not a hundred times in a hundred
> > different closed geo databases.
>
> Suggest to do it once (not a hundred times) and open (not closed) but
> without hijacking OSM community for it. Build a community that is as
> interested in addresses as you are and have them maintain the database.
>
> My guess is that while the address data set is more valuable to (large,
> commercial) users, it will attract less contribution from (private,
> unpaid) mappers, and will therefore require more constant paid work than
> OSM does.
>
> Anyone trying to get OSM to ingest the existing open address data of
> this world and then even maintain and improve it is hoping for a free
> ride on the back of mappers who'd rather do other stuff and who in many
> areas are already thin enough on the ground. Whoever wants us to add 200
> million addresses, should also add to our community the people needed to
> do the maintenance on them.
>
> Yes there are addresses in OSM at the moment, but these are *mainly*
> created by people where no open data exists, in the same spirit that was
> guiding OSM when it started: "They won't give it to us, so we'll make
> our own." - frankly, if there was a halfway usable repository of open
> addresses that could be merged with OSM for those who want it, and if
> open addresses become available for regions where OSM already has
> addresses, I'd not be opposed to dropping the addresses from OSM in
> those regions.
>
> tl;dr addresses are valuable to have but just because OSM already exists
> doesn't mean it is the natural receptacle.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Proposed "Metadata"-Guideline

[Frederik Ramm]

Martin,

On 10/14/2015 11:18 AM, Martin Koppenhoefer wrote:
> frankly, if there was a halfway usable repository of open
> addresses that could be merged with OSM for those who want it, and if
> open addresses become available for regions where OSM already has
> addresses, I'd not be opposed to dropping the addresses from OSM in
> those regions.
> 
> Really? I've always thought our user's ground truth would be trumping
> data we'd import, i.e. we'd request from importers not to drop features
> that are already there, but to conflate in the opposite way, drop from
> the external data set the stuff that we already have, before importing
> the rest. Did I read you right? Can you explain why you changed your mind?

You read me right and Michal did too.

Yes, I always said that we would want to be able to import Open Data at
the processing stage (i.e. into Nominatim etc.) instead of importing it
into OSM, so Michal is right.

This of course has the drawback that you can't edit the government data
sets, and this is why Tom Lee would prefer to import the government data
sets into OSM to make them accessible for editing.

To which I replied that I would prefer to have this data in a non-OSM
editable repository, rather than in OSM, because I feel that there is a
disparity between the amount of address data and the number of mappers
actually interested; I would prefer if those who want a crowd-sourced
address data set would not burden OSM with that. Tom wrote that there's
not enough manpower in openaddresses to actually edit the data, and I
cautioned him against assuming that the OSM manpower would automatically
be available for editing addresses.

Now if there *was* a crowd-sourced address collection project, then I
would not object to OSM deferring to that for addresses. If, say region
X made their address data openly available, it would be possible to
conflate that with the (supposedly better) stuff we already have in OSM,
add the result to the crowd-sourced address collection project, and drop
it from OSM. If the alternatives are to either add the gov't data to OSM
or move existing OSM address data into a separate project, I'd clearly
prefer the latter, although I recognize that there might be people who
would like to keep "their" address data in OSM. It is something that
would have to be discussed.

It might be possible to piggyback the crowd-sourced address collection
project onto OSM  but I would really think that if crowd-sourced address
collection is not viable as a project in its own right (because of lack
of people willing to give away their spare time to improve it), then it
will not be viable in OSM either - only that the situation would be less
obvious.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Tom Lee]

> He’s clearly not suggesting that.
>
> He’s suggesting that if you want to put geocodes in OSM that you go do
that, and create a community around it, rather than this method of “change
the license or we won’t do anything” which Fred feels is hijacking.

If I misunderstood, I apologize. Frederik's email discussed the burden of
maintaining address data, the relative lack of interest in addresses within
the OSM community, and the implicit obligation to contribute labor to the
data's maintenance; and it didn't mention licensing at all. That's why I
read it the way I did. But perhaps it will be best to let him clarify his
own words.

In that same spirit of clarification: at no point in this thread have I
asked for a change to the license. I've been arguing for a clarification of
how the existing license applies to geocoding use cases -- an issue
parallel but related to the guidance Simon introduced. If I'm not mistaken,
the LWG and larger community have acknowledged this to be an open issue for
some time.


On Wed, Oct 14, 2015 at 10:50 AM, Steve Coast  wrote:

>
> > On Oct 14, 2015, at 8:30 AM, Tom Lee  wrote:
> >
> > Frederik. I think it's a bit ungenerous to suggest that getting open
> address data into OSM constitutes "hijacking" the project.
>
> He’s clearly not suggesting that.
>
> He’s suggesting that if you want to put geocodes in OSM that you go do
> that, and create a community around it, rather than this method of “change
> the license or we won’t do anything” which Fred feels is hijacking.
>
> Steve
> ___
> 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] Proposed "Metadata"-Guideline

[Steve Coast]

> On Oct 14, 2015, at 9:19 AM, Tom Lee  wrote:
> 
> > He’s clearly not suggesting that.
> >
> > He’s suggesting that if you want to put geocodes in OSM that you go do 
> > that, and create a community around it, rather than this method of “change 
> > the license or we won’t do anything” which Fred feels is hijacking.
> 
> If I misunderstood, I apologize. Frederik's email discussed the burden of 
> maintaining address data, the relative lack of interest in addresses within 
> the OSM community, and the implicit obligation to contribute labor to the 
> data's maintenance; and it didn't mention licensing at all. That's why I read 
> it the way I did. But perhaps it will be best to let him clarify his own 
> words.
> 
> In that same spirit of clarification: at no point in this thread have I asked 
> for a change to the license.

Sorry “add a guideline or we won’t do anything”.[1]

It’s the threat he’s probably reacting to. It would just be more efficient all 
around to build the community since whether you get your data in OSM by force 
or by happy local community editors you still need a community at the other end 
to maintain it, right?

Best

Steve

[1] - 
https://lists.openstreetmap.org/pipermail/legal-talk/2015-October/008288.html___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Steve Coast]

Tom looks like I misread Fred a little, apologies.

Steve

> On Oct 14, 2015, at 9:28 AM, Frederik Ramm  wrote:
> 
> Martin,
> 
> On 10/14/2015 11:18 AM, Martin Koppenhoefer wrote:
>>frankly, if there was a halfway usable repository of open
>>addresses that could be merged with OSM for those who want it, and if
>>open addresses become available for regions where OSM already has
>>addresses, I'd not be opposed to dropping the addresses from OSM in
>>those regions.
>> 
>> Really? I've always thought our user's ground truth would be trumping
>> data we'd import, i.e. we'd request from importers not to drop features
>> that are already there, but to conflate in the opposite way, drop from
>> the external data set the stuff that we already have, before importing
>> the rest. Did I read you right? Can you explain why you changed your mind?
> 
> You read me right and Michal did too.
> 
> Yes, I always said that we would want to be able to import Open Data at
> the processing stage (i.e. into Nominatim etc.) instead of importing it
> into OSM, so Michal is right.
> 
> This of course has the drawback that you can't edit the government data
> sets, and this is why Tom Lee would prefer to import the government data
> sets into OSM to make them accessible for editing.
> 
> To which I replied that I would prefer to have this data in a non-OSM
> editable repository, rather than in OSM, because I feel that there is a
> disparity between the amount of address data and the number of mappers
> actually interested; I would prefer if those who want a crowd-sourced
> address data set would not burden OSM with that. Tom wrote that there's
> not enough manpower in openaddresses to actually edit the data, and I
> cautioned him against assuming that the OSM manpower would automatically
> be available for editing addresses.
> 
> Now if there *was* a crowd-sourced address collection project, then I
> would not object to OSM deferring to that for addresses. If, say region
> X made their address data openly available, it would be possible to
> conflate that with the (supposedly better) stuff we already have in OSM,
> add the result to the crowd-sourced address collection project, and drop
> it from OSM. If the alternatives are to either add the gov't data to OSM
> or move existing OSM address data into a separate project, I'd clearly
> prefer the latter, although I recognize that there might be people who
> would like to keep "their" address data in OSM. It is something that
> would have to be discussed.
> 
> It might be possible to piggyback the crowd-sourced address collection
> project onto OSM  but I would really think that if crowd-sourced address
> collection is not viable as a project in its own right (because of lack
> of people willing to give away their spare time to improve it), then it
> will not be viable in OSM either - only that the situation would be less
> obvious.
> 
> Bye
> Frederik
> 
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> 
> ___
> 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] Proposed "Metadata"-Guideline

[Steve Coast]

> On Oct 14, 2015, at 8:30 AM, Tom Lee  wrote:
> 
> Frederik. I think it's a bit ungenerous to suggest that getting open address 
> data into OSM constitutes "hijacking" the project.

He’s clearly not suggesting that.

He’s suggesting that if you want to put geocodes in OSM that you go do that, 
and create a community around it, rather than this method of “change the 
license or we won’t do anything” which Fred feels is hijacking.

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Martin Koppenhoefer]

thank you Michal, I see it now. I have finally discovered that I cannot
contribute much to this list and apologize for having caused disruption
from time to time, I'm unsubscribing, see you on the other lists ;-)

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Martin Koppenhoefer]

2015-10-13 21:08 GMT+02:00 Frederik Ramm :

> rankly, if there was a halfway usable repository of open
> addresses that could be merged with OSM for those who want it, and if
> open addresses become available for regions where OSM already has
> addresses, I'd not be opposed to dropping the addresses from OSM in
> those regions.
>


Really? I've always thought our user's ground truth would be trumping data
we'd import, i.e. we'd request from importers not to drop features that are
already there, but to conflate in the opposite way, drop from the external
data set the stuff that we already have, before importing the rest. Did I
read you right? Can you explain why you changed your mind?

FWIW, if this usable open address dataset became available in Italy I'd
still insist on keeping the already present data and merge just the rest of
the public open data.

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Michal Palenik]

On Wed, Oct 14, 2015 at 11:18:43AM +0200, Martin Koppenhoefer wrote:
> 2015-10-13 21:08 GMT+02:00 Frederik Ramm :
> 
> > rankly, if there was a halfway usable repository of open
> > addresses that could be merged with OSM for those who want it, and if
> > open addresses become available for regions where OSM already has
> > addresses, I'd not be opposed to dropping the addresses from OSM in
> > those regions.
> 
> Really? I've always thought our user's ground truth would be trumping data
> we'd import, i.e. we'd request from importers not to drop features that are
> already there, but to conflate in the opposite way, drop from the external
> data set the stuff that we already have, before importing the rest. Did I
> read you right? Can you explain why you changed your mind?

imho, the initial idea by frederik was that you (as data consumer), when
using data for nominatim/mapnik/... should be able to drop all addr:*
elements from OSM and use addr from that external data
(just as postcodes for US in nominatim are from external data and not
OSM)

importing into osm is way different area.

michal



-- 
michal palenik
www.freemap.sk
www.oma.sk


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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Tom Lee]

> I think I agree with everything but this - I still don’t think it’s good
enough. Of course, I also want it to be better - but that cogent argument
thing you mentioned is missing either way.

I and many others have been investing considerable energy into the
OpenAddresses project because of ambiguity surround ODbL's implications for
geocoding. OA is now over 200M address points collected from government
sources under open licenses; OSM currently has 56M features with
`addr:housenumber`.

Obviously, not all of those 200M points belong in OSM. But many of them do.
OpenAddresses does not have the toolchain or community needed to improve
and maintain that data. Ultimately, those datasets should enter a
collaborative space where they are accessible to and improvable by all. In
the not-too-distant future, I suspect I will need to adjust a point when
the local pizza place has their drone drop my order on the roof
.
I want to do that work once in OSM, not a hundred times in a hundred
different closed geo databases.

OSM is already good enough to make geocoding services *better* for many
geography types and locations. The plausible mechanism by which it becomes
*self-sufficient* and then *great* at geocoding is through network effects
and concrete needs, not through individual pizza purchasers complying with
the Terms of Service printed on the box containing their dinner.

To me, this means making sure OSM-enabled geocoding services can be
constructed alongside proprietary data; and that their results can be used
by enough people to make the project's improvement matter to them.





On Mon, Oct 12, 2015 at 7:15 PM, Simon Poole  wrote:

>
>
> Am 12.10.2015 um 23:43 schrieb Mr. Stace D Maples:
>
> ..
> Neither of the projects was scrapped because we *couldn’t* use OSM for
> the project, but because we couldn’t determine IF WE COULD use OSM for our
> particular uses.
>
> ...
>
>
> And you or your legal department approached the licensor of the data and
> asked for an opinion on your use of the data?
>
>
>
>
> ___
> 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] Proposed "Metadata"-Guideline

[Steve Coast]

Tom

Isn’t the problem one of imports? The debate on importing 200M points would be 
entertaining.

Steve

> On Oct 13, 2015, at 10:12 AM, Tom Lee  wrote:
> 
> > I think I agree with everything but this - I still don’t think it’s good 
> > enough. Of course, I also want it to be better - but that cogent argument 
> > thing you mentioned is missing either way.
> 
> I and many others have been investing considerable energy into the 
> OpenAddresses project because of ambiguity surround ODbL's implications for 
> geocoding. OA is now over 200M address points collected from government 
> sources under open licenses; OSM currently has 56M features with 
> `addr:housenumber`.
> 
> Obviously, not all of those 200M points belong in OSM. But many of them do. 
> OpenAddresses does not have the toolchain or community needed to improve and 
> maintain that data. Ultimately, those datasets should enter a collaborative 
> space where they are accessible to and improvable by all. In the 
> not-too-distant future, I suspect I will need to adjust a point when the 
> local pizza place has their drone drop my order on the roof 
> .
>  I want to do that work once in OSM, not a hundred times in a hundred 
> different closed geo databases.
> 
> OSM is already good enough to make geocoding services better for many 
> geography types and locations. The plausible mechanism by which it becomes 
> self-sufficient and then great at geocoding is through network effects and 
> concrete needs, not through individual pizza purchasers complying with the 
> Terms of Service printed on the box containing their dinner. 
> 
> To me, this means making sure OSM-enabled geocoding services can be 
> constructed alongside proprietary data; and that their results can be used by 
> enough people to make the project's improvement matter to them.
> 
> 
> 
> 
> 
> On Mon, Oct 12, 2015 at 7:15 PM, Simon Poole  > wrote:
> 
> 
> Am 12.10.2015 um 23:43 schrieb Mr. Stace D Maples:
>> ..
>> Neither of the projects was scrapped because we couldn’t use OSM for the 
>> project, but because we couldn’t determine IF WE COULD use OSM for our 
>> particular uses.
>> 
>> ...
> 
> And you or your legal department approached the licensor of the data and 
> asked for an opinion on your use of the data?
> 
> 
> 
> 
> ___
> 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] Proposed "Metadata"-Guideline

[Frederik Ramm]

Hi,

On 10/13/2015 06:12 PM, Tom Lee wrote:
> Obviously, not all of those 200M points belong in OSM. But many of them
> do. OpenAddresses does not have the toolchain or community needed to
> improve and maintain that data. 

...

> I want to do that work once in OSM, not a hundred times in a hundred
> different closed geo databases.

Suggest to do it once (not a hundred times) and open (not closed) but
without hijacking OSM community for it. Build a community that is as
interested in addresses as you are and have them maintain the database.

My guess is that while the address data set is more valuable to (large,
commercial) users, it will attract less contribution from (private,
unpaid) mappers, and will therefore require more constant paid work than
OSM does.

Anyone trying to get OSM to ingest the existing open address data of
this world and then even maintain and improve it is hoping for a free
ride on the back of mappers who'd rather do other stuff and who in many
areas are already thin enough on the ground. Whoever wants us to add 200
million addresses, should also add to our community the people needed to
do the maintenance on them.

Yes there are addresses in OSM at the moment, but these are *mainly*
created by people where no open data exists, in the same spirit that was
guiding OSM when it started: "They won't give it to us, so we'll make
our own." - frankly, if there was a halfway usable repository of open
addresses that could be merged with OSM for those who want it, and if
open addresses become available for regions where OSM already has
addresses, I'd not be opposed to dropping the addresses from OSM in
those regions.

tl;dr addresses are valuable to have but just because OSM already exists
doesn't mean it is the natural receptacle.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Tom Lee]

Certainly that's a related issue, but it's one with solutions.
OpenAddresses is not monolithic; its 1400+ individual datasources would
need to be evaluated individually and in concert with local mappers. In
some cases it might be appropriate to perform automated imports; in others
it might make sense to use a microtasking interface and/or to combine the
workflow with building-tracing tasks. In some cases the source data
includes footprints as well. And in others the data probably shouldn't be
imported at all.

It's not a trivial amount of work, but it's a project I and a number of
other people would be glad to dive into, if OSM was a better home for
geocoding.

On Tue, Oct 13, 2015 at 1:43 PM, Steve Coast  wrote:

> Tom
>
> Isn’t the problem one of imports? The debate on importing 200M points
> would be entertaining.
>
> Steve
>
> On Oct 13, 2015, at 10:12 AM, Tom Lee  wrote:
>
> > I think I agree with everything but this - I still don’t think it’s good
> enough. Of course, I also want it to be better - but that cogent argument
> thing you mentioned is missing either way.
>
> I and many others have been investing considerable energy into the
> OpenAddresses project because of ambiguity surround ODbL's implications for
> geocoding. OA is now over 200M address points collected from government
> sources under open licenses; OSM currently has 56M features with
> `addr:housenumber`.
>
> Obviously, not all of those 200M points belong in OSM. But many of them
> do. OpenAddresses does not have the toolchain or community needed to
> improve and maintain that data. Ultimately, those datasets should enter a
> collaborative space where they are accessible to and improvable by all. In
> the not-too-distant future, I suspect I will need to adjust a point when
> the local pizza place has their drone drop my order on the roof
> .
> I want to do that work once in OSM, not a hundred times in a hundred
> different closed geo databases.
>
> OSM is already good enough to make geocoding services *better* for many
> geography types and locations. The plausible mechanism by which it becomes
> *self-sufficient* and then *great* at geocoding is through network
> effects and concrete needs, not through individual pizza purchasers
> complying with the Terms of Service printed on the box containing their
> dinner.
>
> To me, this means making sure OSM-enabled geocoding services can be
> constructed alongside proprietary data; and that their results can be used
> by enough people to make the project's improvement matter to them.
>
>
>
>
>
> On Mon, Oct 12, 2015 at 7:15 PM, Simon Poole  wrote:
>
>>
>>
>> Am 12.10.2015 um 23:43 schrieb Mr. Stace D Maples:
>>
>> ..
>> Neither of the projects was scrapped because we *couldn’t* use OSM for
>> the project, but because we couldn’t determine IF WE COULD use OSM for our
>> particular uses.
>>
>> ...
>>
>>
>> And you or your legal department approached the licensor of the data and
>> asked for an opinion on your use of the data?
>>
>>
>>
>>
>> ___
>> 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] Proposed "Metadata"-Guideline

[Mr. Stace D Maples]

Thanks, Alex.

Clarity is exactly what is needed. Ambiguity = IRB Death. I'm going to be going 
through the OSM Licensing/Copyright Guidelines more closely over the next week 
and will comment outside this thread, if I have comments.

For the record, I hardly think solving things like diarrhoeal disease (2nd 
leading cause of death in children, globally) and tracking human rights abuses 
in repressive regimes are a 1% problems.

In F,L,
Stace Maples
Geospatial Manager
Stanford Geospatial Center
@mapninja
staceymaples@G+
Skype: stacey.maples
214.641.0920
Find GeoData: https://earthworks.stanford.edu<https://earthworks.stanford.edu/>
Get GeoHelp: https://gis.stanford.edu/

"I have a map of the United States... actual size.
It says, "Scale: 1 mile = 1 mile."
I spent last summer folding it."
-Steven Wright-

From: Alex Barth <a...@mapbox.com<mailto:a...@mapbox.com>>
Reply-To: "Licensing and other legal discussions." 
<legal-talk@openstreetmap.org<mailto:legal-talk@openstreetmap.org>>
Date: Monday, October 12, 2015 at 12:32 PM
To: "Licensing and other legal discussions." 
<legal-talk@openstreetmap.org<mailto:legal-talk@openstreetmap.org>>
Subject: Re: [OSM-legal-talk] Proposed "Metadata"-Guideline


On Fri, Oct 9, 2015 at 5:41 PM, Steve Coast 
<st...@asklater.com<mailto:st...@asklater.com>> wrote:

On Oct 9, 2015, at 3:22 PM, Alex Barth 
<a...@mapbox.com<mailto:a...@mapbox.com>> wrote:
On Fri, Oct 9, 2015 at 12:07 PM, Steve Coast 
<st...@asklater.com<mailto:st...@asklater.com>> wrote:
If you want all these rights, you can just pick up the phone and pay HERE or 
TomTom for them, they'd love to hear from you.

What's more interesting than sending people to HERE and TomTom is making them 
contributors to OpenStreetMap, no?

Absolutely, but at what cost?

OSM solved 95% or 99% of our problems. Should we fundamentally change OSM to 
claim the last 1% so someone can make slightly more money or complete an 
academic project? I don't think that's a worthwhile tradeoff. I'm super happy 
with the 99% we achieved already.

I'm very happy about what we have achieved too. I don't think we're solving 95% 
of our problems with OSM though.

"our problems" would of course need more definition and I'm running the risk 
here of misinterpreting what you said. I'm thinking about all the cases where 
OSM isn't used yet, all the mapping that isn't happing in OSM yet. OSM has the 
potential to fundamentally change how we capture and share knowledge about the 
world but we aren't anywhere near the full impact we should be having. 300,000 
active mappers is impressive but the world is much bigger. At a time where the 
internet that was supposed to be Open is turning more and more into a closed 
game of big players and growth for OSM is linear - what's our plan? Fixing the 
license surely can't be the extent of our plan, but we need to be able to have 
a frank conversation about how licensing is hurting use cases and engagement on 
OSM, without second guessing people's intentions and without just showing them 
the door to TomTom and HERE. In that context I find comparing ODbL to Public 
Domain absolutely useful.

I think Stace's comments give a great glimpse into licensing pain points in the 
academic community in the US and the guideline Simon pulled together is going 
to fix some of the issues he's brought up. Having clarity how data linked to 
OSM does not extend the ODbL's share alike to that data should go a long way to 
address some of the concerns he raised.

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Steve Coast]

Stace

Regarding your first email on this topic you said - 

"to built a geocoding platform on Open Source software and Public Domain data 
that could be used to geocode research data”

Could you give an example of what the geocodable string would look like (just 
make one up)? Is it like  “1 Alpha Street, Fooville” or is it more like 
“Smallville, AK” ?

If it’s address data - are you aware that OSM doesn’t actually contain much at 
all and thus can’t help you?

If it’s not address data - are you aware that there are multiple PD sources for 
non-address level geocoding?

Because either way I’m having trouble understanding why OSM is in the way to 
achieving what you’re trying to do?

Best

Steve

> On Oct 12, 2015, at 2:08 PM, Mr. Stace D Maples <stacemap...@stanford.edu> 
> wrote:
> 
> Thanks, Alex. 
> 
> Clarity is exactly what is needed. Ambiguity = IRB Death. I’m going to be 
> going through the OSM Licensing/Copyright Guidelines more closely over the 
> next week and will comment outside this thread, if I have comments. 
> 
> For the record, I hardly think solving things like diarrhoeal disease (2nd 
> leading cause of death in children, globally) and tracking human rights 
> abuses in repressive regimes are a 1% problems. 
> 
> In F,L,
> Stace Maples 
> Geospatial Manager 
> Stanford Geospatial Center
> @mapninja 
> staceymaples@G+
> Skype: stacey.maples
> 214.641.0920
> Find GeoData: https://earthworks.stanford.edu 
> <https://earthworks.stanford.edu/> 
> Get GeoHelp: https://gis.stanford.edu/ <https://gis.stanford.edu/>
> 
> "I have a map of the United States... actual size. 
> It says, "Scale: 1 mile = 1 mile." 
> I spent last summer folding it." 
> -Steven Wright-
> 
> From: Alex Barth <a...@mapbox.com <mailto:a...@mapbox.com>>
> Reply-To: "Licensing and other legal discussions." 
> <legal-talk@openstreetmap.org <mailto:legal-talk@openstreetmap.org>>
> Date: Monday, October 12, 2015 at 12:32 PM
> To: "Licensing and other legal discussions." <legal-talk@openstreetmap.org 
> <mailto:legal-talk@openstreetmap.org>>
> Subject: Re: [OSM-legal-talk] Proposed "Metadata"-Guideline
> 
> 
> On Fri, Oct 9, 2015 at 5:41 PM, Steve Coast <st...@asklater.com 
> <mailto:st...@asklater.com>> wrote:
> 
>> On Oct 9, 2015, at 3:22 PM, Alex Barth <a...@mapbox.com 
>> <mailto:a...@mapbox.com>> wrote:
>> On Fri, Oct 9, 2015 at 12:07 PM, Steve Coast <st...@asklater.com 
>> <mailto:st...@asklater.com>> wrote:
>> If you want all these rights, you can just pick up the phone and pay HERE or 
>> TomTom for them, they’d love to hear from you.
>> 
>> What's more interesting than sending people to HERE and TomTom is making 
>> them contributors to OpenStreetMap, no?
> 
> Absolutely, but at what cost?
> 
> OSM solved 95% or 99% of our problems. Should we fundamentally change OSM to 
> claim the last 1% so someone can make slightly more money or complete an 
> academic project? I don’t think that’s a worthwhile tradeoff. I’m super happy 
> with the 99% we achieved already.
> 
> I'm very happy about what we have achieved too. I don't think we're solving 
> 95% of our problems with OSM though.
> 
> "our problems" would of course need more definition and I'm running the risk 
> here of misinterpreting what you said. I'm thinking about all the cases where 
> OSM isn't used yet, all the mapping that isn't happing in OSM yet. OSM has 
> the potential to fundamentally change how we capture and share knowledge 
> about the world but we aren't anywhere near the full impact we should be 
> having. 300,000 active mappers is impressive but the world is much bigger. At 
> a time where the internet that was supposed to be Open is turning more and 
> more into a closed game of big players and growth for OSM is linear - what's 
> our plan? Fixing the license surely can't be the extent of our plan, but we 
> need to be able to have a frank conversation about how licensing is hurting 
> use cases and engagement on OSM, without second guessing people's intentions 
> and without just showing them the door to TomTom and HERE. In that context I 
> find comparing ODbL to Public Domain absolutely useful.
> 
> I think Stace's comments give a great glimpse into licensing pain points in 
> the academic community in the US and the guideline Simon pulled together is 
> going to fix some of the issues he's brought up. Having clarity how data 
> linked to OSM does not extend the ODbL's share alike to that data should go a 
> long way to address some of the concerns he raised.
> 
> ___
> 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] Proposed "Metadata"-Guideline

[Richard Fairhurst]

Alex Barth wrote:
> Fixing the license surely can't be the extent of our plan, but we need 
> to be able to have a frank conversation about how licensing is hurting 
> use cases and engagement on OSM, without second guessing 
> people's intentions and without just showing them the door to
> TomTom and HERE.

I've said this once or twice or eight gazillion times already, but I guess
once more doesn't hurt. :)

ODbL 1.0 - not exclusively an OSM licence, but one strongly informed by OSM
as the biggest producer of collaborative openly-licensed data - was largely
a product of the experiences we'd had up to then.

I, and others, had been burned by CC-BY-SA's requirement to "virally"
license non-data products when using an open data source. This was
(eventually) agreed as a pain point by those of us who shouted loudest, and
so ODbL came to apply the CC-like "collective work" theory to such uses.
That's what became a Produced Work. 

At the time, no-one was doing serious geocoding off OSM data - it wasn't
good enough. So there was no-one prepared to argue for a comparable
rationale for geocoded data. That's not to say that geocoding _shouldn't_ be
considered as a use case for an open database licence. Nor is it to say that
there was any great intent in the relicensing process to rule out geocoding
uses. We just, genuinely, hadn't thought of it... and no-one had pointed it
out to us.

It would be good to fix it _with_a_rationale_. It can't just be "we need
this to work". There has to be a cogent argument why a reciprocal open data
licence, outwith of OSM, can permit it. I'm 100% sure that case can be made,
but it can't be done by fiat. It has to be expressed as "this legalese will
further the aims of a reciprocally licensed data project" as exemplified by
OSM, because it is still the case that OSM's rights-holders - the
contributors - won't agree to anything else.

ODbL needs a 1.1. Creative Commons, working in the much better understood
field of copyrightable artistic works, is already on 4.0 - which is a
realistic recognition that the previous three versions haven't been perfect.
There's no admission of failure on the part of OSM, ODbL, OSM's users, or
anyone to admit that "this can be improved". Of course it can. Let's focus
on the achievable goal of working with Open Data Commons to do just that.

your friendly local WTFPL fundamentalist
Richard





--
View this message in context: 
http://gis.19327.n5.nabble.com/OSM-legal-talk-Proposed-Metadata-Guideline-tp5855168p5856834.html
Sent from the Legal Talk mailing list archive at Nabble.com.

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Steve Coast]

> On Oct 12, 2015, at 3:03 PM, Richard Fairhurst  wrote:
> At the time, no-one was doing serious geocoding off OSM data - it wasn't
> good enough. 

I think I agree with everything but this - I still don’t think it’s good 
enough. Of course, I also want it to be better - but that cogent argument thing 
you mentioned is missing either way.

Best

Steve


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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Simon Poole]

Am 12.10.2015 um 23:43 schrieb Mr. Stace D Maples:
> ..
> Neither of the projects was scrapped because we /couldn’t/ use OSM for
> the project, but because we couldn’t determine IF WE COULD use OSM for
> our particular uses.
>
> ...

And you or your legal department approached the licensor of the data and
asked for an opinion on your use of the data?





signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Mr. Stace D Maples]

Steve

No, not addresses (though that would be nice, too, though. Wasn’t Foursquare 
trying to help with that?), but geocoding to administrative boundaries,as well 
as POI. We were interested in building a system that could be elastic enough to 
geocode to esoteric localities, such as “1 km north of Kendua, Bangladesh” or 
“Madan Pharmacy, Madan, BG” and provide options for retrieving a point, point 
with an uncertainty radius, or an actual json admin boundary, moved north 1 km. 
This would be something similar to Tulane’s Geolocate, but with access to the 
ever growing corpus of POI and features in OSM. Originally, we wanted to build 
something that could be used in a variety of use cases for augmenting medical 
data with location data based upon OSM extracts.

I’m aware of the PD sources for data, however, for instance, there does not 
currently exist a PD source for the locations of all villages (96,817) in 
Bangladesh (we’ve been provided a table of the village names and their unions, 
upazila, etc… by the BG Health Ministry, but without geometries of any type). 
There is, however, the potential for OSM to have most of these villages, 
especially given the efforts of World Bank, HOT… in supporting mapping in 
developing countries, in the future. We’d wanted to be able to identify 
villages from OSM for our data dashboards, but couldn’t determine whether 
mixing the OSM data with personal health information for cholera patients would 
cause an issue and so didn’t.

On the Damascus project, we were interested in doing network analysis on 
reports from informants on the ground about grey-outs of communication and 
power infrastructure, followed by military sweeps of neighborhoods, using OSM 
for street data and the neighborhood boundaries.

Neither of the projects was scrapped because we couldn’t use OSM for the 
project, but because we couldn’t determine IF WE COULD use OSM for our 
particular uses.

Additional question… Is it like the “Elephant in the room” that the 
humanitarian relief space disregards ODbL sharealike? How does OSM feel about 
the difference between potential users who want to operate within the 
parameters of the licensing and those who ignore it (arguably for noble cause, 
in both cases)? I’ve asked people in that space about how ODbL effects/hinders 
their efforts and the answers were the equivalent of shrugs and sly smiles. 
Unfortunately, our IRB seems a bit more skittish than that.

In F,L,
Stace Maples
Geospatial Manager
Stanford Geospatial Center
@mapninja
staceymaples@G+
Skype: stacey.maples
214.641.0920
Find GeoData: https://earthworks.stanford.edu<https://earthworks.stanford.edu/>
Get GeoHelp: https://gis.stanford.edu/

"I have a map of the United States... actual size.
It says, "Scale: 1 mile = 1 mile."
I spent last summer folding it."
-Steven Wright-

From: Steve Coast <st...@asklater.com<mailto:st...@asklater.com>>
Reply-To: "Licensing and other legal discussions." 
<legal-talk@openstreetmap.org<mailto:legal-talk@openstreetmap.org>>
Date: Monday, October 12, 2015 at 1:19 PM
To: "Licensing and other legal discussions." 
<legal-talk@openstreetmap.org<mailto:legal-talk@openstreetmap.org>>
Subject: Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

Stace

Regarding your first email on this topic you said -

"to built a geocoding platform on Open Source software and Public Domain data 
that could be used to geocode research data”

Could you give an example of what the geocodable string would look like (just 
make one up)? Is it like “1 Alpha Street, Fooville” or is it more like 
“Smallville, AK” ?

If it’s address data - are you aware that OSM doesn’t actually contain much at 
all and thus can’t help you?

If it’s not address data - are you aware that there are multiple PD sources for 
non-address level geocoding?

Because either way I’m having trouble understanding why OSM is in the way to 
achieving what you’re trying to do?

Best

Steve

On Oct 12, 2015, at 2:08 PM, Mr. Stace D Maples 
<stacemap...@stanford.edu<mailto:stacemap...@stanford.edu>> wrote:

Thanks, Alex.

Clarity is exactly what is needed. Ambiguity = IRB Death. I’m going to be going 
through the OSM Licensing/Copyright Guidelines more closely over the next week 
and will comment outside this thread, if I have comments.

For the record, I hardly think solving things like diarrhoeal disease (2nd 
leading cause of death in children, globally) and tracking human rights abuses 
in repressive regimes are a 1% problems.

In F,L,
Stace Maples
Geospatial Manager
Stanford Geospatial Center
@mapninja
staceymaples@G+
Skype: stacey.maples
214.641.0920
Find GeoData: https://earthworks.stanford.edu<https://earthworks.stanford.edu/>
Get GeoHelp: https://gis.stanford.edu/

"I have a map of the United States... actual size.
It says, "Scale: 1 mile = 1 mile."
I spent last summer folding it."

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Simon Poole]

Could we please get back on topic?

Neither the pros and cons of share-alike, nor use cases in which the
data  is not publicly used, nor alternative licensing schemes, nor
mumbo-jumbo from conference sessions is the subject of this discussion.

Please feel free to discuss any of the above in separate threads with
topics that clearly indicate what they are about.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Alex Barth]

On Fri, Oct 9, 2015 at 12:07 PM, Steve Coast  wrote:

> If you want all these rights, you can just pick up the phone and pay HERE
> or TomTom for them, they’d love to hear from you.


What's more interesting than sending people to HERE and TomTom is making
them contributors to OpenStreetMap, no?
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Simon Poole]

For those readers that are  not well versed with wikis, I just wanted to
point out that some points have been raised on the discussion page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_Metadata_Guideline

I personally would prefer if feedback was given here, but obviously
using the discussion page is completely OK too.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Steve Coast]

> On Oct 9, 2015, at 3:22 PM, Alex Barth  wrote:
> On Fri, Oct 9, 2015 at 12:07 PM, Steve Coast  > wrote:
> If you want all these rights, you can just pick up the phone and pay HERE or 
> TomTom for them, they’d love to hear from you.
> 
> What's more interesting than sending people to HERE and TomTom is making them 
> contributors to OpenStreetMap, no?

Absolutely, but at what cost?

OSM solved 95% or 99% of our problems. Should we fundamentally change OSM to 
claim the last 1% so someone can make slightly more money or complete an 
academic project? I don’t think that’s a worthwhile tradeoff. I’m super happy 
with the 99% we achieved already.

As a sidenote, we should think about etiquette for how many employees from one 
firm contribute to discussions: It would not be fair for volunteers to be 
spammed by companies & their customers. I propose companies appoint one person 
to round up feedback per organization?

Steve

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

[OSM-legal-talk] Proposed "Metadata"-Guideline

[Mr. Stace D Maples]

Hello all, I’m new to this list, but wanted to chime in that I am happy to see 
this thread of discussion, here. I’ve been supporting research and teaching 
with geospatial tools for about 15 years (first, at Yale, now at Stanford) and 
I’d like to chime in from that perspective, since the industry angle is well 
represented in the discussion over the last few years.

The ODbL ShareAlike issue first came to my attention at the DC SotM a couple of 
years ago, which I was attending in support of a proposal I had put forth at 
Yale Medical Library to built a geocoding platform on Open Source software and 
Public Domain data that could be used to geocode research data that contains 
personal health information and is therefore subject to the restriction in 
handling and use imposed by HIPAA, the Health Insurance Portability and 
Accountability Act . That, I think, was the meeting where the sharealike issue 
really came to a head, and I went home convinced that I would not be successful 
in getting the licensing terms for OSM past an Internal Review Board, who would 
squash ANY development of a project that could introduce conflicts with HIPAA 
restriction on personal health information. Ironic, in fact, that the very 
answer I had come up with to solve the problem of using non-transparent, 
proprietary software and data, invoked even more serious conflicts with the law 
that was the impetus for the project, in the first place.

Now, two years on, I have seen the lack of clarity in the ODbL and the OSM 
guidance on the subject create a chilling effect on the use of OSM data for 
academic research, particularly in the fields of public health and medicine. In 
several instances, researchers who could have benefitted greatly from the use 
of OSM and who could have done great good in the world with it, have declined 
to use it because of the lack of clarity (in the part of ODbL and OSM) in 
defining just what constitutes a derivative database.

In two instances now, one the above cited project, and another project to 
create a mobile application to help doctors in remote areas of Bangladesh track 
and treat cholera outbreaks, I have seen OSM cause IRB problems and eventually 
seen it stripped from the projects. Additionally, I have seen other researchers 
decline to use OSM data due to privacy issues (in the case of a researcher who 
was hesitant to use OSM to geocode data received from confidential informants 
in Damascus, for obvious reasons), as well as the more benign (but no less 
problematic, in academia) issue of publishing embargoes on research. 
Researchers at higher ed institutions are required to publish. Publishing is a 
competitive game, and many researchers are hesitant to invest their time in 
using research data that may or may not require them to share their own 
research out before they have had a chance to publish.

I am of the opinion that the use of the ShareAlike license does little to 
protect OSM from use by people and organizations that are not willing to 
contribute back to OSM, which I suspect is the idea. What I DO see it doing is 
causing a chilling effect on the use of the data for legitimate research 
purposes, which I can’t imagine that the vast majority of OSM contributors 
would be opposed to. So, ideally, OpenStreetMap should actually be open for any 
use, but barring the dropping of sharealike, there certainly needs to be a 
great deal of clarification and specificity in how the clause is applied. 
Certainly, clearly defined examples of use cases and the parameters of the 
application of sharealike, would be helpful. For instance, if research using 
OSM is subject to sharealike, when must the data be released? Immediately, 
eventually, after a 3 year publishing embargo (that’s our default publishing 
embargo on the Stanford Digital Repository for research data)? How do you 
resolve a conflict between HIPAA and ODbL, when personal health information 
CANNOT be released, under any circumstances? Is research using OSM data in 
Public Health and Medicine simply off limits?

Again, I’m happy to see an active discussion of these issues beginning, here, 
and welcome any questions the list members might have about OSM/ODbL license 
implications outside of commercial applications.

One other question, and I’m just curious, not trying to start a flame war. 
Isn’t some of the data in OSM from public domain datasets? If so, what is the 
OSM rationale for placing a more restrictive licensing model on that data?

Best to all, hope to hear from you soon.

In F,L,
Stace Maples
Geospatial Manager
Stanford Geospatial Center
@mapninja
staceymaples@G+
Skype: stacey.maples
214.641.0920
Find GeoData: https://earthworks.stanford.edu<https://earthworks.stanford.edu/>
Get GeoHelp: https://gis.stanford.edu/

"I have a map of the United States... actual size.
It says, "Scale: 1 mile = 1 mile."
I spent last summer folding it."
-Steven Wright-

[OSM-legal-talk] Proposed "Meta

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Steve Coast]

I designed a license concept that’s relevant as an alternative way of thinking 
about this:

http://stevecoast.com/2015/09/30/license-ascent/

On a different note: It’s a false dichotomy to compare OSM and Public Domain, 
it’s really about comparing buying a proprietary map (which the OP didn’t 
mention that I saw) and OSM. If you want all these rights, you can just pick up 
the phone and pay HERE or TomTom for them, they’d love to hear from you. From 
that standpoint OSM looks wonderful of course.

Best

Steve

> On Oct 9, 2015, at 12:56 PM, Eugene Alvin Villar  wrote:
> 
> On Fri, Oct 9, 2015 at 11:49 PM, Mr. Stace D Maples  > wrote:
> One other question, and I’m just curious, not trying to start a flame war. 
> Isn’t some of the data in OSM from public domain datasets? If so, what is the 
> OSM rationale for placing a more restrictive licensing model on that data?
> 
> Well, this issue is actually a "religious" war most commonly known as the BSD 
> vs. GPL debate.
> 
> Personally, I take issue with your statement that ODbL is a "more 
> restrictive" license than public domain. It all depends on your definition of 
> "restrictive" vis-a-vis "freedom". Public domain or CC-BY-style licensing 
> (aka BSD style) does provide the immediate user with a lot more rights than a 
> share-alike license like ODbL or CC-BY-SA (aka GPL style). However, those 
> rights are only guaranteed for the immediate user. The immediate user can add 
> his own improvements to it and then make those improvements proprietary—a 
> usage right that's allowed. Unfortunately, other users cannot make use of 
> those improvements.
> 
> On the other hand, a share-alike license aims to be a more sustainable model. 
> It restricts the immediate user on only one aspect: the right to make a 
> share-alike content/data/IP proprietary is explicitly disallowed. This 
> ensures that any improvements are shared back to the community, unlike with 
> the BSD-style licensing.
> 
> For me, share-alike licensing for OSM data is a net positive. This licensing 
> ensures that nobody can take the data, improve it to make it even more 
> valuable and then make it proprietary.
> 
> ___
> 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] Proposed "Metadata"-Guideline

[Tom Lee]

Allow me to gently suggest that we try to keep this thread grounded in
concrete concerns. I am always up for some flag-waving about sharealike
versus PD, but I think it would be best housed in a new thread or the talk
list (it's a general enough principle that the larger community deserves to
weigh in if it's to be revisited).

Stace has pointed to specific use cases that I suspect many of us would
like OSM to support--academic research subject to temporary embargo and
scenarios with serious privacy limitations--and to the current lack of
guidance being a stumbling block.

Stace, do you feel the guideline under consideration would address the kind
of roadblocks you've referenced?


On Fri, Oct 9, 2015 at 3:07 PM, Steve Coast  wrote:

> I designed a license concept that’s relevant as an alternative way of
> thinking about this:
>
> http://stevecoast.com/2015/09/30/license-ascent/
>
> On a different note: It’s a false dichotomy to compare OSM and Public
> Domain, it’s really about comparing buying a proprietary map (which the OP
> didn’t mention that I saw) and OSM. If you want all these rights, you can
> just pick up the phone and pay HERE or TomTom for them, they’d love to hear
> from you. From that standpoint OSM looks wonderful of course.
>
> Best
>
> Steve
>
> On Oct 9, 2015, at 12:56 PM, Eugene Alvin Villar  wrote:
>
> On Fri, Oct 9, 2015 at 11:49 PM, Mr. Stace D Maples <
> stacemap...@stanford.edu> wrote:
>
>> One other question, and I’m just curious, not trying to start a flame
>> war. Isn’t some of the data in OSM from public domain datasets? If so, what
>> is the OSM rationale for placing a more restrictive licensing model on that
>> data?
>>
>
> Well, this issue is actually a "religious" war most commonly known as the
> BSD vs. GPL debate.
>
> Personally, I take issue with your statement that ODbL is a "more
> restrictive" license than public domain. It all depends on your definition
> of "restrictive" vis-a-vis "freedom". Public domain or CC-BY-style
> licensing (aka BSD style) does provide the immediate user with a lot more
> rights than a share-alike license like ODbL or CC-BY-SA (aka GPL style).
> However, those rights are only guaranteed for the immediate user. The
> immediate user can add his own improvements to it and then make those
> improvements proprietary—a usage right that's allowed. Unfortunately, other
> users cannot make use of those improvements.
>
> On the other hand, a share-alike license aims to be a more sustainable
> model. It restricts the immediate user on only one aspect: the right to
> make a share-alike content/data/IP proprietary is explicitly disallowed.
> This ensures that any improvements are shared back to the community, unlike
> with the BSD-style licensing.
>
> For me, share-alike licensing for OSM data is a net positive. This
> licensing ensures that nobody can take the data, improve it to make it even
> more valuable and then make it proprietary.
>
> ___
> 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] Proposed "Metadata"-Guideline

[Simon Poole]

Michael

thanks for the feed back it is very helpful.

Anybody else with input?

IMHO we might do away completely with a negative (as in share alike
invoked) example  because of the issues this has caused and undoubtedly
will continue to cause.

Simon

 

Am 02.10.2015 um 18:31 schrieb Michael Steffen:
> Simon et al -
>
> First of all, hello! I started a few months ago as in-house counsel at
> Mapbox. I come from the U.S. gov (FCC) where I did a lot of work,
> among other things, on opening FCC geodata to the public. I've had to
> focus on other things in my first few months, but am looking forward
> to finally being able to turn more of attention to working with this
> group.
>
> As Tom mentioned, several of us at Mapbox have been digging into the
> specifics of the Metadata guideline and we think something like this
> could be useful in clarifying and opening up important use cases.
> (This is true independently of the broader threads going on around
> geocoding.)
>
> I've offered specific suggestions below, with explanatory notes.
>
> Thanks for pushing this along Simon (and others),
>
> -Michael
>
>
> -
>
> > = Metadata Guideline =
>
> > == Background ==
>
> > Many users of OpenStreetMap data are concerned about the share alike
> > implications of the ODbL when using OpenStreetMap derived data
> together with
> > proprietary data, even with such data that is clearly outside the
> scope of
> > the OpenStreetMap project.
>
> > This guideline attempts to better define usage of OpenStreetMap data
> that
> > the OSMF and the community views as acceptable without invoking the
> share
> > alike clauses of the ODbL. This does not imply, as with all community
> > guidelines, that this is the only legal way to do so, just legal
> usage we
> > consider in line with the goals of the project.
>
> > The ODbL defines two ways OpenStreetMap data can be utilized with third
> > party data: as part of a “Collective Database” or as a “Derivative
> > Database”.
>
> > Use in a “Collective Database” does not invoke share alike, the ODbL
> > requires that the individual component databases of the collective
> database
> > are “independent” however does not further define what that means.
>
> > ~~While it would seem to be simple to define “independent” as having no
> > ~~reference to OpenStreetMap data, every geographic dataset can be
> linked
> > ~~just by virtue of its location information and further it is a trivial
> > ~~exercise to link two datasets isolating OpenStreetMap derived data and
> > ~~references to the other dataset in just one of them, so that is
> likely not
> > ~~a useful criteria.~~
>
> I'd recommend deleting the paragraph above: it's unnecessary
> and a bit confusing--the first two grafs amply explain why the guidance
> is needed.
>
> > == The Guideline ==
>
> > A database containing one or more datasets derived from
> OpenStreetMap data
> > and other sources is considered an ODbL collective database if one
> of the
> > following conditions are fulfilled by the database elements from other
> > sources:
>
> > * the elements do not contain references to OpenStreetMap original or
> > derived elements 
>
> > * the elements that contain references to OpenStreetMap elements do not
> > replace or modify existing attributes or geometry of the referenced 
> > OpenStreetMap elements.
>
> > For the purpose of this guideline
>
> > * a reference can be a primary or composite database key or any
> other method
> > of identifying a specific OpenStreetMap derived element. 
>
> > * adding additional attributes by means of such a reference is not 
> > considered modifying the existing attributes of the referenced 
> > OpenStreetMap element. 
>
> > * referring from an OpenStreetMap derived element to an element from
> another 
> > source in the database is considered equivalent to a reference in
> the other
> > direction.
>
> I'd add an additional bullet akin to the following:
>
> > * technical implementations that are functionally equivalent to a
> primary or
> > composite key reference but facilitate performance improvements -- for 
> > example a join of tables by a primary ID for purposes of a production 
> > database -- are equivalent to a reference.
>
> > == Examples ==
>
> > The following examples will demonstrate this further.
>
> > === Examples of where you DO NOT need to share your
> non-OpenStreetMap data
>
> > * You collect restaurant reviews and reference the restaurants in your
> > database by OSM object id.__[^1]__ ~~(note this is technically
> > defective)~~. Your restaurant reviews are not subject to sharealike.
>
> As indicated above, I think it would be clearer to move the technical
> point
> to a footnote, where we'd briefly explain *why* it's technically
> defective to use OSM
> ID as a database key.
>
> > * You generate traffic data from in-car GPS information and use the
> location
> > information to identify roads in OSM to weight them differently in your
> > routing application.
>
> > ~~=== 

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Michael Steffen]

Simon et al -

First of all, hello! I started a few months ago as in-house counsel at
Mapbox. I come from the U.S. gov (FCC) where I did a lot of work, among
other things, on opening FCC geodata to the public. I've had to focus on
other things in my first few months, but am looking forward to finally
being able to turn more of my attention to working with this group.

As Tom mentioned, several of us at Mapbox have been digging into the
specifics of the Metadata guideline and I think something like this could
be useful in clarifying and opening up important use cases. (This is true
independently of the broader threads going on around geocoding.)

I've offered specific suggestions below, with explanatory notes.

Thanks for pushing this along Simon (and others),

-Michael


-

> = Metadata Guideline =

> == Background ==

> Many users of OpenStreetMap data are concerned about the share alike
> implications of the ODbL when using OpenStreetMap derived data together
with
> proprietary data, even with such data that is clearly outside the scope of
> the OpenStreetMap project.

> This guideline attempts to better define usage of OpenStreetMap data that
> the OSMF and the community views as acceptable without invoking the share
> alike clauses of the ODbL. This does not imply, as with all community
> guidelines, that this is the only legal way to do so, just legal usage we
> consider in line with the goals of the project.

> The ODbL defines two ways OpenStreetMap data can be utilized with third
> party data: as part of a “Collective Database” or as a “Derivative
> Database”.

> Use in a “Collective Database” does not invoke share alike, the ODbL
> requires that the individual component databases of the collective
database
> are “independent” however does not further define what that means.

> ~~While it would seem to be simple to define “independent” as having no
> ~~reference to OpenStreetMap data, every geographic dataset can be linked
> ~~just by virtue of its location information and further it is a trivial
> ~~exercise to link two datasets isolating OpenStreetMap derived data and
> ~~references to the other dataset in just one of them, so that is likely
not
> ~~a useful criteria.~~

I'd recommend deleting the paragraph above: it's unnecessary
and a bit confusing--the first two grafs amply explain why the guidance
is needed.

> == The Guideline ==

> A database containing one or more datasets derived from OpenStreetMap data
> and other sources is considered an ODbL collective database if one of the
> following conditions are fulfilled by the database elements from other
> sources:

> * the elements do not contain references to OpenStreetMap original or
> derived elements

> * the elements that contain references to OpenStreetMap elements do not
> replace or modify existing attributes or geometry of the referenced
> OpenStreetMap elements.

> For the purpose of this guideline

> * a reference can be a primary or composite database key or any other
method
> of identifying a specific OpenStreetMap derived element.

> * adding additional attributes by means of such a reference is not
> considered modifying the existing attributes of the referenced
> OpenStreetMap element.

> * referring from an OpenStreetMap derived element to an element from
another
> source in the database is considered equivalent to a reference in the
other
> direction.

I'd add an additional bullet akin to the following:

> * technical implementations that are functionally equivalent to a primary
or
> composite key reference but facilitate performance improvements -- for
> example a join of tables by a primary ID for purposes of a production
> database -- are equivalent to a reference.

> == Examples ==

> The following examples will demonstrate this further.

> === Examples of where you DO NOT need to share your non-OpenStreetMap data

> * You collect restaurant reviews and reference the restaurants in your
> database by OSM object id.__[^1]__ ~~(note this is technically
> defective)~~. Your restaurant reviews are not subject to sharealike.

As indicated above, I think it would be clearer to move the technical point
to a footnote, where we'd briefly explain *why* it's technically defective
to use OSM
ID as a database key.

> * You generate traffic data from in-car GPS information and use the
location
> information to identify roads in OSM to weight them differently in your
> routing application.

> ~~=== Examples of where you DO need to share your non-OpenStreetMap data

> ~~* you own a database of restaurant star ratings, you publish a product
> ~~that provides one dataset that uses ratings from OSM when you don’t have
> ~~it in your database and otherwise your data. The data that you publish
> ~~is subject to sharealike. Note: if you don’t use the relevant OSM
> ~~attributes and just your data, your data is not subject to sharealike as
> ~~defined in the “Horizontal Layers” guideline. Note this is a
> ~~hypothetical use case and not 

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Frederik Ramm]

(initially sent from from address, sorry)

Hi,

On 10/02/2015 06:31 PM, Michael Steffen wrote:
>> ~~=== Examples of where you DO need to share your non-OpenStreetMap data
> 
>> ~~* you own a database of restaurant star ratings, you publish a product
>> ~~that provides one dataset that uses ratings from OSM when you don’t have
>> ~~it in your database and otherwise your data. The data that you publish
>> ~~is subject to sharealike. Note: if you don’t use the relevant OSM
>> ~~attributes and just your data, your data is not subject to sharealike as
>> ~~defined in the “Horizontal Layers” guideline. Note this is a
>> ~~hypothetical use case and not an actual one.~~
> 
> I recommend striking the paragraph above: 

I agree that the example sounds a bit too contrived; but simply striking
it out without a replacement makes the document much less useful.

I'd suggest the following as a replacement:

"You publish a mobile navigation app with a restaurant directory taken
from OpenStreetMap, using the wheelchair attribute from OSM to flag some
restaurants as wheelchair accessible. You allow your users to report
back the wheelchair status they observed locally, and you collect that
information in a separate data set, keyed by the OSM ID of the
restaurant. Your application queries the database in a way that your
user reports override the information taken from OSM, but for
restaurants where you don't have user reports, the OSM information is used."

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Frederik Ramm]

Hi,

   I'm deliberately taking this out of the geocoding context here to
make a point regarding the mixing of OSM and non-OSM data:

On 09/23/2015 01:26 AM, Alex Barth wrote:
> mixing OSM and non-OSM POIs
> should not extend the ODbL to non-OSM POIs and so forth.

What we'd like to avoid is someone making a business of selling "the
better OSM" by adding to our data other, separately curated, proprietary
data, thereby improving OSM without sharing any of the improvements back.

That would enable someone to offer e.g. a "better navigation app" that
was largely based on OSM but had proprietary data improvements, and the
exposure OSM would get from that would be worth nothing as nobody else
could use that same database.

This would be a use case that the license is specifically designed
against and we must take care not to weaken our position here.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Simon Poole]

Am 22.09.2015 um 22:14 schrieb alyssa wright:
> What does this mean? "uses ratings from OSM " 
>
Again: it is just a hypothetical example.

Obviously using a real life use case and declaring that as
non-conformant or whatever in a not yet agreed to guideline would not be
sensible (just imagine the outrage).

Not to mention the ability of the OSM community to dig out many years
stale and obviously out of date wiki pages and to pretend that they are
meaningful implies that anything that we put in writing is going to be
quoted for the next couple of decades regardless of what guideline we
end up with eventually.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Tom Lee]

Martin,


Is there a problem with the current license? Is it not clear from a legal
point of view, how it should be interpreted?


Correct--it's currently unclear how the license applies to many important
use cases. Partly this is because it's untested: OSM is the only important
user of ODbL (with allowances for some geo datasets that have been released
under ODbL in the hopes of being imported).

There is much more that could and should be done to clarify use and
establish norms without revisions to the license. This proposal could be a
useful step forward. A couple of us at Mapbox are taking a careful a look
at the specifics, and plan to weigh in with more thoughts.

I must admit I feel some reluctance towards the practise of introducing
more and more examples and guidelines how to interpret the legal text,
because every additional word is augmenting the risk of introducing
loopholes and weakening our position in a potential prosecution of
infringers.


As you note, infringements have never been prosecuted. But right now, every
day, data is being collected in places other than OSM because of
uncertainty regarding the license (cf OpenAddresses, OpenTraffic). I came
to Mapbox to work on open data, having spent six years advocating for it at
a nonprofit called the Sunlight Foundation. It's dismaying to see the
landscape fractured. I would like OSM to become a better legal home (or at
least partner) for all geodata, including new datasets like LIDAR, traffic
and street-level imagery. Those projects are going elsewhere right now.

I understand your desire to preserve a strong position for hypothetical
future infringement claims. But this goal clearly only makes sense insofar
as it serves the larger goal of creating a useful project. The point of
OpenStreetMap is not to win lawsuits, after all.

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Frederik Ramm]

Hi,

   this is not the right group to discuss the matter but let me just say
that your statement

On 09/22/2015 10:57 PM, Tom Lee wrote:
> It's dismaying to see the landscape fractured. I would like OSM to become a 
> better legal
> home (or at least partner) for all geodata, including new datasets like
> LIDAR, traffic and street-level imagery. 

is certainly not universally held in OSM, and that

> Those projects are going
> elsewhere right now.

is a welcome effect, rather than a shortcoming of OSM, for those who see
OSM as a project of makers rather than a receptacle for other people's
geodata.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Rob Myers]

On 2015-09-22 16:26, Alex Barth wrote:


Overall, I'd love to see us moving towards a share alike
interpretation that applies to "OSM as the map" and allows for liberal
intermingling of narrower data extracts. In plain terms: to
specifically _not_ extend the ODbL via share alike to third party data
elements intermingled with OSM data elements of the same kind. E. g.
mixing OSM and non-OSM addresses should not extend ODbL to non-OSM
addresses, mixing OSM and non-OSM POIs should not extend the ODbL to
non-OSM POIs and so forth.


This would explicitly go against the license if it's a qualitative 
rather a quantitative statement.


Calling something "geocoding" is a distraction.

Look at what processes are involved (copying a database) and what the 
results are (a substantial or non-substantial amount of the database 
being copied).


- Rob.


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

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Luis Villa]

On Tue, Sep 22, 2015 at 1:58 PM Tom Lee  wrote:

> Martin,
>
>
> Is there a problem with the current license? Is it not clear from a legal
> point of view, how it should be interpreted?
>
>
> Correct--it's currently unclear how the license applies to many important
> use cases. Partly this is because it's untested: OSM is the only important
> user of ODbL [...]
>

Also, unlike copyright, the ODbL is based on legal terms and concepts that
are largely untested and undefined. As I've explained on this list
before[1], some very basic terms like "substantial" are not well-defined in
the statute or caselaw. In some cases, that vagueness may be helpful for
OSM; in other cases, not so much.

Luis

[1]
https://lists.openstreetmap.org/pipermail/legal-talk/2014-April/007809.html
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Simon Poole]

Naturally musings about hypothetical better worlds in which OSM has a
different licence (and in which we undoubtedly would be having exactly
the same discussions) are just as off topic in this thread as
stipulations that company XYZ is violating the licence.

Could we pls have some comments on the subject at hand.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Kathy Bizzoco]

Please unsubscribe. Please. I don't know how to login.

On 9/22/15, 5:27 PM, Simon Poole wrote:

Naturally musings about hypothetical better worlds in which OSM has a
different licence (and in which we undoubtedly would be having exactly
the same discussions) are just as off topic in this thread as
stipulations that company XYZ is violating the licence.

Could we pls have some comments on the subject at hand.

Simon



___
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] Proposed "Metadata"-Guideline

[Simon Poole]

I've added a clarification to the example in question as it is causing
some contention.

Simon

Am 22.09.2015 um 22:39 schrieb Simon Poole:
>
> Am 22.09.2015 um 22:14 schrieb alyssa wright:
>> What does this mean? "uses ratings from OSM " 
>>
> Again: it is just a hypothetical example.
>
> Obviously using a real life use case and declaring that as
> non-conformant or whatever in a not yet agreed to guideline would not be
> sensible (just imagine the outrage).
>
> Not to mention the ability of the OSM community to dig out many years
> stale and obviously out of date wiki pages and to pretend that they are
> meaningful implies that anything that we put in writing is going to be
> quoted for the next couple of decades regardless of what guideline we
> end up with eventually.
>
> Simon
>




signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Alex Barth]

On Mon, Sep 21, 2015 at 6:43 AM, Simon Poole  wrote:

> One of the big grey areas remaining wrt our distribution licence is
> defining if, and how you can link from external data to an OpenStreetMap
> derived dataset. Nailing this down is, in my opinion, key to progress in
> getting rid of other areas of contention (for example geo-coding).
>

The Fairhurst Doctrine won't get us all the way on geocoding. It still
leaves open what happens in scenarios where elements of the same kind in
third party databases are geocoded with OSM data and others with third
party data. This is a highly relevant scenario as OSM data particularly for
geocoding (addresses, POIs) is usually not complete enough. The ability to
use OSM for geocoding and "backfill" it with (non-license-compatible) third
party data is exactly what would would make a gradual adoption of OSM
possible.

Overall, I'd love to see us moving towards a share alike interpretation
that applies to "OSM as the map" and allows for liberal intermingling of
narrower data extracts. In plain terms: to specifically _not_ extend the
ODbL via share alike to third party data elements intermingled with OSM
data elements of the same kind. E. g. mixing OSM and non-OSM addresses
should not extend ODbL to non-OSM addresses, mixing OSM and non-OSM POIs
should not extend the ODbL to non-OSM POIs and so forth.

This could be well done within the confines of the ODbL by endorsing the
"Geocoding is Produced Work" guideline
https://lists.openstreetmap.org/pipermail/legal-talk/2014-July/007900.html
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Martin Koppenhoefer]

Is there a problem with the current license? Is it not clear from a legal
point of view, how it should be interpreted?
I must admit I feel some reluctance towards the practise of introducing
more and more examples and guidelines how to interpret the legal text,
because every additional word is augmenting the risk of introducing
loopholes and weakening our position in a potential prosecution of
infringers. Also, according to the mandate the OSMF is given from the
original IP holders by means of the CTs, any modification of the current
license has to be approved by a majority of active contributors.

Is the OSMF consulting with their legal advisors before publishing these
amendments/interpretations?

Finally, the OSMF in the past didn't seem to care about prosecution of
actual infringers. Is there any example where some action was taken? Is
someone from the OSMF checking this list from time for instance:
http://wiki.openstreetmap.org/wiki/Lacking_proper_attribution ?

FWIW, apple maps continues big scale infringement, e.g. their map app in
the most recent OS (OX-X 10.10.5) has the attribution very hidden, it is
neither on the screen nor when you print a map (but you can get to it by
clicking in the menu on "Maps"->"About Maps" and then on "Data from TomTom
and others ->"  (on my system nothing happens after the click, but that's
likely just a bug)). Also Apple's "Friends" app on iOS has no attribution
whatsoever.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Simon Poole]

Am 22.09.2015 um 11:05 schrieb Martin Koppenhoefer:
> Is there a problem with the current license? Is it not clear from a
> legal point of view, how it should be interpreted?

Please read the introduction to the proposed guideline.

>
> I must admit I feel some reluctance towards the practise of
> introducing more and more examples and guidelines how to interpret the
> legal text, because every additional word is augmenting the risk of
> introducing loopholes and weakening our position in a potential
> prosecution of infringers. Also, according to the mandate the OSMF is
> given from the original IP holders by means of the CTs, any
> modification of the current license has to be approved by a majority
> of active contributors.
>
> Is the OSMF consulting with their legal advisors before publishing
> these amendments/interpretations?
>
> Finally, the OSMF in the past didn't seem to care about prosecution of
> actual infringers. Is there any example where some action was taken?
> Is someone from the OSMF checking this list from time for instance:
> http://wiki.openstreetmap.org/wiki/Lacking_proper_attribution ?
>
> FWIW, apple maps continues big scale infringement, e.g. their map app
> in the most recent OS (OX-X 10.10.5) has the attribution very hidden,
> it is neither on the screen nor when you print a map (but you can get
> to it by clicking in the menu on "Maps"->"About Maps" and then on
> "Data from TomTom and others ->"  (on my system nothing happens after
> the click, but that's likely just a bug)). Also Apple's "Friends" app
> on iOS has no attribution whatsoever.

Please stick to the topic at hand.

Simon




signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Simon Poole]

Am 21.09.2015 um 14:01 schrieb Martin Koppenhoefer:
>
>
> I don't believe that the restaurant star rating is a good example, as
> we don't rate restaurants ourselves,

I'm using a hypothetical, but "in principle could be possible" example
on purpose for the negative scenario.

> and copying the rating from other professional restaurant testers
> might even be an infraction of their intellectual property.
That is really substantially off topic in this thread.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Proposed "Metadata"-Guideline

[Martin Koppenhoefer]

2015-09-21 12:43 GMT+02:00 Simon Poole :

> I have to say that I'm not completely happy with the document as is,
> however nobody has come up with anything better. It will definitely need
> some more examples in a final version.
>


I don't believe that the restaurant star rating is a good example, as we
don't rate restaurants ourselves, and copying the rating from other
professional restaurant testers might even be an infraction of their
intellectual property.


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

[OSM-legal-talk] Proposed "Metadata"-Guideline

[Simon Poole]

Dear All

One of the big grey areas remaining wrt our distribution licence is
defining if, and how you can link from external data to an OpenStreetMap
derived dataset. Nailing this down is, in my opinion, key to progress in
getting rid of other areas of contention (for example geo-coding).

In the past it seems that most people that have engaged in the
discussion in principle would be happy with the "Fairhurst Doctrine"
however we have had trouble actually turning that in to a usable text.
I've now drafted a proposal that tries to actually express the essence
of the doctrine while at the same time remaining compatible with the the
"Horizontal Layers" guideline.

The proposal is here
http://wiki.openstreetmap.org/wiki/Proposed_Metadata_Guideline

The relevant discussion pages
http://wiki.openstreetmap.org/wiki/Open_Data_License/Metadata_Layers_-_Guideline

I have to say that I'm not completely happy with the document as is,
however nobody has come up with anything better. It will definitely need
some more examples in a final version.

Simon



signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk