Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-07 Thread Simon Poole


Am 06.05.2014 21:40, schrieb Rob Myers:
 On 05/05/14 09:16 AM, Simon Poole wrote:

 We have raised the question of Dynamic Data in a dedicated guideline
 given that a number of things are not so clear and even while, using the
 example from the guideline, the occupancy of a parking lot is an
 observable fact it is questionable if we would want to require that
 anybody that creates such or similar application has to provide a real
 time feed of the data on ODbL terms.
 
 If a loophole for this case is inserted, expect to see a sudden increase
 in realtime (and realtime) generation of data. ;-)
 

I hope we (as in the LWG) are not creating the impression that we are
trying to assemble as many loop holes as possible, it is more
identifying some of the edge cases and trying to document the community
consensus on the interpretation. In the case at hand we are simply
saying: here is a potential use case that is in a grey area, what do you
think?

In the case of the parking lot occupancy, dynamic data case: assume we
have a proprietary source for that data. The owner of the data will
already know which parking lot and where it is by some means, the
dataset would clearly have value on its own. One way to combine the
data in a useful way would be an app that routes you to the nearest
parking lot that still has space (underlying assumption is that the app
some kind of live feed of the occupancy data). Does this trigger SA?
Does it depend on the internals of the app? Does it depend on how the
match OSM parking lot id - proprietary parking lot id is done?

Simon



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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-07 Thread Jean-Marc Liotier

On 07/05/2014 08:20, Simon Poole wrote:

[..] Does it depend on how the match OSM parking
lot id - proprietary parking lot id is done ?


In this thread, we have seen a few mentions of the implementation as the 
ultimate factor in discriminating the resulting database between 
derivative and collective. Isn't that going to result in hypocritical 
implementations exploiting the letter of the license but not its spirit 
? Shouldn't the decision be taken by looking at the data itself and how 
it combines at a functional level ? For example, would asking whether 
the external dataset can stand on its own be a relevant question in 
clarifying a situation ?


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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-07 Thread Luis Villa
On Tue, May 6, 2014 at 11:20 PM, Simon Poole si...@poole.ch wrote:

 I hope we (as in the LWG) are not creating the impression that we are
 trying to assemble as many loop holes as possible, it is more
 identifying some of the edge cases and trying to document the community
 consensus on the interpretation. In the case at hand we are simply
 saying: here is a potential use case that is in a grey area, what do you
 think?


It is difficult to provide clarity and consistency/reliability without also
introducing loopholes. Richard Fontana (co-author of GPL v3) has written
about this issue in the software copyleft context here:
https://lists.fedorahosted.org/pipermail/copyleft-next/2013-April/000639.html

Richard's email may be useful reading for folks thinking about how OSM
should approach this very difficult problem. Short version: balancing
between clarity and loopholes is a well-known problem for lawyers
(sometimes called the rules/standards problem), and there is no good answer
when trying to write general-purpose legal documents, like laws,
constitutions, or copyleft licenses :) I would suggest that OSM is better
off creating some clarity (and thereby encouraging more contributions) and
risking some loopholes, since the people interested in the loopholes are
likely to not contribute back anyway. But that is a judgment call and there
is no 100% right answer.

Luis

-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

NOTICE: *This message may be confidential or legally privileged. If you
have received it by accident, please delete it and let us know about the
mistake. As an attorney for the Wikimedia Foundation, for legal/ethical
reasons I cannot give legal advice to, or serve as a lawyer for, community
members, volunteers, or staff members in their personal capacity.*
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-06 Thread Rob Myers
On 05/05/14 09:16 AM, Simon Poole wrote:
 
 We have raised the question of Dynamic Data in a dedicated guideline
 given that a number of things are not so clear and even while, using the
 example from the guideline, the occupancy of a parking lot is an
 observable fact it is questionable if we would want to require that
 anybody that creates such or similar application has to provide a real
 time feed of the data on ODbL terms.

If a loophole for this case is inserted, expect to see a sudden increase
in realtime (and realtime) generation of data. ;-)

If we change realtime to ephemeral, mapping data is ephemeral in
geological time. If we stick with Dynamic, well, SQL queries and views
are dynamic aren't they?

If I want to e.g. combine parking data with littering data for a study
or translate it into audio so I can consult it safely while driving,
access to the data is useful. This may not amount to a moral imperative,
but the debate is currently framed in terms of utility...

