You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently software such as vault is not built by ofborg, and I don't really understand why. bsl11 may not be open source, but it is source-available and redistributable = true;.
I could see an ideological argument here, but I don't think that should an excuse for being unhelpful to Nixpkgs maintainers.
So I'd like to ask, is this limitation intentional?
The text was updated successfully, but these errors were encountered:
A relevant conversation is NixOS/nixpkgs#83884, in particular the suggestion to introduce a "curated [white]list" of licenses instead of unfreeRedistributable (also an example of implementation from Gentoo)
As to my opinion, I think the solution is hierarchical:
We should evaluate everything (unfree, insecure, cross) in order to compensate for the lack of static typing. IMO this we should start doing now, maybe in a concurrent job. The only excuse not to do this is Nix's performance, and it's a bad excuse because developers' time is more expensive than the compute
We should build the tests for whitelisted unfree licenses, but we should abstain from distributing the closures to the "user"
For a subset of white-listed licenses, we should "build" and cache the FODs (e.g. the singular contention point about the CUDA EULA is whether "patchelf"-ing substitutes a "modification"; there's seemingly no reason, however, not to keep the original tarballs from disappearing)
A tangential point is that we seem to lack tools to plug a third party Ofborg-like CI in and out of the Nixpkgs forge...
Currently software such as
vault
is not built by ofborg, and I don't really understand why.bsl11
may not be open source, but it is source-available andredistributable = true;
.I could see an ideological argument here, but I don't think that should an excuse for being unhelpful to Nixpkgs maintainers.
So I'd like to ask, is this limitation intentional?
The text was updated successfully, but these errors were encountered: