Re: [OSM-legal-talk] OSM's future Was: Re: Proposed "Metadata"-Guideline

[Alex Barth]

On Mon, Oct 12, 2015 at 4:05 PM, Steve Coast  wrote:

> > "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?
>
> Yes - we discovered that OSM is linear at CloudMade and our VCs were
> worried too, but that’s not quite the same thing as it being a problem for
> OSM.
>

Reducing licensing ambiguity and making OpenStreetMap more usable by more
people effects non-profit organizations, governments, academics and
companies (both public companies like your employer Telenav and private
companies like Mapbox that have taken VC). Our VC's aren't worried, I'm
worried. All of us on this list are on the same team, we want OpenStreetMap
to be the conical data set for the world. Mapbox buys address data and
directions data from traditional third party providers, much like Telenav
does this for Scout. Its one of the data sources for us, in addition to
OpenAddresses and other open government data sets that have clear licensing.

How is it a bad thing that OSM is used in more places where it can't be
used today and hence grows? The lack of clarity around use cases like
geocoding infects other datasets with ODBL is killing the incentives for
businesses, NGOs and government to contribute to OSM. Let's clarify the
important use cases, leave share alike intact and we all have a better OSM.
Looking back over to the other thread, I don't think we're that far off
from each other:
https://lists.openstreetmap.org/pipermail/legal-talk/2015-October/008283.html
___
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 5:41 PM, Steve Coast  wrote:

>
> 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.
>

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

[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] When should ODbL apply to geocoding

[Alex Barth]

On Mon, Sep 28, 2015 at 5:10 AM, Simon Poole  wrote:

> The later naturally makes the former unnecessary,  so we might as well
> simply propose that geo-coding creates a non-substantive extract (which has
> been suggested btw in a different forum and is in discussion in the LWG).
>

This would work.


> In a way I would actually support this if geo-coding was a clearly and
> tightly defined process, which, as I've pointed out earlier, it isn't.
>

We could work on a definition of geocoding for the purpose of a guideline
though.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] When should ODbL apply to geocoding

[Alex Barth]

On Tue, Sep 22, 2015 at 7:38 PM, Paul Norman  wrote:

> On 9/22/2015 4:26 PM, 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.
>>
>
> Turning this around, when do you think share-alike should apply in a
> geocoding context?
>

If you methodically use a geocoder to reverse engineer the OpenStreetMap
database, share alike would kick in. "Reverse engineering OpenStreetMap"
would need a better definition and it would have to cover two dimensions:

1. Comprehensiveness (not just a "narrow extract" like addresses, buildings
or businesses, but rather a comprehensive extract of the most important
OpenStreetMap features together)
2. Geographic size (e. g. a country)

We could establish these limits with an update to the community guidelines
for what's Substantial.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Geocoding as produced work

[Alex Barth]

On Wed, Sep 23, 2015 at 4:22 PM, Simon Poole  wrote:

> it might actually force
> such a service provider to differentiate between geo-coding for public
> vs in-house use.
>

This suggestion has come up before and I'd like to flag that this is
impractical. No organization would and should take the risk that a
potential future (accidental) publication of a private OpenStreetMap based
work could jeopardize sensitive data. The risk is significant as even the
publication of a Produced Work can bring the share alike stipulations of
the ODbL to bear.
___
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] Any expert CC-BY -> ODbL negotiators?

[Alex Barth]

On Sun, Aug 30, 2015 at 9:54 PM, Paul Norman  wrote:

> The problem is that they have specified a license with attribution that is
> unreasonable for geodata (CC BY 3.0 and earlier).
>

How so?

Emphasis is on "in a manner reasonable to the medium" which would be
totally satisfied by a mention and general terms of how data would be
modified on OSM on http://wiki.openstreetmap.org/wiki/Contributors

http://creativecommons.org/licenses/by/3.0/au/legalcode
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Any expert CC-BY -> ODbL negotiators?

[Alex Barth]

On Sun, Aug 30, 2015 at 9:04 PM, Steve Bennett  wrote:

> My understanding was that when you import data into OSM, you assign
> special permission to the OSMF to re-license the data under ODbL, so you
> need more than just CC-BY licensing to begin with. Did something change, or
> have I just been mistaken for a long time?


Not quite, you only need special permission if terms aren't clearly
compatible with an import in OSM:

> Sometimes the exact terms under which data can used is unclear and
clarification is needed.

http://wiki.openstreetmap.org/wiki/Import/GettingPermission
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Any expert CC-BY -> ODbL negotiators?

[Alex Barth]

On Sun, Aug 30, 2015 at 2:33 PM, Stephan Knauss 
wrote:

> Hello Steve,
>
> On 30.08.2015 17:14, Steve Bennett wrote:
>
>> I wonder if there are any expert licence negotiators here who might be
>> able to get involved in the discussion.
>>
>
> I'm no such expert, but they just require attribution. Did they state any
> specific way of doing so? If not, then maybe just mentioning in the wiki is
> fine for them?
>
> http://wiki.openstreetmap.org/wiki/Contributors
>
>
Right. You don't need DELWP to give you any statement or permission in
order to import their data to OpenStreetMap or derive data  for
OpenStreetMap from their data.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Thu, Feb 19, 2015 at 11:52 PM, Simon Poole  wrote:

> >
> http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative
> >
> > 1. Why is the input data part of the Derivative Database?
>
> There is an underlying assumption that the input data will match, in the
> best case exactly, an object in the OSM dataset, and that you are
> extracting further information about it (aka its geographic location)
> from the OSM data.
>
> Note that in this model we are treating the input data as a key in to
> the geocoded dataset.
>
> Treating the geocoded results plus input data as a derivative DB
> sidesteps various issues. They have their roots in, on the one hand, the
> most popular OSM based geocoder not just returning a pair of coordinates
> and, on the other hand, us having no control over how geocoding is
> technically implemented. It further makes clear if that you are using
> more attributes to improve the geocoding that they are subject to the
> same terms.


Not sure I follow here. The "geocoded results plus input data" in and
itself would be in the most common cases not Substantial even by OSM's very
aggressive definition of what's Substantial (< 100 features OTOH).

So it depends on how you'd store the results returned by the geocoder and
whether you'd store the input data with it. Which brings us to point 2:

>> 2. This language is not explicit about Geocoding Results from other
>> databases that are stored in the same database. Would they be part of
>> the Derivative Database?

> I believe that is a not an issue as formulated. You would need a clear
> way of keeping the data separate. For lack of a better example: two
> tables: addresses geocoded with OSM, addresses geocoded with here, but
> IMHO labelling the geocoding source could be considered enough (given
> that you may want to provide dynamically displayed attribution you would
> likely want to do this in any case).

Now this interpretation together with the linked data concept of the same
Collective Database alternative (below) would mean that only data directly
retrieved from OSM would ever be covered by the ODbL. The ODbL would not
extend to any data added to the same database. Right?

> Any additional data that may be linked to this data, even sitting in the
same
> logical database table, is however not considered to be part of the
derivative
> database (instead it forms a collective database together with the
derivative
> database) and therefore, does not have to be shared under the ODbL.

http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License Working Group news

[Alex Barth]

Mike -

Thank you for all your work for OpenStreetMap as member and lead of the
Licensing Working Group. I know it's not always fun and work that's often
in the focus of heated debate. I've always admired your cool headedness and
appreciated your practical advice.

Thank you!

Alex


On Tue, Nov 18, 2014 at 12:48 AM, Michael Collinson  wrote:

>  The License Working Group is undermanned and has only met twice this
> year, most recently on 28th October. [1]
>
> This is due in great part to my lack of time, enthusiasm and attention in
> calling meetings.  I am therefore stepping down as below and welcome
> volunteers to join as full members and indeed, subject to the agreement of
> other LWG members and board endorsement, take over the chair role.
>
> I would also like to highlight that we also now welcome associate members
> who can help us occassionally or want to work on a specific topic that
> fires you up. This involves no specific formalities nor duties.   It has
> been brought to my attention that this might therefore suit legal
> practioners who would otherwise have a conflict of interest.  We would
> certainly welcome involvement from real lawyers!
>
> Lastly, Satoshi Iida, an extremely active member of the OSM Japan
> community has asked to participate in LWG and I welcome him
> enthusiastically. It is important to broaden our scope beyond Western
> Europe/US thinking.
>
> Mike
>
>
> [1] http://www.osmfoundation.org/wiki/Working_Group_Minutes
>
> === Slightly edited copy of email sent to LWG ==
>
> Dear LWG,  and CC Board for their information,
>
> I feel that I do not, and will be unable to give, LWG the time and
> attention it needs.  I have also been in the position for at least 6 years
> and it is time for a new and more enthusiastic face.   I am therefore
> formally resigning as Chair and invite the LWG to consider a replacement.
> I would prefer that this was not a member of the current board, and therein
> lies a problem.  I am asking Simon now his current status, but apart from
> him, all other current members are also board members.  I have also one
> piece of good news in that Satoshi Iida, an extremely active member of the
> OSM Japan community has asked to participate and I welcome him
> enthusiastically.
>
> I regret adding even more to the current board's starting load, but think
> it best to just face facts. I am therefore happy to stay in a caretaker
> role until that person is in place, but emphasise that this will be less
> than ideal.
>
> The issues that LWG should ideally be dealing with are:
>
>- Assisting end-users by developing clarificatory community guidelines
>for providing OSM-based data services (rather than maps) in a mixed data
>environment.
>- License compatibility with CC 4 and the general issue of license
>harmonisation.
>- Diligently answering now frequent license enquiries.
>
>
> Mike
>
> ___
> 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] Updated geocoding community guideline proposal

[Alex Barth]

On Mon, Nov 3, 2014 at 9:23 AM, Martin Koppenhoefer 
wrote:

> Let's presume we all followed this reading, then when would something
> actually fall under the definition of "derivative" database? Why would we
> still be writing to legal talk instead of using the whole OSM db as a
> produced work - produced e.g. by performing some operations like wget
> planet.osm -O osm-produced.work


The command you describe would just be a copy and not actually a query or a
search of the database. But extrapolating from what you write, copying the
entire db through a geocoder is actually hard. You'll have to know all
addresses in advance or query all locations in the world. The latter is
expensive and it would always leave you with an inaccurate copy. Either
way, if you did this in a systematic way you'd be looking at a Derivative
Database again. Just like the example of OCRing an OSM based tiled map and
thus rebuilding the OSM database that has come up before.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Mon, Nov 3, 2014 at 8:56 AM, Martin Koppenhoefer 
wrote:

> where in one of the first paragraphs there is this unproven claim:
>
> "
>
> Geocoding Results are a Produced Work by the definition of the ODbL
> (section 1.):
>
> “Produced Work” – a work (such as an image, audiovisual material, text, or
> sounds) resulting from using the whole or a Substantial part of the
> Contents (via a search or other query) from this Database, a Derivative
> Database, or this Database as part of a Collective Database."
>
>
A geocoding result is created via a search or a query. It's a Produced
Work. A work can specifically be a database, see
http://www.out-law.com/page-5698, "Databases are treated as a class of
literary works and may therefore receive copyright protection for the
selection and/or arrangement of the contents under the terms of the
Copyright, Designs and Patents Act 1988." (UK law)

This is clearly a possible reading of the ODbL and it would enable
geocoding.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Contents Licence for OSM Data

