Re: [OSM-talk] Let's talk Attribution

[Tom Lee via talk]

At the risk of repeating others' words, I strongly encourage participants
in this conversation to review the draft attribution guideline (
https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline) and
previous conversations regarding attribution on this list. It would be hard
to overstate the depth of experience that the legal working group has
regarding these issues, so it has been surprising to me to see their
perspective receive so little attention.

Because I know not everyone will dig back into those listserv archives, I
want to highlight one point that has been previously made: OpenStreetMap
itself does not meet the ODbL attribution standards that are being
presented as obvious by some parties to this conversation. This applies not
only to several ODbL data source attributions present on
https://wiki.openstreetmap.org/wiki/Contributors (but not on the map) but
also to the many ODbL data sources that can be found under
https://wiki.openstreetmap.org/wiki/Category:Data_sources (note that not
all of these sources may be in use; this part of the wiki is not
sufficiently organized to be sure).

OpenStreetMap is by far the most significant project using ODbL, and when
geodata is published under ODbL terms (as frequently happens in France[1])
or when it is adopted by a geodata project (such as Datameet's work on
Indian village boundaries[2]
) it is typically
with the intent of making the data useful to OpenStreetMap. It doesn't seem
plausible that the volunteers working on those Indian village boundaries
expect their preferred attribution[3] to be part of the UI that greets any
OSM user. This suggests to me that volunteers' attribution expectations are
not as uniform as has been suggested in this thread.

Reviewing the diversity of attribution policies found under
https://wiki.openstreetmap.org/wiki/Category:Data_sources might prove more
illuminating than rehashing our understanding of Google's terms and what
they might or might not do for enterprise customers. A review of the many
custom government licenses and amended CC-BY licenses that OSM volunteers
have added to those wiki pages will show a variety of approaches to
attribution, almost none of which meet the level of obtrusiveness proposed
at various times in this thread. Obviously, the ODbL is its own beast; as
others have noted, the practices of the rest of the open mapping world and
commercial mapping industry need not bind it. But I do think they are a
useful signal as we consider what "reasonable" could mean.

[1]
https://wiki.openstreetmap.org/wiki/FR:Sources_de_donn%C3%A9es_potentielles/France
[2] http://projects.datameet.org/indian_village_boundaries/
[3] "Villages Maps Provided by Indian Village Boundaries Project [
http://projects.datameet.org/indian_village_boundaries/] by Data{Meet}. Its
made available under the Open Database License (ODbL)[
http://opendatacommons.org/licenses/odbl/];
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-legal-talk] Adding OSM-ids to an external database and publish in CC-BY

[Tom Lee via legal-talk]

This seems similar to the problem discussed here:
https://wiki.openstreetmap.org/wiki/Open_Data_License/Metadata_Layers_-_Guideline

The doctrine proposed by Richard Fairhurst (and discussed on that page)
strikes me as reasonable. It's hard for me to see how OSM IDs could qualify
as a substantial part of the database when used in isolation, in this
manner. They're algorithmically generated and, by themselves, contain no
information about the world that OSM describes.

In a broader sense, it seems like it would be very counterproductive for an
open project to embrace policies that make it difficult for people to even
*refer* to useful parts of it, which is what a hyperlink amounts to.

On Tue, Mar 31, 2020 at 1:57 PM Martin Koppenhoefer 
wrote:

> In Italy we have been discussing this situation: a member of the community
> wants to add links to OSM objects into a list of specific shops (those that
> are open during the covid-19 pandemia).
>
> The list will be published here: https://www.covid19italia.help/opendata/
> with an CC-BY-4.0 license.
>
> The links will be of the kind
> https://www.openstreetmap.org/relation/1834818
>
> Question is, will it be possible to publish such a list, containing
> OSM-ids (or links to OSM objects) with a CC-BY-4.0 license?
>
> Thank you for your replies.
>
> 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

Re: [OSM-legal-talk] use OSM data to select proprietary data

[Tom Lee via legal-talk]

> I was aware of this and just wanted to get a consensus by the data
creators: the users.

This is an admirable impulse, but it is worth emphasizing that those of us
who participate on OSM listservs are a small and unrepresentative fraction
of the project's 5.9 million registered users. Lists like this one are a
great way to find the slice of users who are most interested and passionate
about a particular issue, and who consequently can be expected to have
well-informed (and often strongly held) opinions that reflect the gamut of
possible answers.

But if you are seeking consensus, the closest thing available is the text
of the license itself and guidelines that have been approved by elected
members of the OSMF board. Usually when there is broad agreement on an
issue, the answer is memorialized in a wiki page that people find before
they wind up here :-)
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Licensing question

[Tom Lee via legal-talk]

> if the way you use the data is more in a database-like fashion or more in
the form of a finished product ready for human consumption

This raises more questions, doesn't it? I think everyone agrees that a map
contained by a PNG file is a produced work. But such a file is merely a
collection of pixels that may be programmatically queried or rendered for
human consumption by purpose-built software. If you replace "pixels" with
"triangles", the exact same thing can be said of the 3D objects being
rendered here for use by the Flight Gear simulator.

The official guideline on this question can be found here:
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline
--
here is the relevant portion:

> The published result of your project is either a Produced Worked or a
Derivative Database within the meaning of the ODbL. If the published result
of your project is intended for the extraction of the original data, then
it is a database and not a Produced Work. Otherwise it is a Produced Work.
However, if you publish a produced work, the underlying database has to be
published as well (or alternations to the original database as is the case
of derived databases), according to section 4.6 of ODbL.

In this case it does not seem as though the intended use of generated files
is extraction of the original data, so I'm inclined to agree with those
arguing that this sounds like a produced work.



On Fri, Aug 2, 2019 at 1:34 PM Christoph Hormann 
wrote:

>
> To avoid you drawing the wrong conclusions based on the (rather
> abstract) explanations made by others - based on a quick look at the
> documentation on
>
> http://wiki.flightgear.org/Osm2city.py
> https://osm2city.readthedocs.io/en/latest/
>
> that tool seems mainly a geometry data conversion program for OSM data -
> not unlike tools used routinely for cartographic applications like
> osm2pgsql etc.  The output of this tool is in most cases likely a
> derivative database or a collective database depending on how much
> intermingling of OSM data with other data is happening.  If for example
> extruded building geometries based on OSM polygons are textured with
> texture images from other sources that is quite clearly a collective
> database.  If you generate guessed building geometries based on non-OSM
> landuse data as explained on:
>
>
> https://osm2city.readthedocs.io/en/latest/how_it_works.html#chapter-howto-generate-would-be-buildings-label
>
> (which is an interesting feature by the way) and combine this with OSM
> based buildings that would be a derivative database.
>
> For distinguishing between a produced work and a derivative database a
> useful approach is to see if the way you use the data is more in a
> database-like fashion or more in the form of a finished product ready
> for human consumption.  The scene geometry for a 3d rendering is quite
> clearly more database-like in its use.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] OSM for training ML machines

[Tom Lee via legal-talk]

I'll defer to others on the finer points of how downstream or intermediate
ML products fit into the licensing picture, but this did catch my eye:

> If you need an example:  Take a translator for geographic names trained
> using OSM data.  This translator in practical use will spit out names
> or name components identical to those from the OSM database (if it does
> not it'd be pretty useless).  These names - in sufficient volume -
> evidently form a derivative database IMO - even if they are not the
> result of a literal copy but result from 'knowledge' encoded in a
> neural network.

I have sometimes sene similar arguments about intellectual property brought
up in engineering-focused conversations, which propose elaborate technical
mechanisms by which data might be transformed, then recreated, and in the
process its intellectual property rights somehow purged. There are already
several community guidelines explaining why this isn't acceptable. Beyond
that, my own sense is that this is at odds with how the legal system
approaches these questions (and confusion about what "transformative use"
means). If a party has custody of proprietary data, feeds it through a
black box that a judge and jury don't really understand, and the original
data comes out the other side--well, you can see why it's a hard argument
to win.

I think the risk of recreating OSM data via ML trickery is pretty low: it's
an elaborate approach that offer dubious legal advantages. If the question
is whether OSM could claim rights over a fictional but plausible map-like
output from an OSM-trained ML model, I'd say the question is more open. But
I suspect this is a less worrisome scenario for most.

On Wed, Apr 10, 2019 at 10:12 AM Christoph Hormann 
wrote:

> On Wednesday 10 April 2019, althio wrote:
> >
> > You may have skipped parts of my message, so excuse me if I repeat a
> > few lines. You quoted only two sentences and I slightly wonder if you
> > genuinely read the whole.
>
> I am sorry if i left the impression that i was specifically criticizing
> your ideas - i was more referring to the general course of the
> discussion towards a rather mechanical exegesis of the ODbL based on a
> simplistic view of how algorithms work as a mechanical process
> converting well defined input data into well defined output data.
>
> > [...]
> > I don't think my original message can be read as "sweepingly declare
> > any output of algorithms as having no copyright connection".
>
> I did not mean to imply that - but since your line of reasoning only
> covers this case it is to be expected that people assume this is the
> only relevant case.
>
> > [...]
> >
> > My final two cents:
> > Take the Geocoding guideline, replace "Geocoding" by "Machine
> > Learning" and this is, in my humble opinion, an acceptable first
> > draft for discussion.
>
> But as far as i understand you, you up-front want to declare
> the "database" behind the Machine Learning, i.e. the adaptive part of
> the algorithms that gets modified through training, to be a produced
> work and therefore not subject to share-alike.
>
> If not i don't see the practical usefulness in applying the geocoding
> guideline to this in analogy because while for geocoding the individual
> result is a frequent practical use case Machine Learning and similar
> algorithms are mostly used to produce bulk results which are usually
> substantial in terms of database law.
>
> As far as the Horizontal Layers guideline and the concept of produced
> works in general is concerned - the only consistent view of these
> concepts is IMO to consider them to be limited exclusively to cases
> when you are talking about things produced for and used only for direct
> human consumption.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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: [Talk-us] State Open Data (Brian May)

[Tom Lee]

> If a billionaire is reading this list and wants to put their money
> towards doing a lot of public good and good for the economy in general
> (data is the new oil), they could make the sky rain lawyers!

I share your enthusiasm for billionaires with idiosyncratic obsessions (who
doesn't like Batman?) and think this would be a great project.

But let me also add that there's a lot of work we non-billionaires (and
even non-lawyers) can do to make this scenario more likely. Going through
the tedious process of FOIAing, appealing the denial, then FOIAing for the
emails about the process, then publishing everything in a blog post --
these steps set the stage for a larger action (if appropriate) and
typically have to be done first. Actual practitioners are the ones in the
best position to know what data is needed and where the rationale for
keeping it locked up is most absurd. Not every one of these efforts will
end in success, but it's a necessary start.

I'll add that folks who do undertake such an effort might want to check out
MuckRock, which is a great resource for submitting and sharing FOIAs. And
of course Carl Malamud's work at public.resource.org is an inspiration on
this front, though I suspect he's so much on his plate that it might be
hard to get him interested in geodata.

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Tom Lee]

