release-unfree: init

[zimbatm]

Description of changes

Due to the NixOS project's current policies, there is a whole set of nixpkgs packages whose code is currently untested by the main hydra.nixos.org.

At nix-community/infra#1406 we started testing those packages, so we can get feedback on what breaks.

The motivation to adding this file to nixpkgs instead of maintaining https://github.com/numtide/nixpkgs-unfree is that it makes it easier to keep it in sync with the rest of the nixpkgs code base.

Things done

• 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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

[emilazy]

cc #83884

I think that this should at least be based on unfreeRedistributable rather than unfree in general, even if it’s not built on the main Hydra itself, since touching non‐redistributable packages is a minefield, even if you don’t redistribute them (we often use lib.licenses.unfree to represent “you cannot build this package without committing a copyright violation”).

I’ll also link my own #83884 (comment), although if it is for third‐parties to build on their own infrastructure, especially without redistribution, then just a warning about the risks may be enough.

[zimbatm]

Thanks. I updated the file header in that direction. I agree that the topic is a bit of a minefield, which is why we're tackling it in a sister project that the NixOS Foundation doesn't control. IANAL, but our intent here is not to redistribute or to circumvent copyright but to test the code. If we cannot do that, then we should have a conversation on whenever these packages belong in nixpkgs in the first place.

[emilazy]

I learned that the nix-community Hydra has been building this branch and is e.g. redistributing Aseprite, which is marked as lib.licenses.unfree and is expressly not redistributable, via Cachix. That’s not good. (Thanks to @Kamillaova for pointing this out.)

[zimbatm]

Looking past the surface, isn't it useful to know that Aseprite is building correctly? And also getting insight on other software failing to build:

It goes without saying, please pay for Asperite if you're going to use it. There is also an argument to make that setting NIXPKGS_ALLOW_UNFREE=1 isn't exactly the same as accepting the EULA. Or you could say that packaging Asperite in the first place is discouraging people to buy the software as it reduces the friction of building from source vs the other binary distributions the project is providing.

The subject is quite deep and it would be nice to be able to have a richer conversation around it. I agree the current setup isn't ideal, but also, please understand that it isn't exactly easy to setup a whole parallel build infra for this exploration.

[Kamillaova]

in my opinion, building all unfree packages is good, but at least publishing them in a public cache is bad

[emilazy]

There is also an argument to make that setting NIXPKGS_ALLOW_UNFREE=1 isn't exactly the same as accepting the EULA.

It’s not enough. The EULA explicitly prohibits distributing binary versions that you compile at all, as nix-community is doing here. The violation isn’t only on the part of the end user.

[Kamillaova]

I also can do nix-store -r /nix/store/r40gsqikj02jycsg9c19lx0pkrclyapf-aseprite-1.3.7, in which case I don't need to accept anything.

Or I can just download NAR via curl or smth like that

[emilazy]

To clarify… I have no particular attachment to or care for Aseprite. I’m not even the one who found this issue; @Kamillaova reported it in Matrix and I felt like it should be recorded somewhere more permanent. It’s just an example of a package whose terms expressly and with clear intent forbid this kind of redistribution, which also applies to the vast majority of lib.licenses.unfree packages. Building and testing is one thing, but if a package could be redistributed via a binary cache without legal issues, it would already be marked as lib.licenses.unfreeRedistributable. Redistributing lib.licenses.unfree stuff is a really big legal liability, since those are specifically the things marked as not being okay to redistribute.

I really appreciate the resources nix-community provides and don’t want to see that jeopardized by copyright issues. I thought it would have been a simple oversight and that me reporting it would be welcome. If that’s not the case, I’m sorry; I don’t want to cause conflict.

[zimbatm]

Please forgive my frustration, I was reacting to a larger pattern that isn't you. I appreciate and agree with your point and observation overall.

[SomeoneSerge]

An alternative question to answer is should we be more aggressive about merging packages that come with "legal baggage" designed to make these packages (and their reverse dependencies) more expensive to maintain?..

We need CI, if we acknowledge the maintainer time to be our scarcest resource.
Then a private cachix for unfree-non-redistributable is more or less a lowerbound on the cost of keeping such packages and their reverse-dependencies in the tree.

[zimbatm]

Looking back, I should have been better prepared. There are multiple threads of conversation I should have addressed head-on:

1. Is it legal? I'm not sure. IANAL. I don't think it's black and white. What counts as a binary distribution from a legal perspective could be different. From an intent perspective, Asperite wants to encourage users to use their distribution channels where the user is directed to pay for said software. This intent is already attacked by simplifying the source distribution trough our derivation code. We should come up with ways to make sure they are getting paid. Currently, all a user has to do is set NIXPKGS_ALLOW_UNFREE=1, and they can get Asperite without explicitly agreeing to their EULA.
2. Is it risky? Again, IANAL, but legal systems have different levels, and my understanding is that we are on the very lowest level. IF something happens, my understanding is that a lawyer would send us a cease-and-desist letter (send to admin@nix-community.org), we would disable the hydra build and flush the cache, and that's it. Also, if we are that afraid, we should review every package in nixpkgs very carefully because it could affect the main project then (and we have no GC capability there).
3. Is it worth doing? I believe it is worth stepping around the line because it gives us insight into parts of nixpkgs that are currently not exercised. And it can generate conversation on what belongs to nixpkgs (which I badly clipped sorry). I also see a future where we partner with some unfree vendors by showing the utility developing around our packaging. That being said, it doesn't mean we want to be permanently in this state. Either we split out the cache so it becomes private (but this requires more infra), or decide to go the unfree-redistributable route, but then I would like us to determine what to do with the unfree packages. But if we don't go down that route, the experiment gets clipped early, and we won't be able to find out.
4. Can this PR be included in nixpkgs? All the above is part of a deeper conversation. Do those all have to be resolved before this PR can be merged? Or can we agree that the risk is mainly on the nix-community project and, ultimately, our decision on whether it's worth taking the risk?

I prefer that we focus the conversation on (4) for this PR, but I would love to expand on all the other points as well, maybe in another place?

[zimbatm]

Closing to restart the conversation on a better footing, with unfree+redistributable this time.

There was also an issue with the branch as it was under the nixpkgs- branch protection rule, which I had to disable temporarily to remove this branch.