[Alex Barth]

On Mon, Nov 3, 2014 at 5:09 AM, Martin Koppenhoefer 
wrote:

> We have no significant third party ODbL data releases due to OSM share
>> alike to show for
>
>
>
> Actually the Italian Government has designed their open data license
> (IODL) to be compatible with OdbL:
> http://www.dati.gov.it/content/italian-open-data-license-domande-e-risposte


Not what I was trying to get at. The share alike provision in the ODbL is
designed to open improvements on top of OpenStreetMap data. If the ODbL
worked for OpenStreetMap we should see significant releases of such
improvements under the ODbL - following the mechanism of the license. We
don't. The example you gave is not such an improvement.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Contents Licence for OSM Data

[Alex Barth]

On Sun, Nov 2, 2014 at 7:50 PM, Rob Myers  wrote:

> > We have no significant third party ODbL data releases due to OSM
> > share alike to show for,
>
> Then clearly OMS should have stuck with BY-SA for the database, as
> that did gain third party data releases.


Did it? I'm not sure what point you're trying to make, no matter whether I
read this line literally or ironically. Or are you trolling me :) ?
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Mon, Nov 3, 2014 at 6:45 AM, Martin Koppenhoefer 
wrote:

>
> my bad, sorry for the confusion, my comment was referring to the following
> edit, which was 4 minutes later:
>
> http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guideline&diff=next&oldid=1102233
>

Got it, yes. Databases of items of Produced Work aren't Derivative
Databases per 4.5b.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

I have two questions on the Collective DB alternative:

> The derivative database consists of the data that has been used as the
input data for the geocoding process, as well as the data that has been
gained from OpenStreetMap in the process. Any additional data that may be
linked to this data, even sitting in the same logical database table, is
however not considered to be part of the derivative database (instead it
forms a collective database together with the derivative database) and
therefore, does not have to be shared under the ODbL.

http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative

1. Why is the input data part of the Derivative Database?
2. This language is not explicit about Geocoding Results from other
databases that are stored in the same database. Would they be part of the
Derivative Database?

An example to clarify my question in (2):

Say I have a database of Starbucks locations with addresses. I use
OpenStreetMap to geocode all addresses and store geocoding results (lat lon
pairs) from OpenStreetMap next to my existing records. A handful of
addresses failed to properly geocode so I use a geocoder with proprietary
data to backfill the results.

What specifically constitutes the Derivative Database here?

A) the input data + records I copied from OpenStreetMap
B) A + any additions of the same kind of Content, aka the lat lon pairs I
added from the proprietary geocoder




On Thu, Aug 21, 2014 at 1:26 PM, Frederik Ramm  wrote:

> Rob,
>
> On 08/21/2014 06:42 PM, Rob Myers wrote:
> >> It would be great if people would help fill in the blanks, or
> >> correct me where I might have misrepresented the discussion.
> >
> > The page asserts:
> >
> > "Geocodes are a Produced Work
>
> [...]
>
>
> > The rest of the page then silently slips
>
> [...]
>
> I have tried to present the two different viewpoints in two columns. On
> the left is Alex' original version which claims what you summarized in
> your message (that geocodes are produced works etc.); on the right is a
> version that explicitly claims "A database of Geocodes is a derivative
> database by the definition of the ODbL" - which seems to be exactly the
> statement that you were aiming at, no?
>
> The "blanks" that need filling are the consequences of this different
> interpreatation for the various use cases. I added one for use case #1,
> but only an empty column for use cases #2-#4 and #7. I added no extra
> column for #5 and #6 because those struck me as identical under both
> interpretations but of course I might be wrong.
>
> 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] Updated geocoding community guideline proposal

[Alex Barth]

On Wed, Oct 29, 2014 at 5:12 PM, Michal Palenik 
wrote:

> 4.4.c. Derivative Databases and Produced Works. A Derivative Database is
>  Publicly Used and so must comply with Section 4.4. if a Produced Work
>  created from the Derivative Database is Publicly Used.
>
> which say, that it does not matter whether you declare geocodes produced
> work or derivative db. if this didn't exist, i could declare anything
> a produced work (things like any "enhanced" database) and the whold odbl
> would not exists.


Right, if your geocoding service is Public in the sense of the ODbL and it
uses an ODbL Derivative Database to look up geocoding results, the
Derivative Database must be disclosed per 4.4. Per 4.4 c this is the case
for both current interpretations on the guidelines. The disclosure
stipulations set forth in 4.6 apply.

Right now, the geocoding guidelines don't talk about the database a
geocoder uses to look up results though, they only talk about the database
geocoding results are stored in. This could change.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Thu, Oct 30, 2014 at 8:40 AM, Martin Koppenhoefer  wrote:

> 2014-10-29 20:56 GMT+01:00 Alex Barth :
>
>> Updated:
>> http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guideline&diff=1102233&oldid=1076215
>>
>>
> wouldn't it make more sense to come to a conclusion here before updating
> the wiki?


Hey Martin - the change you link to was to replace the term 'geocode' with
the more common 'geocoding result' - do you have a specific concern with it?
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Contents Licence for OSM Data

[Alex Barth]

On Thu, Oct 30, 2014 at 4:30 PM, Rob Myers  wrote:

> > For corporations its most of the time easier to spend 500K€ on a
> > commercial dataset than to spend 5k€ on a Lawyer analyzing a
> > licensing issue.
>
> If we add up the cost of all the time company representatives have
> spent trying to get OSM to change its licensing *a second time*, it
> would have been a lot cheaper for them to get together and just hire a
> lawyer who knew what they were doing.


1. I wish this was true.
2. I wish you described the problem.

There's a brake on adoption we put on OpenStreetMap by way of share alike
for no tangible benefit. This is not just about shaping the OSM license to
taste for certain 'company representatives' but about the overall growth
potential of the project which is limited by its applications. All we have
in favor of share alike is fear, and the fact that we've used it so far. We
have no significant third party ODbL data releases due to OSM share alike
to show for, but clear reasons and examples of people walking away from the
project because of share alike.

I've stated this argument before and I do understand that for many in the
community share alike represents an important protection for the project. I
don't follow this sentiment at all because of all the reasons Florian laid
out in his response [1]. But I do understand the desire for a strong,
lasting and independent OpenStreetMap. Maybe there's a way to think outside
of the box of a license and come up with guarantees or principles
the OpenStreetMap project would want to have to protect its interests.
Thinking out loud.

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

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

Hey Michal -

On Wed, Oct 29, 2014 at 9:38 AM, Michal Palenik 
wrote:

> alex, please read 4.6 of odbl, which basically says there is no
> difference between derivative db and produced work with regards to
> database rights.
>

4.6 talks about disclosure standards in cases where share-alike applies
(offer copy of entire database or alteration file). Not sure how this
relates?

http://opendatacommons.org/licenses/odbl/1-0/
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Mon, Oct 27, 2014 at 8:33 PM, Paul Norman  wrote:

> A geocoding result is not the same as a database of geocoding results.
> Column 1 says the former is a produced work, but is silent on the latter.
>

I updated the guide to be explicit about this case:

http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guideline&diff=1102235&oldid=1102233
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Mon, Oct 27, 2014 at 8:06 PM, Paul Norman  wrote:

> I'm wondering if we should replace "geocodes" with "geocoding results"
> throughout the page. I think it improves clarity as to what is being
> discussed, and geocodes is not a term in common use for what we are
> discussing. Thoughts? It shouldn't change the meaning.
>

Updated:
http://wiki.openstreetmap.org/w/index.php?title=Open_Data_License%2FGeocoding_-_Guideline&diff=1102233&oldid=1076215
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] White Paper on ODbL and OSM

[Alex Barth]

I posted a summary of the white paper on my diary.

In discussions at State of the Map US and EU people have asked for a more
comprehensive review of the license and more specific use cases that we're
currently missing out on - which in turn means contributors we're missing
out on. I hope this paper sheds more light on this. Clearly, share alike is
one of the main impediments to broader adoption, but it's not the only
issue with the license - read on for details.

http://www.openstreetmap.org/user/lxbarth/diary/25979


On Mon, Oct 27, 2014 at 6:16 PM, Kevin Pomfret  wrote:

> Attached please find a link to a blog post on the Spatial Law and Policy
> blog that discusses a White Paper prepared by the Centre for Spatial Law
> and Policy on the ODbL and the use of OSM data. The blog post contains a
> link to the paper.
>
>
> http://spatiallaw.blogspot.com/2014/10/the-odbl-and-openstreetmap-analysis-and.html
>
> ___
> 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] Updated geocoding community guideline proposal

[Alex Barth]

Good call on geocodes -> geocoding results. That's clearer.

On Mon, Oct 27, 2014 at 8:06 PM, Paul Norman  wrote:

> What do you think the status of a database of geocoding results is under
> the interpretation in column 1?
>

According to the interpretation in column 1, the ODbL doesn't imply any
specific licensing for geocoding results, they are Produced Works.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

Picking up on Paul's offer to help along the discussion here [1]. Also
copying Steve here as he's renewed his call for better addressing in
OpenStreetMap - which I entirely agree with [2].

Feedback from this thread is incorporated on the wiki [2] - thanks
particularly to Frederik for this work. However, we have two competing
visions for how to interpret geocoding. Column 1 of the wiki page
interprets the information queried from OpenStreetMap in a typical
geocoding request as Produced Work, thus not extending share alike
provisions to geocoded data. Column 2 interprets the content pulled from
OpenStreetMap in a geocoding process as a Derivative Database but the
database this content is inserted to as a Collective Database.

Column 1 entirely enables permanent geocoding with OpenStreetMap data from
a legal perspective.

Column 2 doesn't enable permanent geocoding by extending share alike
provisions to the part of a database that contains OSM derived geocodes.
This interpretation would impede the important fall back use case where a
geocoder uses OpenStreetMap data - and where OpenStreetMap data is not
sufficient - proprietary data as a fallback. In such scenarios both
OpenStreetMap data (e. g. lat/lon's) and proprietary data would wind up in
the same database to be licensed under the ODbL. It would also impede use
cases where data is expected to be relicensed.

For making OpenStreetMap viable as a geocoding database, we'll want a
permissive reading of our license - no matter what we opine on share alike
for the larger database. Of course, enabling permanent geocoding isn't the
end-all-be-all strategy for making OpenStreetMap an awesome geocoding
database - but it's an important incentive that we can't do without. Having
more people use OpenStreetMap as a geocoding database will give us better
admin polygons, better place data and better addresses. The opportunity is
huge, none of the proprietary data providers provide reasonable terms for
_permanent_ geocoding - making everyone look for alternatives.
OpenStreetMap should be that alternative.

Would love suggestions on how to proceed on taking a decision here.

[1] https://lists.openstreetmap.org/pipermail/talk/2014-October/071153.html
[2] https://lists.openstreetmap.org/pipermail/talk/2014-October/071135.html
[3]
http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline


On Mon, Aug 25, 2014 at 12:53 AM, Eugene Alvin Villar 
wrote:

> On Mon, Aug 25, 2014 at 12:08 PM, Alex Barth  wrote:
>
>> How would the Collective Database approach work if the OSM Database must
>> remain unmodified to be part of a Collective Database?
>>
>> The definition of Collective Database seems to be tailored to use cases
>> where the OpenStreetMap database *in unmodified form* is part of a larger
>> database. I can't quite conjure up a real world example, but the ODbL is
>> pretty clear about this:
>>
>> > “Collective Database” – Means this Database in unmodified form as part
>> of a collection of independent databases in themselves that together are
>> assembled into a collective whole. A work that constitutes a Collective
>> Database will not be considered a Derivative Database. - See more at:
>> http://opendatacommons.org/licenses/odbl/1-0/#sthash.mDtnZAPO.dpuf
>>
>
> The "this Database in unmodified form" means the particular database that
> is licensed under ODbL. It can be the OSM database itself, or any database
> derived from the OSM database that must in itself be licensed under ODbL.
>
> So if you did any transformations on the OSM database (ex., converted it
> into a form suitable for a geocoder), the transformed database is licensed
> under the ODbL. You can either publish this transformed database or provide
> the software used to create the transformed database to comply with the
> license of the source OSM database.
>
> Then, this geocoder database can become part of the collective database.
>
> ___
> 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] Updated geocoding community guideline proposal

