amulet-map-editor: init at 0.10.44

[Tibso]

This PR adds the Amulet Map Editor package to Nixpkgs.
This application is a map editor for the video game Minecraft.

The application has python-modules dependencies that I also added individually, in case people want to use them for some Minecraft Python projects.

This closes #201016

And I suppose also closes #356035
Some peeps on Discord told me there was already a PR for this package, but silly me must have forgotten to check for a previous PR. So I've quickly added some stuff from the other PR (thank you @pluiedev) but I did not include stuff like tests and Sphinx docs stuff because I haven't looked into those yet, so I don't know how those things work.
Tell me if I need to add those for this PR.

The application works and is usable, although there are some UI rendering issues related to wxpython, which make the application hard to use. The application devs are aware of the UI issues (seems to be related to this issue #127) and they seem to occur for any linux user (so also for other distros).
The devs are working on replacing wxpython to fix the UI issues.

Things done

• Added myself to maintainers.list
• Added amulet to licenses.list
• Added the amulet-map-editor application

The following python-modules were also added:

• amulet-core
• amulet-leveldb
• amulet-nbt
• minecraft-resource-pack
• pymctranslate

Building and testing:

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Sigmanificient]

Hi, welcome to nixpkgs and thanks you for your awesome work!

Theses two change request apply to all the derivation in order to follow current buildPython{Application,Package} standards, sorry this is quite some changes to do.
Lets also make sure we can importa theses packages using pyrhonImportsCheck!

[pluiedev]

Hey :) I'm okay with closing my PR in favor of yours if I could be credited as a co-author on changes that were taken from my PR (add Co-authored-by: Leah Amelia Chen <[email protected]> at the very bottom of the commit message). No need to add me as a maintainer though, as I was only trying to package this as an experiment and not out of vested personal interest.

[Tibso]

I've fixed all mentioned issues.
Let me know if there's still something to change or add.

Edit: I will try to remove the overrides.

[Tibso]

I've fixed mentioned issues again, minus the modules tests because they fail for reasons I don't understand.
I'll look into it if it is necessary for this PR.

[alyssais]

Ack license.

[Tibso]

Okay now we have the tests running and passing except on minecraft-resource-pack. I disabled those tests because the dev told me they were broken for that one module.

I asked for help on our Discord server to add the tests. @langsjo discovered that the reason I was having issues was because the modules I fetched from PyPI didn’t include any tests. The solution was to use fetchFromGitHub instead of fetchPypi to get the modules with the test files included... So basically like on the older PR...

I sincerely hope this PR is ready to go now.
Let me know. = )

[dtomvan]