I'm surprised to see that this conversation has made it past the weekend.
Since it has, let me add my voice to those suggesting that encoding OLC in
the database (or any other values that can be algorithmically derived from
geometry) makes very little sense. I'm grateful to everyone who has already
made this point, in various ways and with various levels of forcefulness.

If the folks advocating for OLC would like to walk through the rationale
some more or explore alternative ways of getting OLC into their workflow, I
suspect that a number of people on this thread would be happy to talk
through it, myself included. Please don't hesitate to email.

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

[Talk-us] keeping the National Agricultural Imagery Program (NAIP) dataset open

[Tom Lee]

The NAIP dataset

is valuable for mapping in the continental US, so I suspect there are more
than a few people on this list who share my alarm at the leaked proposal to
move it to a licensed model. My colleague Charlie just wrote about this on
the Mapbox blog:

https://blog.mapbox.com/keeping-naip-free-open-cf9ad9d310be

If you're a NAIP user, please consider writing about why the dataset is
important to you and why it should remain open. Now is the time to make the
case for keeping this resource available to all. Public statements are the
best way to spread the word about this, but if you'd prefer to stay
private, I'm happy to collect testimonials by email and make sure they get
to the right people in government.

If you're interested in staying up to date with how this advocacy effort is
proceeding, there's also a low-volume listserv you can join:
https://groups.google.com/forum/#!forum/save-the-naip

Thanks!
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Tom Lee]

Like many conversations about Wikidata tagging, I think this one suffers
from varying levels of stringency -- and perhaps letting the perfect become
the enemy of the good.

At the risk of stating the obvious, it is often the case that Wikidata's
conceptual model of places does not exactly match OpenStreetMap's more
precise spatial model of them: for example, the formal administrative
boundaries of a town versus its popular conception; or the historical sense
of a place versus its current boundaries. This is not always true, and when
it is possible to match the conceptual models precisely, that is of course
what should be done (including making Wikidata's model more precise).

I think it is a mistake to say that a critique based on these kinds of
imprecision necessarily constitutes a good reason for removing the tag. It
is often the case that the slightly-mismatched entity is still tremendously
useful. First and foremost, in the vast majority of cases the multilingual
Wikidata labels on the associated entity will still be correct even when
there is a conceptual mismatch. This is a particularly vital function given
the OSM community's occasional insistence that mechanical transliterations
are a trivial problem.

This sort of utility exists with other Wikidata properties as well. And the
relationship can be revised to a more precise form as users' needs arise.
By way of analogy: a forest area tagged as `natural=wood` can be a useful
part of the map even if it contains clearings or meadows. It would be
counterproductive to revert features mapped as such rather than focusing on
their improvement as user needs demand it.

My 0.02. FWIW, we are using Wikidata matched entities extensively in
production (albeit matched to data sources other than OSM). As you might
imagine, these kinds of mismatch problems are unavoidable for us, too. But
the presence of the Wikidata relationship is of truly incredible value, and
often delivers substantial utility even when the match is imperfect.

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

Re: [OSM-legal-talk] What types of sources can be listed that are OK to use for OSM?

[Tom Lee]

James, I think your list of "definitely OK" sources is a good one.

The rest of your list does a good job of reflecting how complex geodata
rights can be. In most cases, OSM elects to use a conservative
interpretation of the situation in order to avoid any possible danger to
the project.

I will mention, though, that facts are not copyrightable. I think it is
vanishingly unlikely that something like a single business's operating
hours could pose a problem, unless you had personally entered into an
unusual contract regarding how you collect and use that information. Any
information you personally observe and record during a walk is probably
going to be okay -- even in circumstances where trademark or other
protections apply to a business name, that will not constitute a
prohibition on recording it as a fact about the world.

When you start using large collections of information assembled by third
parties -- especially if it undercuts their business -- things get more
complicated.

On Sun, Jul 24, 2016 at 4:48 PM, James McCloud 
wrote:

> There is documentation that hits on this but I am looking for more
> clarification and any additional sources.
>
> Here are my own conclusions:
>
> Definitely OK to use(whiter than white):
>
> From the beginners guide(
> http://wiki.openstreetmap.org/wiki/Beginners_Guide_1.1):
>   * Your own GPS traces(without data you entered while looking at your
> navigation source).
>   * Sources already in the editors(not additional ones you add).
> From the legal faq(
> http://wiki.openstreetmap.org/wiki/Legal_FAQ#2._Contributing):
>   * Anything licensed Public Domain(PD).
>   * out-of-copyright(check country specific laws) with compatible terms of
> use. Question here, isn't terms of use part of a copyright and thus expires
> with copyright?
>   * Anything where permission is obtained(leaving out procedures here).
>   * Other possible compatible copyrights when confirmed with the OSM
> community.
> From some posts/threads and license compatibility:
> http://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>   * Anything licensed Creative Commons Zero(CC0).
>
> Generally OK to use(if there is any doubt, don't use it): The community
> seems to accept some of these even though copyright is possible. Perhaps
> 'doubt' should be applied to a slight chance(1 in 1000?) that a source's
> owner would not be OK with the use for OSM.
>
> * Anything to which copyright law does not protect, both from your
> source's country AND OSM's country(UK).
>   What is unprotected? Examples might be names, titles, phrases, and
> slogans, but they cannot be used in OSM if obtained from within a
> copyrighted collection/database.
>   Knowledge may come from copyrighted sources, so under what conditions
> does it become unprotected(or usable in OSM)?
>   * Knowledge: Any information directly from memory in which the true
> source cannot be recalled.
>   * Information may also be obtained from asking other people(friends,
> family, even complete strangers) for their knowledge.
> If there is an indication that the knowledge came from a copyrighted
> source then don't us it.
> Don't do anything with the intent of getting around copyright, e.g.,
> don't ask a friend to look something up for you(not knowing their source)
> so you can use it for OSM.
>
> What data obtained from a survey/walk/journey can be used?
>   * Layout(as seen directly, not from a document) of roads, buildings,
> walls, land, water.
>   * Signs: Traffic, road, access, places(name and service provided), guide
> posts:
> Note: Signs that are 'likely' owned by your 'national' government are
> 'likely' public domain. This is less likely for state and local, and most
> definitely not for private ownership.
>   Road signs are very likely public domain and are often not creative
> enough to be protected.
>   Names of places(shops, businesses, etc.), either since the owners
> don't care or welcome the advertisement. However, complaints could be made
> and I can think of some reasons.
>   Contact Information(address, email, phone) when you physically see
> it(or from a photo you took of it) at the location. It should also appear
> to be intended for public use.
>   Posted business hours are likely OK if by themselves.
>   Signs that contain more information(documents) or
> originality/creativity are much more likely to be copyrighted and
> considered unacceptable for use in OSM(without proper license/permission).
> Some examples: - Any kind of map(even on a permanent outdoor
> display like at a historic site, or city bus route map)
>   - Things posted on a tourist
> information board
>   - a Text description of foot/bike
> routes with path names and access restrictions
>
> * Information on a business card or receipt.
> * Contact information for a business on it's website. It should be easy to
> access, and 

Re: [OSM-legal-talk] FYI Collective Database Guideline

[Tom Lee]

> This is a desirable goal but don't forget there is another side to
> that - if i as an entrepreneur consider contributing to the OSM
> database it could be important for me that my contributions cannot be
> used by the competition against my interests.  Share-alike might play a
> significant role in such consideration.  So having pro-share-alike safe
> harbour statements might be equally important.

Protecting commercial interests by limiting reuse is generally not a goal
of open licenses*. If someone owns proprietary data and wants to extract
rents from it, they probably shouldn't contribute it to an open data
project like OSM.

* obviously there are exceptions -- CC-BY-NC exists, though it's
little-loved both in terms of adoption and its creating organization -- but
I think it would be a stretch to say the ODbL was designed for this purpose
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] licenses suitable for import

[Tom Lee]

Tobias, the best option for ensuring the data is usable by OSM is an
explicit statement of permission for the OpenStreetMap project to
incorporate and use the data under the project's terms. This is generally
considered preferable to a dataset that is ODbL-licensed without such a
statement.

However, I would encourage you to consider non-OSM users as well when
choosing the license. ODbL is not widely used outside of OSM. A license
like CC-BY 4.0 is more widely used and actively maintained. Choosing it
would ensure compatibility with a large number of non-OSM datasets. And if
paired with a permission statement like what's described above, OSM could
still use the data without any license compatibility worries.

Of course, if you can do without attribution, you might consider something
even more simple that disclaims liability but imposes no other terms. If
that's an option let me know and I can turn up some examples.

On Thu, Mar 17, 2016 at 5:43 PM, Erik Johansson  wrote:

> On Sun, Mar 13, 2016 at 8:27 PM, Tobias Wendorff
>  wrote:
> > Dear list,
> >
> > could you please recommend me licenses for releasing data to ODbL?
> > From my point of view, compatible licenses are CC-license without
> > "SA" and "BY" and (only if possible) CC0 and PD or finally special
> > license, like the following one:
> >
> > Some crporations like "Deutsche Bahn" (the biggest rail corporation
> > in Germany) has released their data under CC BY 4.0 with a special text
> > for OpenStreetMap (roughly translated):
> >
> > "If the data of Deutsche Bahn is part of the OpenStreetMap database work,
> > a reference to the Deutsche Bahn AG in the list of contributors is
> enough.
> > Crediting DB at each use of the data by a licensee of the mentioned
> database
> > work is no longer necessary then. Indirect credits (with reference to the
> > publisher of this databse work, which refers to the DB) is sufficient."
> >
> > Actually, that's a kind of dual-licensing with a special license for OSM.
> > From my understanding, releasing data ODbL would be the worst thing,
> > since the "BY" attribution of the data donator isn't compatible, is it?
>
>
> I've choosen not to start on a couple of imports because of the CC-by
> issue, I've gotten ok from the owners but they want to be included on
> http://osm.org/contributors . Deutsche Bahn seems to be much more
> free, I interpret it as source=Deutsche Bahn seems to be enough.
>
>
> I wish people would stop releasing data with CC-by; "you have to
> attribute us, but you have to remove that attribution when ever we
> want you too" which is not present in ODbL so
>
>
>
> --
> /emj
>
> ___
> 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] ECJ confirmed 96/9/EG for printed maps

[Tom Lee]

I think this conversation is suffering from a few confusions.

First, the EU Database Right and copyright are related but distinct. One or
both can apply to a work. From the ODbL: "Database Rights can apply even
when there is no copyright over the Database." German copyright's notion of
"fading" is interesting but as far as I know the primary documents of OSM
are built exclusively on EU and UK law (I could easily be mistaken about
this!).

Second, the project license is a grant of rights *beyond* the rights
automatically conveyed by the Database Right and copyright.  Judgments
about the status of different classes of work may affect the limits of
which rights OSM can reserve, but they will generally not affect what
rights it is able to grant to users (or the terminology it selects for
various concepts).

With all of that said, I think there's plenty of room for creating useful
guidelines on how to interpret the ODbL, so I would welcome the
clarifications that others have called for. But I tend to agree with others
on this thread that this ruling doesn't substantially change the legal
environment surrounding OSM licensing.

On Sun, Mar 13, 2016 at 9:37 AM, Tobias Wendorff <
tobias.wendo...@tu-dortmund.de> wrote:

> Am So, 13.03.2016, 14:07 schrieb Martin Koppenhoefer:
> >
> > shouldn't this go further and include cases where the published result
> > wasn't intended for the extraction of the original (or derived) data, but
> > it was used to do it?
>
> I don't think you can permit extraction of the data, since that's the
> principe of share-alike?
>
>
> ___
> 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-talk] Not sure what to think

[Tom Lee]

Google indexing a site, and your use of that index to find the site, does
not taint the interaction between you and that site. If I trespass on
private property on my way to buy groceries, the property owner might have
a claim against me. But it is unlikely that they have any claim on my
newly-purchased groceries.

In this case, there are additional factors in our favor: the information
being retrieved doesn't seem to be collected systematically; it's factual
information about the world; and it's being collected from unstructured
sources.

I don't want to pretend there is no tension here--indeed, I think there's a
very real tension between the idea of database rights and the necessity of
making facts unencumbered by IP. And it is conceivable to me that some
corner of the Google TOS implies a right to restrict this kind of user
activity. It's common for such tensions to exist without resolution until
they are brought before a judge.

But the idea that facts indexed by Google could be tainted is a stretch.
It's not something they've tried to claim, it would be a tenuous legal
argument, and it doesn't make much sense. I think this is a case where
practical judgment must outweigh theoretical concerns.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-legal-talk] Using a WMS imagery with CC-BY4.0