[Alex Barth]

How would the Collective Database approach work if the OSM Database must
remain unmodified to be part of a Collective Database?

The definition of Collective Database seems to be tailored to use cases
where the OpenStreetMap database *in unmodified form* is part of a larger
database. I can't quite conjure up a real world example, but the ODbL is
pretty clear about this:

> “Collective Database” – Means this Database in unmodified form as part of
a collection of independent databases in themselves that together are
assembled into a collective whole. A work that constitutes a Collective
Database will not be considered a Derivative Database. - See more at:
http://opendatacommons.org/licenses/odbl/1-0/#sthash.mDtnZAPO.dpuf

On Thu, Aug 21, 2014 at 1:26 PM, Frederik Ramm  wrote:
>
> Rob,
>
> On 08/21/2014 06:42 PM, Rob Myers wrote:
> >> It would be great if people would help fill in the blanks, or
> >> correct me where I might have misrepresented the discussion.
> >
> > The page asserts:
> >
> > "Geocodes are a Produced Work
>
> [...]
>
>
> > The rest of the page then silently slips
>
> [...]
>
> I have tried to present the two different viewpoints in two columns. On
> the left is Alex' original version which claims what you summarized in
> your message (that geocodes are produced works etc.); on the right is a
> version that explicitly claims "A database of Geocodes is a derivative
> database by the definition of the ODbL" - which seems to be exactly the
> statement that you were aiming at, no?
>
> The "blanks" that need filling are the consequences of this different
> interpreatation for the various use cases. I added one for use case #1,
> but only an empty column for use cases #2-#4 and #7. I added no extra
> column for #5 and #6 because those struck me as identical under both
> interpretations but of course I might be wrong.
>
> 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] OpenStreetMap Geocoded Replication Data and Licensing

[Alex Barth]

Peter -

>  Do we have the ability to assign our own license to this replication
data, or will we have to release the replication data under the ODC Open
Database License?

My read is yes, you have the ability to assign your own license to the
dataset you're creating. Note you'll have to attribute OpenStreetMap.

Background of this interpretation is here:
http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline

(Note this document is a draft but not an officially sanctioned guideline,
in recent discussions there were diverging opinions).


On Wed, Aug 20, 2014 at 1:12 PM, Rudloff, Peter J  wrote:

>  I have a question regarding a research project I and my colleague are
> working on at Oklahoma State University.  We are working with a dataset of
> terrorist events that contains location data such as "city name,
> administrative/state name, country name".  We are planning on geocoding the
> dataset with the MapQuest Open Geocoding API Web Service, which uses the
> OpenStreetMap data.  The Global Terrorism Database (
> http://www.start.umd.edu/gtd/) we are using contains approximately 70,000
> events (although many are duplicates in terms of location) that will be
> geocoded (i.e. associated with latitude, longitude, etc. from the
> OpenStreetMap data).  My question pertains to the license we are allowed to
> use when distributing our replication data, which would contain within it
> some data drawn from the OpenStreetMap data (i.e. latitude and longitude).
>  As this is an academic project we hope to publish, we want to make our
> data available to others for easy analysis and replication, etc.  Do we
> have the ability to assign our own license to this replication data, or
> will we have to release the replication data under the ODC Open Database
> License?
>
>  Also, is there anything else that you would like researchers to do when
> publishing work using the OpenStreetMap data, such as using a particular
> citation, notifying the OpenStreetMap Foundation when a work is published
> that used OpenStreetMap data, etc.?
>
>  Peter Rudloff
>
> ___
> 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] YouTube videos

[Alex Barth]

I've in the past used information from Youtube videos in rare instances.
For example to confirm the surface quality of a road. Facts aren't
copyrightable. I'd love to hear a more qualified person's opinion though.


On Tue, Aug 5, 2014 at 2:25 PM, Martijn van Exel  wrote:

> Hi all,
>
> Has anyone ever looked into the legal aspects of using YouTube videos to
> derive information from? Do any general rules apply?
>
> An example of a potentially useful video would be
> https://www.youtube.com/watch?v=oH99jVtb1eg&feature=youtu.be - I see that
> the Standard YouTube License is applied to this video, the salient part of
> those terms (to my mind) being 'You shall not copy, reproduce,
> distribute, transmit, broadcast, display, sell, license, or otherwise
> exploit any Content for any other purposes without the prior written
> consent of YouTube or the respective licensors of the Content.’
>
> See the full terms here: https://www.youtube.com/static?template=terms
>
> Note that YouTube users can also choose a CC-BY license - which should be
> compatible with ODbL. But the default is the Standard YouTube License
> outlined above.
>
> Thanks -
> --
> Martijn van Exel
>
> ___
> 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] Updated geocoding community guideline proposal

[Alex Barth]

On Mon, Jul 28, 2014 at 12:04 PM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:

> Am 28/lug/2014 um 09:07 schrieb Alex Barth :
>
> Our lawyers' advice is captured in the guideline as shared and posted in
> this revision:
>
>
>
> your lawyers did really say according to their understanding a pair of
> coordinates is similar to an image or a video, hence a "work"?
>

Yeah, there's no definition of 'work' in the ODbL, just a non-exclusive
list of examples in the definition of Produced Work.

> “Produced Work” – a work (such as an image, audiovisual material, text,
or sounds) resulting from using the whole or a Substantial part of the
Contents (via a search or other query) from this Database, a Derivative
Database, or this Database as part of a Collective Database. - See more at:
http://opendatacommons.org/licenses/odbl/1-0/#sthash.JPKZj3yo.dpuf
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Wed, Jul 30, 2014 at 12:31 AM, Paul Norman  wrote:

>
> On 7/28/2014 12:07 AM, Alex Barth wrote:
>
> On Mon, Jul 28, 2014 at 7:30 AM, Paul Norman  wrote:
>
>>  Please review:
>>> https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline
>>>
>>
>> Alex, you mention it was based on what you've gotten from lawyers. Is
>> there anything that can be shared, either publicly, or with the LWG for
>> when they consider the guideline?
>
>
>  Our lawyers' advice is captured in the guideline as shared and posted in
> this revision:
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guideline&oldid=1060775
>
> Just to clarify, the above is what your lawyers sent you, except for
> formatting changes to place it into a Wiki format?
>

The above is not what our lawyers sent us, it's the translation into
community guidelines of what our lawyers told us.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Mon, Jul 28, 2014 at 7:30 AM, Paul Norman  wrote:

> Please review: https://wiki.openstreetmap.org/wiki/Open_Data_License/
>> Geocoding_-_Guideline
>>
>
> Alex, you mention it was based on what you've gotten from lawyers. Is
> there anything that can be shared, either publicly, or with the LWG for
> when they consider the guideline?


Our lawyers' advice is captured in the guideline as shared and posted in
this revision:

https://wiki.openstreetmap.org/w/index.php?title=Open_Data_License/Geocoding_-_Guideline&oldid=1060775
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Sat, Jul 26, 2014 at 11:02 PM, Frederik Ramm  wrote:

> Again and again we hear, make it easier for people to geocode their
> proprietary databases and OSM can only benefit from it because everyone
> who saves $$ using OSM somehow magically "helps" OSM. I'm not convinced
> of that.
>

One could say the same about the permissive parts of OpenStreetMap today.
But there are companies today who're using OpenStreetMap and who are
playing an active role to improve the database directly or indirectly
(think software, event sponsoring). Interestingly, I have yet to see a
company that supports OpenStreetMap as a need of following the letter of
the ODbL. There aren't exactly tons of announcements of new ODbL datasets.

In addition, even if companies, non profit organizations or governments
decide to use but not actively support OpenStreetMap at all, they typically
bring OpenStreetMap to broad audiences at a time, and expose OpenStreetMap
to more potential individual contributors.

What I'm seeing is an attractive OpenStreetMap to participate in, with
great reasons to contribute and a growing group of institutional data users
with huge opportunities to do so - and already doing so. But right now
we're stuck insisting in one very particular way to contribute - and that
way isn't defined all too well and it impedes the use of OpenStreetMap for
a key use case: geocoding.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Fri, Jul 25, 2014 at 11:39 AM, Simon Poole  wrote:

> If you apply this to your above example, the addresses would be subject
> to SA (however no further information), and while potentially one could
> infer that these are likely the addresses of the store locations, no
> further information would needed to be disclosed*.
>

So I think I follow: in a database of store locations [1], where
coordinates have been added through OSM-based geocoding, only the
coordinates (latitude/longitude pairs) from OpenStreetMap are subject to
share alike. The store names, street names, house numbers, etc. wouldn't be
subject to share alike, they didn't come through the OSM-based geocoder -
nor any coordinates that haven't been added through the OSM-based geocoder.

While this reading is better than the uncertainty we have now it is not
practical beyond well informed users. To appropriately handle geocoding
under this practice, a geocoder application would not only have to expose
on a granular level where data was sourced from [2] - but a geocoder user
would have to store this information in a granular way to be able to
release data appropriately.

[1] Chain Retailer example (number 1):
https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline
[2] Assuming a complex geocoder with a fallback to appropriate third party
data.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Sat, Jul 12, 2014 at 2:30 AM, Paul Norman  wrote:

> > Consider a chain retailer's database of store locations with store
> > names and addresses (street, house number, ZIP, state/province,
> country).
> > The addresses are used to search corresponding latitude / longitude
> > coordinates in OpenStreetMap. The coordinates are stored next to the
> > store locations in the store database (forward Geocoding).
> > OpenStreetMap.org's Nominatim based geocoder is used. The store
> locations
> > are being exposed to the public on a store locator map using Bing maps.
> > The geocoded store locations database remains fully proprietary to the
> > chain retailer. The map carries a notice "(c) OpenStreetMap contributors"
> > linking to http://www.openstreetmap.org/copyright.
>
> In this example, the database powering the geocoder is a derived database.
> The geocoding results are produced works, which are then collected into
> what forms a derivative database as part of a collective database.
>

Not following how I can make a Derivative Database from a Produced Work.
Once it's a Produced Work it's a Produced Work, right? Sure if I abuse to
recreate OSM that's one thing, but at this level?

Taking a step back, is the above use case not one we'd like to support
without triggering share alike? I'm directing my question to everyone, not
just Paul who's taken the time to review my example above.