Deciding which data is and isn't useful (to users, not OSM) has two
problems:

1. It requires an Oracle. We cannot know which data is and isn't useful.
For example the locations of taxis in London may not seem all that
useful after the fact, but:
http://wiki.openstreetmap.org/w/index.php?title=Merchandiseoldid=1838

2. People will always push to avoid the license, and any exception will
be abused. That isn't a reason to not add an exception or clarification,
but it is a reason to be wary of pressure for them.

- Rob.


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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Simon Poole


Am 05.05.2014 06:38, schrieb Rob Myers:
..
 
 But the license doesn't exist to collect data for OSM.
 
..
True, but our immediate, admittedly egoistic, interest is that we are
free to use any improvements (in a wide sense of the word) to OSM data
and that derivatives of OSM remain free.

 It exists to ensure that all the users (or in the terms of the license,
 all its recipients if you Use it Publicly) of that data, in combination
 with whichever other data and in whatever form and wherever they
 encounter it, are free to use it.

The licence is substantially more restrictive in what it effects
(original OSM data and derivatives of it) than you are portraying it. In
particular it explicitly allows combination with other data without
effecting the legal status of such. IF the ODbL had the effect you
attribute to it, then we would really have a problem (and likely OSM
usage would go through the floor).

Simon



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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Martin Koppenhoefer
2014-05-05 14:05 GMT+02:00 Tobias Knerr o...@tobias-knerr.de:

  *And share-alike only applies to what we collect.*

 Let me first say that this is a brilliantly clear way to put it. I like
 this a lot.



I believe this is somehow more limiting than what we actually might want.
E.g. we don't collect traffic data, but if there was a company which used
our data as basemap and associated average speeds for time spans to our
graph (e.g. automatically from the analysis of their users / smartphones) I
think we would be interested to get this data to improve our routing.

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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Jean-Marc Liotier

On 05/05/2014 16:32, Martin Koppenhoefer wrote:


2014-05-05 14:05 GMT+02:00 Tobias Knerr o...@tobias-knerr.de 
mailto:o...@tobias-knerr.de:


 *And share-alike only applies to what we collect.*

Let me first say that this is a brilliantly clear way to put it. I
like
this a lot.


I believe this is somehow more limiting than what we actually might 
want. E.g. we don't collect traffic data, but if there was a company 
which used our data as basemap and associated average speeds for time 
spans to our graph (e.g. automatically from the analysis of their 
users / smartphones) I think we would be interested to get this data 
to improve our routing.


Usefulness to Openstreetmap is orthogonal to the ODBL.

That traffic data might relate to way identifiers, but it does not 
improve or even modify Openstreetmap data - so I fail to see how 
Openstreetmap might lay claim on a map showing traffic over 
Openstreetmap highways.


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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Frederik Ramm
Hi,

On 05.05.2014 16:39, Jean-Marc Liotier wrote:
 I believe this is somehow more limiting than what we actually might
 want. E.g. we don't collect traffic data, but if there was a company
 which used our data as basemap and associated average speeds for time
 spans to our graph (e.g. automatically from the analysis of their
 users / smartphones) I think we would be interested to get this data
 to improve our routing.
 
 Usefulness to Openstreetmap is orthogonal to the ODBL.
 
 That traffic data might relate to way identifiers, but it does not
 improve or even modify Openstreetmap data - so I fail to see how
 Openstreetmap might lay claim on a map showing traffic over
 Openstreetmap highways.

True but the use case sketched here went far beyond simply displaying an
overlay; this use case was about snapping speed recordings to OSM street
data to find out which street the recording was for in the first place,
thereby creating a derivative database.

Bye
Frederik

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

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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Jean-Marc Liotier

On 05/05/2014 16:47, Frederik Ramm wrote:
the use case sketched here went far beyond simply displaying an 
overlay; this use case was about snapping speed recordings to OSM 
street data to find out which street the recording was for in the 
first place, thereby creating a derivative database.


In data modeling terms, displaying a speed data overlay requires 
snapping speed recordings to OSM street data (giving ways a 'speed' 
attribute) - both operations are complementary, not alternative.


According to your message, a graphical rendering of Openstreetmap ways 
and traffic data mashed up in a browser by joining on an OSM ID implies 
a derivative database. If it is, then I understand how some may avoid 
using Openstreetmap data for fear of virality.