[Tom Lee]

Another update: I still haven't heard anything from the academic affiliated
with CC with whom I had met, so I have to assume she's no longer interested
in this project. That's a shame, but I know that OKFN is amenable to
examining the question of compatibility more closely. I'll continue to look
for ways to make this happen in 2016.

On Thu, Dec 24, 2015 at 5:22 AM, Andrew Harvey <andrew.harv...@gmail.com>
wrote:

> Sorry my mistake. Thanks for picking up on that.
> On 24/12/2015 9:01 pm, "Simon Poole" <si...@poole.ch> wrote:
>
>> Am 23.12.2015 um 23:58 schrieb Andrew Harvey:
>> > I'm really keen on seeing this compatibility question resolved too. CC
>> > BY is becoming the standard license for government geospatial data in
>> > Australia, and it would be much simpler to interchange data both ways
>> There might be a misunderstanding there, CC by is not going to be an
>> option as long as we have a licence with a share-alike component. The
>> only thing that we are discussing for now is attribution only input
>> licences.
>>
>> Simon
>>
>> > if it were compatible with the ODbL.
>> >
>> > On 15 July 2015 at 00:22, Tom Lee <t...@mapbox.com> wrote:
>> >> I'll add that I've been in touch with CC's US affiliate and they've
>> >> expressed interest in resolving the compatibility question (either with
>> >> formal guidance that applies to 4.0 or in preparation for the next
>> license
>> >> revision). That's on hold pending their availability at summer's end;
>> stay
>> >> tuned.
>> >>
>> >>> To clarify a bit, any CC licenses that are ND or NC are non-open and
>> >>> clearly incompatible with the ODbL or any open license. CC BY SA 4.0
>> is
>> >>> currently incompatible, but Creative Commons could change that.
>> >>>
>> >>> CC BY 2.0, 2.5, and 3.0 are clearly  incompatible, thanks to the
>> >>> attribution requirements that can't be met.
>> >>>
>> >>> CC BY 4.0 has some open questions about compatibility.
>> >>
>> >> ___
>> >> legal-talk mailing list
>> >> legal-talk@openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/legal-talk
>> >>
>> > ___
>> > legal-talk mailing list
>> > legal-talk@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/legal-talk
>>
>>
>>
>> ___
>> legal-talk mailing list
>> legal-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/legal-talk
>>
>>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] NSW LPI permission

[Tom Lee]

ense text.
> >
> > However, not in the latter case if for instance all their data were to
> > be imported into OSM and then someone pulled only their data from OSM,
> > in such a case they believe end users would need to attribute them. I
> > suppose that could be of a concern, so I'll reply back with Tom's
> > suggested wording for clarification.
> >
> > That said, the data they have released isn't raw data, it's only
> > imagery + raster basemaps, not sure if that makes a difference.
> >
> >> It would therefore probably be safer if you could get
> >> an explicit statement that they're happy for the data to be used in
> >> OSM, rather than just that they're happy for the attribution that OSM
> >> provides for its own direct use.
> >
> > I'm not a fan of that, because explicit permission for OSM to use such
> > data wouldn't extend to any other downstream organisations using such
> > data through OSM?
> >
> > On 13 December 2015 at 02:46, Tom Lee <t...@mapbox.com> wrote:
> >> I agree that there's no harm in sending another email asking for assent
> to
> >> more specific terms. I've drafted some suggested language, to make this
> >> easy.
> >
> > Thanks.
> >
> >> Having recently spoken to a number of parties about Australia's open
> data
> >> push (specifically address data), including folks from the PM's office
> and
> >> the NSW government, I doubt the odds of a dual-licensing request meeting
> >> with success are very high. The national government is centralizing and
> >> standardizing its open data program, and it's clear that their default
> >> license will be CC-BY (or possibly a compatible national variant a la
> >> license ouverte).
> >
> > Exactly my thoughts.
> >
> >> Andrew has already found someone who feels comfortable offering
> >> clarifications and assurances regarding use and license interpretation;
> >> asking for relicensing is likely to require that she involve other
> parties,
> >> which could easily derail things. Still, I defer to his judgment about
> the
> >> best course.
> >>
> >> Suggested language follows:
> >>
> >> Thanks very much for your help with this matter. I think we understand
> one
> >> another, but for the sake of clarity, can you agree to the following
> three
> >> points?
> >>
> >> - OpenStreetMap (OSM) may use and incorporate NSW data and derived
> products
> >> into its database if attribution is provided as previously specified in
> this
> >> email chain
> >>
> >> - You understand that the OSM database into which the NSW data will be
> >> incorporated is presently licensed under the terms of the Open Database
> >> License (ODbL) version 1.0; and that it is possible for the project to
> >> update or change this license (though I should note that this has only
> >> happened once in the project's ten year history)
> >>
> >> - You understand that OSM data is reused by various third parties under
> the
> >> terms of the ODbL ("downstream use") and in ways that make attribution
> of
> >> all original data sources impossible; and you therefore agree that
> >> downstream use of OSM data including or derived from NSW data is not
> subject
> >> to the "reasonable" attribution requirements imposed by the NSW data's
> CC-BY
> >> license
> >
> > I will reply back with that.
> >
> >> Sorry to make this so formal, but I'm sure you can imagine the
> consequences
> >> for OpenStreetMap if we fail to make sure our data sources are legally
> >> compatible.
> >
> > Agreed.
>
> ___
> 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] NSW LPI permission

[Tom Lee]

Andrew, I am not a member of the LWG, but insofar as:

- questions regarding CC-BY 3.0's compatibility with ODbL hinge on the
impracticality of downstream compliance with the license's attribution
requirements in a geo context
- the rightsholder has made it clear that they understand downstream
attribution requirements to be unreasonable in many cases, and don't
believe the obligation should apply in those cases
- the rightsholder has made it clear what attribution they wish to receive,
and it's obviously within OSM's power to comply with those wishes

I think this looks like a pretty good chance to incorporate some valuable
open data.

On Wed, Dec 9, 2015 at 7:36 PM, Andrew Harvey 
wrote:

> We've received some correspondence from a state government department
> regarding the use of their CC BY 3.0 AU licensed data and imagery
> within OpenStreetMap.
>
> One OSM member initially received the response:
>
> https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Government_Data#Cleary.27s_Letter
>
> I then followed up about some ambiguous sections of the text and
> received this response:
>
> https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Government_Data#Andrew.27s_Letter
>
> Would this be sufficiently legally binding and legally solid to allow
> us to include their CC BY 3.0 AU licensed data, derivative data and
> information derived from their imagery within 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] Proposed "Metadata"-Guideline

[Tom Lee]

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

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

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


On Tue, Oct 13, 2015 at 3:08 PM, Frederik Ramm <frede...@remote.org> wrote:

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

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

[Tom Lee]

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

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

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


On Wed, Oct 14, 2015 at 10:50 AM, Steve Coast <st...@asklater.com> wrote:

>
> > On Oct 14, 2015, at 8:30 AM, Tom Lee <t...@mapbox.com> wrote:
> >
> > Frederik. I think it's a bit ungenerous to suggest that getting open
> address data into OSM constitutes "hijacking" the project.
>
> He’s clearly not suggesting that.
>
> He’s suggesting that if you want to put geocodes in OSM that you go do
> that, and create a community around it, rather than this method of “change
> the license or we won’t do anything” which Fred feels is hijacking.
>
> Steve
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Tom Lee]

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

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

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

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

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





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

>
>
> Am 12.10.2015 um 23:43 schrieb Mr. Stace D Maples:
>
> ..
> Neither of the projects was scrapped because we *couldn’t* use OSM for
> the project, but because we couldn’t determine IF WE COULD use OSM for our
> particular uses.
>
> ...
>
>
> And you or your legal department approached the licensor of the data and
> asked for an opinion on your use of the data?
>
>
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Tom Lee]

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

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

On Tue, Oct 13, 2015 at 1:43 PM, Steve Coast <st...@asklater.com> wrote:

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

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

[Tom Lee]

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

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

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


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

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

Re: [OSM-legal-talk] Using a WMS imagery with CC-BY4.0

[Tom Lee]

I appreciate the nudge--looks like my contact promised a check-in after a
pending call with CC HQ, but that failed to materialize. I've emailed to
follow up. Apologies, this dropped off my radar.

On Wed, Oct 7, 2015 at 7:46 AM, Simon Poole <si...@poole.ch> wrote:

> Tom, any feedback yet?
>
> Simon
>
>
> Am 14.07.2015 um 16:22 schrieb Tom Lee:
>
> I'll add that I've been in touch with CC's US affiliate and they've
> expressed interest in resolving the compatibility question (either with
> formal guidance that applies to 4.0 or in preparation for the next license
> revision). That's on hold pending their availability at summer's end; stay
> tuned.
>
>
>> To clarify a bit, any CC licenses that are ND or NC are non-open and
>> clearly incompatible with the ODbL or any open license. CC BY SA 4.0 is
>> currently incompatible, but Creative Commons could change that.
>>
>> CC BY 2.0, 2.5, and 3.0 are clearly  incompatible, thanks to the
>> attribution requirements that can't be met.
>>
>> CC BY 4.0 has some open questions about compatibility.
>>
>
>
> ___
> legal-talk mailing 
> listlegal-talk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/legal-talk
>
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Tom Lee]

> In a way I would actually support [geocoding results being considered
non-substantive extracts] if geo-coding was a clearly and tightly defined
process, which, as I've pointed out earlier, it isn't.

Are you referring to this thread, Simon, or a larger conversation
elsewhere? If the latter, I'd e grateful for a link.

