Licensing Working Group/Minutes/2025-05-12

OpenStreetMap Foundation, Licensing Working Group (LWG) - Agenda & Minutes
12 May 2025, 18:00 UTC

The minutes of the topics "OSMF move to the EU - EU Articles of Association" and "Forwarded by DWG" were redacted, as decided by the LWG during their June 2025 meeting.

Participants

• Kathleen Lu (Chairing)
• Dermot McNally
• Tom Hummel
• Tom Lee
• Simon Hughes
• Guillaume Rischard (OSMF board member)

Administrative

Adoption of past minutes

• 2025-04-14 Approved - Minutes of the sections "Move to the EU" and "Online Service Act" to be redacted.
• 2025-03-10 Approved - Minutes of the sections "Move to the EU" and "Online Service Act" 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?

---

From Board: OSMF move to the EU - EU Articles of Association. Redacted.

Discussion for 32 minutes.

Minutes redacted, as decided by the LWG during their June 2025 meeting.

---

Heat Map issue

Background Proposed response from Kathleen:

Dear all,
Upon discussion of the LWG, we are agreed that while the heat map does represent a use of personal data, it is a presentation of information that is already available via the profile, does not present a heightened privacy risk considering the information that can be gleaned from it, is of similar overall nature to other information on the profile (info on how a user maps), and is for legitimate purposes already listed in the OSMF Privacy Policy ("facilitating the communication between OpenStreetMap contributors", and possibly others). In a balancing of interests, we would agree that the heat map presentation is not necessary, and therefore any user objection would outweigh OSMF's legitimate interests. Thus, users should have the ability to opt out of their heat map being visible, but opt-in is not needed under GDPR.

Best,
Kathleen Lu

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:

1. A requirement for what?
2. How this requirement is supposed to manifest itself?

Possible answers to question 1 are:

• to log in to the osm website
• to do anything on the website that requires login
• to do some things that don't yet require login by making them first require login
• (probably other options, we don't care about the details of question 1 here)

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:

• pre-2012 accounts: have to tick the two terms checkboxes and click Continue:
  

[image]

• post-2018 accounts: no checkboxes, have to click a button:
  

[image]

• 2012-2018 accounts: no requirements, and this is what's supposed to change

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:

• Terms of Use don't cover just the osm website, but rather 'all "services officially operated and provided by the OSMF"'. If you're not even using the website, how are you going to accept the terms by ticking a checkbox? Where's the checkbox on a tile server? It doesn't exist.
• Instead of using a checkbox or a button you agree to the ToU by continuing to use the services. That's what the ToU 'already says'.

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:

• 'GDPR Position Paper' which says "the contributors will need to be logged on and have agreed to a set of ToU", without saying how exactly the agreement is supposed to happen. Note "will need" here.
• 'list of affected services', which has a 2x2 table at the beginning, containing a claim that ToU being "not accepted/unknown" is "the standard case for access through the web interface by a non-logged in user". This claim implies that accessing the website doesn't make you implicitly accept the terms.

Here's the 2x2 table from list of affected services:

	ToU accepted	ToU not accepted/unknown
logged in	frequent case: This will be the standard case for access by logged-in users through the web interface once all users have accepted the ToU.	rare case: For a transition period, there will be old user accounts that have not yet accepted the ToU. These would not be given access to "sensitive" material.
not logged in	rare case: If, at some point, we offer some kind of API access with an API key where registration of the API key requires accepting the ToU, then even non-logged-in accesses that come with an API key would be given access to "sensitive" material.	frequent case: This is the standard case for access through the web interface by a non-logged in user.

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:

• The unlikely option of doing nothing because the entire job was done just by writing about continued use in the ToU.
• Let the users accept the ToU using a checkbox, as done in 'my pull request'. In this case we need to convince another osm-website maintainer to merge the pull request, which is probably achievable by a LWG member going there and commenting.
• Let the users visit some other kind of terms page without a checkbox but with something that tells about the terms, and count the page visit as accepting the terms. Or maybe place a button there and count pressing the button. This is if we want accepting the ToU for 2012-2018 accounts to be similar to the current signup flow.
• Postpone answering question 2 and proceed with implementing the GDPR restrictions with some configurable settings. The settings would allow to decide if/when the restrictions are enabled. This is what I'd like to do anyway and have already started, but there's a common objection that it makes things more complicated, whereas a hard requirement to tick the checkbox on login is seen as a simpler solution. That simpler solution requires answering question 2 first by going with another option.

To be discussed next time.

---

Queries to legal-questions

Lantmäteriet - Swedish data privacy question, via legal@

Email shared by the LWG

We (the Swedish OSM community) are working towards using the newly (more) openly released High Value Data from Lantmäteriet, the national land survey of Sweden, in OpenStreetMap.

Annoyingly, Lantmäteriet have made the licensing situation somewhat convoluted; they have released the data under CC BY 4.0 but attached some additional terms. The reason for this is that they have determined that a lot of the data (including buildings and addresses) may be personal information under the GDPR, and they don’t want any risk that comes with the distribution. The full terms are available here (in Swedish, Google Translate does a decent job of translating it): https://www.lantmateriet.se/globalassets/geodata/geodataprodukter/anvandningsvillkor_for_vardefulla_datamangder_pu.pdf So far, we’ve determined that we’ll need to request exceptions/clarifications on:

• The DRM-issue (2a5B in CC BY 4.0)
• Terms from Lantmäteriet that restrict the usage of data (such as 3.3) which isn’t actually allowed according to CC BY 4.0
• (attribution is already clarified in their terms)

This leaves us with the general issue of personal information, especially in addresses (where it’s not possible to scrub it of PI without losing all value). We hope that putting them in OSM is fine (since many addresses already exist there), but just to make sure that we don’t make a mistake: Can we put data from a source which explicitly marks it as personal information under the GDPR into OpenStreetMap?

Legally, Lantmäteriet transfers the data processor role to the entity getting the data from them (so in our case the private citizen doing the import). We both want to make sure that that person doesn’t end up with any legal trouble, as well as that we don’t accidently put data into OSM that “poisons the water” by carrying legal restrictions or similar.

Jan Dalheimer
On behalf of the Swedish OSM community

---

Queries back:
We disagree with the position that building outlines and addresses (without info on the name of the resident) are personal information. There is no information about a person involved. Has Lantmäteriet actually made a specific determination that building footprint and addresses are personal data, or are they just saying that there could be personal data in the variety of datasets they have released? What exactly are you looking to import? The machine translation we has says the user is a data controller, not a data processor:
3.2 The user is the data controller or has other legal responsibility for the personal data that it receives from Lantmäteriet. This means that the user is responsible for ensuring that the processing of personal data complies with the rules in the GDPR.
Is this translating right? OSM cannot be a data processor to anyone.

---

Followup from May 9:
They have commissioned a legal examination (or what it’s called) on the topic. The reasoning is basically that an address (or a unique ID for a building) in itself may constitute personal information for single-person dwellings (i.e. if you have an address “Church Street 5” which is for a single building with a single occupant, then “Church Street 5” can uniquely designate that person, and is thus personal information). I don’t have enough of a legal background to really evaluate that claim, it does feel strange, but I can also follow their logic. But at the same time there is also a lot of talk about combined data sets (i.e. it becomes personal information when combined with other data).

The translation is correct, I was wrong in my original email, Lantmäteriet by way of the T&C place the data controller (sv. personuppgiftsansvarig) role on the person accessing the data from them. That’s why we’re worried that if we’d do something wrong then the volunteer would open themselves up to legal risks.

They wrote back saying that,

• the terms would mean we would be a data controller, not a data processor,
• the licence has restrictions related to DRM,
• the personal element in the data is the building outlines.

Issue

• The swedish government seems to be questioning whether just addresses are personal information.

Suggestion To ask them to take caution what they are importing into OSM, e.g. cadastral information.

Other points mentioned during discussion

• In Estonia, one of the background layers available in JOSM shows the boundaries of the land plots an the street address and number for each block.

LWG views

• Just building outlines or addresses (no other info, e.g. owner of property) are not personal information under GDPR.
• OSMF’s position is that info by itself is not PI.

Kathleen replied on June 7.

---

OSM Apps Catalog, via legal@

Email and updated shared by the LWG

Hello OSMF-Team

I am working as a volunteer on a project called OSM Apps Catalog (https://osm-apps.zottelig.ch), which displays applications that use OpenStreetMap data. I want to help people to switch to OpenStreetMap and contribute to the popularity of OSM. I currently host the catalog on a subdomain of my own domain. To make it look more professional, I intend to buy a domain that contains OSM (osm-apps.org). I have read the Trademarket Policy and assume that I need to apply for a license first. I have attached the completed “Project License and Domain Grandfathering Application” document. I kindly ask you to consider my request.

---

Kathleen’s recommendation:
I see nothing objectionable. I think we should update the standard Project license to account for new domain request and condition permission on 1) preapproval from OSMF, and 2) assigning the domain to OSMF should the project stop being OSM related

---

Update: New form received April 19

Thank you very much for the feedback. I am glad that LWG agree that my project is appropriate for a licence.

I have filled in the new template and attached it to this e-mail. I look forward to hearing from you.

• Agreement approved after updating grandfathering and domain template
• New template to be sent to Dorothea for future use.

---

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 on April 26. No reply thus far.

• Last time we agreed to write them letter, but they have not replied.
• The HTTP referrer is set, so Overpass should be able to block their access.

Action item

Tom Lee to ask Roland Olbricht to block Infocasas accessing Overpass.

---

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,

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

• The original report to LWG came with a small sample of locations with data from OSM.
• Dermot shared a draft reply to Dopper on LWG's Signal chat group.

Dopper

• seem to have a combined dataset which includes OSM data. They are some taps that we don't have, or we have them at different locations.
• are using an OSM map as background and they are not complying with the attribution requirements.

Action item

LWG members to review Dermot's draft and offer feedback.

---

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

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

Kathleen emailed an LCCWG member from Wikimedia Italia and asked for any background that Wikimedia may have about this agreement. There was no reply yet.

---

Request from Catalan OSM Community regarding authorization for the use of the trademark, via legal

Email shared by the LWG

I'm from the Catalan Community of OpenStreetMap, and we're working on establishing ourselves formally by registering as an association in with the government.The Adminstration has asked us to provide an authorization for the use of the trademark.

• The Catalan OSM community needs a trademark permission letter for government entity registration.
• Kathleen emailed the LCCWG, who replied that OSMF requires a registered organisation before an organisation applying to become a Local Chapter.
• The local Catalan community has not sent us their draft articles of the organisation they want to register.

Suggestion
LWG to draft an agreement for use of trademarks for 6-12 months to use the marks for purposes of the organisation registration, in furtherance of becoming a local chapter. The agreement will expire if they don't make enough movement towards becoming a Local Chapter.

Other points mentioned during discussion

• Wikipedia approved their Spain Local Chapter four days before it became registered.

Kathleen sent an authorisation on 2025-06-07.

---

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
Clifford Snow

--

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.
I searched for "Ukraine Populated Places shapefile" for my project and was directed to the website OSMToday, and discovered the map of Ukraine missing 4 regions Russia illegally annexed in the violation of international law.

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"
The name of the website implies affiliation with the OSM organization. The website itself imitates openstreetmap.org esthetics, uses the same font, etc. creating an impression that the site is affiliated with OpenStreetMap organization, to add legitimacy to their propaganda activities, and imply that the illegally occupied borders are somehow endorsed or recognized by OpenStreetMap.

Please stop this blatant abuse of your intellectual property and good name.
Notes:
The server for osmtoday.com is 78.31.71.149, which is located in Germany

$ whois 78.31.71.149
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer: whois.ripe.net

inetnum: 78.0.0.0 - 78.255.255.255
organisation: RIPE NCC
status: ALLOCATED

whois: whois.ripe.net

changed: 2006-08
source: IANA

1. whois.ripe.net

inetnum: 78.31.64.0 - 78.31.71.255
netname: DE-MYLOC-DUS
country: DE
org: ORG-MMIA3-RIPE
admin-c: MOPS-RIPE
tech-c: MOPS-RIPE
status: ASSIGNED PI
mnt-by: MYLOC-MNT
mnt-by: RIPE-NCC-END-MNT
created: 2020-11-04T10:31:13Z
last-modified: 2020-11-04T10:31:13Z
source: RIPE

organisation: ORG-MMIA3-RIPE
org-name: WIIT AG
country: DE
org-type: LIR
address: Joachim-Erwin-Platz 3
address: 40212
address: D�sseldorf
address: GERMANY
phone: +4921161708110
fax-no: +4921161708111
admin-c: MOPS-RIPE
tech-c: MOPS-RIPE
abuse-c: MOPS-RIPE
mnt-ref: MYLOC-MNT
mnt-by: RIPE-NCC-HM-MNT
mnt-by: MYLOC-MNT
created: 2019-10-28T10:48:29Z
last-modified: 2025-02-06T07:32:26Z
source: RIPE # Filtered
remarks: Phone number is 24/7 NOC number with senior engineer on duty for routing/backbone related issues.
remarks: This number should NOT be used for customer support nor for requests by public authorities.
remarks: Thanks for your understanding.

role: WIIT AG NOC
address: WIIT AG
address: Network Operations & Services
address: Joachim-Erwin-Platz 3
address: 40412 Duesseldorf DE
admin-c: PHAN
tech-c: PHAN
tech-c: DDO
tech-c: JOH
tech-c: AKIN-RIPE
tech-c: STH
tech-c: KT3550-RIPE
nic-hdl: MOPS-RIPE
remarks: +---------------------------------------------------+
remarks: | Please direct abuse issues ONLY |
remarks: | via web portal |
remarks: | https://abuse.wiit-cloud.io/report/create |
remarks: | |
remarks: | Complaints in other ways will be deemed |
remarks: | as spam and not further processed! |
remarks: +---------------------------------------------------+
remarks: | Please send legal/law enforcement inquiries to. | remarks: | auskunft_AT_myloc.de. |
remarks: | |
remarks: | PGP-Key ID for auskunft@myloc.de is 0xBB75B2C5 |
remarks: | |
remarks: | You can send your inquiry also via fax to this |
remarks: | number: +49 211 61708 551 |
remarks: | |
remarks: | For questions on legal/law enforcement use phone |
remarks: | number: +49 211 61708 114 |
remarks: | |
remarks: | Mails to abuse@myloc.de WILL |
remarks: | be automatically processed and the customer WILL |
remarks: | get a notification about your inquiry. |
remarks: +---------------------------------------------------+
remarks: | ONLY In case of routing/peering related issues |
remarks: | please contact NOC: |
remarks: | |
remarks: | 24/7 NOC email: noc@wiit.cloud |
remarks: | 24/7 NOC phone: +49 211 61708 110 |
remarks: +---------------------------------------------------+
abuse-mailbox: abuse@myloc.de
mnt-by: MYLOC-MNT
created: 2013-02-11T16:38:10Z
last-modified: 2025-02-11T13:37:49Z source: RIPE # Filtered

% Information related to '78.31.64.0/21AS24961'

route: 78.31.64.0/21
descr: myLoc managed IT AG
origin: AS24961
mnt-by: MYLOC-MNT
created: 2010-03-02T12:04:36Z
last-modified: 2017-02-07T16:39:12Z
source: RIPE

% This query was served by the RIPE Database Query Service version 1.117 (DEXTER)

