Only because the purist inventors of nixpkgs structured the policy of what must go into nixpkgs to have this rule. Why doesn’t the same limitation exist for homebrew, for instance? It isn’t some idiosyncracy of the way they are building things, it was a conscious and deliberate policy decision.
And it might be the right one for what they are trying to achieve, but if the goal of the project is to make it more accessible and see more widespread adoption, stuff like this is a shot in the Achilles heel
> purist inventors of nixpkgs structured the policy of what must go into nixpkgs to have this rule
No. Both lib.licenses.unfree and lib.licenses.unfreeRedistributable are accepted into Nixpkgs, but the former marker indicates that the developer has declared it illegal to distribute builds so the official binary cache (sorry, “substituter”) does not.
What Homebrew likely does is fetch the upstream binaries from the upstream download server. Nixpkgs does have a policy against that when buildable source code is available, but that’s mostly because the way Nix achieves isolation (both from the host system and between packages) is by placing almost all shared libraries and data files in hash-decorated places that are emphatically different from what an upstream binary expects. On Linux, it’s possible, if very distasteful, to cram that peg into this hole using mount namespaces and bind mounts (see buildFHSEnv et al.); not sure about Darwin, but the general response to asking Nixpkgs maintainers to keep this sort of fragile mess working is, indeed, pretty much exactly “ain’t nobody got time for that”.
And it might be the right one for what they are trying to achieve, but if the goal of the project is to make it more accessible and see more widespread adoption, stuff like this is a shot in the Achilles heel