bot, build org.multimc.MultiMC

Queued test build for org.multimc.MultiMC.

Started test build 33936

Build 33936 failed

bot, build org.multimc.MultiMC

Queued test build for org.multimc.MultiMC.

Started test build 33937

Build 33937 failed

bot, build org.multimc.MultiMC

Queued test build for org.multimc.MultiMC.

Started test build 33938

Build 33938 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/32694/org.multimc.MultiMC.flatpakref

bot, build org.multimc.MultiMC

Queued test build for org.multimc.MultiMC.

Started test build 34061

Build 34061 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/32812/org.multimc.MultiMC.flatpakref

bot, build org.multimc.MultiMC

Queued test build for org.multimc.MultiMC.

This latest build adds some build switches that were found in the stable release PKGBUILD:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=multimc5#n55

Build 34376 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/33113/org.multimc.MultiMC.flatpakref

Hey @peterix, my apologies for the late response!

MultiMC handles user credentials and enforces DRM on behalf of Mojang/Microsoft.

I had to ask the snap people to take down one of those because people put up a cracked version on the snap repos. Thankfully, they had the decency to take it down and I didn't have to figure out how to follow up on that.

I'm sorry you've had to deal with cracked clients. I've supported Minecraft since it was in Alpha development, and it can be frustrating to see the MC community being flooded with shady mods and cracked launchers undermining the efforts and legitimacy of those who've put their time into Minecraft and passion projects such as MultiMC.

I'm not saying that you are doing something wrong in this regard, but I do not have the time or inclination to audit what you do on an ongoing basis. I'm in the same relationship with Mojang/MS - very unofficial.

And yeah, there are builds with auth/drm disabled or cracked copies of MultiMC floatong around the internet. I wish there weren't, because it's a liability.

Auditability is a very important property in software, and I'm glad that you prioritize it. There are a few ways you can audit flatpak builds:

• Flathub git repositories
• Flathub's CI system

It would be virtually impossible for someone to sneak in shady patches because it would need approval for merging from a maintainer, and there's an extensive audit trail left behind since it's all publicly visible in git history. For example, this is the commit hash of the latest change I made as of this writing:

c253c55

Which is found in the Build Properties of the respective build in Flathub's CI:

https://flathub.org/builds/#/builders/32/builds/34376

The build output can be readily inspected and compared against local builds, which I often do by running:

$ flatpak-builder --verbose --install-deps-from=flathub _build --force-clean org.multimc.MultiMC.yml

The game is pretty complicated to get running correctly

The mods and variability in user systems is a bad enough problem without unofficial builds floating around. It's OK if you mess with the code as an end user and you generally have some idea about what you are doing. ... but if you push that to others and call it MultiMC while leaving me to deal with the support issues, that's sersiously NOT OK.

As barthalion pointed out, the expected procedure for supporting a flatpak is that users file bugs on its bug tracker. It's not any different from users having to go to a bug tracker for Debian, Fedora, etc. For example, there's a bug tracker for the Obsidian flatpak I maintain

In addition to there being a bug tracker, flatpak gives users the tooling they need to extensively debug. This has been useful for when I've had to help debug Wayland crashes with the Veloren developers:

[jstone@localhost ~]$ flatpak install net.veloren.veloren net.veloren.veloren.Debug
[jstone@localhost ~]$ flatpak run --command=sh --devel net.veloren.veloren
[📦 net.veloren.veloren ~]$ gdb /app/bin/veloren-voxygen

Currently, MultiMC and the Mojang launcher do not bundle any Java on linux. MultiMC should follow what Mojang is doing in this regard. Different versions of Java will be bundled in the future based on the needs of the game, not based on what you think was appropriate to throw in.

The license is used to enforce the above

Out-of-the-box Java support can certainly be moved out of the build for fitting more in line with the goals of Minecraft and MultiMC. The current configuration of bundling the prepackaged openjdk8 is not intrinsic to flatpak; you can either keep the base application minimal with support libraries installed separately, or bundle whatever you feel is necessary. In this case, it's merely a convenience for first runs because flathub already packages openjdk8, and whether it's bundled or installed as a shared system library is irrelevant due to ostree's design deduplicating files.

I've considered removing all branding, infrastructure URLs, and links to support places from the codebase before. Might have to do it sooner or later, for multiple reasons. You are not the first to want to redistribute it, and with the name and logo being there by default and not easy to change in one place, it's not as easy to maintain such a rebranded fork.

While the name and logo are not registered as a trademark, I believe they are still protected under common law (IANAL, and I don't particularly feel like paying lawyers unless I absolutely have to).

Future issues with MS authentication

Having to extensively patch MultiMC for a rebrand is certainly not going to be simple, but is necessary for satisfying requirements for a downstream package. If you can, please list which exact parts of the application would need to be patched.

Here's a (probably incomplete) list of what I believe would have to be changed based on a cursory glance:

• App ID in the repository
• Application ID that'll be seen in the desktop environment's launch menu
• Application icon
• Application name in window title bar
• Bug tracker URL
• Support URLs
• Patreon URL (I'd personally prefer to leave the URL unchanged, but could change the text to "Support Upstream")
• Application name in debug logs
• Application name in Settings

One major upcoming concern is that Microsoft is getting involved with third party launchers. You will likely not be able to build a full-featured version of the launcher without registering the application with Microsoft in the future.

So, you may not be able to make working builds in the future without becoming responsible for user safety and privacy (having a formal relationship with Mojang/MS, implementing MSA correctly, etc), or without actively trying to impersonate me.

I am not OK with being liable for your actions.

Ultimately, I've been doing this for years and feel responsible. From my POV, you are making flatpak my problem against my will, while walking into a bunch of problems that you are not ready to handle.

Whatever issues may impact the flatpak shouldn't be your problem, as it was already made clear from the very first commit as well as in the original license

One of the key benefits of the open source community is that volunteers can put in improving the quality of software in a transparent, especially if there's a policy in upstreaming patches so that everyone can benefit. That is the relationship I intend to have when maintaining this.

So. My answer is a decisive NO.

If you really want to deal with maintaining a Minecraft launcher, go ahead. Fork it completely, infrastructure included. Please don't half-ass it. I don't want even a hint of implication that I am involved in whatever you are doing.

The infrastructure already exists, otherwise the Flathub community wouldn't able to maintain the 1000+ apps at the time of this writing. MultiMC isn't going to be much different.

Note: I am not a fltahub/flatpak decider, neither a Minecroft user.
@peterix I've read in to this discussion and I strongly disagree with your attitude.
The reason is that there are flatpak-only Linux distributions out and in the works.
You're actively saying as an open source developer: "I don't want my software to work on distribution XY".
You're offered to maintain the distribution of the flatpak yourself (and already do so for your preferred systems that you
obviously try to push - like anbox does, which I find much more useful, does with snap and Nobuntu).
The edits of MultiMC in questions are configure path's basically, so your comment on changes can be only seen as a pretext.

So the following should resolve the question to determine your true colors:
If you're really 'concerned' about the 5 lines of patch that edits MultiMc (the configure/java path)
than the following should have your blessing: A flatpak MultiMC not build from source but uses wine (https://winepak.org/)
to run that software unmodified (downloads and silently installs MultiMC at download time)

I do not approve this.

I said NO many times.

And I see this continuing as hostile action. I will respond in kind if you force me.

@peterix You said no to a "modified" version, a version that is exactly re-packaged from a binary package from your website without modification is something completely different, so you must be okay with that, unless you're completely hostile towards any other distribution than arch and ubuntu.

No, I am against you repackaging or hosting MultiMC in any way. MultiMC comes from multimc.org - nowhere else.

And that is final.

If I have to make the repositories private and change the license, I will.

You people are entirely inconsiderate, relentless and can't be reasoned with in any way.

You people are entirely inconsiderate, relentless and can't be reasoned with in any way.

So far nothing has been published. You have actually said moments ago that you do not wish this to be redistributed
in any way (even without modification), yet you chose the Apache license.
Maybe you should consider and appropriate license for your project if you don't wish that to happen and avoid all the drama.

Maybe you should consider 'no' as an answer and have some respect for other people.

I can imagine that this has been as bad of a discussion for you as for anyone involved, which you could have avoided entirely.
I've forked MultiMC on github, not that I am willing to put any effort into something that I have no use for.

You probably didn't know but on flatpak irc people are very compassionate to not include MultiMC based on your wishes.

If you wish to use the label open source, I would suggest that you also respect the open source initiative
https://opensource.org/ and not label it as such and than disrespect people who than put work into distributing it according to that very license.

Great. That is the desired outcome. I do not want MultiMC to be in flatpak, appimage, snap or anything similar.
I do not want to deal with users of these things.

You could have avoided this by not being aggressive and trying to take over everything.

The desired outcome would definitely include also you not misrepresenting the open source brand.

Go read the license again. It gives you no rights to the name.

I suggest you do the same:
2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, **and distribute the Work and such Derivative Works in Source or Object form.**

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.****

except as required for reasonable and customary use

which is covered by section 2

No, it is not. It's a distinct section of the license.

@peterix Would you mind if we ask the OSI for clarification?

Look, I'm telling you 'no, I don't want this' and you are trying to find some technicality to get around it and ignore what I say.

I'm sorry but I don't want to get around anything, it's the other way around.

You are basically saying open source (apache 2) is not redistributable based on some technicality which is covered by section 2.
I'm merely asking you to chose the right license for your project to resolve current and future discussions.

It seems to me that you've chosen the incorrect license for the project (an open source one).
You can't have it both ways. Either you are open source or you are not. (And both is fine!)
The open source brand is controlled by the OSI so I think we should ask them if you are allowed to use their brand (open source)
or not

The license does not give you the right to use the name or the infrastructure MultiMC requires to function.

There are two very distinct things:
MultiMC, the launcher as distributed on multimc.org - I am willing to support it and have for almost 9 years. It is packaged in a specific way and you don't get to say how.
MultiMC, the open source code on github.

It is clear that I need to strip all branding from the open source code and make it present only in binary packages built by the MultiMC CI.

It is clear that I need to strip all branding from the open source code and make it present only in binary packages built by the MultiMC CI.

I think this is a solution and glad that you can be reasoned with.
I hope that this will also prevent you from having to lead such discussion in the future, as they are not pleasant for anyone involved.

People interested in having unbranded MultiMC on Flathub are welcome to submit it; at this point I don't want MultiMC on Flathub either.