Licensing Working Group/Minutes/2025-06-16
OpenStreetMap Foundation, Licensing Working Group (LWG) - Agenda & Minutes
16 June 2025, 18:00 UTC
One topic was redacted from the minutes, as decided by the LWG during their July 2025 meeting.
Participants
- Kathleen Lu (Chairing)
- Dermot McNally
- Tom Lee
- Guillaume Rischard (OSMF board member)
- Minh Nguyễn (OSM core software development facilitator, guest, until 32’)
Absent
- Tom Hummel
- Simon Hughes
Administrative
Adoption of past minutes
- 2025-05-12 Approved - Minutes for "EU move" and a DWG topic to be redacted.
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?
Heat Map issue
Background |
---|
Proposed response from Kathleen:
Dear all, Best, |
Action item: Tom Hummel to add edits.
Osm-website query
Email shared by the LWG | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
(see https://antonkh.dev.osm.org/docs/2025-05-26-tou.html for images)
Dear Licensing Working Group, Now I have a question about the GDPR-related changes to the osm website. The question is at the end of this email. It's still not clear what is supposed to be done about GDPR. The smaller part of it is "to make accepting the terms of use a requirement", which is a quote from the EWG, the thing that they want to happen next. The obvious two questions about it are:
Possible answers to question 1 are:
Doing any of this requires an answer to question 2 because you won't be able to fulfill the requirement otherwise. An answer to question 2 is likely that there should be a webpage that you can either voluntarily visit or you are force-redirected to when you try to log in. That webpage probably has a link to the terms of use and a checkbox that says "I'm accepting the ToU". You tick that checkbox, click the submit button and you've fulfilled the requirement. Or at least it seemed to be the plan when this pull request was made in 2018. That pull request changed the new account registration page, or actually one of the pages because you had to complete two pages. One of the pages showed you the contributor terms and had a checkbox "I have read and agree to the above contributor terms". The pull request added a similar checkbox for the ToU: "I have read and agree to the Terms of Use", which you had to tick in order to create an account. So it was considered that after the pull request was merged, all newly created accounts had agreed to the ToU, but older accounts had not, hence the requirement. Making the ToU acceptance mandatory for older accounts was supposed to happen later, before other restrictions go into force. But things have changed since. There was a redesign of the signup flow that removed the "I agree" checkboxes from new account registration pages, and removed the terms page, replacing it with links to terms. So now new users don't have to tick any checkboxes to accept the ToU. All they have to do is to click the Sign Up button that has the following text above: "By signing up, you agree to our Terms of Use, privacy policy and contributor terms." Does it mean that old accounts also don't need checkboxes, and if they don't, what do they need for the requirement? However the terms page is not completely gone. It is still shown to even older accounts, those that predate the 2012 license change and haven't accepted the contributor terms. The terms page still has the two checkboxes for CT/ToU, and those users have to tick them in order to get write access to osm. So the situation currently looks like this for those who haven't accepted the terms:
[image]
[image]
The easiest thing to do is still to use the same terms page as for pre-2012 accounts and lead to it those who haven't accepted the ToU, make them tick the checkbox and click continue. That's what I tried to do in this pull request. But turns out there's a completely different opinion coming from the OWG members: [1] [2]. Their logic seems to be this:
By this logic active 2012-2018 accounts have already accepted the terms and fulfilled the requirement. Inactive accounts will fulfill the requirement as soon as they become active, which is going to happen if they do anything that could be the answer to question 1. Great, we don't need to do anything about the GDPR! But that seems to be not what the EWG wants. Also it's not what a certain former LWG member who happened to write the 2018 pull request wants. What does the EWG want? Currently they want what's written in Make OSM comply with the GDPR project description. It includes the phrase "all users will be required to accept the Terms of Service" (emphasis mine). So currently the users are not required to accept the terms but they should be, in contrast with the OWG opinion where the users have already accepted the terms. The project description also refers to:
Here's the 2x2 table from list of affected services:
This table wasn't produced by the LWG, unlike GDPR Position Paper. In fact it was added by a DWG member. Note that the entire not accepted column is impossible under the OWG interpretation. Looks like most parties disagree with the OWG on this and users have to do at least something to accept the ToU. Now the actual question to the LWG: what do we do next about the GDPR-related changes? The options are:
|
We have a record of whether a user has accepted the ToS. This option has been presented to people who have signed up as of a certain date.
- ToS https://osmfoundation.org/wiki/Terms_of_Use mention that ""your continued use of the Services after new Terms become effective constitutes your binding acceptance of the new Terms."
- Old discussions about plans to roll out more broadly a checkbox for accepting ToS.
- Unclear what the current plans are.
Users can be divided in different groups
- People who didn't agree with the ODbL. Their accounts were deactivated. Reactivation would need them to accept the contributor terms, which would include ToS.
- People who agreed to contributor terms but didn't have the opportunity to agree to the terms of use (checkbox option).
- Newer users who have this flag set, as they signed up after that was added to the login flow. Unclear if that database column is canonical.
Link shared: https://antonkh.dev.osm.org/docs/2025-05-26-tou.html
- Pre-2012: People who didn't agree to ODbL had their accounts deactivated. If you have a pre-2012 account and have not accepted the old licence, we present this form [Image], where people have to tick 2 checkboxes (contributor terms + terms of use) to reactivate their account. CC-BY terms. We probably don't have a screenshot of how the sign-up page looked back then.
- 2012: Licence change.
- 2012-2018: Nothing presented to people signing-up for an OSM account. No explicit checkbox with ToS. We did have contributor terms, which were shown as part of the migration process, but not the log-in flow.
- Before 2018 (GRPR): No privacy policy. Not agreed to any terms.
- After 2018: People signing-up for an OSM account get "By signing up, you agree to our Terms of Use, privacy policy and contributor terms".
- 2019: People signing-up for an OSM account get the checkbox to agree to the ToS.
On terms
- Unclear if there were terms before 2018 and if there was a clause about updating them.
Notice of ToS change at the time (2018)
- At the time of change, it would be expected that we would have emailed existing OSM account holders, notifying them of the updated terms. This email would mention that continued use of the service after a specified number of days, would constitute agreement to the new terms.
- LWG members do not remember receiving such a notice at the time.
- The text appears somewhere now.
- Unless they received notice of the change of terms, people who signed up between 2012 and 2018 are not covered are not covered by the new terms. They wouldn't have to click anywhere, just receive the notice.
- If the original ToS did not specify something along the lines of "we will give you [x days] notice and if you keep using the service, you accept", then it is debatable if we could update via notice.
- We have to presume that the people who signed-up before 2018 did not get a notice of the terms update - so the update is not binding on them.
- Suggestion: We would have to "gate" the people who signed up between 2012 to 2018, in a similar way we "gate" the pre-2012 sign-ups. Everyone who hasn't agreed to terms, has to be locked down.
Changes to the current terms
XI. Changes to Services or Terms
"We may modify these Terms and other terms related to your use of the Services (like our Privacy Policy) from time to time, by posting the changed terms on the OSMF website. All changes will be effective immediately upon posting to the OSMF website unless they specify a later date. Changes will not apply retroactively. Please check these Terms periodically for changes -- your continued use of the Services after new Terms become effective constitutes your binding acceptance of the new Terms."
This is putting the obligation on the user to check the website - which is not enforceable. You have to give notice to people.
On API access
The terms seem to seem to apply to both the website and the API. Most APIs require some sort of authentication, e.g. a token tied to an account. If someone is using our API anonymously, we have no way to give them notice, e.g. via email. The Foundation's legal risks related to GDPR from anonymous API access would depend on whether any private information can be accessed.
Suggestions
- Include a section in the terms that explains the process for updating the terms.
- Ensure that access to personal information is only available behind a login.
- For people with OSM accounts registered before 2018, if f they do not agree to the new terms, they should not have access to personal information.
On other platforms
- Facebook: would not give unlimited, anonymous access to its API.
- There should be a way of displaying information to non-authenticated users.
- Reddit: you can look at posts without being logged-in. People are choosing to post publicly and they have agreed to Reddit's terms. So, there is access to the post's content, but not to the metadata associated with the user's activity.
On planet files
- We currently offer public planet files for download without a log-in. These files have some fields stripped.
- Planet files include timestamps of OSM edits.
Other points mentioned during discussion
- Timestamps are probably not personal information.
Action item: Minh Nguyễn to reply to Anton that the 2012-2018 cohort of osm.org sign-ups should be treated the same as the pre-2012 group.
Minh disconnected approximately 32 minutes after start.
From Operations – Releasing snapshot .csv files of OSM user profile data
Email shared by the LWG |
---|
Hi OSM LWG, I am seeking your legal view on publicly releasing 2x snapshot CSV files of OpenStreetMap user profile data. The intention of this data release is for the OSM Operations Group to seek assistance from the wider community on designing and training an automated system to identify spam on OpenStreetMap.org. Approximately 3500 users are created a week for the purpose of spam promotion, building SEO backlinks or business promotion. These accounts are primarily created by "SEO Online Marketing Agencies" operating out countries like Bangladesh, Pakistan, India and Vietnam. The spam can often be promoting unregistered online casinos, prostitution, drugs / pharmaceuticals / supplements and similar businesses.
The CSV files are expected to contain the following fields:
If desired I can supply a small sample pack of each to help advise. |
The OWG requested release of snapshot CSV files containing both spam and ham (legitimate user) data for training anti-spam models. We would have to document our justification. Most/all the information in the ham.csv is included in the planet files. They do not contain email addresses.
Suggestions
- Add a restriction on who can access these files. For example, include text next to the download links stating that by downloading, you agree to use the information solely to assist OWG in identifying spam.
- Require a non-disclosure agreement, as then we can also share IP addresses, which are potentially useful.
- The goal is to release these files widely.
Decision
Okay to release with some language limiting purpose -"By downloading these files, you agree to the OSMF Terms of Use and privacy policy, and agree to use the information in these files solely to assist OWG with anti-spam and other OSM improvement purposes approved by OWG."
Queries to legal-questions
Infocasas
Email shared by the LWG |
---|
Thanks for taking this issue again. The site is somewhat deceptive, because in the main page the map is using Google data, but they keep using OpenStreetMap data in other pages that display detailed info about the properties they offer.
To see that this site is using overpass you can browse one of the offerings for rental: https://www.infocasas.com.uy/oficina-en-el-centro/188995182 then click on "Mapa" (map) or scroll down the page and see the schools highligthed as POI (the schools are shown with a pencil, and hospitals with a red cross). And then I entered the Mozilla Web Developer tools (F12) and then in the network tab you can see the request to overpass-api.de (screenshot below), one querying for amenity=hospital and another one querying for amenity=school. Obviously they also show errors on the map, like this https://www.openstreetmap.org/node/11772775981 which has remain undetected until now. [image] By the way, searching for the evidence you request, now i see they are also using basemap from cartocdn.com (seems to be from Carto.com) wich declares it uses OpenStreetMap as data source, and I could'nt find the OpenStreetMap copyright nor any mention to ODBL. Below is the screenshot from https://carto.com/basemaps declaring that fact. I don't know if Carto.com is telling it's customers that they also need to comply with the ODBL. Kathleen sent a more forceful complaint than the one Jim previously sent via email on April 26. No reply thus far. |
Update: Per request of LWG, the maintainer of Overpass is moving to block Infocasas.
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:
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 Thank you in advance for your help, | ||||||||||||||||||||||||||||||||
LWG internal reference: https://otrs.openstreetmap.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=65356 |
Dermot emailed Dopper yesterday (2025-06-15) regarding our assertions based on ODbL. Dermot contacted them at a general email address, which redirected him to a feedback form.
If there is no reply in a few days, we could try to find people working there.
Using Regione Toscana WMS services Ticket#2025041010000202
Email shared by the LWG |
---|
Dear Licensing Working Group
Do I understand it correctly that following this agreement one can legally use in OSM not only the datasets presented on the OpenData Toscana site but also the WMS serqvices provided by the Regione Toscana (both Creative Commons CC licensed)? LWG: Does anyone read Italian? Guillaume to figure out OCR and/or ask Italian speaking members of the board for translation Update: response form Wikimedia Italia Hi Kathleen Lu, thanks a lot for your patience on this request. I reached out to some noted community members asking for some advice since its not so easy to give a correct feedback since this agreement had a 3 year duration from 2014 to 2017. At the time of the agreement Wikimedia Italia was not the OSM Chapter yet. The thing is that, apart of the agreement being expired, it is also a bit ambiguous and the commitments on both parts are not very explicit either task wise or license wise (something not so unusual for Italian agreements between institutions that are usually done only for the sake of promoting collaborations). Regarding the licenses seems like the region have released their data and documents under CC-BY e CC-BY-SA. ODbL is only mentioned on the sentence where is written: Under the condition of reciprocity,Wikimedia Italia agrees to share its geographic knowledge assets, released under ODbL license, with Toscana Region. Seems to me like Wikimedia has only committed to "share" with the Regione Toscana a project (OSM) that is already under ODbL. Also, if there was any data released, especially during those 3 years, it would be the only data that can theoretically be used if it has compatible licenses to OSM, but since there is some ambiguity about the licenses I can't be sure enough to say that it can be used and what way it can be used. Hopefully this information helps somehow. Please let me know if you think I can help more with this! |
LWG internal reference: https://otrs.openstreetmap.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=65685 |
Conclusion: This agreement has expired, as it lasted only for 3 years and the part specific to OSM was about Wikimedia sharing its information with the government.
Data Working Group - OSMtoday, via legal@
Email and updates shared by the LWG |
---|
DWG received a ticket with claims that the website OSMToday.com is putting out false information on our Ukraine borders. It does not sound like a DWG issue. Can you deal with it? I will suggest to the OP that they try a different site to download OSM data. Best regards -- OpenStreetMap Foundation Data Working Group - data@osmfoundation.org -- [Ticket#2025051010000086] Forwarded message Good day! I want to bring to your attention the fact of abuse of the OSM copyright to facilitate Russian propaganda. The website makes false claims to its users and creates false impressions: "Extracts data of Ukraine from OpenStreetMaps", " Fresh geo data from the Openstreetmap project in ESRI Shape format" Please stop this blatant abuse of your intellectual property and good name. $ whois 78.31.71.149 refer: whois.ripe.net inetnum: 78.0.0.0 - 78.255.255.255 whois: whois.ripe.net changed: 2006-08
inetnum: 78.31.64.0 - 78.31.71.255 organisation: ORG-MMIA3-RIPE role: WIIT AG NOC % Information related to '78.31.64.0/21AS24961' route: 78.31.64.0/21 % This query was served by the RIPE Database Query Service version 1.117 (DEXTER) Update: June 6: We'd also like to suggest a look at how you're conveying the ODbL's requirements to your customers. Your customers would be well-served by making it clearer that the PBFs you offer for download are subject to the ODbL. Finally, your use of attribution on the site is appreciated, but please note that according to the Attribution Guideline the preferred link for attribution text is to https://openstreetmap.org/copyright. Thanks again, and please do let me know if you have any questions. |
Tom Lee nudged OSMtoday during this call.
Japanese government's PDL license, via legal@
Email and updates shared by the LWG |
---|
I'm pleased to report that the adoption of the Japanese government's PDL license has been making steady progress.
For example, the following sites have switched to or newly implemented the PDL license: Geospatial Information Authority of Japan: https://www.gsi.go.jp/kikakuchousei/kikakuchousei40182.html Forestry Agency Simple Ortho Images: https://www.geospatial.jp/ckan/dataset/rinya-orthophoto-nagaoka2024 Additionally, an official reference translation of the original terms has been published: https://www.digital.go.jp/en/resources/open_data/public_data_license_v1.0 We would appreciate if you could review the terms of use for compatibility and publish their usability status on the OSMF website, similar to what was done with Canada's OGL? In particular, we would be grateful to receive permission regarding the usability of data from the following agencies, as they would be especially valuable for OpenStreetMap:
Unfortunately, these terms' "important information" sections are mostly written in Japanese, and we cannot expect official English versions to be released. However, machine learning-based Japanese-English translation tools like ChatGPT and Claude have recently become very accurate, and we can ensure translation quality through verification by our team at OSMFJ or by professional translators we commission. If there are any translations we should prepare, please let us know your comments. I appreciate your time and consideration, and look forward to your response. |
Satoshi IIDA provided an English translation of Japan's Public Data License 1.0.
LWG's position
Japan's Public Data License 1.0 appears compatible at baseline level, as long as any additional requirements are not problematic. Satoshi reported that the additional information sections attached to particular data sets tend to be written in Japanese.
LWG processing
- Case-by-case review will be needed initially for Japanese licences based on Japan's Public Data License 1.0. Once repeatable patterns are identified - as was done for Canada - we could provide guidance for licences identical to a single licence, without needing extensive LWG review.
- A lot of help will be needed, as they will not be in English.
Suggestion by Satoshi: publish an OSMF a page for Japan, like for Canada.
New page: https://osmfoundation.org/wiki/PDL_Japan_and_local_variants
Forwarded by DWG - Redacted
This topic was redacted from the minutes, as decided by the LWG during their July meeting.
Is "Korea Open Government License Type 1" safe to be imported into OSM?, via legal@
Email and updates shared by the LWG |
---|
I noticed https://www.openstreetmap.org/changeset/156936039 that mass imported POI from dataset licensed under "Korea Open Government License Type 1" which seems similar to CC-BY-SA Is it also requiring waiver? https://en.wikipedia.org/wiki/Korea_Open_Government_License https://discuss.okfn.org/t/korea-open-government-license-kogl/899 LWG notes: |
There are 4 different types of Korea Open Government License https://en.wikipedia.org/wiki/Korea_Open_Government_License, with type 1 allowing commercial use and distribution of derived works. It's very similar to CC-BY. Help from a Korean speaker will be needed to determine whether it has the DRM or the attribution issues.
- There's no reason to think that "Korea Open Government License Type 1" is similar to CC-BY-SA.
- CC-BY-SA is very unusual for a government data set.
> "The data in this changeset was mapped based on publicly available information provided by the Seoul Open Data Plaza (서울열린데이터광장). Source: https://data.seoul.go.kr/"
It looks like this is created by the sole municipality and there's substantial risk that they're doing this in a way that it can't be exported.
On import
- Mateusz Konieczny asked on the changeset whether the mapper was aware of the import guidelines.
- The import issue is under DWG’s remit.
On Korea Open Government License Type 1
- Archived version of English translation from Korean government: https://web.archive.org/web/20230127203147/https://www.mcst.go.kr/kor/s_open/kogl/koglType.jsp?pTab=05 Does not look like it was written by an official translator.
- Attribution: seems ok - included in the changeset comment.
- Questions:
- Is the licence ok? Probably, but we could use a better translation.
- Did this importer follow the rules? No, the import guidelines were not followed.
- They have not well documented the licence.
Action item
Kathleen to write back that the "Korea Open Government License Type 1" is likely compatible with ODbL, but we need much better documentation to reach a conclusion.
Angebot für die Benutzung Ihre OpenSourceMap Karten, Ticket#2025051610000226
Email and summary shared by the LWG |
---|
Summary of the below: They are asking for (and reminding us that they asked for) offers/quotations for the provision of cartography related to hiking trails. They don’t seem to understand how we operate. We could reply with the URL of the Geofabrik data extracts.
Sehr geehrter Damen und Herren, zwei unserer Gemeinden werden dieses Jahr mit unserer Unterstützung lokalen Wanderwegnetzen in ihren Gebieten umsetzen. Hierfür nutzen wir unser einheitliches Beschilderungssystem, das 2021 entwickelt worden ist. Informationen dazu finden Sie anbei. Wir sind für die Umsetzung beider Projekte auf der Suche nach einer Firma, die uns Kartografie für die Darstellung von Wanderwegen zur Verfügung stellt. Mehr Informationen dazu finden Sie im angehängten Leistungsverzeichnis. Die Kartenmaterialien brauchen wir, wenn alles nach Plan läuft, voraussichtlich in den KW-Wochen 27 – 28. Wenn Sie uns hierfür bis Freitag, den 30. Mai, zwei getrennte Angebote machen könnten, würden wir uns sehr freuen. —- Sehr geehrter Damen und Herren, ich habe noch nichts von Ihnen bezüglich meines E-Mails unten gehört und wollte Sie daran erinnern. Es wäre schön, wenn Sie mir ein Angebot für die angehängten Leistungsverzeichnisse bis diesen Freitag schicken könnten. Auch wenn Sie keine Kapazität haben, zurzeit oder kein Angebot abgeben möchten, wäre es schön, wenn Sie mir kurz Bescheid geben könnten. Herzlichen Dank und schöne Grüße |
Failure to attribute, Townmaps.ie
Email shared by the LWG |
---|
Of the 48 maps on https://townmaps.ie:
|
Action item: Dermot to reply using the LWG template in OTRS.
Any other business
Single sign on and Apple log-in
Somebody opened a pull request on the OSM website repository https://github.com/openstreetmap/openstreetmap-website/issues/2799#issuecomment-2847412646 and the OWG mentioned that the PR will be merged if the LWG says it is needed.
- One of the things that sign up with Apple allows you to do, is to "hide" behind a non typical email address.
- If there's no drawback, it might be a good thing to have.
- Requires much time from someone to implement it, plus GBP 79/year.
- We have access through FOSSGIS.
- If OWG do not want to do it, it is within their power.
- There does not seem to be a legal blocker or contractual imperative to support this.
Conclusion: Any issues are technical, not LWG ones.
Scheduling 2025 meetings
The LWG set the following meetings for 2025:
Jul 14, at 17:00 UTC
Aug 11, at 17:00 UTC
Sep 08, at 17:00 UTC
Oct 06, at 17:00 UTC
Nov 10, at 18:00 UTC (same as normal hours for everyone)
Dec 08, at 18:00 UTC
Meeting adjourned 1 hour and 20 minutes after start.