Forward and reverse geocoding existing records is such a huge potential use
case for OSM, helping us drive contributions. At the same time it's _the_
use case of OSM where we collide heads on with the realities and messiness
of data licensing: Do we really want to make a legal review the hurdle of
entry for using OSM for geocoding? Or limit using OSM for geocoding in
areas where "no one's ever going to sue"? How can we get on the same page
on how we want geocoding to work and then trace back on how we can fit this
into the ODbL? Geocoding should just be possible and frictionless with OSM,
no? Shouldn't there be a way to open up OSM to geocoding while maintaining
share alike on the whole database?

I feel we don't get anywhere by reading the tea leaves of the ODbL - what
do we really want for OSM on geocoding?

Alex

(and yes, when I'm saying geocoding I'm referring to permanent geocoding
here, where the geocoding result winds up being stored in someone else's db)
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

Also if we assume geocoding yields Produced Work the definition of
Substantial doesn't matter.

Taking a step back here. What do we want? From conversations around
dropping share alike my impression was that there was a consensus around
unlocking geocoding - even among share-alike advocates.

Just like how CC-BY-SA created a grey area around the SA implications for
the rendered map which wasn't good for OSM, ODbL does the same with
permanent geocoding. To make OSM viable for geocoding we can't have its
ODbL infecting the datasets it's used on.

There are tons of geodatasets out there waiting to be geocoded and we
should have clarity around the legal implications of doing that. More use
of OSM for geocoding means more incentives to keep and maintain geocoding
data (addresses, POIs, admin polygons) in OSM.

Alex



On Mon, Jul 14, 2014 at 11:34 AM, Paul Norman  wrote:

>
> On 2014-07-14 8:15 AM, Martijn van Exel wrote:
>
>> On Mon, Jul 14, 2014 at 8:44 AM, Alex Barth  wrote:
>>
>>> This is also how I'm reading this. Obviously the sticky point is the
>>> definition of what's a database in this sentence: "systematically recreate
>>> a database from the process". You can't abuse geocoding to recreate
>>> OpenStreetMap without triggering share alike.
>>>
>> The definition of 'substantial' is key here, isn't it? In one of the
>> examples I added, the result of OSM-based geocoding actions would
>> potentially be stored on a client in a collection of 'favorites' together
>> with other favorites that may be the result of tainted geocoding. There's
>> really two questions here - 1) is this collection of favorites
>> 'substantial' and 2) does this mixed storage trigger share alike in an of
>> itself?
>>
>
> Given that any database of geocoding results is going to be clearly based
> upon the Database [OpenStreetMap], and that any interesting uses of OSM are
> probably going to substantial, I don't see the definition of it mattering.
>
> In most of the cases raised in the wiki page, there's a derivative
> database of geocoding results and some other non-derivative database of
> something not taken from OSM, e.g. non-OSM POIs with just an address. You
> then take this collection of data sources and create a produced work, e.g.
> a page showing what the user has showed.
>
> Once you start taking actual POI information from OSM, not just addresses,
> then your POI database will also be a derivative of OSM.
>
>
> ___
> 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] Updated geocoding community guideline proposal

[Alex Barth]

On Sun, Jul 13, 2014 at 10:30 AM, Stephan Knauss 
wrote:

> Only when you start to use the process to systematically recreate a
> database from the process the ODbL kicks in.


This is also how I'm reading this. Obviously the sticky point is the
definition of what's a database in this sentence: "systematically recreate
a database from the process". You can't abuse geocoding to recreate
OpenStreetMap without triggering share alike.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

On Fri, Jul 11, 2014 at 8:30 PM, Paul Norman  wrote:
> On Jul 11, 2014, at 04:11 PM, Alex Barth  wrote:
>
> What I'm looking for a is a clear interpretation by the community,
> supported OSMF, an interpretation that is a permissive reading of the
> ODbL on geocoding to unlock use cases.
>
>
> Guidelines need to be accurate and supported by the ODbL and shouldn't be
> advanced to support a particular viewpoint and the process is not a way to
> weaken share-alike.

Agreed that guidelines need to be accurate and supported by ODbL. In
terms of what recommended interpretation we put forward that's a
strategic decision we should take in the interest of OpenStreetMap.

>
> I'm working my way through the examples.
>
>> Consider a chain retailer's database of store locations with store
>> names and addresses (street, house number, ZIP, state/province, country).
>> The addresses are used to search corresponding latitude / longitude
>> coordinates in OpenStreetMap. The coordinates are stored next to the
>> store locations in the store database (forward Geocoding).
>> OpenStreetMap.org's Nominatim based geocoder is used. The store locations
>> are being exposed to the public on a store locator map using Bing maps.
>> The geocoded store locations database remains fully proprietary to the
>> chain retailer. The map carries a notice "(c) OpenStreetMap contributors"
>> linking to http://www.openstreetmap.org/copyright.
>
> In this example, the database powering the geocoder is a derived database.
> The geocoding results are produced works, which are then collected into what
> forms a derivative database as part of a collective database. This
> derivative database is then used to create a produced work (the locator
> map).
>

What exactly constitutes the derivative db part in the collective db
of this interpretation? How would you think about future additions to
the collective db that might not come from OSM?

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

Re: [OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

We're 100% in grey territory on geocoding and you can keep reading the
ODbL in circles.

> “Produced Work” – a work (such as an image, audiovisual material, text, or 
> sounds) resulting from using the whole or a Substantial part of the Contents 
> (via a search or other query) from this Database, a Derivative Database, or 
> this Database as part of a Collective Database. - See more at: 
> http://opendatacommons.org/licenses/odbl/1.0/#sthash.Fuel2Ngv.dpuf

This definition does not preclude data to be a work as long as it has
been created by a query, and the example in parenthesis are not
exhaustive.

What I'm looking for a is a clear interpretation by the community,
supported OSMF, an interpretation that is a permissive reading of the
ODbL on geocoding to unlock use cases. If there's share alike on data
coming out of a geocoder you can't use it practically for geocoding.
Many data set ups are just too complex. This is about unlocking
geocoding on a broader level. More use cases = more incentives to
improve data.

I'd love to use OSM for geocoding again with more legal certainty at
Mapbox and build further on a feedback loop back into OSM address and
polygon data and I'd love that to be true for other users of OSM for
geocoding too. We need to build up momentum for making OSM viable for
geocoding. Clarifying that SA does not apply to results produced by a
geocoder would do that.

There's a problem with share alike and geocoding, let's make it go away.

Alex


On Fri, Jul 11, 2014 at 6:46 PM, Martin Koppenhoefer
 wrote:
>
>
>> Am 11/lug/2014 um 16:41 schrieb Michal Palenik :
>>
>> so wording "As Geocodes are a Produced Work, they do not trigger the
>> share-alike clauses of the ODbL. " is totally against section 4.6.
>
>
> +1
> the data contained in produced works remains ruled by ODbL / share alike, 
> this is stated in 4.3:
>
> 4.3 Notice for using output (Contents). Creating and Using a Produced Work 
> does not require the notice in Section 4.2. However, if you Publicly Use a 
> Produced Work, You must include a notice associated with the Produced Work 
> reasonably calculated to make any Person that uses, views, accesses, 
> interacts with, or is otherwise exposed to the Produced Work aware that 
> Content was obtained from the Database, Derivative Database, or the Database 
> as part of a Collective Database, and that it is available under this License.
>
>
> I agree it's hard to believe that geocoding would be considered creating a 
> produced work and not a derivative database (maybe we have a different idea 
> what one is doing when "geocoding").
>
> the definition for produced work is
> “Produced Work” – a work (such as an image, audiovisual material, text, or 
> sounds) resulting from using the whole or a Substantial part of the Contents 
> (via a search or other query) from this Database - See more at: 
> http://opendatacommons.org/licenses/odbl/1.0/#sthash.l1YXFGoW.dpuf
>
>
> some use of geocoding might lead to producing a "work" like an "image, 
> audiovisual material, text, or sounds" but the data  behind it remains ODbL 
> and if you reuse those locations obtained by geocoding you'd have to do it 
> under ODbL IMHO.
>
> Generally what I think about when reading "geocoding": you'd take a list of 
> addresses and use the database to localize (translate) them in geo 
> coordinates. This seems to fit perfectly to the derivative db description:
>
> “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. This 
> includes, but is not limited to, Extracting or Re-utilising the whole or a 
> Substantial part of the Contents in a new Database. - See more at: 
> http://opendatacommons.org/licenses/odbl/1.0/#sthash.l1YXFGoW.dpuf
>
>
> cheers,
> Martin
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk

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

[OSM-legal-talk] Updated geocoding community guideline proposal

[Alex Barth]

I just updated the Wiki with a proposed community guideline on geocoding.

In a nutshell: geocoding with OSM data yields Produced Work, share alike
does not apply to Produced Work, other ODbL stipulations such as
attribution do apply. The goal is to remove all uncertainties around
geocoding to help make OpenStreetMap truly useful for geocoding and to
drive important address and admin polygon contributions to OpenStreetMap.

This interpretation is based on what we hear from our lawyers at Mapbox. As
this is an interpretation of the ODbL, grey areas remain and therefore,
seeing this interpretation adopted as a Community Guideline by the OSMF
would be hugely helpful to create more certainty about the consensus around
geocoding with OpenStreetMap data.

Please review:
https://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline

Cheers -

Alex

[1]
https://lists.openstreetmap.org/pipermail/legal-talk/2013-June/007547.html
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-legal-talk] Improved OpenStreetMap Credits on Mapbox Maps

[Alex Barth]

Hello everyone -

We're updating attribution for OpenStreetMap-based Mapbox maps thanks to
feedback on attribution conventions on the diary and here on the mailing
list. The new convention on Mapbox maps is to expand attribution by
default: collapsed attribution should only be used when attribution becomes
unusually long, or screen space is limited. Expect us to roll out these
changes over the next couple of weeks, but check out my diary entry for a
preview right away:

http://www.openstreetmap.org/user/lxbarth/diary/21847
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[OSM-legal-talk] Attributing OpenStreetMap at Mapbox

[Alex Barth]

I just posted a writeup on my diary on how we're attributing OpenStreetMap
at Mapbox. Like many have said here it goes all back to driving potential
new mappers to the map:

http://www.openstreetmap.org/user/lxbarth/diary/21769

The recent discussion about attribution here on this list and on IRC made
me realize I should explain better how and why we attribute OpenStreetMap
the way we do. I hope I could give a comprehensive picture above. Looking
forward to feedback.

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

Re: [OSM-legal-talk] Attribution

[Alex Barth]

> Just a reminder, this thread started of with a discussion of
attribution, or rather lack of such

Doesn't help that the original post conflates the issues :p

On Tuesday, April 29, 2014, Simon Poole  wrote:

>
>
> Just a reminder, this thread started of with a discussion of
> attribution, or rather lack of such. I don't think there is very much
> doubt about what the licence requires even given all the complexity of
> the ODbL, for a produced work it is:
>
> "However, if you Publicly Use a Produced Work, You must include a notice
> associated with the Produced Work reasonably calculated to make any
> Person that uses, views, accesses, interacts with, or is otherwise
> exposed to the Produced Work aware that Content was obtained from the
> Database,"
>
> Our suggested attribution text is already very minimal. It is not clear
> to me what reasonable objections exist against simply attributing OSM as
> we require.
>
> Simon
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Attribution

[Alex Barth]