While I agree with you about the slipperiness of geocoding in the abstract,
as Alex points out it should be possible to narrow the scope within a
guideline. After all, when we license geocoding data from big proprietary
vendors, their lawyers, at least, feel it's possible to define geocoding
and to define unacceptable use in a way that protects their assets. Without
naming names or specific terms, I can point to this language from our TOS
as an example of how these requirements are passed along:

"You may not use geocoding results to develop a general database of
locations or addresses for any neighborhood, city, state, country, or other
such geographic region, or to develop any other general purpose digital map
database."

Naturally it would be preferable to work out a guideline that gives users
more freedom than proprietary vendors allow us to provide. But I think this
at least points in a useful direction (though of course the mechanism here
would be the non-substantive status of the geocoding product, not a bespoke
contractual provision).

On Mon, Sep 28, 2015 at 8:12 AM, Alex Barth  wrote:

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

Re: [OSM-legal-talk] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Tom Lee]

>
> I mean, nobody cares about a single on-the-fly geocoding result (this
> easily falls under the "substantial" guideline) but if you repeatedly
> query an ODbL database with the aim of retrieving from it, say, a
> million lat-lon pairs to store in your own database, then how in the
> world could this new database ever be *not* a derivative? Even if you
> were to define a single geocoding result as a produced work, combining a
> large number of them in a database would still get you a derived
> database again.


Can't the same argument apply to tiles? If you used tiles to recreate the
OSM database (say, by tracing road geometry or by OCRing feature names) and
then republishing under a different license, you would clearly be violating
the ODbL.

It seems as though the same approach can apply to geocoding: locate
features to your heart's content, but if you use the results to create a
general purpose geographic database that substitutes for/competes with OSM,
you'll be in violation of the license.


On Wed, Sep 23, 2015 at 2:18 AM, Frederik Ramm  wrote:

> Hi,
>
> On 09/23/2015 01:26 AM, Alex Barth wrote:
> > 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
>
> Frankly, even if I was of the opinion that it would be desirable for the
> ODbL to not apply to geocoding, I don't think that "Geocoding is
> Produced Work" could ever fly, legally, at least in countries that have
> a sui generis database law.
>
> I mean, nobody cares about a single on-the-fly geocoding result (this
> easily falls under the "substantial" guideline) but if you repeatedly
> query an ODbL database with the aim of retrieving from it, say, a
> million lat-lon pairs to store in your own database, then how in the
> world could this new database ever be *not* a derivative? Even if you
> were to define a single geocoding result as a produced work, combining a
> large number of them in a database would still get you a derived
> database again.
>
> 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] Geocoding as produced work (was: Proposed "Metadata"-Guideline)

[Tom Lee]

>
> why wouldn't you want to provide OSM with a list of addresses that you
> tried to geo-code (successfully and non-successfully)


To use an extreme but hopefully illustrative example, consider the queries
used to create the thematic map on this page:

http://www.huffingtonpost.com/2014/10/09/men-killing-women-domesti_n_5927140.html

I'm sure you can imagine similar scenarios related to sales leads,
potential hires, the healthcare industry or other forms of geographic
information that are sensitive for personal or professional reasons.

More generally, geocoding services that produce a product that has ongoing
licensing obligations--e.g. the user must attend to how the result
intermingles with their other data--will always be a hard sell. I realize
that this may not be of much concern to everyone here, but I do think that
more use of OSM for geocoding will spur improvements in various classes of
under-mapped data (addresses, most obviously).

On Wed, Sep 23, 2015 at 4:01 AM, Simon Poole  wrote:

>
>
> Am 23.09.2015 um 01:26 schrieb Alex Barth:
> > ..
> >
> > 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.
> >
> > .
>
> This is obviously off topic as it has little to do with comments and
> input on the proposed guideline (and the proposed guideline has nothing
> directly to do with geo-coding), however I'm curious: why wouldn't you
> want to provide OSM with a list of addresses that you tried to geo-code
> (successfully and non-successfully), for example as proposed in:
>
> http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#The_Failover_Issue_and_Publishing_Derived_Datasets
>
> Simon
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Tom Lee]

I'm not sure what basis there is for thinking a service provider will
necessarily reuse clients' data. Maybe! That's not my experience, but I can
imagine how it might be useful. I hope you'll agree that data security and
stewardship is a trickier thing to implement within an open project made up
of volunteers than it is in an organization with contract employees.

To point b: if the addresses remain associated with the entity doing the
geocoding, as I think you're proposing, problematic linkages remain
possible. Consider how Brendan Eich's career ended at Mozilla. That case
involved campaign finance records, but a political organization's geocoded
membership database could easily achieve the same result, even with just
addresses.

Anyway even if the organization->address linkage were to be removed,
organizations who comply with EU Safe Harbour privacy requirements (and, I
assume, the EU privacy provisions from which they're derived) could not
share users' address data with a third party in this manner*.

Put bluntly: expecting data back from geocoding users is not workable and
never has been. Maintaining the hope that someday it will produce useful
contributions merely leads to some noncompliance and lots and lots of
deadweight loss. It's a shame, and is inhibiting useful work being
accomplished both outside of OSM and within it.

Tom

* Partner and vendors can receive data from complying organizations, but
the relationship must be disclosed and users must be given the right to
delete data about them. Partner organizations also have to complete
certification procedures (including things like HR training), and may not
pass the data on further, as OSM presumably would want to under sharealike.



On Wed, Sep 23, 2015 at 10:39 AM, Simon Poole <si...@poole.ch> wrote:

>
>
> Am 23.09.2015 um 15:32 schrieb Tom Lee:
>
> why wouldn't you want to provide OSM with a list of addresses that you
>> tried to geo-code (successfully and non-successfully)
>
>
> To use an extreme but hopefully illustrative example, consider the queries
> used to create the thematic map on this page:
>
>
> Naturally you fail to mention that
>
> a) whatever service provider did the geo-coding of the above data
> undoubtedly used the data for the same purposes as OSM would (and likely a
> lot more)
>
> and
>
> b)  in my proposal I specifically address the issue of providing the
> geo-coded addresses anonymously
>
> Simon
>
> PS: just to avoid confusion we are talking about addresses without any
> attached personal information (names etc), so the data protection issue is
> sole the linkage between who is doing the geo-coding and the address.
>
> ___
> 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] Geocoding as produced work

[Tom Lee]

I confess that I'm not sure what to say to this. You're asserting that
running a geocoding business with ODbL attaching to the results is no big
deal, that "all the use cases you can think of" seem fine. Mapbox is
_actually running_ a geocoding business and telling you that we would like
to use OSM in it but can't sell a geocoding service that has ODbL attached
to the results.

And no one has yet offered any examples by which ODbL attaching to
geocoding results has led to contributions that improved OSM. Or
contributions at all (the prospect of Randy's tide station data
notwithstanding).

I realize you'll disagree, but I'm left with the same sense of what's
achievable and desirable for a geocoding guidance. Enable more geocoding.
Protect OSM's assets. Abandon the impractical goal of compelling users to
share their results.

On Wed, Sep 23, 2015 at 2:26 PM, Simon Poole <si...@poole.ch> wrote:

>
>
> Am 23.09.2015 um 19:16 schrieb Tom Lee:
> > I'm not sure what basis there is for thinking a service provider will
> > necessarily reuse clients' data. Maybe!
> Not "maybe" but dead certain, see for example geocoder.ca and I hope you
> don't really believe that google doesn't reuse the data you submit to
> its geo-coding API.
>
> > That's not my experience, but I can imagine how it might be useful. I
> > hope you'll agree that data security and stewardship is a trickier
> > thing to implement within an open project made up of volunteers than
> > it is in an organization with contract employees.
> >
> > To point b: if the addresses remain associated with the entity doing
> > the geocoding, as I think you're proposing, problematic linkages
> > remain possible. Consider how Brendan Eich's career ended at Mozilla.
> > That case involved campaign finance records, but a political
> > organization's geocoded membership database could easily achieve the
> > same result, even with just addresses.
> >
> > Anyway even if the organization->address linkage were to be removed,
> > organizations who comply with EU Safe Harbour privacy requirements
> > (and, I assume, the EU privacy provisions from which they're derived)
> > could not share users' address data with a third party in this manner*.
> >
>
> You are getting slightly carried away: we are talking about SA
> obligations for data derived from OSM that is publicly used, which in in
> the vast vast majority of cases will not have any relevant
> data-protection issues at all. A typical use case would be a company
> geo-coding the addresses of its dealerships for display on a map,
> 4square geo-coding its locations and similar. NOT an insurance
> geo-coding the addresses of its customers and publishing them.
>
> The very legislation you are referring to would in general strongly
> limit any use of location information associated with individuals in the
> first place and it may be that that is actually a rare use case which
> will never be possible to cover with OSM.
>
> > Put bluntly: expecting data back from geocoding users is not workable
> > and never has been. Maintaining the hope that someday it will produce
> > useful contributions merely leads to some noncompliance and lots and
> > lots of deadweight loss. It's a shame, and is inhibiting useful work
> > being accomplished both outside of OSM and within it.
> >
> > Tom
> >
> > * Partner and vendors can receive data from complying organizations,
> > but the relationship must be disclosed and users must be given the
> > right to delete data about them. Partner organizations also have to
> > complete certification procedures (including things like HR training),
> > and may not pass the data on further, as OSM presumably would want to
> > under sharealike.
> >
> See above, all the relevant larger scale use cases which I can think of
> that touch private data of individuals do not involve publishing the
> location information and OSM can be used for that NOW without any fear
> at all of share-alike. Matter of fact you are even better of with OSM
> than with any service provider, because you can actually do it in house
> and don't have to disclose the information to a third party with all the
> involved paper work (yes I've actually signed such contracts and they
> are a pain).
>
> Simon
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Tom Lee]

Thanks, Steve, for pushing this in a productive direction; and apologies to
you, Simon for letting my frustration through.

I should emphasize: I don't think that I'm suggesting a license change at
all, and I don't mean to suggest that sharealike is broadly impractical.
I'm suggesting that a guidance be issued that clarifies how geocoding
relates to the license. And I'm suggesting that treating geocoding results
as a produced work would not pose risk to OSM; would not cost it data;
would offer advantages to some users; and would create new incentives for
improving the map.

Steve is right to point out that other businesses have decided to take the
risk that ODbL's implications for geocoding results will never be enforced.
Or they're just using the data without worrying about compliance at all. I
think it's unfortunate to dismiss this issue solely because there aren't
more actors willing to work on a clear and ethical path forward.

> however it’s also hard to see who would pay for OSM geocoding in the
first place when there’s almost no data compared to proprietary maps

