Disclosure of the Metaserver CDN Source Code

[rtsisyk]

Today I am announcing the public disclose of the source code of so-called "metaserver", that previously was available only to few people of the team. At Organic Maps, we prioritize transparency and open communication with our community and committed to making our source code publicly available, ensuring that users can fully engage with and contribute to the project.

=> https://github.com/organicmaps/meta (MIT License)

What is the Metaserver?

The purpose of so-called "metaserver" is to dynamically redirect users to the most suitable CDN servers containing requested map version based on their geographic location. For example, users in North America are routed to servers in the U.S., ensuring faster map downloads. Additionally, the metaserver enables dynamic server reconfiguration without requiring approval from the App Store or Google Play, which can take weeks.

How does it work?

The service is implemented as a Cloudflare Worker, which returns a JSON response containing a list of servers based on the GeoIP information of the requester. Essentially, this functionality could be replaced with a few static JSON files a series of rules in an Nginx configuration. The decision to use Cloudflare Workers seems controversial at this point. It was likely an unfortunate choice that should be revisited in the near future to prevent vendor lock-in and ensure the project remains independent of large tech corporations.

Why Was It Closed?

The original author of this component justified the decision to close it due to concerns about unauthorized forks. Indeed, we observed at least two forks that misused the content delivery network, funded by donations, for their private gain. However, it appears that the closed-source nature of the component did little to prevent this issue.

Why Open Now?

The component was contributed by Alexandr Borsuk (a.k.a. Alexander Zolotorev) back in 2021 under the MIT license, although the repository itself was not publicly accessible. Throughout November 2024, the issue of closed-source code was discussed several times in the Telegram chats with key contributors.

On November 23, Mr. Borsuk quietly made a change, removing the MIT license while keeping his copyright. The change with the flagrant comment "No MIT yet, sorry." was discovered by me only today. A few non-significant commits were made on top of it.

This subtle, almost unnoticed modification effectively privatized the open-source repository by this individual, preventing any further open-source collaboration. Furthermore, the next change of enabling the logs, clearly violates our commitment to privacy. To my knowledge, this decision was not discussed with any other contributors, including those who had previously contributed to the repository.

commit 30e9911d4c8329068aca82fd6c0d896380ba99de
Author: Alexander Borsuk <170263+biodranik@users.noreply.github.com>
Date:   Sat Nov 23 21:33:36 2024 +0100

    Update LICENSE

    No MIT yet, sorry.

    Signed-off-by: Alexander Borsuk <170263+biodranik@users.noreply.github.com>

link: organicmaps/meta@30e9911

The commit following the license change enabled logging in Cloudflare...

commit a6ff0eb05abfc891e6a3a32faa3cd307a40c6121
Author: Alexander Borsuk <170263+biodranik@users.noreply.github.com>
Date:   Sun Nov 24 21:28:02 2024 +0100

    Observe server abusers when needed

    Signed-off-by: Alexander Borsuk <170263+biodranik@users.noreply.github.com>

diff --git a/wrangler.toml b/wrangler.toml
index bfcdcf6..bad7b47 100644
--- a/wrangler.toml
+++ b/wrangler.toml
@@ -23,3 +23,6 @@ route = 'meta.omaps.app/*'

 [env.prod.vars]
 DEBUG = false
+
+[observability.logs]
+enabled = true

link: organicmaps/meta@a6ff0eb

Actions Taken

1. I am making the code from before November 23, 2024, publicly available again under MIT. As one of the authors who contributed to the code while it was under the MIT license, I have the full right to take this action. Proprietary changes after "No MIT yet, sorry" and "Observe server abusers when needed" has been removed or reverted.
2. The copyright notice has been updated to include "Copyright 2024 Organic Maps Contributors" to accurately reflect the current situation.
3. Contributors and the community are invited to perform a thorough and independent review to verify that the code functions as expected without introducing any undocumented functionality.
4. This post issues an open call to replace the proprietary Cloudflare technology with an open-source alternative, though this may take some time.
   6.. Log collection has been disabled, as it was previously.

---

I, personally, apologize to the community for this matter. All necessary measures have been taken to resolve this issue. Organic Maps remains fully committed to privacy, transparency, and open-source values, which is why we are openly disclosing this issue.

Regards,
Roman.

[RicoElectrico]

Something doesn't seem right? The two Alexanders are apparently a different person? https://tracxn.com/d/companies/mapswithme/__z_UdJbmARcKZWF2k8I8I6LhezhZ-PPLegSR8HKLL0AA/founders-and-board-of-directors