The DWG received a complaint about a website using the OSMtoday domain name without official affiliation, providing altered OSM data.

Issue

• content presented in a manner which might confuse users that is official.
• name confusingly similar to our mark.
  • We do not have a mark in Russia.
  • Content is in English and the website is in Germany.

Suggestions

• Ask the website operators to add a disclaimer that they are not affiliated with OSMF.
• Ask the website operators to change their name. Typical escalation would be with a takedown request to the ISP.

Other points mentioned during discussion

• A domain dipute with ICANN is prohibitively expensive.
• They sell the domain for USD 140: https://osmtoday.com/offer.pdf
• Link shared: https://osmtoday.com/europe/ukraine.html

Action item

Tom Lee to email the webiste operators and tell them they are violating our trademark.

---

Japanese government's PDL license, via legal@

Email 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:

• Original Text: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/f7fde41d-ffca-4b2a-9b25-94b8a701a037/3d15f10d/20241122_resource_open_data_01.pdf
• 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

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.

There is now an official translation of the PDL license, provided by OSMF Japan. Some content still in Japanese.

Action item

LWG members to review the translation.

---

Forwarded by DWG - Redacted

Discussion for 11 minutes.

This topic and its minutes were redacted, as decided by the LWG during their June meeting.

---

Techcrowd app, forwarded by Board

Email shared by the LWG Subject: Using openstreetmap for app

Dear OpenStreetMap Foundation Board,

My name is Bedřich Malý, and I am Backend developer developer atTechcrowd(https://techcrowd.tech/). We are developing a mobile application designed to help users discover and filter child-friendlyplaces and events in their area. To power our maps and location search, we would like to use OpenStreetMap’s open data for:

Displaying points of interest (playgrounds, museums, cafés, etc.)

Locating and filtering children’s events (workshops, performances, outings)

Before proceeding, we want to ensure full compliance with the ODbL license and any Foundation policies. Could you please clarify:

Attribution Requirements:
Is the standard “© OpenStreetMap contributors” credit sufficient on each map in our app, or are there additional wording or placement guidelines we should follow?

Usage Limits & Best Practices:
Are there recommended rate limits or restrictions on the number of API requests per day to avoid service disruption?

Partnerships or Support Programs:
Does the Foundation offer any partnership, sponsorship, or reduced-feeprograms for educational projects?

We greatly appreciate the work of the OpenStreetMap community and want to respect all licensing and technical guidelines. Any documentation or pointers you can share would be immensely helpful.

Thank you for your time and assistance. We look forward to hearing from you.

Kathleen replied on 2025-06-07.

---

Any other business

Filing the declaration of trademark use for Argentina

Email shared by the LWG FYI, from our trademark lawyers

Further to the action we took in November 2024 in relation to the ‘OPENSTREETMAP’ mark in Argentina in class 42, the declaration of use is now also due for the class 41 filing. As Argentina is a single class jurisdiction, the two classes are protected under separate marks. As the Class 41 filing was registered slightly later, this declaration is now due.

The fees for this will be the same as before - £400.00 plus VAT. Please kindly confirm if you are happy to go ahead.

---

Core software development facilitator

Minh Nguyễn’s appointment as Core Software Development Facilitator.

---

Single sign on (SSO) and Apple log-in

Email shared by the LWG

There was an email to the LWG related to Single sign on and Apple log-in. This does not seem to be under the LWG's remit.

• SSO and Microsoft: we had told Microsoft that they can't create proxy accounts.
• Potential for abuse if someone wants to create multiple accounts with their single Apple ID and we see multiple different email addresses.
• We need to make sure that when people log-in via a third party, they still get shown all the necessary information (e.g. terms).

https://github.com/openstreetmap/openstreetmap-website/issues/2799#issuecomment-2847412646

---

Scheduling 2025 meetings

The LWG set the following meetings for 2025:

Jun 16, at 17:00 UTC
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 40 minutes after start.