This speaks to Alex's point about the need to enable iterative uses of the
data, where open data supplements proprietary sources (here's an example:
https://www.mapbox.com/blog/austrian-open-address-data/ ). The name you
chose for this problem is apt. OSM has become a wonderfully powerful tool
for the use cases it's friendly toward, like rendering tiles and routing.
OSM is relatively inflexible toward geocoding, and consequently it is not a
great tool for it. Yet.

At any rate, I can assure you that we have customers today with use cases
that could be served exclusively by OSM data--reverse place-level permanent
geocoding is top of the list. And there are many more who could benefit
from OSM data supplementing the quality of our results.


On Wed, Sep 23, 2015 at 5:33 PM, Steve Coast  wrote:

>
> Steve Coast http://stevecoast.com/ +14087310937
>
> On Sep 23, 2015, at 11:22 PM, Simon Poole  wrote:
>
> Now obviously it does limit in some aspects the T an OSM based
> geo-coding service can use for its business and it might actually force
> such a service provider to differentiate between geo-coding for public
> vs in-house use.  But then it isn't as if you are completely free to do
> what you want with a lot of other data sources either.
>
>
> Another good point: If the OSM license has some edge case problem, it’s
> still far better than proprietary licenses which are the alternative.
>
> I’m calling it "edge case” if the SNIFF TEST in my prior email is not met,
> maybe it’s just as well to call it the “EDGE CASE TEST”, which is similar
> if not identical to the MANY TEST.
>
> Just trying to pull the discussion toward black & white tests which we can
> actually pass or fail, happy to see other suggestions.
>
> Best
>
> Steve
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] license test

[Tom Lee]

This strikes me as a fair and useful framework. I'll take a crack at it,
with geocodes-as-produced-works in mind:

SPIRIT: Surely it's possible to avoid creating a sharealike backdoor by
clarifying that geocodes become substantial only when combined to reverse
engineer the map.

HARM: The evidence that ODbL has produced useful data contributions from
geocoding users is thin.

EFFORT: I'm suggesting a guidance clarifying OSMF's opinion on which
part(s) of the current license apply to a class of data use, not a license
change. This is real work, but clearly achievable, since it's been done
before.

MANY: Obviously, geocoding services like Mapbox have an interest in gaining
this flexibility. But everyone will benefit as we & others improve the map
it for the geocoding use case. Nick and I have loaded more than a hundred
million of openly-licensed addresses into OpenAddresses.io in the course of
our work at Mapbox. (I'm not suggesting that large address imports to OSM
are the path forward here; hopefully you can see my point, though.) I love
the OpenAddresses project, but OSM is much more broadly useful, and I would
be glad to direct that energy where it will do more good.

On Wed, Sep 23, 2015 at 5:01 PM, Steve Coast  wrote:

> A constructive way forward may be to set out some tests that should be met
> for any license change for any issue. Maybe this exists already and I
> missed it. I’d suggest three tests below, but maybe someone here has better
> ones. I’m not sure *who* should judge this. Maybe a vote of some kind.
>
> SPIRIT - Does the suggested change maintain the spirit of the license?
>
> (Doesn’t require much elaboration I think, maybe I’m wrong)
>
> HARM - Does the suggested change not harm the community or data?
>
> (This is the most squirrely, maybe it can be nailed down. I took it from
> Lawrence Lessig’s supreme court copyright case where the judges asked him
> to show the actual harm the DMCA (would have) caused.)
>
> EFFORT - Does the suggested change merit the effort required?
>
> (The last license change was a monumental effort)
>
> Perhaps we could replace the HARM test with the MANY test:
>
> MANY - Does the suggested change help the many or the few?
>
> Best
>
> Steve Coast http://stevecoast.com/ +14087310937
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Tom Lee]

Martin,


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


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

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

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


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

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

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

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

[Tom Lee]

> Turning this around, when do you think share-alike should apply in a geocoding
context?

I think there are two goals that a successful geocoding guidance should
meet:

1. Enable greater use of OSM data for geocoding, including scenarios in
which sharealike provisions must not be applied (e.g. geocoding personally
identifiable or sensitive business information)

2. Protect the integrity of the OSM project and its sharealike requirements
-- i.e., don't open a backdoor by which the project can be copied without
ODbL attaching.

At the risk of putting words in others' mouths, I've seen some people argue
that a third goal should be met: compelling geocoding users to share the
results of their geocodes. It's sometimes suggested that this could be a
valuable source of POIs.

I don't think this is a workable goal for a guidance. Even if it did induce
people to contribute data back (rather than simply avoiding OSM geocoding),
it seems unrealistic to expect the community to figure out how to establish
that there are no other IP rights at play, nor to shepherd each
contribution through the import process.

But more to the point, this is the wrong theory of action for how geocoding
can compel people to improve the map. If more people can run geocoding
services built on OSM data, more people will have an incentive to improve
the map in order to improve their results. I'm not merely speculating: I
spend most of my time working on the Mapbox geocoder these days. If, when a
user reports a missing small town boundary for a reverse geocode, I could
fix the problem by adding the boundary to OSM, I would be delighted. As
things stand, I need to correct these errors by pursuing a much more
complicated process with a proprietary data vendor.

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

Re: [OSM-legal-talk] Legal status of certain mapping activities

[Tom Lee]

Frederik's perspective on question 4 seems correct to me. Speaking
imprecisely (by necessity, given national differences on these questions),
IP rights attach to the creative form that expressions of fact take; and,
in the EU, the collective form of those facts when arranged into a
database. The facts themselves are not protected from reuse.

I'll also add: it's important to consider the intention of the institution
publishing the dataset. Is your library publishing its location to make
money, or to help people find the library? Clearly the latter. What about
when Google does it? Their interest is obviously more commercial.

This may sound a bit ruthlessly realpolitik, but it's not: assessing risk
is a necessary part of making judgments about legal exposure. And when a
violation does occur, the commercial impact of the violation on the IP
owner is generally part of how the law assesses damages. Your library
system will probably have a harder time demonstrating damage to their data
licensing business than Google would.

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

Re: [OSM-legal-talk] GADM license - any news?

[Tom Lee]

If it would be useful, I'd be happy to try to get in touch with the GADM
people. Sending emails like that is a substantial part of my workday :-) I
would just need clarity around what, specifically, we'd like to ask for
this time.

Simone, the factual nature of geodata and its effect on copyright is an
interesting question -- I've had more than a few (US-based) lawyers express
to me in passing that they're skeptical of the copyrightability of such
information. Ultimately, it is a question that can only be settled in a
courtroom.

In practice, I think you'll find limited enthusiasm for that argument here
for a few reasons:

- The argument has weaker footing outside the US; untangling those
jurisdictional questions is also quite tricky for a project of global scope
(and chartered under UK law)

- OSM has no trained IP lawyers at its disposal, cash reserves or potential
commercial windfalls to be had by taking risks. These three factors all
push toward a conservative approach.

- OSM uses copyright to license its own data; dismantling others' license
assertions through arguments about copyrightability is consequently a
pretty thorny prospect.

With all that said, there's no harm in asking GADM for permission. As I
said, I'm more than happy to do so if you'd like to work together on the
question.

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

Re: [OSM-legal-talk] Legal requirements of permissions to import into OSM

[Tom Lee]

Well, I'll withdraw the suggestion; I wasn't party to those conversations
and I'm finding them to be essentially unsearchable due to the license
transition conversations around CC-BY-SA.

I will note that CC itself soft-pedaled the significance of the attribution
change in 4:

http://creativecommons.org/version4



 Pre-4.0 CC BY attribute requirements are clearly incompatible with
 common attribution for multi-source maps, practices of data consumers
 (including Mapbox), and both the CC 4.0 and ODbL 1.0 attribution
 requirements.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Legal requirements of permissions to import into OSM

[Tom Lee]

Having spent a lot of time doing work like this at the Sunlight Foundation,
I will suggest keeping things as simple as they can be, as Simon suggests.

Efforts like opendatacommons.org are admirable, but for an overwhelmed or
disengaged government, they still offer more detail than is desirable. ODC
also promotes the ODbL, which others on this thread have argued may be
undesirable.

I would suggest:

1. ask for a public domain dedication
2. if they balk at this, as for a letter giving OSM permission as described
earlier in the thread
3. if they balk at this, ask for an attribution license, most likely a
pre-4.0 version of CC-BY

It's usually best to avoid presenting options that are not yet necessary,
particularly ones that you don't believe to be the most desirable outcome.

Tom

I wonder if pointing the local governments to http://opendatacommons.org/
 might be a good start. I've been considering providing some cities I've
 contact with a link to Open Data Commons to help them make the right
 decision.

 Clifford


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

Re: [OSM-talk] Etsy

[Tom Lee]

Steve, thanks for pushing on this. We had gotten in touch with Etsy about
the missing attribution when we first noticed it, but your raising the
issue helped to unblock those conversations.

Etsy tells me that appropriate attribution should now be in place. There is
one older product whose push notifications aren't yet fixed, but that
change is scheduled to be deployed on Monday.

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

Re: [OSM-legal-talk] Using OSM data without modifying - are there any guidelines?

[Tom Lee]

 Which nicely illustrates that should the OSM database not
 be found to be worthy of sui generis database protection (a distinct
 possibility), the ODbL would clearly be enforceable based on contract law.

Of course you're right that contracts can be used to create obligations
outside of copyright or database right--but only if the parties enter such
a contract. In the Ryanair case, PR Aviation was collecting information
from Ryanair's site, and the court held that accessing the site amounted to
entering a contractual relationship (as defined by the site TOS).

But of course OSM extracts and snapshots are available all over the web,
and from interfaces that don't introduce or even mention any contractual
relationship with OSMF as a condition of download (whether the user is an
OSM contributor or has used OSMF-owned services directly might be relevant
here). A lawyer commenting on the post you provided explains the dynamic
well:

http://ipkitten.blogspot.com/2015/01/breaking-cjeu-says-that-owner-of-online.html?showComment=1421340621683#c7550848707130069201

Naturally enforceable property rights via the ODbL attach to the data even
when there is no contract. But not to data that is excluded from such
property rights by law, such as IDs.

As you point out, in practice this seems unlikely to matter here: the
Fairhurst Doctrine is a useful and thoughtful policy statement from the
community about what it intends to do with the property rights it does
have, and it seems to clearly indicate that OSMF isn't interested in
asserting claims over trivial use of IDs, whether or not the rights
underlying such claims exist.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Using OSM data without modifying - are there any guidelines?

[Tom Lee]

 As the name of this list says it is legal talk (aka yapping without 
 consequence)
... not get-help-from-the-OSMF

I'm sorry to see this practice discouraged. The archive description[1] says
this is the list for discussion of all legal matters relating to
Openstreetmap, including licensing and copyright and the archives are full
of people asking questions about attribution, virality and  transformation.

Simon, is there a place where guidance issued from the
@osmfoundation.org addresses
you list is made public? It seems like it could benefit others who find
themselves with similar questions; it may also be relevant to resolving
legal questions that are discussed elsewhere.

On point 3 of Jan Erik's question: I've seen a few projects where staleness
is not a concern and snapshots of OSM data can be used, affording ID
stability. So I think it's probably worth talking this scenario through. As
I noted elsewhere[2], EU and US law don't seem to make database IDs
eligible for copyright (or associated license requirements), at least when
their reproduction is associated with the lawful use of the relevant
database. So I think you'd be find in this scenario.

But I agree with Simon that your proposed implementation is going to come
to grief because of ID instability. You might want to take a look at
OpenLR[3], which is designed to solve problems similar to this one. Alas,
it's not trivial to use, so I'm not sure if it would offer your users many
benefits over the geographic information you're already storing.

