I don’t think this is possibility with the LGPL. That would totally be against the idea of Free software and AFAIK, you’re not allowed to pose further restrictions.
You could add a notice to the NixOS option that manages mods that upstream would prefer you download the jar through their ad-infested links or support them on Patreon but requiring that wouldn’t make sense in the context of Nix.
I’m pretty sure it’s possible, given they ultimately own the copyright, so they can license it however they like. At least assuming none of their dependencies is LGPL and none of their contributors disagree. Yeah, messing with licensing for an established project is hard 
Whether this would hold up in court, whether they’d actually attempt it or whether it would even keep anyone from using it in practice is a different matter.
Ultimately I’d much prefer building from source anyway, but their build system is… Well, what you’d expect from a decade old Java project in the Minecraft ecosystem.
Still, I appreciate why they ask, and like at least keeping with the spirit of their request. To my knowledge there is no real commercial backing, despite a lot of commercial organizations using it. I’ve also seen their issue tracker and it’s just about as bad as you’d expect from a game-related github repo.
Your suggestion seems reasonable too, though.
You can still use stdin/stdout with systemd directly by using systemd sockets.
Where you set in systemd:
StandardInput=socket
StandardOutput=journal
Together with writing up a .socket file for telling systemd where it should put the socket file.
You can see how i set it up myself here: https://github.com/imsofi/minecraft_systemd/tree/26a27113eb3eb61ad7d2a7c0394d5c7b20b2b3c2/templates
While i do agree with your points, you are missing the why of why tmux has become a default for selfhosted minecraft servers.
Prefix this with that this issue has seemingly been fixed with 1.17+[1], but minecraft has been extremely bad at listening to SIGTERM commands[2]. Where some versions of minecraft simply ignore the signal entirely, then panicking when the SIGINT comes around. Or the other way around where the server will just brutally stop itself at the second any signal is sent, skipping saving the world folder which is not good. Which is where I feel this anti-pattern of tmux has originated from.
I do still agree that the use of tmux should be avoided for minecraft, as there are better choices for it. One alternative would be what i described in my above message.
1: Minecraft Server on SIGTERM / SIGINT
2: https://bugs.mojang.com/browse/MC-202209
Interesting, I’m also working on managing minecraft with nix, but focus more on the client side: GitHub - Ninlives/minecraft.nix: Command line Minecraft launcher managed by nix
Hm, I had no idea about those bugs, odd that I’ve not run into them. I suppose I didn’t run many servers in the 1.16 era.
Still, even with bugs like that, hooking systemd up to a TTY is heaps and bounds better than abusing tmux. You can always still send commands over the TTY, after all. I think the real reason it’s used is mostly ignorance of systemd’s more advanced options.
On the note of ignorance of systemd options, the socket approach is interesting too, I actually think I like it better than blocking out a TTY, assuming it fulfills that criterium of correctly sending across the escape sequences that mod wants, and you can hack up a script to redirect stdout such that that mod actually works. Probably not going to work as well as a TTY, but I’ll give it a try 
This is pretty neat. I saw that thread too and was considering doing something with it, but since I use PolyMC already, I haven’t really gone far with it. May give it a try at some point.
oh wow great, I have a module that does pretty much the same stuff as you do here which I was looking to upstream over the summer, I’ll have a look at whether or not anything I have is worth adding here instead
Do you have a repo for it, im all for seeing how other people have been approaching packaging and setting up minecraft under nix.
The repo is linked in the original post, unless you mean something else.
If you do mean something else, could you clarify what you mean?
Ah sorry, that was a message i meant in reply to @Dandellion as they were talking about having a similar module to yours.
Hm I too was also thinking about making declarative modded minecraft, though considering a bit more client side.
The main thing I was wondering is how feasible it would be to have ALL the config files be immutable, my gut feeling is that most mods would not be happy, but I haven’t tested it myself…
My main motivation is to make the process of updating a modpack, both server and client, a lot less painful and also destructive. If one could define your config file changes from nix, it could easily be preserved between updates, making them a lot less annoying to deal with. The current method I’m using is using git to track my client/server files directly, but I’d personally say that while better, it’s still suboptimal.
P.S. I didn’t think there would be so many people considering this lmao, as well as so many separate projects trying to accomplish this goal, perhaps if we join up we could make something quite good 
You can also take a look at my project here, although it is WIP. It is quite declarative, and adding support for writing config files directly in nix wouldn’t be that hard, but I think most mods wouldn’t tolerate having their config files as immutable symlinks. For example, I currently just wipe the entire mods/ folder and copy all the mods to it again on every start, since it doesn’t work with symlinks.
Mods definitely work with (their jar files as) symlinks, I’ve been running multiple servers off of symlinks from mods fetched via fetchurl (plus the helper fetchModrinthMod).
In my case, I suppose declarative arbitrary things in the server directory via a symlinks option.
Symlinked config files would definitely be more problematic though, I agree.
I’ve been meaning to improve how the option is handled so that individual files nested in subdirectories are easier to handle. (Right now I make my mods/ into a link farm of the mod derivations.
Yeah, a number of people have definitely been thinking about it.
Part of the issue that comes with client config files is that they’re just kinda a pain to do manually, especially considering that many mods let you configure things immediately through menus and see results. Plus, rebuilding the entire instance derivation for a config change just sounds painful.
That being said though, it would definitely be nice.
Yeah I can see how they’re a pain, though thankfully you don’t change your client configs much after you get them down, and doing it this way makes sure that no update will revert your client config changes.
I wonder if it’s possible to make them declarative without breaking Minecraft? or maybe we could have them be mutable, but any changes are reverted after the game closes? Then you can still make config changes in game, and move any ones you want to keep into your derivation.
This is actually how the server module handles the server.properties file, since Minecraft wants that file to be mutable when the server is running. (It copies the generated file each time the server is started in the pre-start script.)
So i have yet to fully follow through with this, but there is packwiz to manage your entire configuration in a declarative fashion. I have yet to attempt to use packwiz however, but it should supposedly let you configure everything.
And for the .properties files, i used to run ansible with a StartPre system that would copy any file with a specific extension to itself without the extention. Letting you have read only .properties files for both minecraft and mods. For example a server.properties.ansible or mods/my-mod.properties.ansible.
I may look into the feasibility of doing something similar with nix to have any file be able to be declarative, as currently it is only manually copying server.properties at each start.
Only issue i know of so far about implementing a nixifed packwiz is that you cannot easily manage secrets with it. Which is a real problem for a minecraft server, as its configuration files would hold a lot of secrets throughout.
One potential option would be to split the file management between Nix and packwiz, with packwiz managing the non-secrets and Nix managing the secrets with agenix or similar.