Steve,

Agreed on a transparent process for tracking unattributed applications of
OpenStreetMap.

Separate from attribution however, the issue with “share-alike” is that
it's not open, and hurting our community. ODbL's share alike is simply
shutting out OpenStreetMap from many use cases = adoption = incentives to
contribute. While share-alike was intended to foster this project's growth
it now is only putting limits on it. We can fix this. There are straight
forward ways to make a license modification to ensure that our community
can evolve with the best most open license.

It's simplistic to make broad analogies - this isn't Linux or Wikipedia:
OpenStreetMap is data, data is useful down to its smallest subsets and
unfolding the full power of data is to allow it to be combined and mashed
up in any way with other datasets. And for OpenStreetMap to be used as part
of everything and used by different communities it needs to be truly open
data. By being more open we will grow our community and only improve the
data quality.

And it is this data that is going to change the world. The world is
changing fast right now and the very fact that OpenStreetMap is available
in a structured format starts to be its biggest advantage. We can see this
in humanitarian applications every day. I'm saying this with the deepest
respect to all contributors here: What's to gain is OpenStreetMap in a lot
more applications than today. With share alike dropped, a huge hurdle for
using OpenStreetMap is just gone.

Alex

PS: My talk on this very issue at SOTM-US
http://stateofthemap.us/session/more-open/


On Mon, Apr 28, 2014 at 2:42 PM, Steve Coast  wrote:

> http://stevecoast.com/2014/04/28/attribution-is-it-time-to-name-and-shame/
>
> --
>
> OpenStreetMap  is the global, open and free map dataset
> that anyone can use. It is created by a huge community of volunteers who
> pour their time and energy in to the project. It’s also fun, beautiful and
> cool.
>
> So it’s sad that people don’t want to respect the license. It asks two
> very simple things:
>
>1. Please say you’re using OSM. This is very 
> simple
>.
>2. If you change the map, please give the changes back. This is called
>“share-alike”.
>
> Compared to paying a lot of money for incredibly license-restricted data,
> you’d think people would be ok with these requirements.
>
> Sadly, this isn’t the case.
>
> There are those who are now willfully disregarding our tiny little
> requirements. It’s being framed as some gigantic and unreasonable
> proposition, asking to say where the data came from or giving data back
> when you fix things. As if it’s completely bananas to ask such a thing. As
> if Linux or Wikipedia should be disaster ghost towns while asking for
> exactly the same thing of their users.
>
> This is just baloney. The real comparison should be; if you don’t like the
> license you’re free to use expensive and complicatedly-license data. That’s
> your option. Those guys are just a phone call away, and will be happy to
> sell you data. You’d probably find that they have very strong attribution
> requirements, just like OSM does.
>
> It is the ultimate disrespect to the volunteers who built the data to not
> even attribute their contributions. It’s even worse that there are some
> who’re trying to also own OSM for themselves by taking away the share-alike
> requirement.
>
> Is the license perfect? I’m afraid not. Specifically we need more
> clarification around the technical implementation and use of geocodes,
> especially in relation to other datasets. It’s hard today to technically
> comply with some of those edge cases.
>
> But that’s not what we’re talking about. We’re speaking here about the
> simple ask, that if you use OSM you please say clearly on the map that it
> is OSM. You’re getting a great dataset, for free, under an open license,
> that millions of people are contributing to. We’re not asking for $100,000
> license fees, we’re just asking that you say who we are.
>
> It’s the ultimate human need; I was here. I did this.
>
> How could you deny people that?
>
> Apparently, easily and willfully. People within the OSM community have
> been frustrated and trying to fix it for some time. If we were a
> proprietary map supplier we’d revoke a license or jump to legal options.
>
> We are much nicer than that. I propose a four stage plan, organized on
> OSM’s legal mailing 
> listand tracked on the 
> wiki:
>
>1. A polite email, linking to our requirements
>2. A week later: Another polite email, warning of what’s to come.
>3. A week later: Another polite email, same as above
>4. A week later: Very public naming and shaming on OSMs various social
>media channels and blogs
>
> Most people who miss our requirements are making a simple error. This is a
> process that gives three opportunities and an entire month to correct th

[OSM-legal-talk] Clarifying Geocoding and ODbL

[Alex Barth]

With two State of the Map conferences coming up now and plenty of
opportunities for face time, I'd like to restart our conversation around
clarifying the ODbL's implications for geocoding and get to a result. Over
here at MapBox we're hoping to use OpenStreetMap soon as much as possible
for geocoding (right now we don't) and we'd like to do this on firm legal
ground. I know that others have raised similar questions in the past [1].

To quickly recap: the ODbL is unclear on whether or not its share alike
stipulations extend to a dataset that is geocoded by a geocoder that is
powered by ODbL data. So, if I use Nominatim or MapQuest Open's geocoder
and geocode my vacation trip, schools in Kenya or BestBuy's store fronts,
would my vacation trip, schools in Kenya or BestBuy's store fronts need to
be licensed under the ODbL?

Over the past months, we've tried to get legal advice on this question.
This is difficult as the lack of existing case law makes it hard to get
official legal opinion on the document and the license is very complex. But
here is what we have heard back informally:

1. Geocoding can be interpreted as Produced Work per the defintion of
Produced Work in the ODbL [2].
2. The ODbL is too vague in the definition of its terms, requiring
additional clarifications by licensor. This is most importantly the case
around the terms "derivative database" and what constitutes a "substantial"
extraction of data [3].

This is the gist of two different opinions and obviously they are somewhat
conflicting. (2) is particularly an issue as the publicized guidelines [4]
do not include clarifications on Geocoding.

To start this process at a concrete point, I'd like to suggest to adopt to
following terminology as part of the Community Guidelines [4]:

> Geocoding

> Geocoding results in a Produced Work, as that term is defined in the
ODbL. Section 4.5 provides that a Produced Work is not subject to the
share-alike provisions of Section 4.4 of the ODbL.

This would broadly clarify that databases geocoded with OSM data would not
have to be licensed under ODbL, the share alike provisions would not apply.

>From a political standpoint, I think this is a key move for OpenStreetMap.
The project needs a strong incentive to build up its most lacking asset -
addressing. As long as it's not clear that addresses in OSM can actually be
used reasonably this incentive will be missing. That's particularly an
issue for businesses and organizations where buying whole sale into the
ODbL is just not an option because of strategic considerations but much
more often because of the complexity of ownership situations on typical
databases. Further, ODbL is not just incompatible with less open licenses
but also with more open licenses (e. g. public domain).

For the upcoming State of the Map US I'd like to invite attendees to a
Birds of a Feather round table to discuss these aspects. I'm particularly
interested in finding out how we can take a decision on this question and
update the community guideline accordingly over the next month to three
months. I (and others?) will be posting summaries of the discussion here.

Suggested date and time for the State of the Map US session: Saturday, June
8, 5PM Pacific - **look out for confirmation on the white board**.

Please also post your comments here on the thread.

Thank you,

Alex

[1]
https://help.openstreetmap.org/questions/14449/license-question-odbl-use-case

[2]

ODbL section 1.0

"Produced Work" – a work (such as an image, audiovisual material, text, or
sounds) resulting from using the whole or a Substantial part of the
Contents (via a search or other query) from this Database, a Derivative
Database, or this Database as part of a Collective Database.

http://opendatacommons.org/licenses/odbl/1.0/

[3]

“Substantial” – Means substantial in terms of quantity or quality or a
combination of both. The repeated and systematic Extraction or
Re-utilisation of insubstantial parts of the Contents may amount to the
Extraction or Re-utilisation of a Substantial part of the Contents.

http://opendatacommons.org/licenses/odbl/1.0/

[4]
http://wiki.openstreetmap.org/wiki/Open_Data_License/Community_Guidelines
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

Rob, I could only follow your line of argument if OSM was a project that is
trying to compete in the same market as a potential commercial player that
is marketing an OSM + proprietary data mix. As OSM isn't, it has a bigger
benefit from allowing liberal use.


On Fri, Mar 1, 2013 at 12:26 PM, Rob Myers  wrote:

> On Fri, 1 Mar 2013 11:51:18 -0500, Alex Barth wrote:
>
>> On Fri, Mar 1, 2013 at 11:44 AM, Rob Myers  wrote:
>>
>>
>>  despite the economic irrationality of this
>>>
>>
>> It _is_ economically rational to contribute to OSM even if there
>> wasn't a share alike license.
>>
>
> It's economically rational to keep costs down until VC funding is
> available.
>
>
>  This is the point of the matter and where we miss each other.
>>
>> It's economically more than rational to contribute to a
>> non-share-alike OSM (or other open source/data projects). On the flip
>> side share-alike introduces complexities that clearly disincentivize
>> contributing.
>>
>
> But as I stated, contributing is not the point.
>
> Using what is contributed is.
>
> Corporate moral panics don't change this.
>
>
> - Rob.
>
>
> __**_
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/legal-talk<http://lists.openstreetmap.org/listinfo/legal-talk>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

On Fri, Mar 1, 2013 at 11:44 AM, Rob Myers  wrote:

> despite the economic irrationality of this


It _is_ economically rational to contribute to OSM even if there wasn't a
share alike license.

This is the point of the matter and where we miss each other.

It's economically more than rational to contribute to a non-share-alike OSM
(or other open source/data projects). On the flip side share-alike
introduces complexities that clearly disincentivize contributing.
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

On Fri, Mar 1, 2013 at 12:16 AM, Paul Norman  wrote:

> The fact that you can’t mix OSM + proprietary data and then distribute it
> as some kind of “OSM but better” without releasing the proprietary data is
> a feature of share-alike licenses, not a bug.
>

Not every feature is a good feature, just like in software. There are
features that are just a bad idea. In this case, the share alike feature
protects us from something that just won't hurt OSM anyway, in fact it
would help OSM.

Someone goes mixes OSM with proprietary data, sells the result? Awesome!
This is exactly what's going on today with tiles, no? If the individual,
company or organization who sells improved OSM data does not give back into
the OSM ecosystem by creating better tools or contributing unencumbered
data, they're just plain dumb.

Open source or open data is not something you're forced to do, you're doing
it because you're smart.

There is further a false premise that most potential data users who have to
weigh opening non-OSM data they're mixing in somehow have a choice. They
more likely don't and hence we lose them as contributors entirely.

Specifically:

- they more likely just don't own the data they'd like to mix with OSM
- they more likely work in a bureaucratic organization where opening data
is just a multi year endeavour

What we wind up with is a well intentioned share alike clause that keeps
people away rather than help grow the open geo data space.

It comes down to this:

incentive to contribute by opening OSM data to any uses >> incentive to
contribute through retaining share-alike

The public domain argument is a bit of a red herring. If OSM used a PD-like
> license like PDDL or CC0 then we would be unable to make use of most of the
> external sources that we use, having to drop at a bare minimum 40% of the
> ways in the DB, and likely much more.
>

Interesting, can you expand on this a little more? Like for instance what's
a good example of a current external source or two effectively requiring us
to have a share-alike license?
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

On Wed, Feb 27, 2013 at 7:17 PM, Frederik Ramm  wrote:

> I think that the OSM community is already very open towards commercial use;


This is bigger than just commercial use. The ODbL is an obstacle to
contribute to OSM for anyone - business or not - who is bound by the
constraints of using third party data whose license they can't control or
for anyone who's bound by law to keep their data in the public domain.
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

On Wed, Feb 27, 2013 at 11:54 PM, Jake Wasserman wrote:

> 'It makes no difference whether you store the data sets separately, or
> together in the same "database" software, whether that is a RDBMS, NOSQL,
> filesystem or anything else. So long as the other data isn't derived from
> OSM, the result is a Collective Database, not a Derivative Database.'


This looks off.
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

Rob - as long as you don't mix ODbL data and other data in the same
database, ODbL's share alike cause doesn't kick in. So using the OSM tiles
on your web site doesn't mean that data in your web site is affected. I
recommend reading the ODbL, it's pretty clear that way
http://opendatacommons.org/licenses/odbl/

(And yes, I know, an open license shouldn't be that long and that
complicated, but that's another story).


On Wed, Feb 27, 2013 at 5:52 PM, Rob  wrote:

> >> It would appear that any and all data associated with a
> >> website or mobile app becomes fair game once OSM data is used.
>
> > What? No. No, that isn't true. I'm no fan of share-alike but that is
> > trivially disprovable.
>
> Where is the line in the sand?
>
> For example I have a website which is driven by several databases
> whichinclude everything from website members info t
>
> I then integrate OSM into the website by including interactive map tiles,
> address searches (geocoding), POI placement / inclusion, routing, etc...
>
> Sent from my iPhone
>
> On Feb 27, 2013, at 4:54 PM, Richard Fairhurst 
> wrote:
>
> > WhereAmI wrote:
> >> It would appear that any and all data associated with a
> >> website or mobile app becomes fair game once OSM
> >> data is used.
> >
> > What? No. No, that isn't true. I'm no fan of share-alike but that is
> > trivially disprovable.
> >
> > Richard
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://gis.19327.n5.nabble.com/OSM-legal-talk-License-question-user-clicking-on-map-tp5750253p5751314.html
> > Sent from the Legal Talk mailing list archive at Nabble.com.
> >
> > ___
> > legal-talk mailing list
> > legal-talk@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/legal-talk
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

On Fri, Feb 22, 2013 at 11:19 AM, Kate Chapman  wrote:

> My
> understanding is you are saying "I would like it to be this way," but
> at the moment it is not. Correct?
>

Actually to be more specific: I'm saying "I would like geocoding-like use
cases to be clarified, at the moment it is not clear. Here is what we
should do: specifically allow narrow extractions of OSM for geocoding-like
use cases to happen without the share-alike clause to kick in.". I'm also
going to add we should do away with share alike in the mid term. It's just
complicated and hurting OSM. Case in point: example at hand.
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

On Fri, Feb 22, 2013 at 11:19 AM, Kate Chapman  wrote:

> My
> understanding is you are saying "I would like it to be this way," but
> at the moment it is not. Correct?
>

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

Re: [OSM-legal-talk] License question, user clicking on map

[Alex Barth]

I think all of these use cases should be ok and we should adjust the
community guide lines to clarify that ODbL's share alike clause shouldn't
kick in here.


On Thu, Feb 21, 2013 at 6:16 PM, Olov McKie  wrote:

> Hello all!
>
> I have a few usecases for OSM where I do not know if I can use it or not.
>
> I work for a library where we are building a new version of an application
> to handle all sort of collections, for example books, letters, images,
> music sheets, etc. The application will store metadata and digitalized
> versions of the works. To know where an item was created, a letter sent
> from / to, etc we need to store places and information about them. The
> information we normally store about a place is name, alternative names,
> names translated to different languages, etc. A place might be a historic
> one that no longer exists.
>
> In the current system, metadata about a place is constructed by giving it
> a name, known variations of the name, which country it is in (problematic
> as it might change over the time) and translation of the name.
> As an OSM user and contributor my first reaction was, we can make the
> places more precise and avoid the changing countries problem by using
> coordinates for places, and also present them in a better way.
>
> As the applications data should be readable for a long time (forever),
> will we be storing all metadata together with the digitalized objects. We
> will over the lifetime of the application construct several thousand
> places. We will not be able to share the complete db under the ODbL as the
> works have all kinds of licenses that are incompatible with the ODbL. The
> resulting system will be accessible for anyone from the Internet,
> subsections might have restricted access.
>
> 1. If we present an OSM map to the user let them click on the map and use
> the coordinates they clicked on as part of the metadata for a place in our
> application, will the resulting database be considered a derived database?
>  To clarify, we would not extract any information from the map, beside the
> coordinates that the user clicked on, they would by themselves navigate the
> map to for example London and then click somewhere in London.
>
> 2. If we use the overpass API to find possible matches for a placename
> entered by a user, present the possible matches with markers on a map and
> let the user click on the map and use the coordinates the user clicks on,
> will the resulting database be considered a derived database?  Again, we
> would not extract any information from the map, beside the coordinates that
> the user clicked on. Presenting the markers would of course help the user
> find a place, such as London.
>
> 3. If we use the overpass API to find possible matches for a placename
> entered by a user, present the possible matches with markers on a map and
> if we have more then one result ask the user to fill in more details about
> the place such as, country, region, close to major city, local name, etc
> until overpass only returns on result, would the user entered data be
> considered a derived database? To clarify, in this case would we not
> extract the coordinates or any other data from the map.
>
> 4. If we present several places (all data about the place including
> coordinates originates from other sources than OSM) on an OSM map to help
> find duplicates, and then lets the user click on two places marked on the
> map, to merge them into one, would the resulting database be considered a
> derived database?
>
>
> I would love for us to use OSM in our application, but I have been unable
> to find out if we can use it for the four usecases presented above.
>
> with hope of a speedy answer
>
> /Olov
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] License Working Group 2013

[Alex Barth]

I love the outline you posted and the intention to clarify ODbL and promote 
open geo data more actively. I will get in touch to join the meeting.

Alex

On Jan 18, 2013, at 9:37 AM, Michael Collinson  wrote:

> The LWG will hold its first post-license change meeting provisionally Tuesday 
> 22nd January at 18:00 GMT/UTC.
> 
> I would like to draw your attention to the following:
> 
> We'll be discussing our future role and any input on that, preferably to this 
> list, is most welcome.  We've started putting together a remit document here:
> https://docs.google.com/document/d/1D3KwSM_BO7KkcbVADQVVn7eFwkD-RNauMwidhhlVPsI/pub
> 
> We welcome new members and diverse views. If you are interested in opening up 
> geospatial data and imagery for anyone to use, please join us.  You can 
> contact me at my email address if you want more details or you can join us 
> for one meeting to see if you like it.
> 
> If you cannot or do not want to join us long term but have a particular issue 
> that is important to you and it is in the best interests of OSM, we can make 
> it a project and you can join us for one meeting or a few weeks. In the UK, 
> example projects might be freeing up postcodes or public right of way route 
> definitions.  Do you have important issues in your country? Are you an 
> organisation that is finding OSM data difficult to use for legal reasons?
> 
> Mike
> 
> Michael Collinson
> Chair, License Working Group
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] Worry-some bill in Iceland