What the ODBL says:

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.2YNYZwRi.dpuf
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.2YNYZwRi.dpuf
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.2YNYZwRi.dpuf
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


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.2YNYZwRi.dpuf
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.


According to these definitions, because no alteration of Openstreetmap 
data takes place, adding a 'speed' attribute to Openstreetmap ways 
produces a Collective Database, not a Derivative Database. Therefore 
Share Alike does not apply.


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.2YNYZwRi.dpuf
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Jean-Marc Liotier

On 05/05/2014 17:26, Martin Koppenhoefer wrote:
no, this was not about overlaying 2 graphical layers but about joining 
the data into one layer (necessary I guess, in order to perform 
routing). [..]


Usage may be different, but the data is the same: ways with an 
hypothetical 'speed' attribute added to them in the persistent database 
of your choice. Whether you use that joined data to perform Dijkstra 
stunts or just render it graphically does not change its nature. In 
either case, no Openstreetmap data is altered in any way - only extended 
thus meeting the definition of a Collective Database.


To give a counter-example, if the speed data was used to guess 
maxspeed=* or change some of the highway=* classification according to 
detected speeds, then Openstreetmap data would be altered and there 
would be a Derivative Database.


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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Martin Koppenhoefer
2014-05-05 17:42 GMT+02:00 Jean-Marc Liotier j...@liotier.org:

 Usage may be different, but the data is the same: ways with an
 hypothetical 'speed' attribute added to them in the persistent database of
 your choice. Whether you use that joined data to perform Dijkstra stunts or
 just render it graphically does not change its nature. In either case, no
 Openstreetmap data is altered in any way - only extended thus meeting the
 definition of a Collective Database.




The requisite for a collective Database is that the parts are independent,
which they aren't I think when you add information to our graph. Maybe one
has to look into the details of an actual case in order to see whether the
dbs are independant or not. IMHO an extension of OSM data is already an
alteration.

If your point of view was correct, users would hardly ever have to comply
to share alike provisions.

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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Simon Poole


While I think the case of the traffic data is interesting, it really
very much depends on implementation details if and when a derivative DB
might be created.

For example if weights were calculated from the data and associated
directly with OSM ways then likely you would have a derivative DB, but
the question would still remain if the weights are actually useful
information. But if you used the coordinates of the  OSM way to do a
search in the traffic database and use that on the fly, you likely would
not have an issue. Definitely there are dozens of ways to skin this
particular cat.

And I would note again as I've pointed out before, my interpretation of
the ODbL is that only the data in derivative database is what is subject
to the ODbL not the original data source.

We have raised the question of Dynamic Data in a dedicated guideline
given that a number of things are not so clear and even while, using the
example from the guideline, the occupancy of a parking lot is an
observable fact it is questionable if we would want to require that
anybody that creates such or similar application has to provide a real
time feed of the data on ODbL terms.

Simon



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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-05 Thread Michal Palenik
On Mon, May 05, 2014 at 05:42:37PM +0200, Jean-Marc Liotier wrote:
 On 05/05/2014 17:26, Martin Koppenhoefer wrote:
 no, this was not about overlaying 2 graphical layers but about joining the
 data into one layer (necessary I guess, in order to perform routing). [..]
 
 Usage may be different, but the data is the same: ways with an hypothetical
 'speed' attribute added to them in the persistent database of your choice.
 Whether you use that joined data to perform Dijkstra stunts or just render
 it graphically does not change its nature. In either case, no Openstreetmap
 data is altered in any way - only extended thus meeting the definition of a
 Collective Database.

I cannot imagine any more wrong interpretation. ODbL was created just to
stop activities like this.

with your interpretation you could easily create a private fork: just
extend osm data with tags like
myproject:name/myproject:maxspeed/... ridiculous.

so, for the avoidance of doubt I wanted to say that is definitely
a derivative db (from information provided) and not a collective db.

michal


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

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