[rtsisyk]

Something doesn't seem right? The two Alexanders are apparently a different person? https://tracxn.com/d/companies/mapswithme/__z_UdJbmARcKZWF2k8I8I6LhezhZ-PPLegSR8HKLL0AA/founders-and-board-of-directors

The same person as far as I know:

https://github.com/organicmaps/organicmaps/pull/515/files#diff-ade7d2f0db76f7dc0eef2e96386859ee766b144d13448e2e177a049ffbbdc02aL3-L9

[rtsisyk]

Apparently F-Droid's NonFreeNet was somehow legit. This change opens the way to remove that label.

[pastk]

It had been changed awhile ago to a more precise TetheredNet AF already. TetheredNet doesn't imply the server is non-free, just non-changeable by a user.

[pastk]

This is how it looks in the F-Droid Client at the moment

[rtsisyk]

It had been changed awhile ago to a more precise TetheredNet AF already. TetheredNet doesn't imply the server is non-free, just non-changeable by a user.

OK. At least this formerly closed component is not a concern anymore.

[pastk]

Many thanks!
There should be no hidden closed parts in an open project!
Especially in a privacy-focused project.

[oleg-rswll]

It’s unfortunate that a co-founder of an open source project tries to keep it closed.

[rtsisyk]

I can see a butch of emails that my GitHub permissions have been revoked. Well, this is a funny attempt to cover-up the published information.

[gibsonpil]

Ooooooo you're in troouuuuuuuble!

[oleg-rswll]

Alex locking out Roman after Roman opened code on an open-source project, gives the appearance that Alex is trying to hide code.

[rtsisyk]

Nice to know that we have the OWNER here who OWNS the CODE.

[rtsisyk]

The https://github.com/organicmaps/meta repo is not available anymore as of 7pm GMT...

[rtsisyk]

Here's my local copy... Open-source forever! ✊

organicmaps-meta.tar.gz

[pastk]

I have a clone as well: https://github.com/pastk/meta

[pastk]

But I think the biggest issue is not in the availability of the code somewhere per se.

The code/repo should be "officially" open in the project.
Otherwise it casts a shadow onto the image of open source, community-driven and privacy-focused project.

[rtsisyk]

The service is now temporary deployed from https://github.com/rtsisyk/meta/ fork as the https://github.com/organicmaps/meta/ was proprietarized and can't be audited. Logs were disabled explicitly.

[pastk]

@biodranik any comment from you?

You revoked gh permissions from a developer which is a very hostile action and hurts reputation of the whole project.
Please comment.

[rtsisyk]

From the privatization of organicmaps/meta to the privatization of the entire Organic Maps GitHub org. All passengers are welcome aboard the express train back to MAPS.ME-ville.

[rubcap]

@biodranik I'd like to know if OrganicMaps is still an open-source project and why the MIT license was removed from the server code.

I love OrganicMaps 🌱, it is a great and user-friendly alternative for OsmAnd and the privacy focus is a USP. I hope you guys can discuss the matter with respect for each other's contributions, sort out any issues or misunderstandings and continu the project in the most "open" way possible.

From a happy user.

[rtsisyk]

Hey, it has been over 48 hours, and I’m not sure if we have received clear answers to the questions everyone is waiting for:

1. Why and on what basis did Alexander unilaterally remove the MIT license and replace it with his personal copyright on the code?

The explanation in the Telegram chat was that "the MIT license was there by mistake, from the initial template, so I removed it.". Is that the final version? The file has been there since 2021 and multiple people have contributed...

2. Why and on what basis did Alexander remove me from the GitHub organization I founded after I revealed the information in this post?

May we kindly expect clear answers by the end of the day today, December 9? In my opinion, the project needs more transparency, not more of Alexander's vague 'secrets'...

[vng]

I've chimed in from the beginning and am doing my best now.

[andrewshadura]

@vng, so what’s your opinion? I haven’t seen anything in public yet.

[rtsisyk]

It has been a whole week since my access was revoked. When can I expect it to be restored? It could open a way to the de-escalation...

[mnalis]

@biodranik do I understand right that you insist on closing the code / the repo still?

• If a project claims to be fully open then there should be no closed parts. OR
• If there are closed parts then their existence should be disclosed in an honest and transparent manner.

Fully agree here. I'd really like to know the stance on that from each of the cofounders too. It would be unfortunate if the cofounders disagree on such essential direction of the project (i.e. should it be fully or only partially FLOSS), but even then users should have a right to know.

For example, Roman unilaterally and silently removed my and Viktor's email admin rights and removed me from some of our email groups in August 2024 (or earlier). When I discovered it, he refused to explain why he did that and refused to provide access back. I still want to hear his answer and motivation.

@biodranik May I suggest that another discussion is opened about those alleged misconducts (and linked if relevant), as their mentioning here (months after the fact!) seems only to derail the discussion to other subjects instead of the one intended (i.e. "Disclosure of the Metaserver CDN Source Code")?
(of course, if it can better be handled internally, by all means prefer that instead, as all such governance disagreements damage OrganicMaps reputation, and most users would really prefer less drama if possible). And then I'd expect @rtsisyk to give his explanation in that separate discussion (but not here, for mentioned reasons).

It has been a whole week since my access was revoked

It does seem unreasonably long, that should've been enough time for everyone to calm down and agree to follow co-founders’ agreement and governing board rules. While I've too had serious disagreements with @biodranik behaviour, that does seem like a reasonable request to me. Would you @rtsisyk agree to that in order to help with deescalation?

That being said, that repository seem quite trivial: few hundred lines, half of those not even code but simple JSON definitions.
It seems totally blown out of proportions for @biodranik to insist of keeping that code closed (much less to revoke @rtsisyk access over such a triviality as publishing of that!)

[pastk]

agree to follow co-founders’ agreement and governing board rules.

Unfortunately this document doesn't say anything about decision-making rules inbetween board members.

Also this document is known to be outdated and the Board de facto doesn't fulfill some of the self-assigned duties. So I find it strange that @biodranik keeps appealing to it.

There is lack of public record and hence lack of accountability in project's decision-making.

[rtsisyk]

I am reporting of the violation of the Code of Conduct by Alexander Borsuk:

#9860

[pastk]

Here is a proposition how to solve the current governance conflict and ensure it won't happen again.

The basic idea is to make parties act more predictably and responsibly by balancing concentration of admin powers with accountability and by keeping a public record of agreements reached, i.e. transparency.

The proposal is to introduce a "keys keeper" role.
Organic Maps github organization ownership should be transferred from the current owners (@rtsisyk, @biodranik, @vng) to neutral reputable keys keepers.
Keepers' function is NOT to make any decisions on behalf of the project, but only to hold the keys trusted to them and ensure there is no misuse/abuse of these powers.
The keeper role is designed to be not a privilege, but a duty.

For that the ownership powers should be balanced by public accountability and responsibility.
The keepers should be elected for a limited term from the community of OM's contributors and the keepers would pledge publicly not to misuse the permissions trusted to them.
It would be best if they have as little relationship to each other as possible.

Any change/movement that requires ownership permissions should be fulfilled by the keepers only based on explicit agreements of OM's contributors (e.g. a consensus).