Tom

1: https://lists.openstreetmap.org/listinfo/legal-talk
2: https://lists.openstreetmap.org/pipermail/talk/2015-June/073250.html
3: http://www.openlr.org/
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-talk] Some thoughts against remote mapping

[Tom Lee]

These critiques seem to be beginning to develop themes explored more fully
and famously by James Scott in _Seeing Like A State_. In it, he explores
the implications of government efforts at systematization, including the
original French cadastre and some German forest management projects.

I'm afraid the news is worse than you might think, Frederik: Scott makes a
compelling case that the *very act of mapping itself* snuffs out locally
adapted systems of property management, social support and cultural
exchange. It is a troubling critique and one that bears serious
consideration. (It also carries vast and unwieldy intellectual coattails,
including a deep connection to the failed anarchist project of the early
twentieth century.)

For my part, the value of being able to deliver emergency services,
economic development and competent governance seem overwhelmingly worth the
cultural costs that accompany efforts to rationalize the world. It seems to
me that the verdict is in and we're all building a global society (and
global map!). I'm skeptical that OSM should or can be a meaningful bulwark
against this process.

Local mapping is preferable not because it escapes the intellectual
hegemony of mapping practices -- there is no escape from them at all if you
are making a unified map -- but because it delivers a better map.

And some map is better than no map:

 Does every building address need to be mapped? If not, it just seems like
an easy win — why not collect everything? One reason not to is because
later when you find you need local buy-in, even OSM may be viewed as an
outsider project meant to dominate a neighborhood, a city, especially in
sensitive neighborhoods where this has indeed been a primary use of maps. I
wonder if people will one day want to create “our map” separately from OSM.
A different global map wiki which is geared toward self-determination,
perhaps? That would be a major loss for the OSM community.

This struck me as shortsighted.  The author is suggesting that leaving the
map blank is preferable because someone might fill it in later, and that
person might feel intimidated by the presence of existing data. I will
gently submit that needing a blank slate is not even close to the most
off-putting thing about OSM for new mappers.

More to the point, even if you take an *extremely* rosy view of the extent
to which the act of mapping enhances self-determination, the loss to the
OSM community seems vastly less important than the losses to everyone who
could be using the map to facilitate their businesses, recreation, or
government. Every day that a part of the map remains unusably empty is a
day that those people lose benefits they might have had -- or a day in
which they become more reliant on closed data that has already gotten the
job done.

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

Re: [OSM-talk] (licence of wikidata) was: Can wikidata links help fight name inflation?

[Tom Lee]

 As for OSM ID number, this falls under the so-called Fairhurst Doctrine
 and would not be considered Substantial under ODbL if and only if the
 community agrees and the OSMF endorses.

At the risk of splitting hairs, I don't think the community/OSMF's
sense of the substantial threshold is relevant in this case, as OSM
IDs don't appear to be eligible for U.S. copyright protection or
96/9/EC database rights. In particular, from the latter:

 6.5 - The performance by the lawful user of a database or of a copy thereof 
 of any of the acts listed in Article 5 which is necessary for the purposes of 
 access to the contents of the databases and normal use of the contents by the 
 lawful user shall not require the authorization of the author of the database.

 8.1 - The maker of a database which is made available to the public in 
 whatever manner may not prevent a lawful user of the database from extracting 
 and/or re-utilizing insubstantial parts of its contents, evaluated 
 qualitatively and/or quantitatively, for any purposes whatsoever. Where the 
 lawful user is authorized to extract and/or re-utilize only part of the 
 database, this paragraph shall apply only to that part.

There is a threshold in 8.1 related to what is and isn't substantial
but it's at the discretion of the court, if I understand correctly.
But more to the point: if you allow that Wikidata's use of OSM is
lawful, 6.5 seems to specifically allow for reproduction of IDs.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-legal-talk] What extra permissions are needed to include CC-BY data in OSM

[Tom Lee]

Apologies for the delay in my response.


 Any sucess/feedback?


Not from their general inquiry address; I've put another line in via a
shared contact.

I've been meaning to ask if you could clarify a bit further, and/or correct
my understanding of the situation.

You wrote:

The actual requirement is in 4(c):
 You must comply with the conditions in Section 3(a) if You Share all or
 a substantial portion of the contents of the database. which is a bit
 more than just 3(a)1,


3(a) also includes subsections 2, 3 and 4. My message discussed 2; 3 and 4
reads as follows:

If requested by the Licensor, You must remove any of the information
 required by Section 3(a)(1)(A) to the extent reasonably practicable.



 If You Share Adapted Material You produce, the Adapter's License You apply
 must not prevent recipients of the Adapted Material from complying with
 this Public License.


the extent reasonably practicable sounds to me like it could be satisfied
by editing http://wiki.openstreetmap.org/wiki/Contributors.

3(a)(4) is a pass-through of the attribution requirement, but the
flexibility afforded in 3(a)(2) means that OSM's current practices should
accommodate it.

Nope. I was referring to collective databases in the ODbL which are
 roughly the equivalent of collective works in early versions of CC
 licenses and only require the OSM derived part to be subject to the ODbL
 terms.


This is the part I think I could use help understanding. My impression is
that a collective database can contain ODbL and non-ODbL content
side-by-side. Are you saying that CC-BY 4.0 makes this impossible because
its attribution requirements would attach to the non-ODbL content as well?

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

Re: [OSM-legal-talk] What extra permissions are needed to include CC-BY data in OSM

[Tom Lee]

 My, very conservative, reading of CC-BY 4.0 would indicate that it has
 additional issues over just the attribution problem for databases.
 CC-BY 4.0 contains the following (4.b):
 if You include all or a substantial portion of the database contents in
 a database in which You have Sui Generis Database Rights, then the
 database in which You have Sui Generis Database Rights (but not its
 individual contents) is Adapted Material; and
 Adapted Material is essentially a derivative Work, or using ODbL terms
 a derivative database. The CC-BY terms would however seem to make it
 impossible to create an ODbL collective database from an OSM dataset
 including CC-BY material.


I think things are getting a little mixed up. The ODbL refers to
Derivative Databases and Produced Works but not Derivative Works
(well, except one, but I think that line exists because of poor drafting,
not a deliberate choice).

I *think* you are gesturing toward Produced Works and how the full ODbL
does not attach to them, and conflating this idea with CC-BY's Adapted
Material. ODbL Produced Works lose license restrictions; CC-BY Adapted
Material may gain them. Perhaps this contrast is confusing the situation?
Deeming something to be CC-BY Adapted Material gives the creator *more*
control over its license status, not less, because CC-BY is not designed
with virality in mind. This is implicitly affirmed in 3(a)(4), which
mentions the application of other licenses to Adapted Material.

The portion of the license following the and in your excerpt simply
points to CC-BY's attribution requirements, which must follow the
contributed content through into the Adapted Material. These attribution
requirements are extremely generous:

You may satisfy the conditions in Section 3(a)(1)
 https://creativecommons.org/licenses/by/4.0/legalcode#s3a1 in any
 reasonable manner based on the medium, means, and context in which You
 Share the Licensed Material.


I think the vast quantity of CC-BY licenses data is too important a
resource to ignore given the slightness of this limitation, but I
understand the need for conservatism. One of Creative Commons' US
affiliates is located at a law school here in Washington, DC -- I've
reached out to see if they might be able to help.

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

[OSM-ja] experience with Navitime.co.jp coordinate system?

[Tom Lee]

I am still working to connect e-Stat data together into a shapefile of
postal boundaries in Japan. I have found myself encountering data from
services that use the navitime.co.jp mapping platform. These coordinates
seem to employ an unusual datum. There are some references on the web to it
being the Tokyo Datum, and the constants present in some of the navitime
code https://gist.github.com/sbma44/49354581f45d3c7e10a9 indicate the
Bessel Ellipsoid, which supports this idea.

However, there are some strange aspects to these coordinates, such as
multiplying them by constants like 1E3 * Math.PI / 648E3. I have been
unable to successfully transform them into a known coordinate system. Does
anyone have experience with the coordinate system used by the Navitime API?

Here's a link to a CSV file of coordinates and post codes:

http://cl.ly/1e413I1u1c12/navitime.csv
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] experience with Navitime.co.jp coordinate system?

[Tom Lee]

Thank you! I am embarrassed not to have been able to unravel this myself. I
appreciate the help.

