Change:
The "MultiMC" name cannot be used when redistributing MultiMC, according to . Based on discussion on their Discord server, Nixpkgs should either patch MultiMC to change the name or package the official binaries without redistributing them. From my understanding, while granting explicit permission to use the name similar to Firefox would be fine in the short term, MultiMC will require OAuth credentials in the future and they're reluctant to give distributions permission to use them. Maintainer information:
cc to make sure I understand the situation here correctly
It's worth noting that preventing redistribution of unmodified MultiMC binaries violates GNU's Free Software Definition, which I assume is where Nixpkgs' comes from, though I could be wrong.
which is wierd, last I checked the Apache 2.0 was considered Free by the FSF.
Here we go, the ticking time bomb has finally gone off. MultiMC's developer is already notorious for blowing up at flathub maintainers regarding this issue. Fortunately, having taken a quick look at the debacle, it looks like we can stay in compliance of the author's branding request by simply setting , effectively preventing Hydra from building this package and having it redistributed in the binary cache. Unfortunately for MultiMC users, this will meant that Nix will have to build it on their machine. I am possibly open to re-branding MultiMC, but not until work is done upstream to make branding changes very simple ones like it is the case for browsers like Firefox or Chromium. I have no interest in maintaining gigantic patch sets for branding changes.
on the topic of this, incorrectly states the license as . Shouldn't it be ?
Yes, that looks like an oversight. I will correct it when I prepare my PR after work.
gotcha
I'm not so sure this technically counts as redistribution (apart from Hydra caching) given Nix's package system doesn't require Nix to redistribute the actual source code, and just downloads it from GitHub. Regardless, I do have concerns about this package. Minecraft is subject to frequent changes made by the developer, and sometimes these changes need to be implemented quickly to avoid a flood of users complaining that their launcher has suddenly broken. This package was updated only a month ago, and is already outdated, as the latest versions of the game require a newer version of Java. Because of these frequent changes, the upstream binaries have an automatic updater, which allows things to be patched quickly when sudden changes are made. Source-based packages like this which have to disable the auto-updater prevent this from happening, and they usually don't get updated frequently enough to keep up with the constant changes necessary to keep this software working. This is the main reason we prefer the branding to be changed. We don't want to support modified or outdated versions of the software. As far as I know work is actively being done to make it easier to change the branding at build time, but I think the ideal solution for most users who just want a package that always works is to do what I did on NixOS and just run the official binary releases in an FHS-compatible chroot, so they can be auto updated as normal.
This package deliberately allows the user to select between jdk 16 and jdk 8 and prefers jdk 16 by default, not sure what you're trying to imply here. Automatic updaters are against the very spirit of pinned dependencies and should never be included in nixpkgs unless the software being packaged's autoupdater cannot be disabled and has to be worked around (i.e. steam). Like I said, I am open to re-branding the package if I don't have to maintain a non-trivial patch to do so. Until then, we will proceed by disabling binary caching and comply with the Apache 2.0 license terms.
My apologies, I seem to have misread the package here. It was just meant to be an example of the sorts of third party changes that can break this software with little to no warning. As a Nix user myself, I understand the benefits of pinned dependencies for most software, but most software does not rely on third parties such as Mojang and various mod loaders. You cannot pin Minecraft, or Forge, or Fabric, and so you cannot prevent them from changing and breaking this software you have pinned at a specific version. By doing so, you are only making it less reliable, which is counter to one of Nix's core goals. Work is already underway to make this easier, so if this is the way you'd like to proceed, hopefully it will be made easy soon. Apologies if I came on a bit strong here, I just wanted to clarify what I view as a somewhat unique situation that MultiMC has been in for its entire existence. The software works or breaks at the whims of third parties like Mojang, and because of this, we prefer to not have outdated versions in common use.
For what it's worth, I've considered packaging Minecraft directly via Nix (instead of a launcher), which would solve these issues (but wouldn't be MultiMC).
Packaging minecraft directly has already happened in a way with the minecraft-server packages. Maybe we could even get declarative mods/resourcepacks to work then :smile:
packaging Minecraft directly with Nix is outside the scope of this discussion. I think this is acceptable. If it were possible to (with ease) completely declaratively describe a Minecraft installation, we wouldn't even need MultiMC in the first place! As you say, this is entirely possible and users who would like to bypass the purity and immutability provided by Nix package installations are welcome to do so, keeping this package in its current form in nixpkgs isn't stopping anyone from doing it. The barrier to entry for NixOS and Nix in general is pretty high and I expect anyone using nixpkgs to understand the implications of pinned software versions. There will never be an auto-updater for MultiMC here. I don't agree that MultiMC is being made less reliable by being slightly out of date. Sure, future versions of Minecraft aren't guaranteed to work until the software is updated but previous versions of the game will always keep running which I think is a more important point on the reliability front. This package has maintainers (like me) who play Minecraft regularly and will update the package swiftly if something stops working. There isn't even anything stopping you from submitting a PR to update MultiMC if you notice that something's wrong and that no one else has done it. Honestly, I'd love to not even have to mess with branding at all, but I am willing to work with you to re-brand (when it is feasible) since it is apparent that the risk of getting support requests originating from this package is too high for the project. I also think that using the Apache 2.0 license to gate-keep the distribution of binaries is uncalled for since you're still calling for a re-brand even if we stop distributing our own MultiMC binaries.
Why would/should this not be on the MultiMC git repo? It can just be extracted easily... they are not special "secrets".
I am not even sure why he would even care as nix will build the latest version of MultiMC anyways so it's whatever he is pushing to git and it is not possible to use his releases as they will not run on Nix without patching so it is not like an alternative exists... Basically, this is just the MultiMC dev ( being a massive cry baby claiming that he is being "digitally raped" by people distributing his untrademarked software and if he really does not want people to distribute as "MultiMC" he should make the program closed source as he said he would if he kept crying or he should make it not be branded as "MultiMC" by default despite all the code changes being from him even in the Nix version and it is not like anyone removed the Minecraft authentication requirements that he usually cries about people doing and keeping the name as "MultiMC".
I wish it could be so, but both Forge and Minecraft itself have been known to sometimes introduce breaking changes, even to older versions. peterix has taken steps to alleviate this issue with the meta system, but you can only bandage so much, and even the meta system itself can be subject to breaking changes, which are accompanied by a MultiMC update to support those changes, thus breaking older versions. Ultimately there is no guarantee that any of this can be done declaratively without constantly keeping on top of the changes in some way. The issue is more of a burden than a risk, and I don't believe this package will be a burden, especially not compared to the number of support requests we receive for "cracked" forks of the software. Plus, as you have said, Nix users mostly know what they're doing, so they're not likely to need support. Further, this package is mostly unmodified and unlikely to cause issues as from what I can see so long as it's kept updated. I wouldn't have opened this issue myself for those reasons, but since it was already done, I figured I should throw in my two cents here. So no, I don't consider the risk or burden of support requests generated by this package to be too high for the project. This policy is primarily targeted at "cracked" forks which purport to be "MultiMC" while being severely outdated, broken, and allowing violation of Mojang's copyright. The principle still applies here, though. We prefer different branding to distinguish other forks or distributions of the software that may not be exactly up to date with upstream. I appreciate that you're open to doing that, even if you may disagree with it.

Discussion:
''; platforms = platforms.linux; license = licenses.asl20; <ins> # upstream don't want us to re-distribute this application: # https://github.com/NixOS/nixpkgs/issues/131983 hydraPlatforms = []; </ins> maintainers = with maintainers; [ cleverca22 starcraft66 ]; }; }