Licensing Working Group/Minutes/2026-03-09

OpenStreetMap Foundation, Licensing Working Group (LWG) - Agenda & Minutes
9 March 2026, 18:00 UTC

Participants

• Kathleen Lu (Chairing)
• Dermot McNally
• Tom Lee
• Craig Allan (OSMF Chairperson)

Absent

• Simon Hughes

Administrative

Adoption of past minutes

• 2026-02-09 Approved

Minutes by Dorothea Kazazi.

---

Any updates on reported attribution cases?

Reports in OTRS:

• Ticket#2021081210000057 printed maps with false copyright
• Ticket#2022011910000082 interparcel.com: Dermot Emailed them on 10th Nov, no reply
• Ticket#2022012610000149 https://poster.printmijnstad.nl/editor/city
• Ticket#2022033010000217
  • complaint that Aberdeen city council may not be attributing correctly – https://www.aberdeencity.gov.uk/news/consultation-starts-street-improvements-ashgrove-road
  • Note that Aberdeen credits Ordnance Survey, so possible OS is using OSM as one of many sources and the full attribution is not getting carried through
• Ticket#2022032710000125 - https://www.evri.com/find-a-parcelshop
  • Hermes UK changed name to evri. So this is an old issue.
• Ticket#2022062610000078 -
  • Härryda, Sweden, uses OpenStreetMap for an app they developed. Inside the app there are no license references to OSM.
  • You can see the app on the Google Apps store here: https://play.google.com/store/apps/details?id=se.harryda.medborgar.app&gl=US
• Ticket#2021120810000146 mondialrelay.fr not attributing correctly
• Ticket#2022120510000177 — Club Vosgien complaint – any reply?

---

Board items

OpenCollabMap query

Trademark agreement draft has been shared with the Board. Board has signed agreement.

hotelmap.com

Email shared by the LWG Dear LWG,

We sent this notice to Hotelmap.com a couple of weeks ago. We got no notice from them. I see this case as specifically problematic, as Hotelmap.com is deliberately changing Mapbox's attribution to hide OSM and add their own. I noticed the issue, as it's the official booking site for the Geospatial World Forum.

How should we proceed with it? Can we send a more direct message?

Best,
Héctor

Dear team at Hotelmap.com,

We have noticed you are using OpenStreetMap-based tiles for the map background. Based on your page, it appears you are using Mapbox (I have checked this page https://hotelmap.com/MG968).
We are happy that you use OpenStreetMap-based tiles in your application and welcome your use of them through a third-party service like Mapbox.

However, using OSM data through a third party still requires citing the source of the map style and map data. We have noticed that this attribution is not present in Hotelmap.com. Mapbox provides guidance on its website (https://docs.mapbox.com/help/dive-deeper/attribution/) on how to attribute a map using its libraries and styles, including OSM-based ones. In addition, OpenStreetMap has a copyright page with more information on how to cite OSM data-based maps: https://www.openstreetmap.org/copyright.

If you require any clarification, we would be happy to assist.

Héctor Ochoa Ortiz¹

Hotelmap is a Mapbox customer and Tom Lee has reached out to them. Nothing to report yet.

---

From Operations: API/tile overuse abusers, 1. IPRoyal botnet issue, 2. Bright Data

Emails shared by the LWG From IPRoyal

--- Dear OpenStreetMap,
Thank you for your response dated February 20, 2026. We appreciate the continued dialogue and share your interest in reaching a reasonable resolution.

Our Position
IPRoyal operates proxy infrastructure used by customers for diverse legitimate purposes including research, privacy protection, accessibility, and lawful commercial activities. We cannot implement blanket blocks on publicly accessible websites based solely on terms of service complaints without evidence of specific abuse by identifiable customers. Such a measure would be disproportionate, inconsistent with industry standards for infrastructure providers, and would undermine the legitimate uses of our services. We are not aware of any major proxy provider, VPN service, or internet service provider that implements blanket website blocks based on civil ToS complaints.

Our Continued Commitment
We remain willing to investigate and take appropriate action against specific customers who are demonstrated to have engaged in abusive conduct. To do so, we require the information previously requested, namely specific IP addresses observed accessing your services and quantification of the impact or abuse pattern.
Upon receipt of this information, we will conduct a detailed review of the matter. If any violations are confirmed, we will issue formal notices referencing the applicable provisions of our Terms of Service and Acceptable Use Policy and require the customer to immediately cease the identified activity. Continued non-compliance may result in account suspension or termination in accordance with our internal enforcement procedures. Subject to applicable confidentiality restrictions, we will inform you of the general outcome of our review. We also remain open to discussing enhanced verification measures for access to OpenStreetMap services as a reasonable middle ground, though we are not in a position to implement a blanket block affecting all customers.

Conclusion
We understand OpenStreetMap operates as a volunteer-run community resource and we have no interest in facilitating harm to your services. However, we must balance your concerns against our obligations to our customers and the proportionality of any measures we implement.
We encourage you to provide the specific evidence requested so that we may take targeted action against any bad actors. We believe this approach better serves both parties' interests than broad restrictions that would affect legitimate users.
Please direct further correspondence to legal@iproyal.com.

--- From Paul Norman (OWG)

There's a few issues

• Giving them a list of IPs and requests may reveal how we identified them. We don't want to do this as it gives them a major advantage in the ongoing arms race. Their goal is for no one to be able to distinguish their traffic, so any ways of identifying it is a business risk to them.
• Requestor IPs are PII. Sending IPs to network owners in cases of abuse is normal, but with a normal network owner you can be 100% confident of if they own an IP or not. This could lead to the catch-22 where we're willing to send them data on abuse from their users but only if they tell us how to confirm an IP is one of their users. Normal networks are forced to publish a list of all their IPs in order to have traffic routed to them as well as being forced to publish an abuse contact as part of owning those IP ranges.
• I don't know the exact data Grant used in identifying them, but it may have included some data from a company that has installed software with their SDK as a honeypot, and that data may have been given in confidence. Because we're a well-liked project in the tech community we've been able to get help from others.
• I don't think we have a firm grasp on which traffic comes from which proxy network. Abusive traffic from one proxy network can be part of a wider pattern thanks to the reselling in the market. Looked at in isolation a request might appear okay but when looked at in total it's abuse. If the honeypot data clearly identified a pattern coming from IPRoyal SDKs that same pattern could be seen from other networks, and we can't tell which is which.

Grant may have more specifics since he's more in touch with the issue than I am. My main concern with giving them any data is it changes the framing from "we don't want any traffic from your proxy network" to a whack-a-mole where they can argue every instance of abuse
We don't want any traffic from their "network" as a matter of policy, and this is true for all of the proxy networks. This doesn't depend on them agreeing the traffic is abusive, knowing what the traffic is, or even having sent any traffic in the first place.
If they were a reputable network with their own IP ranges we could block an IP range or block the entire network by ASN without ever talking to them.

--- From Tom Hughes (OWG)

This all makes good sense, particularly the portions about revealing private details of OSM methodology, and the bit about wanting to avoid getting into a whack-a-mole situation. If we're unable to definitively associate IPs with this specific network, reporting false positives might also give them a pretext for ignoring our request.
But while all of these arguments are reasonable, some may be less likely to be relevant to this specific situation. Specifically, while I don't disagree about the need to keep OSM's honeypot/detection methodology private, I think that it's unlikely that IPRoyal has a specific interest in understanding/publicizing/subverting those techniques (I doubt they care much about OSM at all). It also seems likely to me that they're going to stick to their policy: they probably don't want to establish any kind of precedent for agreeing to ban access to particular sites (even as a courtesy). Instead, they're willing to police their customers (or at least the commercially unimportant ones).
I think our options are to take them up on that offer or to consider spending money to make this a real legal problem for them (by which I mean one that requires a formal response/expenditure of resources, not necessarily one they would be sure to lose). I doubt we would have to "go the distance" to get them to fold, and there could be some benefits beyond this particular scraper to establishing a record of willingness to be aggressive. But it's certainly a bigger undertaking that would require outside help and meaningful resources--I think we're likely at or close to the limit of what can be done without outside help.
Otherwise, I don't see a way to make our request more urgent to them. But perhaps others on this chain will have better ideas.

--- 2. Bright Data

From OWG: --- Dear Mr Baker,
Thank you for your email.
OpenStreetMap Foundation's Operations team contacted Bright Data because we have observed sustained, high-volume automated access to OpenStreetMap services consistent with large-scale scraping/crawling behaviour, including the use of rotating proxy IP addresses commonly associated with "residential" proxy networks. This activity has a direct operational impact on our volunteer-run services (including degraded performance and the need to apply defensive blocking and rate-limits).
By way of context, OpenStreetMap Foundation's is a small organisation with a large impact. I am keen to resolve this through clear, written technical steps rather than extended back-and-forth.

For clarity, our position is straightforward:

1. We are seeking effective technical mitigation to prevent Bright Data's network (including any SDK/bandwidth-sharing/proxy mechanisms) being used to access OpenStreetMap services in an abusive or unauthorised manner; and
2. We reserve the right to report suspected unlawful interference with our systems to relevant UK and relevant European authorities where appropriate, particularly as our servers are hosted in Dublin and Amsterdam. That is not intended as a "threat"; it is a standard protective step for a UK-based service provider responding to ongoing hostile or abusive traffic.

You asked for "full details" of what we characterise as scraping abuse and why Bright Data is involved. At a high level, the abuse we are addressing includes:

• Automated, high-rate requests against openstreetmap.org and related endpoints, conducted over large rotating IP pools to evade technical measures and blocking, including ignoring our robots.txt directives. We do permit certain legitimate automated access (for example, Archive.org's bot and major search engine crawlers such as Google) within clearly defined rate limits and in compliance with our policies; the activity at issue does not fall within those permitted categories;
• Access patterns consistent with crawling/scraping (systematic traversal, repeated fetches, and concurrency far beyond normal interactive use);
• Behaviour designed to circumvent technical controls (including frequent IP rotation, distributed request origination, and masking identity by presenting as standard browser User-Agent strings).

We publish full global data exports specifically so that third parties do not need to scrape operational websites/services:

• [1]
  

The data is available under the Open Database License (ODbL).

Given these bulk download options, there is no operational necessity to extract OpenStreetMap data by scraping our public-facing websites and services. Accordingly, we do not authorise any Bright Data customer or user to access OpenStreetMap services via Bright Data's network for automated crawling/scraping or other high-volume automated collection, and we withdraw any implied permission for such access.

Evidence and disclosure:
We maintain detailed technical logs for security and operational purposes. However, raw IP-level and third party access logs may include personal data under UK GDPR and are also sensitive from a security perspective. Accordingly, we are not in a position to provide "full" raw logs or a draft report for onward distribution.
That said, we are willing to cooperate constructively and provide a representative, non-personal summary of the indicators we are seeing (time windows, request characteristics, affected endpoints, volumes, and any non-personal identifiers), provided Bright Data first supplies the technical information needed to attribute traffic reliably.

Practical next steps for Bright Data:
To resolve this efficiently, please ask your client to provide, in writing:
# Confirmation that Bright Data has implemented enforceable blocks preventing use of its network/services to access:

• openstreetmap.org, osm.org, and related domains; and
• IP ranges listed at [2]

For the avoidance of doubt, controls that merely restrict "unverified users", or that require us to pursue individual customers, will not be sufficient. We require measures that block all users' attempts to access OpenStreetMap services via Bright Data's services.

# A current list of Bright Data egress IP addresses/ranges (for all relevant products: residential proxy, datacentre proxy, SDK/bandwidth-sharing, scraper tooling), or an alternative reliable method to identify Bright Data traffic (e.g., a stable header/token or published attribution mechanism), so we can validate attribution on our side.

# A brief description of the customer controls and enforcement actions Bright Data will apply to prevent recurrence (e.g., domain blocks, customer suspension/termination for attempts to target OSM services, and monitoring/alerting).

Once we have (2), we can compare against our logs and revert with a focused summary of what we can substantiate and what mitigations appear effective.
If Bright Data would still like a call, I am open to that once the above information is provided, as it will make a discussion materially more productive.

--- From Bright Data’s counsel:

Thank you for your email of 19 February which I have now been able to discuss with Bright Data.
Bright Data continues to believe that a call would be a productive step forward. During that call, Bright Data would like to better understand the nature of your concerns, and the information you are relying on as the basis for those concerns. This is a necessary predicate for them to be able to respond to your allegations of alleged “infringement.” In that regard, Bright Data does not believe that there has been any traffic that would cause any degradation of your servers or systems. Bright Data takes positive steps to ensure that users who are exercising their right to search the public web using Bright Data's services do not adversely impair the performance of any website those users search. If you are seeing high volume traffic, it likely is originating from another source.
To the extent you consider otherwise, it is of course incumbent on OSM to provide relevant details and information so that Bright Data can address OSM's concerns in an informed and constructive way. To date, no information or particularised complaints have been advanced by OSM.
Please let us know your availability for a call.

Issue: bot networks scraping the osm.org API and OSMF tiles.

Actions taken

• The operations team tried to get them to stop and some of them are pushing back.
• The operations team wrote politely, after feedback from the LWG, to several operators of proxy networks.

IPRoyal wrote back but they won't stop and they ask for more information. The operations team is resistant on providing more info, as it may provide more ways to them to evade.

LWG's stance seems to be: There is nothing that the LWG can do. We have provided legal language for communications to them.

The party that operates a proxy service probably doesn't want to:

• extend proactive guardrails to any party that asks for it
• particularly enable this customer
• subvert whatever detection systems we put in place

Suggestions

• share those IPs
• file a lawsuit - the Operations team would have to go to the board and ask for money
• ask the OPS what they ask the LWG to do. If they want to proceed with a lawsuit, they should ask the board for money.

Other points mentioned during discussion

• It is not possible for us to stop them by physical means.
• IPRoyal signaled a level of sophistication and familiarity with this kind of request that is unsurprising.

Action items

• Tom Lee to draft a reply to Paul that the LWG doesn't see any additional action that LWG can take. The Operations team can take the issue to the board, if they want to escalate, or they could consider accepting IP Royals offer. Tom will share the reply with Kathleen, before sending.
• Kathleen to modify Tom Lee's draft response to Paul and email the Operations team about Bright Data.

Second part of the discussion towards the end of the meeting:

OWG and scraping

Kathleen can copy the board when the LWG replies to the OWG.

These are requests routed through proxy services, hitting our tiles and API and overloading the infrastructure. OPS has been sending mutiple cease and desist letters to the services, in order to stop them from sending traffic to OSM. A couple of the services have pushed back, asking for the IP addresses we are seeing. The OWG is reluctant to provide that level of detail, as they might figure out how we detect them. Neither side wants to be the first to provide information.

The LWG can't do anything more.

Options

• Could hire a lawyer to sue them.
• No money for an attorney.
• Provide some IP addresses.
• This will probably not resolve the issue.
• Use a proprietary solution like Cloudflare.
• We were using Cloudflare and recently switched to Fastly.

Suggestions

• Craig proposed to talk with Paul and Grant.
• Technical solutions might probably be the easiest and cheapest for OSM to implement

Other points mentioned during discussion

• OWG does not have any easy technical solution.
• The data is free and they can have it via the planet files.
• AI is spreading widely and everyone wants to scrape data.

Done on March 9, 2026.

---

Redacted topic

Not discussed.

---

Queries to legal-questions

Large copyright infringement (Dopper - water taps) - Ticket#2025040310000645

Email shared by the LWG I am a long-time french OSM contributor, and I've been using Google Maps lately (I know, it's bad) for a hiking trip. I found out that a brand named "Dopper" (https://www.dopper.com/) has imported 130.000+ water tap POI from OpenStreetMap on Google Maps in Europe, in order to promote their water bottles.

Although I can't confirm that the 130 000 POIs have been "stolen" from OSM, 100% of those that I have checked have the exact same coordinates (even when the water tap doesn't exist anymore) on Google Maps and OSM. Here are a few examples:

OpenStreetMap coordinates	Google Maps coordinates	OSM Link	Maps Link
43,9638433 ; 7,4891674	43,9638433 ; 7,4891674	https://www.openstreetmap.org/node/5736598577	https://maps.app.goo.gl/ti6aG8mtugcnC4tp7
42,1715409 ; 9,0981284	42,1715409 ; 9,0981284	https://www.openstreetmap.org/node/7813320092	https://maps.app.goo.gl/qsGrms8SAV8cZYyC8
50,7806453 ; 5,2909056	50,7806453 ; 5,2909056	https://www.openstreetmap.org/node/8069274672	https://maps.app.goo.gl/7ptfv2U9K8RxXiXu8
53,2413833 ; 6,6018479	53,2413833 ; 6,6018479	https://www.openstreetmap.org/node/4302057226	https://maps.app.goo.gl/a1hriDmkFv6MWajQ8
47,2491583 ; 3,8710369	47,2491583 ; 3,8710369	https://www.openstreetmap.org/node/6970461670	https://maps.app.goo.gl/RmsG56ECrCN3rhiP7
46,3599675 ; 1,5759131	46,3599675 ; 1,5759131	https://www.openstreetmap.org/node/9776447890	https://maps.app.goo.gl/jmxW6tw2yd4NhXKbA
43,0676976 ; -1,3759707	43,0676976 ; -1,3759707	https://www.openstreetmap.org/node/9899108956	https://maps.app.goo.gl/1cutwDMzipXRxx5G9

Of course, they also use an OSM-based map on their website without attribution (https://www.dopper.com/products/tap-map), which reference all the water taps (same coordinates than OSM). Even if I can't prove that Dopper has been adding all of these water taps to the map, every Google Maps POI has a link to their website, and they have communicated on this marketing campaign on internet : https://localyse.eu/cases/localyse-helps-dopper-to-make-water-taps-visible-in-google-maps/ / https://weekend.levif.be/partenaires/dopper-au-top-5-faits-surprenants-sur-votre-gourde-durable-preferee/ / https://lehub.laposte.fr/la-marque-de-gourdes-dopper-ajoute-sur-google-maps-les-points-deau-potable.

Were you aware of this marketing copyright-infringement campaign? Is there anything OpenStreetMap can do about it?

Thank you in advance for your help,

15 June - Dermot sent letter to Dopper
Update: email was sent, automatic reply insisted on the filling of a general purpose form, no response to the form (except 2 “how did we do?” emails). We may wish to consider just letting Google deal with this, though there remains an issue of missing attribution on Dopper’s OSM map.

11 August: Dermot’s draft letter for Google (version 2):
I write on behalf of the OpenStreetMap Legal Working Group. Recently we were contacted by a member of our mapping community concerning an initiative on the part of the company Dopper, a manufacturer of water bottles. Dopper presents on its web site an interactive map containing the locations of many drinking water taps, and has also worked with a partner to import these locations into Google Maps: https://localyse.eu/cases/localyse-helps-dopper-to-make-water-taps-visible-in-google-maps/

Our contributor is concerned that many of the locations in question have been sourced from OpenStreetMap, citing identical geographical co-ordinates to many decimal places. This would represent a breach of OpenStreetMap’s Open Database Licence (ODbL), which requires attribution of source and sharealike. We assume that the import of such data into Google Maps would additionally violate your own requirements in terms of permitted data sources.

We have made a good faith attempt to contact Dopper so that they can address these issues, but the available communications channels have not resulted in a response. We therefore feel that it is appropriate to make you aware of the issue so that you can act appropriately to ensure that both your terms and ours are being upheld.

To illustrate the apparent OSM-sourcing, our contributor provided some examples of locations with matching co-ordinates:

OpenStreetMap coordinates	Google Maps coordinates	OSM Link	Maps Link
43,9638433 ; 7,4891674	43,9638433 ; 7,4891674	https://www.openstreetmap.org/node/5736598577	https://maps.app.goo.gl/ti6aG8mtugcnC4tp7
42,1715409 ; 9,0981284	42,1715409 ; 9,0981284	https://www.openstreetmap.org/node/7813320092	https://maps.app.goo.gl/qsGrms8SAV8cZYyC8
50,7806453 ; 5,2909056	50,7806453 ; 5,2909056	https://www.openstreetmap.org/node/8069274672	https://maps.app.goo.gl/7ptfv2U9K8RxXiXu8
53,2413833 ; 6,6018479	53,2413833 ; 6,6018479	https://www.openstreetmap.org/node/4302057226	https://maps.app.goo.gl/a1hriDmkFv6MWajQ8
47,2491583 ; 3,8710369	47,2491583 ; 3,8710369	https://www.openstreetmap.org/node/6970461670	https://maps.app.goo.gl/RmsG56ECrCN3rhiP7
46,3599675 ; 1,5759131	46,3599675 ; 1,5759131	https://www.openstreetmap.org/node/9776447890	https://maps.app.goo.gl/jmxW6tw2yd4NhXKbA
43,0676976 ; -1,3759707	43,0676976 ; -1,3759707	https://www.openstreetmap.org/node/9899108956	https://maps.app.goo.gl/1cutwDMzipXRxx5G9

We would be happy to be of any assistance possible in this matter.

Kathleen emailed Eric Dickinson (product counsel for Google Maps), who replied that he would look into it.
The examples of the original mapper were exact matches. Dermot found some inexact matches, which might be because Google already had the POI.

Previous action item: Dermot to check with original mapper on providing additional examples, if possible.

Dermot had replied to the original correspondent asking for additional examples of problematic data.

The original sender:

• provided around 98 locations that were identical (or within submeter precision) on Gmaps and OSM.
• provided the reasons why the locations might not be identical matches, e.g. due to the community shifting the positions after they had been imported to Gmaps, or due to the precision of the import process.
• noted that the locations with greater correlations between OSM and Google were in rural areas, which are less well mapped with Google Street View cars, or might be related to the fact that people tend to contribute data mostly in urban environments.

We haven't received a reply from Dopper - Dermot had contacted them via their online form.

Previous action item: Kathleen to provide copy of analysis to Google.' Done on 25 January 2026.

Dermot tried to find Dopper's contact information - they have not responded to his message via their webform.

Contact information

Dopper B.V.
Gonnetstraat 26
2011 KA, Haarlem
The Netherlands
+31 (0)23 2049900

Dopper's registration
Dopper Netherlands
Chamber of Commerce number: 57084556
VAT number: NL-852431466B01

Email addresses

• service@dopper.nl
  
• info@dopper.nl
  

Dermot might have emailed service@dopper.nl or info@dopper.nl and got redirected to the webform. Will check.

Dopper CEO: Virginia Yanquilevich
https://www.linkedin.com/in/virginiayanquilevich/

Suggestions

• OSMF to hire an attorney in Netherlands to write a formal letter to Dopper. We could send it to their official address and copies via electronic means.
• Find contact information for their legal department or CEO.
• We can try privacy@ and legal@

Other points mentioned during discussion

• Privacy policy: https://www.dopper.com/legal/privacy-policy

Previous action items'

• Dermot to find email addresses for their legal department or CEO.
• The LWG to ask the Board to authorise them to act on Dopper not abiding with the ODbL. An attorney from the Netherlands must be found.
• Kathleen to ask Lawdit for a firm in Netherlands.

LWG internal reference: https://otrs.openstreetmap.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=65356

• Google has not replied but it seems they have removed Dopper as a source.
• The data might still be in the Dopper dataset.
• No point unless we want to go for legal action.

Input from OSMF Chair, Craig Allan, present at the meeting

• Dopper has removed many of the water taps in Amsterdam.
• Some water taps remaining
  • presumably those are the ones that didn't coincide.
  • some of the remaining water taps did not have a link to Dopper.

Attribution and share-alike issues

https://www.dopper.com/products/tap-map

• Attribution: They have an OSM basemap with points overlaid, without attribution to OSM.
• Share-alike: Assuming that they have both OSM and non-OSM data on their map, they have a share-alike problem.

Suggestion: We tell Dopper to release to us their non-OSM sources, as we are in favour of more open geodata.

Other points mentioned during discussion

• The ultimate goal for OSM is to be more open geo data.
• If they tell us that they don't own the non-OSM data:
  • we will tell them that they have to discontinue using the OSM data mixed with non-OSM, as this would be a licence breach.
  • they could have two separate layers, one from OSM and one for non-OSM.

Action items

• Dermot to check whether some of the water taps have been removed, as mentioned by Craig Allan.
• Dermot to follow up with Dopper regarding releasing non-OSM water tap sources listed on Dopper’s map.

---

EVRI delivery company using OSM without attribution? - Ticket#2026010610000189

Email shared by the LWG is this substantial or not

(Screenshot attached)

Their main map is missing attribution: https://www.evri.com/find-a-parcelshop/#/

They are using these service: https://www.vectorine.com/
https://www.vectorine.com/impressum
Thomas Skowron Barbarastr. 29 50354 Hürth Germany
E-Mail: support@vectorine.com
VAT ID: DE321720437

Previous action item: Tom Lee to reach out to Vectorine regarding compliance to ODbL, and if that doesn’t work, to Evri.

LWG internal reference: https://otrs.openstreetmap.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=77004

Tom reached out, received word that EVRI acknowledged need for attribution.

GRAB and OSM attribution - Ticket#2026011810000246

Email shared by the LWG Hello, does OSM aware that GRAB is using open street map in South East Asia to manipulate drivers and riders in e-hailing and food delivery? Im not sure whether the screenshot below fulfill the term: provide credit to OSM by displaying our attribution notice, because in grab app, Open Street Map becomes GrabMaps. You guys are aiding grab to squeeze drivers and riders by giving them the map monopoly power where fares are not transparent and up-to-grab, without the transparency for driver and rider. I hope OSM stop grab from using OSM as they are not crediting OSM team in obvious way but taking every credit as their trophy. 

Previous action item: Kathleen Lu to ask the mapper what happens when you click on the (i). Sent on February 9. No reply as of March 9, 2026.

LWG internal reference: https://otrs.openstreetmap.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=77501

We haven't received a reply from the mapper with more details, as on 9 March.

Grab is an OSMF Corporate Member and they will work with us, if there is a problem.

Action item

Kathleen to ask the mapper what happens when you click on the (i).

Sent Feb 9. No reply as of March 9.

---

OpenMediaMap via legal@

Email shared by the LWG Just in case nobody has pointed this out <https://www.openstreetmap.org/user/hmaharoof/diary/408171>

On the site it claims that the name is trademarked fwiw and doesn't bother with any attribution of OSM.

Cheers
Simon

Previous action item: Kathleen to message them re trademark, homepage tile image, and attribution

sent Feb 9: Dear hmaharoof,
We at LWG (the OSMF Legal/Licensing Working Group) recently learned about your new project OpenMediaMap. It looks very interesting. However, we do feel obliged to point out that, apart from some legacy projects that pre-date the policy, the https://osmfoundation.org/wiki/Trademark_Policy discourages use of the "Open___Map" naming structure for individual projects due to the potential risk of confusion as to a project's official status, especially as project grow and become more popular. In particular, the use of the TM trademark symbol is concerning as to the project's intentions.
Since the project is just launch, we strongly encourage you to pick a unique name other than the Open___Map format.
Additionally, we noticed when looking at your homepage that the map on the homepage appears to be a hardcoded tile location. This is a rather inefficient use of the map tiles, and the standard map attribution is also cut off by the frame. Given that the map doesn't pan/zoom until one clicks into the main map, we would suggest that a static map image with attribution in the corner would be better for the homepage.
We do not want to discourage you from pursuing your project, but we hope that you are open to these adjustments. Thank you,
Kathleen Lu
Chair, on behalf of the
OSMF Legal/Licensing Working Group

Hello,
Thank you for your kind approach to my project and the naming issue.
I was not previously aware of the trademark policy. I have not filed any trademark applications, and I will be renaming the project ASAP to a unique name. This change will be implemented as soon as I finalize a replacement name.
I also appreciate the feedback regarding the homepage map tiles, and I will be updating the homepage to ensure proper attribution.
Thank you again for the guidance and encouragement. Do keep me updated regarding OSM community standards and policies if anything else arises.
Best, Hasan

We received a polite reply from them that they will find a new name for the project called "OpenMediaMap".

• Their diary entry https://www.openstreetmap.org/user/hmaharoof/diary/408171 currently still points to a page mentioning "OpenMediaMap".
• No newer diary entries from them.

Action item

Kathleen to ask them to notify us when the name change is complete.

March 9: Thank you Hasan, please let us know when your name change is complete. Best, Kathleen

---

Strava Ticket#2026021710000586

Email shared by the LWG Since last year I am working on a project in which I make use of OpenStreetMap data.

We are looking forward to making publications (maps), but I am not 100% sure I am making making the right interpretation from legal perspective.

Here is what I do.

I (Mart Reiling, Track-Landscapes) have made maps for 'Stichting Wandelnet' that visualise walkable infrastructure. The basis for that is OpenStreetMap highways. Though; important for these maps is the distinction on whether a pathway is publicly accessible or not. OSM sometimes contains tags for this, but often not, and tags may be wrong.

What I tested to do here, is adding Strava Metro data (metro.strava.com), to make an estimation on accessibility based on whether a road has been used by a pedestrian that used Strava. Strava Metro data is also based on OpenStreetMap, meaning that you get numbers (amount of passages) of every road in OpenStreetMap.

Basically; I devide OSM highways into two classes '(almost) not used' and 'used' by looking at usage/counts of Strava Metro. So that there are no raw Strava counts/numbers anymore.

When a road is '(almost) not used', I expect that road as a non-public road. Then I also look at highway classes and tags; and based on the combination of these I make an estimation on accessibility. It then gets categorised as 'accessible', 'probably--accessible' or 'probably-not-accessible' or 'not-accessible', which determines how the road is visualised in the map (color, thickniss, or not shown at all).

This is, as I understand it, a derivative database on which 'share alike' would be the case.

• Now, would that mean that it is an obligation to share raw Strava Metro data? Because that is not allowed.
• Or, would it be sufficient when I share the values of the usage-class; being '(almost) not used' or 'used' ?.
• Or, would it even be sufficient when I share my created 'accessibility' end-classes, the values 'accessible', 'probably-accessible' or 'probably-not-accessible' or 'not-accessible' ?
• Or, would it even be sufficient when I share my (R) script in that contains all the rules for determining the categories? So for example;
• - if highway=service and usage=not_used, then accessibility=probably-not-accessible.
• - if highway=service and usagenot_used, and tag=foot_permissive, then accessibility=probably-accessible.

I have also asked Strava Metro on what is allowed on their behalf; they say that sharing highwayusage-class; being '(almost) not used' or 'used' would be allowed in a public webmap, if the region that the map shows has applied to Strava Metro. So for example, If i make/publish the map for province 'Utrecht' then the province of Utrecht must have access to Strava Metro.

If the region that I show the map of has not applied to Strava Metro, then they only allow 'highwayaccessibility' classes.

The case is actually really quite interesting for OpenStreetMap, because it would also mean that roads where accessibility is unclear, will be visible in a public webmap. OSM contributors (like myself) could use this to identify roads where tagging is missing or incorrect, and then improve that in OSM (after checking these roads in the field, or including their local knowledge, because data of usage never guarantees a certain level of accessibility).

The sender:

• refers to roads that are already mapped on OSM.
• seems to draw inference from the fact that many Strava users can be seen to be going along a certain path.
• wants to decide based on the observations above, whether public access is permissible.

Reason for email: LWG's feedback on whether his project triggers share-alike.

On Sharealike

• Sharealike is not triggered, because he uses a type of data we don't manage. The quality of estimation about whether something is accessible, is not something that is mapped to OSM. So, it is not subject to share-alike, as there is no counter-part in OSM. It is a data type layered on top, that OSM does not use.

- The database that the sender is creating is either under the collective database guideline or horizontal layers - it is not attached to the ODbL features.

On information that could be used to improve OSM

• The sender suggests that the data he creates can be used as reminders for mappers to look at a road's public access and to update the tags, if necessary.
• The mappers would be checking, either on the ground, or satellite/street imagery e.g. regarding sidewalk presence, and would be the ones updating OSM. So, the mappers will be providing an independent source for OSM edits.

Other points mentioned during discussion

• A lot of mappers would be wary about the vagueness of the conclusion whether an OSM highway= is publicly accessible.

LWG's stance is

• Probability of accessibility is not a trait subject to sharealike because there's no equivalent in OSM.
• Should have no affect on Strava data.
• The information could be useful to mappers.

Action item

Kathleen to reply -- done March 9

---

Topic redacted

Minutes redacted after request.

---

LinkMyRide using OSM in App without attribution

Email shared by the LWG OpenStreetMap Ireland (local chapter) wishes to escalate this matter to LWG after sustained ignoring of many approaches by app creators. Seeks LWG approval for:

1. Dermot, in name of LWG, to approach app creators, reiterate complaint, demand assurances on provision of correct attribution and threaten to seek removal of their app from app stores on grounds of copyright infringement in the absence of this remediation.

2. If no resolution, proceed with formal process to request app store removal

Back story:

https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution

First spotted: 15th May 2025 by Anne, OSM Ireland Board

16th May: CEO of LinkMyRide claimed "We actually get our map data from Mapbox". Immediate reply sent to clarify actual data ownership and requirements.

> Quickly responded to by LMR: "Ok! I wasn't aware of that! We are in the process of releasing a large update at the end of June. So I will make sure our tech team get that attribution added."

Early July - email sent, no reply after 2 weeks

Jan: email sent, no reply

Early Feb:

<screenshot>

> LinkedIn request to connect was ignored. The view in OSM Ireland is that they are at worst willfully ignoring us, and at best, very lax. This is why we feel that the leverage of app distribution may be needed to ensure some focus.

Issues

• No attribution in app.
• Communication ceased.

Points mentioned during discussion

• Dermot was not involved in any of the previous communications.
• They are a Mapbox customer.
• Tom Lee (Mapbox) is happy to contact them and get this resolved * he has participated in many similar calls with Guillaume.

Other points mentioned during discussion

• When a companies' customer gets an email from an institution they have never heard of,telling them that they have a copyright problem that's like that's pretty bad.
• Sometimes people leave companies, things get dropped and it is difficult to reestablish contact.
  • The first contact was the CEO.
• Preferable to first try to resolve via Mapbox, than to escalate to the app store as a copyright infringement issue.
• They might be overstretched.

Action item

Tom Lee to reach out via Mapbox (and also connect with Dermot)

---

 2026 LWG meeting times

Jan 12, at 18:00 UTC
Feb 09, at 18:00 UTC
Mar 09, at 18:00 UTC (US switch Mar 8, Europe switch Mar 29) (11am PDT/2pm EDT for US attendees)
Apr 20, at 17:00 UTC
May 11, at 17:00 UTC
Jun 08, at 17:00 UTC
Jul 13, at 17:00 UTC
Aug 17, at 17:00 UTC
Sep 14, at 17:00 UTC
Oct 19, at 17:00 UTC
Nov 16, at 18:00 UTC (same as normal hours for everyone)
Dec 14, at 18:00 UTC

---

Meeting adjourned 56 minutes after start.