Uhm, the license that you set has not been merged into their 0.10 branch yet (Amulet-Team/Amulet-Map-Editor#669). Can we actually declare that this is the license that this project is available under, or should it be license = "unfree" for now?

[emilazy]

If I read that PR correctly, there was no licence in the repository at all previously, and they have just pinged every past contributor saying they’re going to assume their changes were under MIT without there having previously been any indication of that?

That is, uh, not how it works. If I understand correctly, then this is going to have to be lib.licenses.unfree with a big warning in a comment forever unless all the previous contributors agree to the change or their contributions are rewritten or can be shown to be too trivial to be copyrightable.

[pluiedev]

As I understand it the core maintainer(s) weren't really concerned about the legal implications of unclear licenses for us packagers. It feels like an unspoken agreement that the repositories should be in their custom Polyform Shield fork, and they never bothered to codify it as such.

I personally wouldn't take any chances and would only label the packages with an explicit LICENSE file with lib.licenses.amulet, and the others with unfree.

[dtomvan]

That is, uh, not how it works

I guess it really is time for lib.licenses.illegal to be a thing then 😅

It feels like an unspoken agreement that the repositories should be in their custom Polyform Shield fork

I think they also all signed a CLA. Not a lawyer but judging from its wording they are able to just change licenses to their heart's content once a contributor has signed the CLA:

In summary, agreeing to this allows us to use, modify, redistribute and re-license your contribution

Longer clause

Subject to the terms and conditions of this Agreement, You hereby grant to Us a worldwide, royalty-free, NON-exclusive, perpetual and irrevocable (except as stated in Section 8.2) license, with the right to transfer an unlimited number of non-exclusive licenses or to grant sublicenses to third parties, under the Copyright covering the Contribution to use the Contribution by all means, including, but not limited to:

publish the Contribution,
modify the Contribution,
prepare derivative works based upon or containing the Contribution and/or to combine the Contribution with other Materials,
reproduce the Contribution in original or modified form,
distribute, to make the Contribution available to the public, display and publicly perform the Contribution in original or modified form.

Looks like they started using CLAassistant since Amulet-Team/Amulet-Map-Editor#530 though (May 2022), so there exist some changes prior that are not "MIT-able", most notably ALTB0ne's (translations) and naor2013's (a couple minor features) ...

If you want to see for yourself, I got this info from the github insights page

[emilazy]

I guess it really is time for lib.licenses.illegal to be a thing then 😅

Oh, we’ve been there for a long time…

lib.licenses.unfree is how we tend to handle this kind of thing. I personally don’t love adding new packages with messed up copyright status but there is a lot of questionable stuff already in the tree.

Looks like they started using CLAassistant since Amulet-Team/Amulet-Map-Editor#530 though (May 2022), so there exist some changes prior that are not "MIT-able", most notably ALTB0ne's (translations) and naor2013's (a couple minor features) ...

These are clearly substantial enough contributions to be copyrightable. If they don’t have permission from these contributors then we can’t record this as Polyform regardless of what the repository says.

[Tibso]

Okay, so if I understand the licensing issue correctly, the Amulet license is somehow flawed.
Therefore, I have to remove the Amulet license (lib.licenses.amulet) and simply use lib.licenses.unfree for the Amulet application and the python modules?
Or the scuffed Amulet license is fine as it is configured now?

I looked at #422452 and there seem to be other issues I haven't encountered myself that would need fixing, but I could work with @erkingoksuu on a following PR to add his fixes.

I'll update this PR for version 0.10.44 whenever I have a bit of time.

I'd really like to be done with this PR as it adds me in the maintainer list and there are other PRs that I would like to do. =)

[dtomvan]

I think you'd need to carefully look which project do and don't include a LICENSE file with the amulet license in it. If it doesn't it should be changed to lib.licenses.unfree, since we cannot truthfully call it "licensed under the amulet license".

For example, amulet-nbt is correct with lib.licenses.amulet, as it does have the amulet license in its tree

I looked at #422452 and there seem to be other issues I haven't encountered myself that would need fixing, but I could work with @erkingoksuu on a following PR to add his fixes.

I wouldn't do that. Because that PR was closed for a reason. I have no idea if those changes that were deemed as "required" by the LLM are actually needed. It would be much better if a human looked at it instead... Happy to help though if you need it (I would need some leads on what's wrong with the package as of now but I think that goes without saying).

[gentlegiantJGC]

Sorry for this being such a pain. I am not a legal expert and licenses make my head hurt.

Looks like they started using CLAassistant since Amulet-Team/Amulet-Map-Editor#530 though (May 2022)

Correct. Newer contributions are not an issue.

there exist some changes prior that are not "MIT-able", most notably ALTB0ne's (translations) and naor2013's (a couple minor features) ...

The advice from my boss (and sponsor of the project) was that contributions to a repository without a license inherit the default license which may be a misunderstanding of section D6 of the terms of service.

I think until we can sort out the license issues your simplest solution is to list it under lib.licenses.unfree

It is also worth noting that I have been working on a large rewrite of a lot of these libraries so the default branch may not be the version you are using and may contain a license where the old one does not.

[Tibso]

Okay I updated the editor and the modules and changed the metadatas to use lib.licenses.unfree whenever the Amulet license was not present in their respective repository.

I retested the editor and it still works with the UI issues already mentioned before. There are also random Pango segfaults that I forgot to mention before. But its apparently another issue that users experience (Amulet-Team/Amulet-Map-Editor#1012).

[UlyssesZh]

I think there is no point in defining lib.licenses.amulet when even PolyForm licenses are not in lib.licenses. What current packages in nixpkgs do is just put unfree and add a comment with the link to the upstream license file.

[Tibso]

I made the change.
Removed the license, used unfree and added comments linking to their license.

Should be good for a merge now ? =)