Scope: its about OM github organization ownership permissions only, other OM keys/assets (trademark, domain, stores' accounts, etc.) are out of scope of this proposal to make it simpler.

The proposed ownership transfer process in more detail:

• keepers are elected by an open and transparent vote of OM's active contributors (need to define a qualification criteria)
• each contributor can nominate and vote for up to 3 persons, but can't vote for themselves
• people may tell they don't want to be nominated/elected
• top 3 persons with the most of votes are elected as key keepers for a 1 year term
• they publicly pledge to:
  • not use the powers to push their own or someone's opinion or for any other misuse/abuse
  • use the powers only to fulfill movements explicitly agreed upon by OM contributors via a consensus or a vote
  • keep a public record of all uses of ownership permissions and who has access to what in the OM github org
  • transfer the ownership to the next elected keepers
  • report/disclose any potential break of the pledge by other keepers or presence of conflict of interests, inability to continue with the duty, etc.
  • be reasonably reachable (e.g. each week there should be at least one keeper available to fulfill the duties)
• then the previous github organization owners transfer the ownership to the new keepers
• the same keeper shouldn't serve two consecutive terms to ensure ownership rotation

A process to reach agreements incl. movements requiring ownership permissions (e.g. give someone merge rights, issues management rights, etc.):

• an issue is created with details of the proposed movement:
  • what needs to be done and why
  • if permissions should be given to someone then for which term (usually 1 year)
  • a person getting permissions should pledge publicly not to misuse them, disclose conflict of interest, etc.
• the most movements will be fulfilled by the keepers if there is a lazy consensus
  • no concerns/blocks and approvals (thumb ups) from at least 3 contributors
  • at least a week time should be given to people to upvote or express a concern
  • an example in Forgejo: https://codeberg.org/forgejo/governance/issues/132
• in case there are concerns raised:
  • strive to address and resolve all concerns first
  • if someone blocks then the block should be explicit and supported by argumentation (e.g. a downvote with no details has no power)
  • if the movement is about revoking someone's permissions then the person in question can't block / downvote
  • basically it becomes a vote and an outcome is determined by simple majority
• very important changes (e.g. modifying the election process) require 80% majority vote and min of 5 votes
• the keepers fulfill the agreed movements that require ownership permissions

Bootstrapping / transitional conditions:

• the current owners should pledge to transfer their OM github org ownership as described above
• the current owners will retain all their other permissions (as much as technically possible) for the 1st year, but afterwards will need to seek re-approval annually
• likewise all other contributors holding extended permissions (merge, issue management, etc.) will initially retain them but will be subject to re-approval afterwards
• being the direct sides of the current governance conflict @rtsisyk and @biodranik shouldn't be nominated/elected for the initial/first term, but they could vote and also could be elected in subsequent elections
• the election and agreement making rules, bootstrapping conditions and initial pledges should be added to the OM repo
• this will mark the process is adopted and then we can move on to key keepers elections

Adoption of this approach should bring the following benefits:

• mutual public accountability and responsibility of all parties
• transparent, reliable and predictable github organization governance
• clear and straightforward process for contributors to apply for permissions needed to facilitate their work
• acknowledgement of efforts of all OM's contributors by including them into basic governance processes
• transparent process to reach agreements and keep a public record of them, to hold the parties publicly accountable
• resolve conflicts in a civil and respectful manner with community's mediation

This proposition is inspired by the governance processes used in Forgejo and Gitea (open source software forges similar to Github, Gitlab... e.g. codeberg.org runs Forgejo).
An example of election of "owners" in Gitea:

• Voting for new owners between 2022/1/1 ~ 2022/12/31 go-gitea/gitea#17872

Another example of someone applying to a team & getting permissions in Forgejo:

• https://codeberg.org/forgejo/governance/issues/110

[pastk]

This will work only if the current owners will agree to it.
@rtsisyk, @biodranik, @vng please voice your support to this proposal or raise your concerns with it and we can discuss/amend.

[pastk]

Some additional clarification:

• the voting is intended to be public / not secret (see Voting for new owners between 2022/1/1 ~ 2022/12/31 go-gitea/gitea#17872 as an example)
• hence anyone could count the votes and check each other
• this proposal is not a silver bullet that would stop any possible abuse, e.g. a person holding the trademark could gain github org ownership and effectively do whatever they want; the scope here is limited intentionally
• it would be great to further separate the powers by forbidding overlap between board members and keyholders, it would be great to have elected and legally bound board members, etc.; but this proposal is intended to be a comparatively small (but still significant and useful) step

[rtsisyk]

@vng and I just held an emergency meeting, and we found a way how to restore the order and move forward. I am closing this discussion to deescalate the situation.

[LuccoJ]

As a user, I am concerned about what is going on and while I wouldn't otherwise intervened, I feel if the discussion is closed, I will have less ability to continue trying to understand what is going on. I would appreciate it if the discussion were kept open and updates posted.

[biodranik]

I also had a talk with @vng, Roman's org ownership has just been restored.

[rtsisyk]

We will mutually respect the value of open-source ✊

[biodranik]

100% agree!

As @rtsisyk has already made the repository publicly available, there is no sense in keeping it private anymore.

[mnalis]

I would like to thank everyone on calming down and sitting down for a talk, and especially @vng for being instrumental in restoring order. ❤️

Closing is not necessary, let the discussion continue to go on please.

Well, while the discussion may go on even with GitHub discussion closed, I understand that insisting of publishing details of that discourse publicly might be detrimental to (possibly tentative) "cease-of-fire" agreement. (Only if all sides feel comfortable with sharing details, it would be welcome - of course!)

What I would like to see is public commitment from cofounders (and other active devs?) to jointly agree and update GOVERNANCE.md in reasonable timeframe, so it has some actionable set of rules how to prevent such project-damaging drama in the future and make clear the expectations. I think that would reassure users and restore faith in the project governance.

[pastk]

First thing to agree upon is Core Values of the project:

• [docs] Add Core Values doc #9905