On Tue, Feb 24, 2015 at 9:15 PM, 田渕直 tabuchi_nao...@trek.co.jp wrote:

 Hi Tom,

 Some googling concluded that:
   - The navitime's coords are ordinary lat/lng's, but
   - they are represented in *milli-second angles.*
 (cf. http://ja.wikipedia.org/wiki/Wikipedia:%E5%9C%B0%E5%9B%B3%
 E3%82%B5%E3%82%A4%E3%83%88%E4%B8%80%E8%A6%A7#NAVITIME, etc.)

 So, dividing them by 3600*1000:
 lat-or-lng / (3600*1000)
 gives you familiar values in degrees.

 For instance, the first line of your CVS:
 511368020,156819220,079-1123
 transforms to:
 142.04667,43.560894
 which points to a certain place in Hokkaido:
 https://goo.gl/maps/6n9zO
 where, ignoring a slight gap bw. Tokyo Datum and WGS84, the postal code
 079-1123 points:
 https://goo.gl/maps/bnXhT

 hope it helps,

 Noashi Tabuchi (tabuchi_nao...@trek.co.jp)

 On 2015/02/25 4:06, Tom Lee wrote:

 I am still working to connect e-Stat data together into a shapefile of
 postal boundaries in Japan. I have found myself encountering data from
 services that use the navitime.co.jp http://navitime.co.jp/ mapping
 platform. These coordinates seem to employ an unusual datum. There are some
 references on the web to it being the Tokyo Datum, and the constants
 present in some of the navitime code https://gist.github.com/
 sbma44/49354581f45d3c7e10a9 indicate the Bessel Ellipsoid, which
 supports this idea.

 However, there are some strange aspects to these coordinates, such as
 multiplying them by constants like 1E3 * Math.PI / 648E3. I have been
 unable to successfully transform them into a known coordinate system. Does
 anyone have experience with the coordinate system used by the Navitime API?

 Here's a link to a CSV file of coordinates and post codes:

 http://cl.ly/1e413I1u1c12/navitime.csv


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





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

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

Re: [OSM-ja] Japan post code polygons

[Tom Lee]

Unfortunately the school address column does not include the postal code in
either of these files. Here's sample output from ogrinfo. At this point I'm
afraid I don't have many good ideas about how to finish this work, unless
someone else from the Japanese mapping community has a suggestion.

OGRFeature(P29-13):7438
  P29_001 (String) = 35201
  P29_002 (String) = 16
  P29_003 (String) = 16002
  P29_004 (String) = 16002
  P29_005 (String) = 玄洋中学校
  P29_006 (String) = 彦島本村町2-8-1
  P29_007 (Real) = 3.00
  X (Real) = 130.906788
  Y (Real) = 33.942762
  No (String) = 58
  FLG (String) = 1
  Memo (String) = H18KSJ
  Memo2 (String) = (null)
  F14 (String) = (null)
  F15 (String) = (null)
  F16 (String) = (null)
  F17 (String) = (null)
  memo3 (String) = (null)
  F18 (String) = (null)

post offices:
OGRFeature(P30-13):10320
  P30_001 (String) = 26344
  P30_002 (String) = 18
  P30_003 (String) = 18002
  P30_004 (String) = 18006
  P30_005 (String) = 郷ノ口郵便局
  P30_006 (String) = 郷之口本町16-2
  P30_007 (Integer) = 0
  X (Real) = 135.8520200
  Y (Real) = 34.8522940
  No (Integer) = 446
  FLG (Integer) = 1
  Memo (String) = H18KSJ
  Memo2 (String) = (null)
  memo3 (String) = (null)
  行政コード (String) = (null)

On Thu, Jan 29, 2015 at 5:52 AM, Satoshi IIDA nyamp...@gmail.com wrote:


  e-Stat has confirmed
 https://gist.github.com/sbma44/2805ee5c0e8dc2825631 via email that
 their data, when transformed, may be used and redistributed with
 attribution.
 Great!
 In fact, 丁目 (neighbourhood) polygon data is very rare (under Open
 License),
 and I'm super happy that we could use when transformed terms.

  shapefile
 What is the digits in Attribute Table?
 It seems it is not post code.

  address data with geometory
 If I understand your motivation correctly,
 most famous data is Kokudo_Suuchi_Joho (KSJ2) that could use even into OSM.
 http://wiki.openstreetmap.org/wiki/Import/Catalogue/Japan_KSJ2_Import

 * list - http://nlftp.mlit.go.jp/ksj/

 e.g.
 * post office - http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-P30.html
   code P30_006 is address column.
 * school - http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-P29.html
   code P29_006 is address column.

 But the notation for address is very messy.

 Anyone knows the geometory dataset with post-code?
 どなたか、郵便番号と住所 (と、緯度経度) が対になったOpenなデータセットをご存知ありませんか？




 2015-01-29 8:51 GMT+09:00 Tom Lee t...@mapbox.com:

 I've made a bit more progress. First, e-Stat has confirmed
 https://gist.github.com/sbma44/2805ee5c0e8dc2825631 via email that
 their data, when transformed, may be used and redistributed with
 attribution.

 Second, I have successfully joined the data together using the methods I
 described above. Below is a link to the compressed shapefile (~240MB).

 https://www.dropbox.com/s/j9sfaogofg5tkkr/japan_estat_joined.zip?dl=0

 I would be grateful for any feedback you can offer on the correctness of
 this geometry, suggestions for means of evaluating it, or how a postal code
 might be assigned to each polygon.

 At the moment I believe I need a source of point geometry that can be
 used to assign postcodes to these polygons. I have working code written
 using some restaurant locations pulled from the web, but this only covers
 about 1% of the polygons. If anyone has appropriate data available under an
 acceptably open license, please let me know if you'd be willing to share
 it! I have not done much research, but I can imagine that voting locations,
 school locations or other public data might be appropriate to this use.

 Thanks very much for any advice or thoughts you might have.

 Tom Lee



 On Tue, Jan 27, 2015 at 10:25 AM, Tom Lee t...@mapbox.com wrote:

 Thank you! This is quite encouraging. I am unable to read Japanese, but
 Google Translate makes your interpretation -- that distributing modified
 data is okay -- seem reasonable to me. I will email e-Stat for
 clarification, and would welcome any thoughts that others on this list
 might have about this.

 Thank you also for the jamfunk.jp links. This is detail about the Japan
 Post CSV that I did not know, and which will certainly be useful. I do not
 believe that it contains a mapping that would allow postcodes to be
 connected to the geometry derived from e-Stat. However, I do have a
 database of zip code centroids for Japan which could be used. I will have
 to check the licensing and see if it can be used to create a
 redistributable product.


 On Mon, Jan 26, 2015 at 11:14 PM, Satoshi IIDA nyamp...@gmail.com
 wrote:


 Hello,

 Amazing work!

 1. source of geo-data
 At first glance, e-Stats data is not Open as we use.
 Data re-distribution is forbidden by Terms of Use.

 http://e-stat.go.jp/SG2/eStatFlex/help/content/_73.html#B007
  Ｂ－７． 第三者に提供することを目的として、ダウンロードしたデータを利用することはできますか？
  本システムからダウンロードしたデータを複製（ファイル形式を変換しての複製を含む）してそのまま第三者に譲渡することは禁じています。
  詳細については、ダウンロードデータについての『使用上の注意』をご参照ください。

 http://e-stat.go.jp/SG2/eStatFlex/help/content/_72.html
  ２．利用の制限
 
 利用者は、本システムでダウンロードしたデータ及び画像データをそのまま複製（ファイル

Re: [OSM-ja] Japan post code polygons

[Tom Lee]

Update: I have spent some time experimenting with the Census shapefiles,
and it seems as though one of their ID fields might be usable for joining
census polygons into postal code polygons. Specifically:

shp2pgsql -W SJIS h22ka13115.shp tokyo1 | psql japan

echo create table tokyozip as select left(KEY_CODE, 10) as KEY_CODE,
st_setsrid(st_union(st_buffer(geom,0)),4326) as geom from tokyo1 group by
left(KEY_CODE, 10); | psql japan

Was used to generate the following shapefile:

http://cl.ly/3p2V1p400h3b/possible_tokyo_postcode.zip

Assigning the correct post code is still a problem to be solved. I also
don't have as much data (or familiarity with Japanese post codes) as I
would like to test this hypothesis. Any advice will be much appreciated.

http://i.imgur.com/JMYR09w.jpg


Tom

On Mon, Jan 26, 2015 at 3:37 PM, Tom Lee t...@mapbox.com wrote:

 I have been trying to find geometry that corresponds to Japanese postal
 codes (sometimes also called zip codes). I initially joined Japan Post's
 CSV download to MLIT's administrative boundary shapefile, but this has
 proven to be too low-resolution.

 I have found the PAREA Zip product
 http://www.parea.jp/datebase/area_map/index.html, but of course an open
 source of data would be preferable.

 I am particularly curious to know whether E-Stat/Census data can be used
 to create postal code polygons. If you visit this URL:

 http://e-stat.go.jp/SG2/eStatGIS/page/download.html

 and select 平成２２年国勢調査（小地域） 2010/10/01

 You can then choose a smaller area and download a high-resolution mesh as
 a shapefile. That file's field definitions can be found here:


 http://e-stat.go.jp/SG2/eStatFlex/help/content/downloaddata/A002005212010.pdf

 Here is one such shapefile in QGIS, overlaid on Bing aerial imagery:
 http://i.imgur.com/7z1dhn4.jpg

 Although the polygons are well-indexed, they do not seem to correspond to
 postal codes.

 Is anyone aware of a means of mapping the data included in this shapefile
 to postal codes? I would be very glad to share the results of my efforts
 under an open license, should I prove able to solve this problem (E-Stat's
 license seems to make this possible).

 Thanks very much!

 Tom Lee

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

[osm-ve] Venezuelan address data

[Tom Lee]

First: apologies for my use of English. I'm afraid it would be even more
annoying if I tried to speak Spanish.

Second: I wonder if anyone in the Venezuelan OSM community knows about
address point data. I am seeking a source for this information so that it
can be contributed to the OpenAddresses.io project. I have not had much
luck finding contacts at the Instituto Geográfico de Venezuela Simón
Bolívar or the Instituto Nacional de Estadística, which seem most likely to
have cadastral or other data that would meet my needs.

Is anyone aware of who maintains this data and under what terms it is
available? I would be grateful for any suggestions or information you can
provide.

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

Re: [Talk-es] access to Spanish cadastre

[Tom Lee]

Ha -- thank you, Agustín and Cruz. This is tremendously helpful. From the
decree, it seems that cadastral data is free for use in general, which I
think much include the INSPIRE data (if that is incorrect, please do let me
know). Working with 7000+ GML files will not be a lot of fun, but I think I
can use this to add the data to OpenAddresses. Thanks very much!

Tom


On Sat, Dec 13, 2014 at 7:00 AM, talk-es-requ...@openstreetmap.org wrote:

 Envíe los mensajes para la lista Talk-es a
 talk-es@openstreetmap.org

 Para subscribirse o anular su subscripción a través de la WEB
 https://lists.openstreetmap.org/listinfo/talk-es

 O por correo electrónico, enviando un mensaje con el texto help en
 el asunto (subject) o en el cuerpo a:
 talk-es-requ...@openstreetmap.org

 Puede contactar con el responsable de la lista escribiendo a:
 talk-es-ow...@openstreetmap.org

 Si responde a algún contenido de este mensaje, por favor, edite la
 linea del asunto (subject) para que el texto sea mas especifico que:
 Re: Contents of Talk-es digest Además, por favor, incluya en la
 respuesta sólo aquellas partes del mensaje a las que está
 respondiendo.


 Asuntos del día:

1. access to Spanish cadastre (Tom Lee)
2. Re: access to Spanish cadastre (Agustín)
3. Re: access to Spanish cadastre (Cruz Enrique Borges Hernandez)


 --

 Message: 1
 Date: Fri, 12 Dec 2014 13:33:57 -0500
 From: Tom Lee t...@mapbox.com
 To: talk-es@openstreetmap.org
 Subject: [Talk-es] access to Spanish cadastre
 Message-ID:
 
 caeuyxdtnarsgx_nmp+40xbpekefhtmxheerxj4jq_brcu7s...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 I've recently been researching Spain's cadastral database, which quickly
 led to the work done on cat2osm and other projects by people on this list.
 However, I find myself confused. I believe that links to bulk downloads of
 the data exist on this page:

 https://www.sedecatastro.gob.es/OVCFrames.aspx?TIPO=TITa=masiv

 In fact, it is discussed in some detail on this OSM wiki page:

 http://wiki.openstreetmap.org/wiki/Cat2Osm#Descargar_datos_de_Catastro

 But when I attempt a download, it seems that I need an X.509 certificate. I
 wonder if anyone can explain the nature of this requirement o a non-Spanish
 citizen? I realize that some elements of the database related to land value
 and ownership are sensitive, but I don't believe that these bulk downloads
 include such data. The license terms associated with this data seem to be
 quite open (

 http://www.catastro.minhap.es/ayuda/legislacion/ovc/resoluciondgc20110323_tfs.pdf
 ), which makes this requirement all the more confounding.

 Any insights are much appreciated.

 Tom
  próxima parte 
 Se ha borrado un adjunto en formato HTML...
 URL: 
 http://lists.openstreetmap.org/pipermail/talk-es/attachments/20141212/766a93fd/attachment-0001.html
 

 --

 Message: 2
 Date: Fri, 12 Dec 2014 20:15:46 +0100
 From: Agustín agustind...@gmail.com
 To: Discusión en Español de OpenStreetMap
 talk-es@openstreetmap.org
 Subject: Re: [Talk-es] access to Spanish cadastre
 Message-ID: 082722c4-ef69-4af6-b8a2-339bf6a54...@gmail.com
 Content-Type: text/plain; charset=utf-8


  On 12 Dec 2014, at 19:33, Tom Lee t...@mapbox.com wrote:
 
  I've recently been researching Spain's cadastral database, which quickly
 led to the work done on cat2osm and other projects by people on this list.
 However, I find myself confused. I believe that links to bulk downloads of
 the data exist on this page:
 
  https://www.sedecatastro.gob.es/OVCFrames.aspx?TIPO=TITa=masiv 
 https://www.sedecatastro.gob.es/OVCFrames.aspx?TIPO=TITa=masiv
 
  In fact, it is discussed in some detail on this OSM wiki page:
 
  http://wiki.openstreetmap.org/wiki/Cat2Osm#Descargar_datos_de_Catastro 
 http://wiki.openstreetmap.org/wiki/Cat2Osm#Descargar_datos_de_Catastro
 
  But when I attempt a download, it seems that I need an X.509
 certificate. I wonder if anyone can explain the nature of this requirement
 o a non-Spanish citizen? I realize that some elements of the database
 related to land value and ownership are sensitive, but I don't believe that
 these bulk downloads include such data. The license terms associated with
 this data seem to be quite open (
 http://www.catastro.minhap.es/ayuda/legislacion/ovc/resoluciondgc20110323_tfs.pdf
 
 http://www.catastro.minhap.es/ayuda/legislacion/ovc/resoluciondgc20110323_tfs.pdf
 ), which makes this requirement all the more confounding.
 Well this is the Spanish government, I guess. Requirements even if there
 are a non-sense, are quiet clear.
 Para descargar los ficheros de catastro es necesario tener DNI-e 
 http://www.dnielectronico.es/, obtener el certificado e instalar los
 drivers http://www.dnielectronico.es/descargas/index.html del lector y
 dni-e. También es posible sin DNI-e mediante un certificado

[Talk-es] access to Spanish cadastre

[Tom Lee]

I've recently been researching Spain's cadastral database, which quickly
led to the work done on cat2osm and other projects by people on this list.
However, I find myself confused. I believe that links to bulk downloads of
the data exist on this page:

https://www.sedecatastro.gob.es/OVCFrames.aspx?TIPO=TITa=masiv

In fact, it is discussed in some detail on this OSM wiki page:

http://wiki.openstreetmap.org/wiki/Cat2Osm#Descargar_datos_de_Catastro

But when I attempt a download, it seems that I need an X.509 certificate. I
wonder if anyone can explain the nature of this requirement o a non-Spanish
citizen? I realize that some elements of the database related to land value
and ownership are sensitive, but I don't believe that these bulk downloads
include such data. The license terms associated with this data seem to be
quite open (
http://www.catastro.minhap.es/ayuda/legislacion/ovc/resoluciondgc20110323_tfs.pdf
), which makes this requirement all the more confounding.

Any insights are much appreciated.

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

Re: [OSM-legal-talk] Using description from wikipedia text (Tom Gregorovic)

[Tom Lee]

Tom,

Licenses like CC and ODbL can only apply to copyrighted material, which
must generally be a specific creative expression in a fixed medium. You
can't copyright facts, nor opinions.

Assuming you don't have some crazy natural language processing workflow in
mind, you'll only be using the ideas expressed in that Wikipedia text
rather than their specific expression. These are not protected by copyright
nor any derived license, so you should be free to use them. I am not a
lawyer--by all means listen to the wisdom of others on this list--but I
believe that there shouldn't be any licensing considerations present.

(also) Tom

On Sat, Oct 18, 2014 at 8:00 AM, legal-talk-requ...@openstreetmap.org
wrote:

 Send legal-talk mailing list submissions to
 legal-talk@openstreetmap.org

 To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.openstreetmap.org/listinfo/legal-talk
 or, via email, send a message with subject or body 'help' to
 legal-talk-requ...@openstreetmap.org

 You can reach the person managing the list at
 legal-talk-ow...@openstreetmap.org

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of legal-talk digest...


 Today's Topics:

1. Using description from wikipedia text (Tom Gregorovic)


 --

 Message: 1
 Date: Fri, 17 Oct 2014 16:15:50 +0200
 From: Tom Gregorovic tomto...@gmail.com
 To: legal-talk@openstreetmap.org
 Subject: [OSM-legal-talk] Using description from wikipedia text
 Message-ID:
 CADETX0_BZrj3-iPj7iXHfYsb5PtnP754Mw=
 hsxfmmk-tcai...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8

 Dear all,
 I just want to ask here, if it is legal and does not violate the OSM
 license to map
 mountain ranges according to text description of its borders from
 wikipedia articles (e.g.
 http://en.wikipedia.org/wiki/Zelengora#Topography). I would combine it
 with contours/relief map of OpenCycleMap and mentioned rivers and peaks
 from OSM to approximately estimate area of the mountain range.

 Thanks,

 Tom Gregorovic



 --

 Subject: Digest Footer

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


 --

 End of legal-talk Digest, Vol 96, Issue 3
 *

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

Re: [OSM-ja] Talk-ja まとめ読み, 80 巻, 8 号

[Tom Lee]

This is enormously helpful. Thank you very much! I have spoken to others
who express concerns about the reliability of this mapping, and in
particular the accuracy of the Japan Post zip code data. We will do our
best to keep an eye on how this data behaves in a production system and
report any observations here.

On Tue, Oct 14, 2014 at 8:00 AM, talk-ja-requ...@openstreetmap.org wrote:

 Talk-ja
 メーリングリストへの投稿は以下のアドレスに送ってください．

 talk-ja@openstreetmap.org

 Webブラウザを使って入退会するには以下のURLにどうぞ．

 https://lists.openstreetmap.org/listinfo/talk-ja
 メールを使う場合，件名(Subject:)または本文に help
 と書いて以下の アドレスに送信してください．
 talk-ja-requ...@openstreetmap.org

 メーリングリストの管理者への連絡は，以下のアドレスにお願いします.

 talk-ja-ow...@openstreetmap.org

 返信する場合，件名を書き直して内容がわかるようにしてください．
 そのままだと，以下のようになってしまいます．
 Re: Talk-ja まとめ読み, XX 巻 XX 号


 本日の話題:

1. Re: reconciling MLIT Shapefile with Japan Post CSV (田渕 直)


 --

 Message: 1
 Date: Tue, 14 Oct 2014 13:01:48 +0900
 From: 田渕 直 tabuchi_nao...@trek.co.jp
 To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org
 Subject: Re: [OSM-ja] reconciling MLIT Shapefile with Japan Post CSV
 Message-ID: 543ca02c.9060...@trek.co.jp
 Content-Type: text/plain; charset=UTF-8; format=flowed

 Hi Tom,

 The common ID scheme is called
全国地方公共団体コード/Zenkoku Chiho-Kokyou Dantai Codes,
 literally meaning The National Code System for Local Public Bodies.
 I don't think there's an official English name for it, but anyway
 it's defined as a Japan's industry standard (JIS X 0402).

 For the columns of the postal-code csv, let's take the 1st line
 as a reference example:
 01101,060 ,0600042,ﾎﾂｶｲﾄﾞｳ,ｻﾂﾎﾟﾛｼﾁﾕｳｵｳｸ,ｵｵﾄﾞｵﾘﾆｼ(1-19ﾁﾖｳ
 ﾒ),北海道,札幌市中央区,大通西（１〜１９丁目）,1,0,1,0,0,0

The column 1: 01101 is the district's ID, as you mentioned,
 2-3: 060 ,0600042 are the postal codes for the district,
  the former is now outdated short form,
  the latter is canonical,
 7-9: 北海道,札幌市中央区,大通西（１〜１９丁目） are the
  prefecture, city and district, street, respectively,
 4-6: ﾎﾂｶｲﾄﾞｳ,ｻﾂﾎﾟﾛｼﾁﾕｳｵｳｸ,ｵｵﾄﾞｵﾘﾆｼ(1-19ﾁﾖｳﾒ) are the
  pronouciation for the pref./city-and-dist./st. resp.

 Let me omit the remainder: they are rather involved flags and won't be
 very important for OSM use.

 Lastly, the distinction bw. oogaki and kogaki wouldn't be serious,
 but I believe kogaki is a bit human- and machine-friendly;
 kogaki can easily be canonicalized into oogaki, but not vice versa.

 Hope it helps (and excuse me for a long post.)

 Regards,

 Noashi Tabuchi (tabuchi_nao...@trek.co.jp)

 (2014/10/12 1:25), Tom Lee wrote:
  Please excuse me for posting to this list in English. I am not a
  Japanese speaker, but have recently been examining the availability of
  Japanese open data for geocoding addresses. This process has been
  difficult due to my unfamiliarity with the language and character set.
  My hope is to share a summary of my work here and receive criticism from
  experts.
 
  My code can be found here:
 
  https://github.com/sbma44/japan_geodata_research
 
  My conclusions and the narrative behind them are present in the
  README.md file, which should display at the bottom of the page when you
  follow that link.
 
  In short: I was surprised to find that Japan Post and MLIT seem to use a
  shared ID scheme, allowing postal codes to be mapped, many-to-one, to
  the boundaries of administrative districts offered in a country-wide
  Shapefile by MLIT.
 
  It might be that this is already common knowledge -- if so, I would be
  glad to know that, too! If not, perhaps this will prove useful to others.
 
  I would be particularly glad to hear suggestions from Japanese speakers
  as to what each column in the postal code CSV should be properly called
  in English and/or in the existing OSM tagging scheme for Japan; and
  whether the difference between the oogaki and kogaki files offered
  by Japan Post represent a concern.
 
  Please do not hesitate to ask questions or point out problems with my
  analysis.
 
  Tom Lee
 
 
  ___
  Talk-ja mailing list
  Talk-ja@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-ja
 




 --

 Subject: まとめ読みフッタ

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


 --

 以上: Talk-ja まとめ読み, 80 巻, 8 号
 **

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

[OSM-ja] reconciling MLIT Shapefile with Japan Post CSV

[Tom Lee]

Please excuse me for posting to this list in English. I am not a Japanese
speaker, but have recently been examining the availability of Japanese open
data for geocoding addresses. This process has been difficult due to my
unfamiliarity with the language and character set. My hope is to share a
summary of my work here and receive criticism from experts.

My code can be found here:

https://github.com/sbma44/japan_geodata_research

My conclusions and the narrative behind them are present in the README.md
file, which should display at the bottom of the page when you follow that
link.

In short: I was surprised to find that Japan Post and MLIT seem to use a
shared ID scheme, allowing postal codes to be mapped, many-to-one, to the
boundaries of administrative districts offered in a country-wide Shapefile
by MLIT.

It might be that this is already common knowledge -- if so, I would be glad
to know that, too! If not, perhaps this will prove useful to others.

I would be particularly glad to hear suggestions from Japanese speakers as
to what each column in the postal code CSV should be properly called in
English and/or in the existing OSM tagging scheme for Japan; and whether
the difference between the oogaki and kogaki files offered by Japan
Post represent a concern.

Please do not hesitate to ask questions or point out problems with my
analysis.

Tom Lee
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja