In general we'll probably allow third parties, as we've done for all of our other content in the general case (e.g. upload.wm.o images are linked and embedded all over the web). I'm probably not the best person to ask about attribution/legal stuff. We don't want to do anything there that would be burdensome for re-users, but we probably need something.

On the pragmatic level with traffic rates and all of that:

• We always reserve the right to block abusive/excessive traffic, and the practical definition of that is "if we notice it hurting our service or impacting us financially". Even if everything about some third-party use is "legal" and obeys our other rules, we're probably not going to let all other use of the service fail due to their onslaught of traffic, nor are we obligated to make large new investments in hardware and/or network links to support some random third party's excessive use.
• If we're writing down some rules somwhere, we should probably ask that anyone planning to send us statistically-significant traffic (e.g. rates that are easiest expressed in reqs/sec) make contact and at least talk to us about their plans and expectations. It's good opportunity to talk about whatever attribution/legal issues there might be anyways.

Hi,

I'm the developper of the app E-walk: https://play.google.com/store/apps/details?id=com.at.ewalk.free

I'd definitively be interested if we could use Wikimedia maps, with a policy close to the OSM's policy (allowing everything, and keeping the right to block abusing software). More specifically, being able to cache (store the tiles for a limited time while the user browses the map, in order to improve performance) and bulk download (select an area of the map, a min and a max zoom levels, and downloading each tiles one after one) the map would be interesting.

I'll keep an eye on the project!

bulk download (select an area of the map, a min and a max zoom levels, and downloading each tiles one after one)

Bulk downloading high zoom image tiles is something almost certain to put an excessive load on the servers as these tiles will not be pre-rendered.

Bulk downloading the vector tiles and rendering client-side is technically feasible.

Attribution-wise, anyone using your tiles would need proper attribution to OSM. It's up to you if you want to require additional attribution for Wikimedia as the server of the tiles or as the author of the style.

For reference, the OSMF tile usage policy is http://wiki.openstreetmap.org/wiki/Tile_usage_policy, and the technical requirements of a valid user-agent or HTTP referer are now being automatically enforced.

Thanks for the input!

Downloading vector tiles and rendering would be really interesting, do you have more information (which tools, which format for the vector tiles, etc)?

No problem for the attribution, I already have an HTML box on top of the map dedicated to it.

@timautin our tiles are stored in Mapbox's vector tile format, and we use this style to convert it to images. It should be possible to set up a local copy of Tilerator to do the rendering from the downloaded tiles, but we do not yet have a bulk vector tile export (T142354)

Some discussions about the equivalent OSM usage policies: https://github.com/openstreetmap/operations/issues/113

@debt: as @BBlack pointed out in the start of this thread, we tend to have a fairly liberal view on who can reuse our content / services. Bulk download of all tiles probably falls into the "abusive / excessive use case", but synchronous usage of our tiles is probably not much of an issue. I'm still working on some load testing for our servers, which might give us a better idea of the load they can actually support.

In T141815#2773589, @Gehel wrote:

@debt: as @BBlack pointed out in the start of this thread, we tend to have a fairly liberal view on who can reuse our content / services

This is a bit larger in magnitude if it starts off; as Firefishy wrote in the quoted ticket the current traffic of the OSM tileservers are around 6800GB/day in over 528 million requests (average of around 13.6KB per request). While this traffic will not just 'come over' to us it'd be probably prudent to plan not to get the servers slashdotted. :-)

We're talking about valid requests in high amounts. An example was Locus Map on Android which was downloaded to a few millions of mobiles and were requesting just the local area in various zooms, which was pretty soon noticed by the server admins and banned with "implement some strict limits please" message. The result is that the app had to slow down display experience to comply.

Similar would be extensive usage of leaflet inserts on webpages showing a simple map with company address or like. Mapquest seems to have been bitten by that and have closed their open servers recently. And it is a really simple and a definitely valid usage (pattern).

I definitely support doing it but I suggest capacity planning, too.

I think this task is conflating two separate issues.

• Define technical tile usage policy (i.e. what users can do without melting the servers down)
• Define ethical tile usage policy (i.e. attribution requirements, legal requirements, etc.)

What might be acceptable to one (e.g. "Reuse all you like provided you attribute") might not be acceptable to the other (e.g. "Please don't bulk download all our tiles or you'll overload the service"). The two have to be combined into a single policy in the end, but it may be beneficial to split the discussion out.

@Deskana as always, you have the word of wisdom!

In any case, this is a discussion that will take some time, and that will need to be rolled out progressively. We will definitely not advertise our tiles broadly at first and we need to have better visibility on how much traffic our current infrastructure can actually handle before we move forward. I was mainly pointing out that the idea in itself has merit and is inline with what we usually do.

Another sidenote: this decision should have a good visibility to the people planning server resources.
And I try to ask around MapQuest what traffic levels did they observe before throwing it in.

Moving to 'stalled' as we don't have wording from Legal.

And I try to ask around MapQuest what traffic levels did they observe before throwing it in.

Some statistics from the HOT layer were that when MQ Open closed non-osm.org tile requests went from 2.2M/day to 8.5M/day. I don't have any numbers directly from MQ Open (at least not that I can share), but I wouldn't assume issues MQ Open had are applicable to what we'll have.

Thanks for the reminder, I've got a word back from MQ, and they said, that in 2014 MapQuest served 380 million Open Tiles per day, 9.3 million Open geocodes per day, and 38 million Open reverse geocodes per day (these numbers were readily available).

Added a meeting to chat about this with Legal and the Interactive team on Thursday, Jan 5, 2017

We clarified the tile usage policy in the Maps Terms of Use:

Using maps in third-party services

If you use the Wikimedia Maps service for your third-party project (that is, outside of the Wikimedia projects), please respect our limited services and resources. We reserve the right to discontinue or change our service, block or limit certain users or applications, or take other measures in cases at our sole discretion at any time without notice. If you use the service too heavily, it could affect the service's stability for others or degrade our quality of service.

If you are developing an application that uses the Wikimedia Maps service, you must provide a valid HTTP User-Agent that includes your application, version, and sufficient information to easily contact you (e.g., your email address).

The following are prohibited on the Wikimedia Maps service:

• Excessive downloading (such as downloading significant areas of tiles for later offline usage)
• Accessing the service without a proper HTTP User-Agent or HTTP referer
• Using the service without compliance with any license or copyright terms

@timautin , this means you are welcome to download or use tiles in your app, but please note the caveats above. The policy may change as we continue to work on the Wikimedia Maps service, so I wouldn't recommend relying on it in a widely used app for now.

Thanks for the update, @Slaporte !

Great, thanks! So this means that caching (storing tiles as the user browses the map to improve performance) is allowed but not bulk downloading (the user selects an area, min and max zoom and the app download the area), right? Or both are allowed as long as there is no excessive usage? E-walk does not set a limit for now but warns the user if he tries to download more than 5000 tiles.

Hi @timautin - yes, these things can be done as long as there isn't excessive usage, as noted by @Slaporte in the above comment.