Licensing Working Group/Minutes/2026-09-14
OpenStreetMap Foundation, Licensing Working Group (LWG) - Agenda & Minutes
14 September 2026, 17:00 UTC
Approved during the 2026-10-20 LWG meeting.
Participants
- Kathleen Lu (Chairing)
- Dermot McNally
Absent
- Simon Hughes
- Tom Lee
Administrative
Adoption of past minutes
- 2026-08-17 Approved
- 2026-06-08 Pending, as Tom Lee is absent
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 εmailed them on 10th Nov, no reply
- Ticket#2022012610000149 poster.printmijnstad.nl/editor/city
- Ticket#2022033010000217
- complaint that Aberdeen city council may not be attributing correctly – Aberdeen city council consultation
- 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 - Evri parcelshop finder
- 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: Google Play Store app listing
- Ticket#2021120810000146 mondialrelay.fr not attributing correctly
- Ticket#2022120510000177 — Club Vosgien complaint – any reply?
Board items
Any followup to the ChatGPT issue?
| Email shared by the LWG |
|---|
| Dear LWG,
I got sent this Mastodon toot (Mastodon post), warning that ChatGPT uses Mapbox basemaps (which then use OSM data) without attribution. I have tried this myself with this query ChatGPT query, checked areas I usually map for confirmation that the basemap matches (it does), and also checked through the network requests that indeed, the tiles are fetched from Mapbox. [screenshot attached] Given that ChatGPT is widely used nowadays, I believe we have to try extra hard to ensure they cite its basemap correctly. I found this form: Copyright dispute form Should I fill it out, or should we contact them another way? I wanted to contact you as LWG before going ahead myself. If there is no complaint from your side in a week's time, I will send myself. Mapbox has an attribution guide we can point to in the request: Mapbox attribution guide [screenshot attached] |
| 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" (Dopper website) 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:
Of course, they also use an OSM-based map on their website without attribution (Dopper 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 : Localyse case study / Le Vie article / La Poste Hub article.. Were you aware of this Thank you in advance for your help, 15 June - Dermot sent letter to Dopper 11 August: Dermot's draft letter for Google (version 2): 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:
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. Previous action item: Dermot to check with original mapper on providing additional examples, if possible. Previous action item: Kathleen to provide copy of analysis to Google.' Done on 25 January 2026. Dermot had replied to the original correspondent asking for additional examples of problematic data. Dermot tried to find Dopper's contact information - they have not responded to his message via their webform. Dermot might have emailed service@dopper.nl or info@dopper.nl and got redirected to the webform. Will check.
Other points mentioned during discussion
Previous action items
Google seems to have removed Dopper as a source Update: no reply to Dermot's email to CEO Still no reply. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| LWG internal reference: View ticket #65356 |
While the LWG thinks that data has been removed from GoogleMaps, Dopper probably still has the data.
Suggestions:
- Put a letter to OSMF letterhead. Dorothea can provide a letterhead template, if needed.
- Escalate the issue to the board.
- The board has other topics to deal with.
Other points mentioned:
- It is ultimately up to the board.
No formal decision was made, but the LWG leaned towards leaving the matter as it is.
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: Evri parcelshop finder They are using these service: Vectorine Previous LWG updates: Previous action item: Tom Lee to reach out to Vectorine regarding compliance to ODbL, and if that doesn't work, to Evri. Tom Lee reached out March 31, received word that EVRI acknowledged need for attribution Note: Also related to Ticket#2022032710000125 - Evri parcelshop finder – attribution problems in multiple places Tom in conversation with Vectorine dev... |
| LWG internal reference: View ticket #77004 |
Not discussed.
| Email shared by the LWG |
|---|
| Flagged by former board member Joost Schouppe. |
Issue: GitHub organisation github.com/osm-foundation, which seems to stand for "Open Source Macedonia". Typing OSM into GitHub almost auto-populates this option, so it is potentially confusing.
- Issue flagged by Joost Schouppe, former board member.
- The repository was created 2 weeks ago in North Macedonia.
- No public repositories, just a few commits.
- The profile mentions that it is created by a passionate nine-year-old developer from Macedonia - might be vibe coded.
Action item
Kathleen to create a GitHub issue politely asking whether they might consider a different name to avoid confusion. Done: GitHub issue #2
Request from Cameroon for OSM Forge Hub
| Email shared by the LWG |
|---|
| Does the Board have an opinion on the matter?
Dear OpenStreetMap Foundation team, My name is Modo Levo Engelbert Steve. I am a geomatics engineer based in Yaoundé, Cameroon, an OpenStreetMap contributor since 2023, a HOT voting member, validator and mentor, and one of the UN Maps Community Ambassadors for 2026. I also founded OSM ENSTP, a student mapping community in Cameroon. I am writing to ask for your guidance and, ideally, your authorization to use "OSM" in the name of a new association I am creating: OSM Forge Hub. I want to be transparent about the vision, because it is built entirely around strengthening OpenStreetMap and the open data community. I am a dreamer, and I see an Africa that is master of its own destiny, with its youth as the driving force and open data as the lever. This is not abstract: about 60% of Africa's population is under 25, making it the youngest continent in the world, and by 2030 young Africans are expected to make up around 42% of the world's youth. Africa needs these young people, and it needs to multiply initiatives that train them into leaders and give them real opportunities. My conviction is simple: young Africans should not merely consume data produced elsewhere; they should create it, own it, and use it to solve the real problems of our societies. I believe deeply in the power of data, and I am passionate about spatial intelligence and what it can bring, not only to my country but to Africa and the world. OSM Forge Hub is an association starting in Cameroon, with the ambition to grow across Africa, built around three connected goals: - Education: train young people to understand the value of open geospatial data and to create and use it (OpenStreetMap, crowdsourcing) in their studies, research and projects. In short, the association exists to grow the OSM community, starting in Cameroon and extending across Africa, a region where this model is still largely absent, and to put OpenStreetMap at the center of youth education, leadership and local development. I understand that "OpenStreetMap" and "OSM" are trademarks of the Foundation, and I want to do this the right way, with your blessing and in line with your trademark policy. I would be grateful to know what conditions apply and what I should provide for you to consider the request. Thank you for everything the Foundation does for our community. I would be honored to build this in partnership with you rather than beside you. |
The LWG doesn't know who the person is, their relationship to the local community, what the project entails, or how much it interests other OSM people and HOT.
The email was also sent to the board. Kathleen followed up with a note to the board saying this is outside the standard policy and that the board could have something custom drawn up.
Referred to Board for direction.
Any other business
Attribution and licensing of OSM derived routing results within NeTEx and GTFS - Ticket#202608071000030
| Email shared by the LWG |
|---|
| As you may be aware, OpenStreetMap data is currently shipped in many transit related authoring software suites. I am not talking about a basemap, but the pbf files are transformed in some way or the other so they become routable, replacing historic vendors like TomTom and Here. The result is either exported in NeTEx (Europe) as RouteLinks or ServiceLinks, or in GTFS (worldwide) via shapes.txt. That result is either presented on a map as an extra layer, or used as input for map matching to an internal dataset. In both use cases the coordinates (not attributes) are distributed without any attribution, in a different format, maybe even geospatial projection as the original.
From a legal framework the question arises if a result of a routing engine using OpenStreetMap requires attribution and/or the same ODbL license, for at least that subset of the published dataset. From the Attribution Guidelines the following quote can be obtained: Routing instructions generated by such a routing engine need not maintain attribution attached to the instructions, as long as they do not form a Derivative Database. From any understanding: a NeTEx or GTFS does form a new database, but I could also argue a GeoJSON file would also fulfill that, which makes the "instruction argument" vague, because the presentation format should to change legal outcomes. While for the Dutch use case, we do have government alternative CC-0 sources, and the ability to generate geospatial data directly from GPS traces from automatic vehicle location systems, having a discussion on the matter would make sense. There is currently an opportunity to define the impact. Previous LWG update: Dermot to investigate what is the underlying question. |
| LWG internal link: View ticket #89275 |
Dermot asked Stefan to clarify which specific pieces the LWG can help with. The linked GitHub discussion seems to be about whether a repository should include OSM attribution when appropriate and how to do that.
The LWG will wait for Stefan's reply.
Lizensverstoß, Flyer without attribution - Ticket#2026062010000125
| Email shared by the LWG |
|---|
| Machine translation: Hello. Today, I received a flyer from what it claims to be a non-NGO that features a map based on OSM data. Unfortunately, there is no indication of the source or the license. See the attachment for images. Should I contact the copyright holder myself?
Perhaps someone can respond to him in German that since OSM was clearly attributed, enabling him to find us, it's sufficient? Tom Lee to follow up. Note: there was no attachment. |
| LWG internal link: View ticket #86157 |
Skipped, as Tom Lee (absent) is following up.
Canada: Town of Oakville Open Government License compatibility - Ticket#2026090110000031
| Email shared by the LWG |
|---|
| I'm sending this email, as the procedure on OGL Canada wiki page requires, because I followed the procedure and concluded that the license for the open data provided by the Town of Oakville.
The license can be accessed at Oakville licence PDF which is linked to at Oakville open data page. The procedure on the wiki says that I should compare the license to the license of Ottawa and if the differences were limited to the four criteria listed, I should add Oakville to OSM Contributors page and email my explanation this way. I believe this license is different to Ottawa's only in the ways in that list: 1. References to the name of the locality - Oakville's license uses "Town of Oakville" instead of "City of Ottawa" throughout I have a MapRoulette challenge that I started based on the Oakville data, which I paused as soon as another OSM user informed me the Oakville license had not yet been approved. Now that I have followed the procedure as defined in the wiki, to the best of my ability, I plan to keep the challenge paused for at least one week to allow time for reply to this email in case I have made any errors. Please let me know if I have not followed the procedure properly or if you have any other questions or concerns. |
| LWG internal link: View ticket #90762 |
No issues raised.
Action item
Kathleen to let him know it's approved.
Fuel price app - Ticket#2026083010000139
| Email shared by the LWG |
|---|
| Hello OSMF Licensing Working Group,
We are assessing a commercial Australian fuel-price application that may enrich its own station records using OpenStreetMap. The proposed process would query OSM for candidate fuel-station POIs near existing independently sourced station coordinates, match the candidate, and copy only explicitly tagged amenity facts such as toilets, shop, ATM, car wash, food, and opening-hours indicators into a provenance-aware internal database. Missing or uncertain fields remain unknown. The app would publicly display these amenity facts, with OpenStreetMap attribution and a link to the ODbL/copyright page. We would not redistribute an OSM extract, map tiles, or a general-purpose geodatabase. A pilot involved 500 stations, with OSM used for 298 station matches; production could eventually cover fuel stations nationally. Official operator data would remain separately sourced and separately attributed. Could you clarify whether systematically retaining these amenity tags for one primary feature type across Australia would create a Derivative Database subject to ODbL share-alike, or whether it may remain a Collective Database / collection of insubstantial extracts if provenance and source separation are preserved? If the answer depends on scale, schema separation, public display, or another design detail, please identify the relevant threshold or recommended compliant structure. We understand OSMF guidance is not legal advice and will obtain Australian legal advice if necessary. Kind regards |
| LWG internal link: View ticket #90654 |
Potential issue: There may be a derivative database problem if the amenity tags overlap with the operator data.
The sender has fuel station locations and names from an official non-OSM database. They seem to want to find the nearest OSM fuel stations and want to copy information such as toilets, shop, ATM, car wash, food, and opening-hours to an internal database.
- The internal database would maintain metadata for each amenity fact, recording the source (OSM or not).
- The app would display the facts with OSM attribution.
Discussion
- This seems like a horizontal layer case.
- If they want to find extra stations, they would have to make the existing station locations available under share-alike. This would not mean sharing their entire dataset, for example turnover data for those stations.
Action item
Reply and emphasize that the key is to source each primary feature (e.g. ATM) from either OSM or non-OSM, or to share back the non-OSM data for any primary feature that is from "mixed" sources.
iTagTip - Ticket#2026090410000785
| Email shared by the LWG |
|---|
| Hello OpenStreetMap Team,
I am reaching out on behalf of iTagTip, a location-based mobile application that allows users to discover points of interest and receive location-aware notifications. Some of the location data displayed in our application originates from OpenStreetMap, while other locations are sourced from our own users, business partners, public data sources, and proprietary datasets. As a result, only a subset of the tags and locations presented within the app are derived from OpenStreetMap data. We would appreciate clarification on the preferred and compliant way to provide attribution in this scenario. Specifically: We want to ensure that we fully comply with both the spirit and letter of OpenStreetMap's attribution requirements while providing a clear and uncluttered user experience.' Kind regards, |
| LWG internal reference: View ticket #91090 |
They seem to want to make a derivative database, as they want both datasets on the same map view. It is not 100% clear whether the locations are for the same primary feature types. For example, if museum locations came from a government source and hotel locations from OSM, then it would be a collective database.
Action item
Kathleen to reply and emphasize that each primary feature needs to be either all OSM or non-OSM. If they mix it, they should share the data.
Hiking app DB - Ticket#2026090810000769
| Email shared by the LWG |
|---|
| Dear Licensing Working Group,
I am building a mountain database for a hiking app and would like to check one interpretation with you before the architecture is fixed. I have read the Collective Database Guideline, the Produced Work Guideline and ODbL sections 4.4 to 4.6, and my question concerns a case the guidelines do not seem to address directly. What the database contains The summits themselves are not taken from OSM. They are computed from public elevation models (Copernicus GLO-30, Sonny's DTM, national LiDAR) with a prominence algorithm, which finds the peaks independently. OSM contributes the name of a summit, its node position, and where present the ele tag. The stored table has 72 columns. Every column is filled from exactly one source, and no column ever mixes: from OSM (16 columns) osm_id, name, name_de, name_en, alt_name, int_name, kind, osm_lat, osm_lng, osm_ele, wikidata, country_osm, country_osm_alt, range_osm, range_osm_de, range_osm_path computed or from other sources (56 columns) elevation_dem_m, prominence_dem_m, isolation_dem_km, saddle positions, elevation_wikidata_m (CC0), the resolved elevation_m / prominence_m / isolation_km and their *_source columns, and so on elevation_m is resolved from a fixed hierarchy of non-OSM sources. It is never filled from osm_ele, and osm_ele never enters any calculation. OSM has no tag for prominence or isolation, so those two are entirely ours in any case. This follows your guideline's phone-number example, with elevations in place of phone numbers, and we rely on the sentence that two datasets "need not be physically separated" to qualify as independent. The three questions 1. Display-time fallback. For about 14 % of rows we have no elevation of our own and none from Wikidata, but OSM carries one. May the application, at display time, show osm_ele for those summits — clearly attributed — while the stored elevation_m column remains empty? The stored columns stay separate; the choice is made per summit when rendering. 2. Filter queries reading both columns. May a query read both columns without materialising the result, for example WHERE elevation_m >= 2000 OR (elevation_m IS NULL AND osm_ele >= 2000) so that a user filtering by elevation also finds summits whose only elevation is the OSM one? No mixed column is stored, no index over a combined value is created, and the result is rendered rather than exported. 3. Scope of the section 4.6 offer. We read the guideline as saying that share-alike "only applies to the parts containing or derived from OSM-data", and we therefore plan to offer the 16 OSM-derived columns listed above as a free ODbL download, attributed to OpenStreetMap contributors, alongside the published app. Please let us know if you read that differently. Any pointer would be much appreciated. I understand you cannot give legal advice, I am asking how the Foundation reads its own guideline, and I would rather build it correctly now than discover the problem after release. Thank you! |
| LWG internal reference: View ticket #91535 |
The hiking app seems to want to use OSM elevations as a fallback, when their own elevation field is empty. Their elevations are computed from public elevation models.
- A display-time fallback would result in a derivative database.
- Elevation column: If they want to use OSM as fallback, only this column seems to be the issue.
Discussion
- Matching a peak in their dataset (for example Mount Everest) with the OSM peak in order to take its elevation, requires mixing their peaks with OSM peaks, because the match involves judgements on location or name.
- References are permitted in general. Example of restaurant phone numbers: if one has their own database of restaurant phone numbers, then matching on OSM names and addresses, and displaying own phone numbers (nor taking any from OSM) would be fine.
- If some phone numbers were missing, and they would fill them in using OSM phone-numbers, that would be a case of a derivative database.
On this case
- Elevation seems to be an overlap of type of data they are pulling both from OSM and from other sources.
- The data sources they use do not appear to have clear licencing and appear to be partly owned by private entities. Some seem to come from universities, where the openness to sharing for research is not the same as licensing, and the universities do not own the data.
- If they want to mix the elevation sources, then they are creating a derivative database, which will trigger sharing obligations - which they might have no right to enter into.
Action item
Reply that using OSM elevation as a fallback would likely create a derivative database.
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 48 minutes after start.