[Alex Barth]

Ugh. Like you're saying, this is clearly not a good "open" policy. Does Iceland 
or any involved politicians have ambitions to join the Open Government 
Partnership? This might be an angle.

Maybe worthwhile to put in an official notice by the OSMF that this law would 
hurt volunteer contributed geo data projects like OSM?

Also, Pakistan comes to mind: 
http://dawn.com/2012/11/21/pakistanis-lost-without-maps/

On Jan 17, 2013, at 12:46 PM, Svavar Kjarrval  wrote:

> Hi.
> 
> There is a bill (in the meaning of 'proposed law') in the Icelandic
> parliament regarding nature protection that worries me. The bill states
> that the National Land Survey of Iceland is supposed to create a
> database of roads and road tracks and it should be free (as in cost) and
> „available“ (nothing prevents terms being set for distribution). That's
> not what worries me since free (as in freedom) data is excellent.
> 
> It further states that all maps distributed in Iceland have to conform
> to the database mentioned above, or The Environment Agency of Iceland
> can invoke daily fines on whoever distributes a database that doesn't
> conform to this standard. This requirement is put on everybody, not just
> those who get a copy of said database. By definition, it's impossible to
> ensure that the OSM database conforms to this standard at all times
> since the database can always be freely downloaded and edited. It could
> also restrict people in Iceland that would like to legally distribute
> OSM maps and data since they'd have a hard time being sure that the
> requirement is fulfilled in their copy of the database.
> 
> The bill is under review by a parliamentary committee and I'd like to
> send it a review under my name. I would like some pointers of what I
> should mention in the review to convince them to drop that requirement.
> If you'd like, I could provide a rough translation of the corresponding
> article in the bill.
> 
> With regards,
> Svavar Kjarrval
> 
> _______
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] Combining NC Data with ODbL

[Alex Barth]

On Jan 16, 2013, at 6:03 AM, Simon Poole  wrote:

> 
> Am 15.01.2013 18:02, schrieb Alex Barth:
>> On Jan 14, 2013, at 5:30 AM, Simon Poole  wrote:
> 
> It would not be out of the question to add a specific "geo-coding"
> licence or terms to the canon of licences that the OSMF is allowed to
> distribute the data with, but as you realize that is a major undertaking
> and up to now nobody has stepped forward  and taken ownership of the issue.

This idea is looking interesting at first glance. And as to ownership over the 
issue: noted, I hope to be able to work on this at some point. Just flagging 
the issue as the discussion was coming up :)

> 
> Simon
> 
> 
> 
> 
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] Combining NC Data with ODbL

[Alex Barth]

On Jan 14, 2013, at 5:30 AM, Simon Poole  wrote:

> 
> Am 14.01.2013 08:36, schrieb Kate Chapman:
>> 2. I have a spreadsheet of hospital locations licensed CC-BY-NC, I use
>> OSM to geocode these locations. I believe this can't happen because of
>> the incompatibility of the two licenses.
>> 3. I export school locations from OSM and then append capacity of the
>> schools and other information to the exported data. I then release the
>> data CC BY-NC on my organizations website. Also can't happen because
>> of the incompatibility of licenses.
> 
> With both 2) and 3) if you remain within the bounds of an insubstantial
> extract
> (http://wiki.openstreetmap.org/wiki/Open_Data_License/Substantial_-_Guideline)
> your usage would be ok, even though as you correctly state both extracts
> would normally be considered derivative databases and would require
> release of the underlying data with the ODbL.

The insubstantial guidelines are way too strict (less than 100 features(!)). 
Not being able to geocode w/ OSM is hurting the project right now. We've 
discussed this issue earlier [1], I know next action is to gather examples of 
where OSM is currently not applicable in geocoding scenarios. This is one good 
example.

[1] http://lists.openstreetmap.org/pipermail/legal-talk/2012-October/007283.html

> 
> In both cases you are naturally free to simply produce such results on
> the fly. My reading of the ODbL would seem to indicate that if you for
> example geocoding on the fly you may not even have to provide an
> indication from where you results were derived.
> 
> Simon
> 
> 
> 
> 
> _______
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] [Talk-us] press from SOTM US

[Alex Barth]

And this is where SA gets really hairy. It's entirely possible and actually 
quite common that part of a database that contains private data is public. E. 
g. public facing web sites that are powered from a Salesforce DB through a 
private API. Again, we need real-world examples. Working on this.