Re: [OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-04 Thread Rob Myers
On 03/05/14 08:51 AM, Michael Collinson wrote:
 
 Geocoding: So I have to share a patient's medical record because it is
 geocoded against OSM?

Who with?

 Dynamic Data: So if I use OpenStreetMap car park location data, I have
 to share the real-time occupancy data?

Who with?

 Algorithmic transformations: So I thought of this clever idea to
 pre-format OSM data for fast loading into my game. Now I have to share
 my that or my algorithm?

Who with?

 General maps: I want to use OSM to show locations of restaurants on my
 restaurant review site. Now I have to share the reviews?

Who with?

 *And share-alike only applies to what we collect.*

But the license doesn't exist to collect data for OSM.

It exists to ensure that all the users (or in the terms of the license,
all its recipients if you Use it Publicly) of that data, in combination
with whichever other data and in whatever form and wherever they
encounter it, are free to use it.

If that leads to patients having better access to their medical data,
people being able to find somewhere to park, players of games being able
to maintain and modify them creatively to build communities around them
and drive sales, and people being able to check the actual rankings of
the restaurants they're being directed to that's definitely a win for
Open Data.

- Rob.


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


[OSM-legal-talk] The edges of share-alike on data Re: Attribution

2014-05-03 Thread Michael Collinson
I've renamed the subject because it has gone way off topic, but I wanted 
to come back on Tobias' comment because it struck a chord and I would 
like to share a personal research topic. I am curious to evolve the idea 
further to see if there is any positive value.


Open data is a different animal to software source code and 
highly-creative works and I suspect it will a few more years yet until 
we understand it all fully.


I personally see this unwanted data  is an underlying theme under many 
of the issues the LWG has been looking at under the Community Guidelines 
process :-


Geocoding: So I have to share a patient's medical record because it is 
geocoded against OSM?


Dynamic Data: So if I use OpenStreetMap car park location data, I have 
to share the real-time occupancy data?


Algorithmic transformations: So I thought of this clever idea to 
pre-format OSM data for fast loading into my game. Now I have to share 
my that or my algorithm?


General maps: I want to use OSM to show locations of restaurants on my 
restaurant review site. Now I have to share the reviews?


And so on.   Now many of these issues may be resolved, and in some case 
have been resolved, in other ways which remain within the scope of the 
current ODbL version. But a very simple way of dealing with everything 
in one go is to say:


*The OpenStreetMap project collects long-lived geospatial data as a set 
of intelligently or machine-made physical observations only.* [Wording 
needs improving!]


And then to say:

*And share-alike only applies to what we collect.*

Again, it just a research topic. I see it as benefiting the 
OpenStreetMap project enormously but at the same time potentially 
debasing the whole concept of share-alike for the wider open data 
community ... perhaps those restaurant reviews should be shared?


Mike



On 30/04/2014 23:35, Tobias Knerr wrote:

On 30.04.2014 19:37, Rob Myers wrote:

On 30/04/14 03:18 AM, Tobias Knerr wrote:

But we have to judge a license based on its actual effects, not the
original intention. What annoys me, for example, is when we require
people to publish data that we wouldn't even want if they offered it.

The users of the data may want it. The license exists to benefit them,
not (just) OSM.

If the actual effects worked against this then yes there would be a problem.

I think there is quite a bit of data that will, with high likelihood,
never be of use to anyone. That's especially true for byproducts of the
creation of a produced work.

But your argument about also shows that there are mappers who ask for a
lot more than just giving data back when you fix things. Thus it would
be foolish for a data consumer to assume they only have to follow that
spirit, as much as I wish that was enough.

___
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] The edges of share-alike on data Re: Attribution

2014-05-03 Thread Richard Weait
On Sat, May 3, 2014 at 11:51 AM, Michael Collinson m...@ayeltd.biz wrote:

 Open data is a different animal to software source code and highly-creative
 works and I suspect it will [be] a few more years yet until we understand it 
 all
 fully.

Sure.  Of course, we are part of why it is a big deal now, and we are
also part of why it is still evolving.  It should be no surprise that
Old Model Entities have a hard time keeping up with us.  :-)

[ ... ]

 Again, it just a research topic. I see it as benefiting the OpenStreetMap
 project enormously but at the same time potentially debasing the whole
 concept of share-alike for the wider open data community ... perhaps those
 restaurant reviews should be shared?

One benefit of the community guidelines, and the recognition of them
by ODC-ODbL[1] is that they apply to our community, and not to another
Open Data project community unless they deliberately adopt them.

Another benefit is that the community guidelines are trivially easy
for the OpenStreetMap community to amend and adapt compared to waiting
for an updated version of ODbL.  That gives us the ability to revise
the wording of the community guidelines should that be required to
adapt to our changing world.  That's not a hypothetical situation;
we're changing it.

Super to have your thoughts on this Mike.

[1] http://opendatacommons.org/faq/licenses/#What_is_8216Substantial8217

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