On Oct 25, 2012, at 2:46 PM, Mikel Maron  wrote:

> > geocoding patient data, client data, suppliers data, members data
> 
> With this kind of sensitive private data, the database would not be 
> redistributed, hence not invoking share-alike.
>  
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
> From: Alex Barth 
> To: Licensing and other legal discussions.  
> Sent: Thursday, October 25, 2012 2:43 PM
> Subject: Re: [OSM-legal-talk] [Talk-us] press from SOTM US
> 
> +1 for examples. I'm working on pulling some together.
> 
> The like for like principle overlooks that data submitted to geocoders can be 
> sensitive for privacy or IP reasons. Think of geocoding patient data, client 
> data, suppliers data, members data in a scenario where a geocoder is only 
> used for a single client. Definitely a scenario where we as MapBox would be 
> able to offer an OSM based solution.
> 
> On Oct 25, 2012, at 2:04 PM, Frederik Ramm  wrote:
> 
> > Hi,
> > 
> > On 25.10.2012 17:30, Mikel Maron wrote:
> >> I don't see the issue with companies complying with like-for-like. There
> >> is some logistical burden, but that could be offloaded by geocoding
> >> services.
> > 
> > +1 - I think we're all (including LWG) still waiting for concrete use case 
> > where somebody says: This is how I want to use OSM for geocoding, this is 
> > what I believe the ODbL would mean for me, and this is why it is 
> > unacceptable for my business.
> > 
> > I don't know if it has already been said, but there is a *vast* amount of 
> > use cases where we need on-the-fly geocoding - user enters address and is 
> > zoomed to location - which are totally unproblematic as no derived database 
> > is even created.
> > 
> > In many other use cases I can think of, the ODbL's requirement may mean an 
> > inconvenience and may mean that users can't be just as secretive as they 
> > would like to be, but still sufficiently secretive as not to hurt their 
> > business.
> > 
> > I'm willing to hear concrete examples but I think that talk of "giving up" 
> > and "too much at stake" sound like OSM was unsuitable for geocoding which 
> > in my opinion it clearly isn't!
> > 
> > Bye
> > Frederik
> > 
> > -- 
> > Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> > 
> > ___
> > legal-talk mailing list
> > legal-talk@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/legal-talk
> 
> Alex Barth
> http://twitter.com/lxbarth
> tel (+1) 202 250 3633
> 
> 
> 
> 
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk
> 
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] [Talk-us] press from SOTM US

[Alex Barth]

On Oct 25, 2012, at 2:43 PM, Alex Barth  wrote:

> +1 for examples. I'm working on pulling some together.
> 
> The like for like principle overlooks that data submitted to geocoders can be 
> sensitive for privacy or IP reasons. Think of geocoding patient data, client 
> data, suppliers data, members data in a scenario where a geocoder is only 
> used for a single client. Definitely a scenario where we as MapBox would be 
> able to offer an OSM based solution.

The last sentence should be: "Definitely a scenario where we as MapBox would 
_love to_ be able to offer an OSM based solution."

> 
> On Oct 25, 2012, at 2:04 PM, Frederik Ramm  wrote:
> 
>> Hi,
>> 
>> On 25.10.2012 17:30, Mikel Maron wrote:
>>> I don't see the issue with companies complying with like-for-like. There
>>> is some logistical burden, but that could be offloaded by geocoding
>>> services.
>> 
>> +1 - I think we're all (including LWG) still waiting for concrete use case 
>> where somebody says: This is how I want to use OSM for geocoding, this is 
>> what I believe the ODbL would mean for me, and this is why it is 
>> unacceptable for my business.
>> 
>> I don't know if it has already been said, but there is a *vast* amount of 
>> use cases where we need on-the-fly geocoding - user enters address and is 
>> zoomed to location - which are totally unproblematic as no derived database 
>> is even created.
>> 
>> In many other use cases I can think of, the ODbL's requirement may mean an 
>> inconvenience and may mean that users can't be just as secretive as they 
>> would like to be, but still sufficiently secretive as not to hurt their 
>> business.
>> 
>> I'm willing to hear concrete examples but I think that talk of "giving up" 
>> and "too much at stake" sound like OSM was unsuitable for geocoding which in 
>> my opinion it clearly isn't!
>> 
>> Bye
>> Frederik
>> 
>> -- 
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>> 
>> ___
>> legal-talk mailing list
>> legal-talk@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/legal-talk
> 
> Alex Barth
> http://twitter.com/lxbarth
> tel (+1) 202 250 3633
> 
> 
> 
> 

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] [Talk-us] press from SOTM US

[Alex Barth]

+1 for examples. I'm working on pulling some together.

The like for like principle overlooks that data submitted to geocoders can be 
sensitive for privacy or IP reasons. Think of geocoding patient data, client 
data, suppliers data, members data in a scenario where a geocoder is only used 
for a single client. Definitely a scenario where we as MapBox would be able to 
offer an OSM based solution.

On Oct 25, 2012, at 2:04 PM, Frederik Ramm  wrote:

> Hi,
> 
> On 25.10.2012 17:30, Mikel Maron wrote:
>> I don't see the issue with companies complying with like-for-like. There
>> is some logistical burden, but that could be offloaded by geocoding
>> services.
> 
> +1 - I think we're all (including LWG) still waiting for concrete use case 
> where somebody says: This is how I want to use OSM for geocoding, this is 
> what I believe the ODbL would mean for me, and this is why it is unacceptable 
> for my business.
> 
> I don't know if it has already been said, but there is a *vast* amount of use 
> cases where we need on-the-fly geocoding - user enters address and is zoomed 
> to location - which are totally unproblematic as no derived database is even 
> created.
> 
> In many other use cases I can think of, the ODbL's requirement may mean an 
> inconvenience and may mean that users can't be just as secretive as they 
> would like to be, but still sufficiently secretive as not to hurt their 
> business.
> 
> I'm willing to hear concrete examples but I think that talk of "giving up" 
> and "too much at stake" sound like OSM was unsuitable for geocoding which in 
> my opinion it clearly isn't!
> 
> Bye
> Frederik
> 
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] [Talk-us] press from SOTM US

[Alex Barth]

I'd hate to see us give up here, there is too much at stake. The open questions 
around geocoding are doing OSM a disservice just as CC-BY-SA did. This is from 
a commercial community member's perspective just as an individual's, assuming 
we all want a better open map. Opening OSM to geocoding would be one of the 
main drivers for getting better boundary data and better addresses. Depending 
on your read of the license, right now OSM's terms on geocoding are potentially 
stricter than Google's or Navteq's.

I'd love to work with whoever is interested on wording a clarification 
statement and figuring out the process on how to decide on it.

On Oct 25, 2012, at 2:36 AM, Simon Poole  wrote:

> 
> I personally can't see enough wiggle room both in the ODbL and the CTs
> to make any dataset generated by geocoding and/or reverse geocoding
> anything else than a derivative database. It is just the ODbL working as
> intended. We went through a lot of effort to get from a broken to a
> functional licence that is appropriate for the subject matter and we
> shouldn't be unhappy with the fact that our licence now works (even
> though I like many others, would have preferred a more liberal licence).
> 
> We don't have any exact information on the position of the community,
> but I would suspect that we have substantial support for strong share a
> like provisions and that getting a 2/3 majority for relaxed terms would
> be big challenge (I would like to remind everybody that we lost a number
> of quite large mappers during the licence change process due to the ODbL
> being a sell out to commercial interests and not SA enough).
> 
> The only way out that I could see to avoid "infection" of propriety
> information is, along the lines of the suggestion by the LWG, to only
> geocode address information and use the address information as a key to
> look up such propriety information on the fly, the address DB itself
> being subject to ODbL terms. This however wouldn't help in the reverse
> geocoding use case (example: user clicks on a map to locate a bar and we
> return an address, the dataset of such addresses and any associated
> information would probably always be "tainted").
> 
> Simon
> 
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] [Talk-us] press from SOTM US

[Alex Barth]

On Oct 23, 2012, at 10:37 PM, andrzej zaborowski  wrote:
> 
> As has been noted in the Public Domain subset thread, the contributors
> can make license statement that they like, but the OSMF can still
> enforce the database rights.  So a statement by the contributors (e.g.
> on OSM wiki) that is not confirmed by the OSMF is not very helpful to
> the end user.

Right, there needs to be confirmation by the OSMF.

> 
> Cheers
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] [Talk-us] press from SOTM US

[Alex Barth]

On Oct 23, 2012, at 5:44 AM, Frederik Ramm  wrote:

> Hi,
> 
> On 10/23/12 01:24, Alex Barth wrote:
>> Say we clarified that geocoding a dataset with an OSM powered
>> geocoder (e. g. Nominatim) does not extend the ODbL license to such a
>> dataset. This clarification would not apply to the dataset that
>> actually powered the geo coder. So if I went and gathered improvement
>> suggestions of my users ("move the marker to the right position on
>> the map") and I added them into that OSM dataset that powers the
>> geocoder, this OSM dataset would still constitute a derivative DB.
> 
> That much is clear + agreed, but there will likely be a good business case 
> for gathering improvement suggestions from your users and *not* adding them 
> to the OSM dataset that powers the geocoder.
> 
> As I tried to say with the geocoder.ca example, even without actively 
> involving the user - just recording what they typed - you can collect 
> valuable information and improve your own geocoding database without 
> necessarily adding the results to OSM; your collecting that information, 
> however, can only start once you have a geocoder that basically works, i.e. 
> OSM. So, for your particular use, the OSM geocoding capability is clearly 
> essential - you could not start from nothing.

If I understand this case right, it wouldn't be governed by the ODbL at all 
either way, strict interpretation of substantial or not. If I record my user's 
corrections to my OSM powered geocoder's output and if I never add these 
corrections to my geocoder's OSM database, there wouldn't ever be a derivative 
database, hence the ODbL's share alike clause couldn't even begin to come into 
effect. As long as I don't combine datasets into the same database, I'm fine. 
In fact, there are such geocoders, for instance Carmen doesn't need to mix 
datasets in order to leverage them all for a single query 
https://github.com/mapbox/carmen.

Now, the story is different for the dataset I'm geocoding, of course the result 
of a say, OSM+PD powered geocoder would continue to have the grey area 
questions that I'd love to clear up...

> 
> It is *possible* that something is essential and insubstantial at the same 
> time, but it does sound a bit strange.
> 
> Another question that we could ask to enlighten us is: What do commercial 
> geocoding providers usually allow you to do once you have paid them? When you 
> geocode a dataset with TomTom data and you pay them for that, do TomTom then 
> still claim any rights about your resulting database, or do they say, like 
> you sketched above, that "their license does not extend to the geocoded 
> dataset"?

Interesting question. Not sure what the pricing is, but I'm sure you can get 
commercial datasets for geocoding with no strings attached. Right now you can't 
get a no-strings attached geocoding guarantee with OSM at all and that's what 
I'm worried about.

> 
> I think that nobody in OSM actually expects users to share their customer or 
> patient record just because it has been geocoded with OSM. But there is 
> likely an expectation that any data someone might have that can help to 
> *improve* geocoding should be shared back.
> 
> During the license change discussion, my position was often this: Instead of 
> trying to codify everything in watertight legalese, let's just make the data 
> PD and write a human-readable "moral contract" that lists things we *expect* 
> users to do, but don't *enforce*. - Maybe the same can be done with 
> geocoding; we could agree on making no legal request for opening up any 
> geodata, but at the same time make it very clear that we would consider it 
> shameful for someone to exploit this in order to build any kind of "improved 
> geocoding" without sharing back.

I would welcome such an approach. Not sure about the shaming part, I like 
encouragement better… In my life as an open source contributor I have never 
seen good contributions coming from enforced rules, but from inspired and 
driven community members - individuals, orgs, companies. Share alike has us 
have these mind breaking conversations :)

> 
> (In today's world, a press release that goes "The OSMF foundation regrets to 
> see company X violating OSM's moral code by doing Y" can be more powerful 
> than legal threats anyway.)
> 
>> In my mind there's much to be gained by giving
>> better incentives to contribute to OSM by clarifying the geocoding
>> situation and little to be lost by allowing narrow extracts of OSM.
> 
> The whole share-alike thing is about striking a balance between exposure 
> (surely a public domain release would give us maximum

Re: [OSM-legal-talk] [Talk-us] press from SOTM US

[Alex Barth]

Thanks for kicking over to legal list. Responses inline.

On Oct 22, 2012, at 6:34 PM, Frederik Ramm  wrote:

> Hi,
> 
> On 22.10.2012 22:12, Alex Barth wrote:
>> I do hope to come to an agreement within OSM along the lines you just
>> hashed out, Frederik (while not quite advocating for it):
> 
> This really ought to be discussed on legal-talk where there are many people 
> with a year-long involvement into the finer details of the license - 
> Cc+Followup there.
> 
>> Right now we largely don't have functioning municipal
>> boundaries in OSM. Obviously, any data that is mixed into OSM data
>> for _powering_ the geocoder would fall under share alike
>> stipulations.
> 
> I'm not sure about this "obviously".
> 
> I can imagine situations where someone collects geocoding queries and OSM's 
> answers and perhaps even records which of the results the user clicked on 
> afterwards, giving them a distinct advantage over other OSM users who don't 
> have all that extra data. IIRC, geocoder.ca has proven that they can build a 
> valuable geocoding database with such techniques. If we were to make a 
> blanket declaration that geocoding doesn't trigger share-alike, we'd give 
> that away, we'd allow people to build their own "improved upon OSM" geocoding 
> databases and sell them on. If we allow it, then it *will* happen, because 
> there's a commercial gain to be had.

I think a blanket declaration on geocoding isn't quite necessary. It's about 
clarifying what happens to the dataset that is being geocoded (a user database, 
a picture database, etc.).

Say we clarified that geocoding a dataset with an OSM powered geocoder (e. g. 
Nominatim) does not extend the ODbL license to such a dataset. This 
clarification would not apply to the dataset that actually powered the geo 
coder. So if I went and gathered improvement suggestions of my users ("move the 
marker to the right position on the map") and I added them into that OSM 
dataset that powers the geocoder, this OSM dataset would still constitute a 
derivative DB.

More below...

> We would even open the door to services where someone geocodes with OSM and 
> then says "wrong result? just move the marker to the right position on this 
> map", and keeps the corrections to himself, in a separate "corrections" 
> database.
> 
> I haven't thought this through enough to actually say which of the "unwanted 
> use cases" are indeed possible even with the current "substantial" guidelines 
> (http://wiki.openstreetmap.org/wiki/Open_Data_License/Substantial_-_Guideline)
>  and which additional "unwanted use cases" would be possible with a weakened 
> form of those.
> 
> We should perhaps not only make a list of "what people would like to do with 
> geocoding", but a second list of "what we don't want people to do" (things 
> like I sketched above - build improved database on top of OSM and market 
> that), then we can maybe check any guidelines we draft against these points.
> 
>> You bring up the important problem of properly bounding the geocoding
>> case. I'm thinking if all that can be extracted from OSM's database
>> are names and addresses for lat/lon pairs or lat/lon pairs for names
>> or addresses, it would be arguably impossible or at least
>> impractically hard to recreate a functioning street network from it
>> and the extracted data would be a narrow subset of OSM no matter how
>> many locations are being geocoded. Thoughts?
> 
> I'm not sure that "a functioning street network" is the bit that share-alike 
> intends to protect and the rest is not: This whole discussion arose from the 
> fact that there is heightened commercial interest in OSM-based geocoding - 
> that there even seem to be people who are not interested in a functioning 
> road network at all but who would be prepared to invest quite a bit of money 
> to "switch2osm" their geocoding. So it seems that maybe address data is as 
> valuable as the street network and should have the same level of protection?

Fair point. Still - I would ask what is the purpose of this protection and how 
does it benefit OSM on this particular level? OSM clearly benefits of being 
used. The usage of OSM data in maps has been clarified, I believe the ability 
to unencumberedly leverage OSM data to create produced works is a huge benefit 
for OpenStreetMap as a whole as it creates more versatile map styles, (and yes, 
abilities to monetize them) and in turn have more map users and thousands of 
micro incentives of improving our common map. Important similar incentives are 
routing or geo coding. The latter is wh

Re: [OSM-legal-talk] importing ODBl data

[Alex Barth]

Mike, I think we should come to a clearer recommendation, specifically with 
regards to share-alike data.

The highly infectuous character of share alike licenses severely restricts 
OSM's leeway of adjusting its license and we shouldn't paint ourselves into a 
corner this way.

Here are the simple rules I do recommend currently when talking to people and 
that I would love OSM to adopt officially.

Contribute only data that is:

- Yours
- Is public domain or merely requires attribution
- You have an explicit permission from owner for contribution to OSM for

BTW, I actually think there are only very few potential datasets that are in 
question here. I have doubts whether ODbL is actually compatible given OSMF's 
option to change the license to another open license in the future, and 
CC-BY-SA is clearly not compatible as it does not distinguish between derived 
and produced works.

On Sep 20, 2012, at 11:26 AM, Michael Collinson  wrote:

> On 20/09/2012 07:32, Mike Dupont wrote:
>> Hi there,
>> 
>> I have a question about imports and the ODBl,
>> 
>> I see that some sources have decided to dual license the data
>> http://wiki.openstreetmap.org/wiki/Import/Catalogue
>> 
>> But how can some third parties data be compatible when the CT says it
>> can change any time, surly they might be compatible with the current
>> instance of the license, but how can they be compatible with future
>> versions of the license when they are no known?
>> 
>> How can a contributor import any data and keep the data open to
>> license change? How can you keep any imports at all from people who
>> have not agreed to the CT directly?
>> 
>> thanks
>> mike
>>   
> This one has been covered pretty exhaustively previously.  To recap for all 
> interested:
> 
> () The CTs where written carefully to say, "If you contribute Contents, You 
> are indicating that, as far as You know, You have the right to authorize OSMF 
> to use and distribute those Contents under our current licence terms."  
> "current license terms", so ODbL 1.0.
> 
> () The future is the future, so cannot be known.
> 
> () Should the license terms change in the future, there is a possibility that 
> imported data may become incompatible. Therefore the original licensor needs 
> be contacted for approval. Given the general trend to more open data, after 
> what we are all about, that approval may well be given.
> 
> () Note also that, by design, a duty to provide first level attribution is 
> placed on the OSMF. This survives any potential license change and is general 
> the most important concern of government organisations.
> 
> () The is always the possibility that data may need to be removed and that is 
> one of the minuses of imports. That is why it is important to always 
> understand third-party licenses and to get general consent of any potentially 
> affected, usually national or regional level, OSM mapping community before 
> importing.  There is a healthy debate indirectly about this going on in the 
> general talk list.
> 
> Mike
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] importing ODBl data

[Alex Barth]

On Sep 20, 2012, at 3:13 AM, Stephan Knauss  wrote:

> On 20.09.2012 07:32, Mike Dupont wrote:
>> How can a contributor import any data and keep the data open to
>> license change? How can you keep any imports at all from people who
>> have not agreed to the CT directly?
> I agree with you in this point.
> 
> If we import donated data, it must be stated that OpenStreetmap can publish 
> the data under ODbL or any other license as specified in the CT.
> 
> Could we create a special version of the Contributor Terms for data 
> donations? So they could sign it. We could mail it to the OSMF to keep the 
> records.

I think that could be useful, especially if hosted on osmfoundation.org and 
with an attached list of who has signed. When trying to work with potential 
data owners I usually struggle to point to a clear procedure on how data is 
being passed on to OSM and I struggle with coming up with good examples of 
other institutions who have opened data to OSM with an explicit permission. I'd 
prefer something very short referring to the CT, essentially saying "X hereby 
grants express permission to contribute X data under the CT to OSM."

> 
> It is quite common to ask for contributor terms. For big imports a paper 
> contract might be better than a "click here to accept" contract.
> 
> See what others do, for example apache foundation:
> http://www.apache.org/licenses/icla.txt
> 
> Stephan
> 
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] importing ODBl data

[Alex Barth]

On Sep 20, 2012, at 1:32 AM, Mike Dupont  wrote:
> 
> How can a contributor import any data and keep the data open to
> license change? How can you keep any imports at all from people who
> have not agreed to the CT directly?
> 

IMO, you can really only be sure if:

- it's your data
- it's public domain-like data (e. g. at most it requires you to attribute)
- if you have the express permission of the data owner to contribute under CT

I explicitly think we need to clarify this section in the current CT and avoid 
having any data imported that cements the current licensing status for all 
times.

> thanks
> mike
> 
> -- 
> James Michael DuPont
> Member of Free Libre Open Source Software Kosova http://flossk.org
> Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com
> Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
> Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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

Re: [OSM-legal-talk] Interpretation of a Mexian license

[Alex Barth]

I agree the license is not permissive enough but I think we should wait with 
removing the data.

Last Thursday we had a meeting with Alejandro Cervantes, Subdirector de 
Vinculación con Sectores Estratégicos of INEGI, the Mexican national statistics 
institute who's data is in question here. The meeting was unrelated to this 
import.

INEGI's data policies are changing right now under the specter of the the Open 
Government Partnership, he has assured us verbally that as of recently, there's 
no problem in using their data for OpenStreetMap. This is of course not enough 
for starting to use INEGI data in OpenStreetMap, so I have followed up with him 
to get this statement in written form including a link to published terms of 
use or laws.

I hope to hear back from him this week. I will also try to get information 
through other channels.

Any pointers to the data that has been imported?

On Aug 11, 2012, at 2:11 PM, Paul Norman wrote:

> I recently came across an undocumented import where the source has a license
> in Spanish. Not speaking Spanish, I can't interpret this license but the
> Google translation raises some concerns with at least one of the terms.
> The license is located at
> http://www.inegi.org.mx/inegi/acercade/condiciones.aspx?=492
> 
> The term that I have concerns with is "Queda por tanto prohibida toda
> comercialización de este derecho de acceso"
>   
> Google translates this as "Is therefore prohibited any commercialization of
> this right of access"
> 
> This could either be a NC term which prohibits commercial use of the data or
> a term which prohibits commercial use of their server but does not affect
> derivative works of their data. If the first, the data must obviously be
> removed from OSM. If the second, it depends on the rest of the license.
> 
> Could a Spanish-speaker either provide some interpretation of the license,
> or a better translation?
> 
> 
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk

Alex Barth
http://twitter.com/lxbarth
tel (+1) 202 250 3633





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