From 6c0e4bc5a6d1607818d7fb5d175dee3ddf462e89 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Sun, 15 Dec 2024 19:24:16 +0100 Subject: [PATCH 01/11] [RFC 0185] Redistribute redistributable software --- rfcs/0185-redistribute-redistributable.md | 108 ++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 rfcs/0185-redistribute-redistributable.md diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md new file mode 100644 index 0000000..e697911 --- /dev/null +++ b/rfcs/0185-redistribute-redistributable.md @@ -0,0 +1,108 @@ +--- +feature: redistribute-redistributable +start-date: 2024-12-15 +author: Ekleog +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +related-issues: https://github.com/NixOS/nixpkgs/issues/83884 +--- + +# Summary +[summary]: #summary + +Make Hydra build and provide all redistributable software. + +# Motivation +[motivation]: #motivation + +Currently, Hydra builds only free software and unfree redistributable firmware. +This means that unfree redistributable software needs to be rebuilt by all the users. +For example, using MongoDB on a Raspberry Pi 4 (aarch64, which otherwise has access to hydra's cache) takes literally days and huge amounts of swap. + +Hydra could provide builds for unfree redistributable firmware, at minimal added costs. +This would make life much better for users of such software. +Especially when the software is still source-available even without being free software, like MongoDB. + +# Detailed design +[design]: #detailed-design + +Hydra will build all packages with licenses for which `redistributable = true`. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +With this change, Hydra will start building, among others: +- CUDA +- DragonflyDB +- MongoDB +- Nomad +- NVIDIA drivers +- Outline +- SurrealDB +- TeamSpeak +- Terraform +- Unrar +- Vagrant + +Hydra will keep not building, among others: +- CompCert +- DataBricks +- Elasticsearch +- GeoGebra +- Widevine CDM + +# Drawbacks +[drawbacks]: #drawbacks + +The only previously listed drawback is that NixOS could end up including unfree software in the ISO image without noticing. +However, as there is already unfree firmware, this fight is already half-lost. + +Also, adding unfree software to the ISO image would still require a NixOS maintainer to actually add it there. +The only benefit we currently get out of not building unfree redistributable software, is that the hydra builds for the ISO would fail if someone were to make a mistake. + +# Alternatives +[alternatives]: #alternatives + +## Having Hydra actually only build FOSS derivations, not even unfree redistributable firmware + +This would likely break many installation scenarios, but would bring us to a consistent ethical standpoint, though it's not mine. + +## Keeping the statu quo + +This results in very long builds for lots of software, as exhibited by the number of years people have been complaining about it. + +## Implementing this RFC + +See above for the details + +## Implementing this RFC, plus adding a check on Hydra to validate no unfree software enters the ISO image + +This would likely be harder to implement. +It could be a job override, that would make hydra allow unfree redistributable software for all jobs except for the ISO image, which would only allow unfree redistributable firmware. + +The drawback of this alternative is that it would be more effort to implement, especially as manpower around Hydra is very scarce and limited. +However, it would solve the only previously listed drawback. + +## Building all software, including unfree non-redistributable software + +This is quite obviously illegal, and thus not an option. + +# Prior art +[prior-art]: #prior-art + +According to [this discussion](https://github.com/NixOS/nixpkgs/issues/83433), the current statu quo dates back to the 20.03 release meeting. +More than four years have passed, and it is likely worth rekindling this discussion, especially now that we actually have a Steering Committee. + +Recent exchanges have been happening in [this issue](https://github.com/NixOS/nixpkgs/issues/83884). + +# Unresolved questions +[unresolved]: #unresolved-questions + +None. + +# Future work +[future]: #future-work + +If this RFC lands as-is, future work could be around adding the check on hydra listed in the alternatives section. +This would validate that no unfree redistributable software enters the ISO image. From c48a29bcb3a76358bffaf0402b461392ce3eea9a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Sun, 15 Dec 2024 19:35:45 +0100 Subject: [PATCH 02/11] smaller titles --- rfcs/0185-redistribute-redistributable.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index e697911..849f884 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -64,19 +64,19 @@ The only benefit we currently get out of not building unfree redistributable sof # Alternatives [alternatives]: #alternatives -## Having Hydra actually only build FOSS derivations, not even unfree redistributable firmware +### Having Hydra actually only build FOSS derivations, not even unfree redistributable firmware This would likely break many installation scenarios, but would bring us to a consistent ethical standpoint, though it's not mine. -## Keeping the statu quo +### Keeping the statu quo This results in very long builds for lots of software, as exhibited by the number of years people have been complaining about it. -## Implementing this RFC +### Implementing this RFC See above for the details -## Implementing this RFC, plus adding a check on Hydra to validate no unfree software enters the ISO image +### Implementing this RFC, plus adding a check on Hydra to validate no unfree software enters the ISO image This would likely be harder to implement. It could be a job override, that would make hydra allow unfree redistributable software for all jobs except for the ISO image, which would only allow unfree redistributable firmware. @@ -84,7 +84,7 @@ It could be a job override, that would make hydra allow unfree redistributable s The drawback of this alternative is that it would be more effort to implement, especially as manpower around Hydra is very scarce and limited. However, it would solve the only previously listed drawback. -## Building all software, including unfree non-redistributable software +### Building all software, including unfree non-redistributable software This is quite obviously illegal, and thus not an option. From 54164cf593d8ae71c3f373e870e57f6e6ce8ad7d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Sun, 15 Dec 2024 19:58:56 +0100 Subject: [PATCH 03/11] fix typo Co-authored-by: Matt McHenry --- rfcs/0185-redistribute-redistributable.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index 849f884..0ce5a01 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -20,7 +20,7 @@ Currently, Hydra builds only free software and unfree redistributable firmware. This means that unfree redistributable software needs to be rebuilt by all the users. For example, using MongoDB on a Raspberry Pi 4 (aarch64, which otherwise has access to hydra's cache) takes literally days and huge amounts of swap. -Hydra could provide builds for unfree redistributable firmware, at minimal added costs. +Hydra could provide builds for unfree redistributable software, at minimal added costs. This would make life much better for users of such software. Especially when the software is still source-available even without being free software, like MongoDB. From d218e50cea08eb85063a7ee25115a64bf786baf6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Tue, 17 Dec 2024 18:36:44 +0100 Subject: [PATCH 04/11] handle review comments --- rfcs/0185-redistribute-redistributable.md | 66 ++++++++++++++++------- 1 file changed, 46 insertions(+), 20 deletions(-) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index 0ce5a01..90105f2 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -11,7 +11,7 @@ related-issues: https://github.com/NixOS/nixpkgs/issues/83884 # Summary [summary]: #summary -Make Hydra build and provide all redistributable software. +Make Hydra build and provide all redistributable software, while making sure installation methods stay as fully free as today. # Motivation [motivation]: #motivation @@ -28,11 +28,36 @@ Especially when the software is still source-available even without being free s [design]: #detailed-design Hydra will build all packages with licenses for which `redistributable = true`. +It will still fail evaluation if the ISO image build or the Amazon AMIs were to contain unfree software. + +This will be done by evaluating Nixpkgs twice in `release.nix`. +Once with `allowUnfree = false` like today, plus once with `allowlistedLicenses = builtins.filter (l: l.redistributable) lib.licenses`. +Then, most of the jobs will be taken from the allowlisted nixpkgs, while only the builds destined for installation will be taken from the no-unfree nixpkgs. + +The list of jobs destined for installation, that cannot contain unfree software is: +- `amazonImage` +- `amazonImageAutomaticSize` +- `amazonImageZfs` +- `iso_gnome` +- `iso_minimal` +- `iso_minimal_new_kernel` +- `iso_minimal_new_kernel_no_zfs` +- `iso_plasma5` +- `iso_plasma6` +- `sd_image` +- `sd_image_new_kernel` +- `sd_image_new_kernel_no_zfs` # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -With this change, Hydra will start building, among others: +With these changes, here is what would happen as things currently stand. +This is not meant to be indicative of what should happen or not, but indicative of what would happen. +Each package's individual `license` field setup is left to its maintainers, and nixpkgs governance should conflict arise. +This RFC does not mean to indicate that it is right or wrong, and is not the right place to discuss changes to this field. +Should one have disagreements on any specific package in this list, please bring that up to that package's maintainers. + +With this in mind, Hydra will start building, among others: - CUDA - DragonflyDB - MongoDB @@ -44,8 +69,9 @@ With this change, Hydra will start building, among others: - Terraform - Unrar - Vagrant +- NixOS tests that involve such software (eg. MongoDB or Nomad) -Hydra will keep not building, among others: +And Hydra will keep not building, among others: - CompCert - DataBricks - Elasticsearch @@ -55,34 +81,33 @@ Hydra will keep not building, among others: # Drawbacks [drawbacks]: #drawbacks -The only previously listed drawback is that NixOS could end up including unfree software in the ISO image without noticing. -However, as there is already unfree firmware, this fight is already half-lost. +The main risk is that NixOS could end up including unfree software in an installation image if: +1. we forgot to add it to the list of no-allowed-unfree jobs, and +2. a maintainer did actually add unfree software to that build. -Also, adding unfree software to the ISO image would still require a NixOS maintainer to actually add it there. -The only benefit we currently get out of not building unfree redistributable software, is that the hydra builds for the ISO would fail if someone were to make a mistake. +This seems exceedingly unlikely, making this change basically risk-free. + +The only remaining drawback is that Hydra would have to evaluate Nixpkgs twice, thus adding to eval times. +However, the second eval (with no-unfree) should be reasonably small and not actually evaluate all packages, as it is only used for installation media. # Alternatives [alternatives]: #alternatives -### Having Hydra actually only build FOSS derivations, not even unfree redistributable firmware +### Having Hydra actually only build FOSS derivations, not even unfree redistributable firmware This would likely break many installation scenarios, but would bring us to a consistent ethical standpoint, though it's not mine. -### Keeping the statu quo +### Keeping the status quo This results in very long builds for lots of software, as exhibited by the number of years people have been complaining about it. -### Implementing this RFC +### Having Hydra redistribute redistributable software, without verifying installation media -See above for the details +This would be slightly simpler to implement, but would not have the benefit of being 100% sure our installation media are free. -### Implementing this RFC, plus adding a check on Hydra to validate no unfree software enters the ISO image +### Having Hydra redistribute redistributable software, with a check for the installation media -This would likely be harder to implement. -It could be a job override, that would make hydra allow unfree redistributable software for all jobs except for the ISO image, which would only allow unfree redistributable firmware. - -The drawback of this alternative is that it would be more effort to implement, especially as manpower around Hydra is very scarce and limited. -However, it would solve the only previously listed drawback. +This is the current RFC. ### Building all software, including unfree non-redistributable software @@ -99,10 +124,11 @@ Recent exchanges have been happening in [this issue](https://github.com/NixOS/ni # Unresolved questions [unresolved]: #unresolved-questions -None. +Is the list of installation methods correct? +I took it from my personal history as well as the NixOS website, but there may be others. +Also, I may have the wrong job name, as I tried to guess the correct job name from the various links. # Future work [future]: #future-work -If this RFC lands as-is, future work could be around adding the check on hydra listed in the alternatives section. -This would validate that no unfree redistributable software enters the ISO image. +None. From 9dc23a7269877be12dc4febc34b2533602db0084 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Wed, 18 Dec 2024 20:35:24 +0100 Subject: [PATCH 05/11] add runnableOnHydra field for run restrictions --- rfcs/0185-redistribute-redistributable.md | 25 ++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index 90105f2..2d4b87d 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -27,11 +27,13 @@ Especially when the software is still source-available even without being free s # Detailed design [design]: #detailed-design -Hydra will build all packages with licenses for which `redistributable = true`. -It will still fail evaluation if the ISO image build or the Amazon AMIs were to contain unfree software. +We will add a `runnableOnHydra` field on all licenses, that will be initially set to its `free` field, and set to `true` only for well-known licenses. + +Hydra will build all packages with licenses for which `redistributable && runnableOnHydra`. +It will still fail evaluation if the ISO image build or the Amazon AMIs were to contain any unfree software. This will be done by evaluating Nixpkgs twice in `release.nix`. -Once with `allowUnfree = false` like today, plus once with `allowlistedLicenses = builtins.filter (l: l.redistributable) lib.licenses`. +Once with `allowUnfree = false` like today, plus once with `allowlistedLicenses = builtins.filter (l: l.redistributable && l.runnableOnHydra) lib.licenses`. Then, most of the jobs will be taken from the allowlisted nixpkgs, while only the builds destined for installation will be taken from the no-unfree nixpkgs. The list of jobs destined for installation, that cannot contain unfree software is: @@ -51,13 +53,13 @@ The list of jobs destined for installation, that cannot contain unfree software # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -With these changes, here is what would happen as things currently stand. -This is not meant to be indicative of what should happen or not, but indicative of what would happen. +With these changes, here is what could happen as things currently stand, if the licenses were all to be marked `runnableOnHydra`. +This is not meant to be indicative of what should happen or not, but indicative of what could happen. Each package's individual `license` field setup is left to its maintainers, and nixpkgs governance should conflict arise. This RFC does not mean to indicate that it is right or wrong, and is not the right place to discuss changes to this field. Should one have disagreements on any specific package in this list, please bring that up to that package's maintainers. -With this in mind, Hydra will start building, among others: +With this in mind, Hydra could start building, among others: - CUDA - DragonflyDB - MongoDB @@ -113,6 +115,14 @@ This is the current RFC. This is quite obviously illegal, and thus not an option. +### Not having the `runnableOnHydra` field on licenses + +This would make it impossible for Hydra to build them as things currently stand: +Hydra would then risk actually running these packages within builds for other derivations (eg. NixOS tests). + +This would thus only be compatible with changes to Hydra, that would allow to tag a package as not allowed to run, but only to redistribute. +Such a change to Hydra would most likely be pretty invasive, and is thus left as future work. + # Prior art [prior-art]: #prior-art @@ -131,4 +141,5 @@ Also, I may have the wrong job name, as I tried to guess the correct job name fr # Future work [future]: #future-work -None. +Modifying Hydra to allow building and redistributing packages that it is not legally allowed to run. +This would be a follow-up project that is definitely not covered by this RFC due to its complexity, and would require a new RFC before implementation. From 27241c34b9d36c2218c7be270491bc0ee2190ae0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Thu, 19 Dec 2024 12:40:53 +0100 Subject: [PATCH 06/11] list additional drawbacks --- rfcs/0185-redistribute-redistributable.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index 2d4b87d..69657bf 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -59,6 +59,12 @@ Each package's individual `license` field setup is left to its maintainers, and This RFC does not mean to indicate that it is right or wrong, and is not the right place to discuss changes to this field. Should one have disagreements on any specific package in this list, please bring that up to that package's maintainers. +It is also suggested in this RFC that people, upon marking licenses as `runnableOnHydra`, check all the derivations that use this license. +They could then have to mark them as either `hydraPlatforms = []`, `preferLocalBuild = true` and/or `allowSubstitutes = false`. +This might be useful for packages like TPTP: +they may not yet be marked as such due to these flags having no impact on unfree packages; +but would take gigabytes on Hydra for basically no local build time improvement + With this in mind, Hydra could start building, among others: - CUDA - DragonflyDB @@ -138,6 +144,9 @@ Is the list of installation methods correct? I took it from my personal history as well as the NixOS website, but there may be others. Also, I may have the wrong job name, as I tried to guess the correct job name from the various links. +How large are the packages Hydra would need to additionally store? +This could be another drawback, if it is large enough to not be negligible compared to free software only. + # Future work [future]: #future-work From ecf93739de22b327be893c660735992d6db745cb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Tue, 31 Dec 2024 13:14:47 +0100 Subject: [PATCH 07/11] handle review comments and add size information --- rfcs/0185-redistribute-redistributable.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index 69657bf..090a205 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -132,7 +132,7 @@ Such a change to Hydra would most likely be pretty invasive, and is thus left as # Prior art [prior-art]: #prior-art -According to [this discussion](https://github.com/NixOS/nixpkgs/issues/83433), the current statu quo dates back to the 20.03 release meeting. +According to [this discussion](https://github.com/NixOS/nixpkgs/issues/83433), the current status quo dates back to the 20.03 release meeting. More than four years have passed, and it is likely worth rekindling this discussion, especially now that we actually have a Steering Committee. Recent exchanges have been happening in [this issue](https://github.com/NixOS/nixpkgs/issues/83884). @@ -144,8 +144,14 @@ Is the list of installation methods correct? I took it from my personal history as well as the NixOS website, but there may be others. Also, I may have the wrong job name, as I tried to guess the correct job name from the various links. -How large are the packages Hydra would need to additionally store? -This could be another drawback, if it is large enough to not be negligible compared to free software only. +### How large are the packages Hydra would need to additionally store? + +`nix-community`'s Hydra instance can give us approximations. +Its `unfree-redist-full` channel is currently 215G large, including around 200G of NVidia kernel packages and 15G for all the rest of unfree redistributable software. +Its `cuda` channel is currently 482G large. + +It might make sense not to build the cuda/nvidia builds on Hydra for now, at least not before culling a bit the packages, considering there are eg. more than a hundred different NVidia kernel packages. +Hence, this RFC suggests not setting `runnableOnHydra` for the relevant derivations before cleaning up a bit the NVidia ecosystem in nixpkgs. # Future work [future]: #future-work From bede48d092ca09f99a64b17de86126e2f47c226f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Fri, 21 Mar 2025 19:46:20 +0100 Subject: [PATCH 08/11] commit resolved questions and future work --- rfcs/0185-redistribute-redistributable.md | 40 +++++++++++++++++------ 1 file changed, 30 insertions(+), 10 deletions(-) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index 090a205..a3efaa0 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -137,12 +137,7 @@ More than four years have passed, and it is likely worth rekindling this discuss Recent exchanges have been happening in [this issue](https://github.com/NixOS/nixpkgs/issues/83884). -# Unresolved questions -[unresolved]: #unresolved-questions - -Is the list of installation methods correct? -I took it from my personal history as well as the NixOS website, but there may be others. -Also, I may have the wrong job name, as I tried to guess the correct job name from the various links. +# Resolved questions ### How large are the packages Hydra would need to additionally store? @@ -150,11 +145,36 @@ Also, I may have the wrong job name, as I tried to guess the correct job name fr Its `unfree-redist-full` channel is currently 215G large, including around 200G of NVidia kernel packages and 15G for all the rest of unfree redistributable software. Its `cuda` channel is currently 482G large. -It might make sense not to build the cuda/nvidia builds on Hydra for now, at least not before culling a bit the packages, considering there are eg. more than a hundred different NVidia kernel packages. -Hence, this RFC suggests not setting `runnableOnHydra` for the relevant derivations before cleaning up a bit the NVidia ecosystem in nixpkgs. +Currently, NixOS' hydra pushes around 2TB per month to S3, with rebuilds taken into account. +Noteworthy is the fact that these 2TB are of compressed data. +Hence, the expected increase would not be 700G per rebuild, but something lower than this, which is hard to pre-compute. + +Regardless, Hydra should be able to deal pretty well even with a one-time 700G data dump. +The issues would come only if compression were not good, in addition to rebuilds being frequent enough to significantly increase the amount of data Hydra pushes to S3. + +# Unresolved questions +[unresolved]: #unresolved-questions + +Is the list of installation methods correct? +I took it from my personal history as well as the NixOS website, but there may be others. +Also, I may have the wrong job name, as I tried to guess the correct job name from the various links. # Future work [future]: #future-work -Modifying Hydra to allow building and redistributing packages that it is not legally allowed to run. -This would be a follow-up project that is definitely not covered by this RFC due to its complexity, and would require a new RFC before implementation. +- **Actually tagging licenses and packages as `runnableOnHydra`.** + Without this, this RFC would have no impact. + This will be done package-by-package, and should require no RFC, unless there are significant disagreements on whether a license should be runnable on hydra or not. + +- **Monitoring Hydra to confirm it does not push too much data to S3.** + If this change causes Hydra to push an economically non-viable amount of data to S3, then we should revert the addition of `runnableOnHydra` to the relevant packages and reconsider. + +- **Culling NVidia kernels and CUDA derivations.** + We suggest not caring too much about S3 size increases in the first step, considering the numbers from the resolved questions section. + However, if compression is less efficient than could be expected, we could be required to cull old NVidia kernels and/or CUDA derivations. + This would reduce the availability of older or more niche configurations, in exchange with reducing Hydra closure size. + Or we could move them to a set in which Hydra does not recurse. + For now, this is left as future work, that should be handled close to tagging the relevant derivations as `runnableOnHydra`. + +- **Modifying Hydra to allow building and redistributing packages that it is not legally allowed to run.** + This would be a follow-up project that is definitely not covered by this RFC due to its complexity, and would require a new RFC before implementation. From 497f40c51698dcc0f4ab5d005b1ea51f7c7b576e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Fri, 21 Mar 2025 19:51:04 +0100 Subject: [PATCH 09/11] explicitly exclude proprietary packages from zhf --- rfcs/0185-redistribute-redistributable.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index a3efaa0..3e38ac6 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -50,6 +50,10 @@ The list of jobs destined for installation, that cannot contain unfree software - `sd_image_new_kernel` - `sd_image_new_kernel_no_zfs` +This RFC offers absolutely no more guarantees than the current statu quo, as to whether proprietary packages will or not build on hydra. +In particular, proprietary packages will not necessarily be part of the Zero Hydra Failures project upon release, +though release managers could, at their own discretion, decide to include some specific proprietary packages in there. + # Examples and Interactions [examples-and-interactions]: #examples-and-interactions From 1c2b2e8fe4534b66b691a3c27499aa37275226ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Fri, 21 Mar 2025 20:16:56 +0100 Subject: [PATCH 10/11] emilazy's review comments --- rfcs/0185-redistribute-redistributable.md | 41 +++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index 3e38ac6..4df8bee 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -93,6 +93,8 @@ And Hydra will keep not building, among others: # Drawbacks [drawbacks]: #drawbacks +## Technical drawbacks + The main risk is that NixOS could end up including unfree software in an installation image if: 1. we forgot to add it to the list of no-allowed-unfree jobs, and 2. a maintainer did actually add unfree software to that build. @@ -102,6 +104,29 @@ This seems exceedingly unlikely, making this change basically risk-free. The only remaining drawback is that Hydra would have to evaluate Nixpkgs twice, thus adding to eval times. However, the second eval (with no-unfree) should be reasonably small and not actually evaluate all packages, as it is only used for installation media. +## Political drawbacks + +Whether distributing unfree software is a political drawback is left to each reader's opinion. + +Besides that, there are three main political risks. +First is, this RFC could end up completely unused. +Maybe, with proper license investigation, we will notice that none of the packages listed above can actually be redistributed by Hydra. + +The second risk is one of manpower. +We may need the Foundation's input on whether a specific license is ok to redistribute or not. +This could require some manpower from the Foundation's side. + +Finally, the third risk is one of propagation. +With both hydra and some nixos maintainers running with `allowUnfree`, there is a risk that free packages start unnecessarily depending on unfree packages. +This would then break the setup of the people not actually running with `allowUnfree`. + +This being said, all these risks are probably less impactful than the current statu quo. +Indeed, we currently have packages for Mac that are not marked with any license, because they would otherwise have to be marked unfree, +yet we do want to build and test them. +This means that we are already lying on licenses in order to get them through Hydra. +And, in particular, this means they could actually reach the machine of users without `allowUnfree`. +This situation is entirely due to the absence of this RFC, and could only be improved by it. + # Alternatives [alternatives]: #alternatives @@ -163,6 +188,15 @@ Is the list of installation methods correct? I took it from my personal history as well as the NixOS website, but there may be others. Also, I may have the wrong job name, as I tried to guess the correct job name from the various links. +Do we need a specific `redistributableWhenPatched` field on the license? +It feels like this would be a bit too much, and probably `redistributable` would be enough. +However, we may need to have it still. + +Will we need to redistribute some derivations with `runnableOnHydra = false`? +For example, some firmware might not be legal to run on hydra. +However, Hydra will never actually try to run it, as it cannot be used at runtime to build other packages. +Maybe even `runnableOnHydra` could be better named to encompass this case too? + # Future work [future]: #future-work @@ -182,3 +216,10 @@ Also, I may have the wrong job name, as I tried to guess the correct job name fr - **Modifying Hydra to allow building and redistributing packages that it is not legally allowed to run.** This would be a follow-up project that is definitely not covered by this RFC due to its complexity, and would require a new RFC before implementation. + +- **Validating licenses and dependencies.** + We may be interested in figuring out the aggregate license of one derivation. + This could be automatically computed by evaluating the Nix scripts. + In particular, we could have a specific `enforceFree` meta argument that'd enforce that this derivation as well as all dependencies are transitively free. + Implementing this may be doable in pure nix, or could require an additional hydra check. + This is left as future work, because even without validating licenses this RFC probably reduces the risk for FOSS users from installing proprietary software. From 03bcdc0a310a72b089029098f6ae8c342acade97 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Gaspard?= Date: Sun, 25 May 2025 18:26:46 +0200 Subject: [PATCH 11/11] Update rfcs/0185-redistribute-redistributable.md Co-authored-by: Silvan Mosberger --- rfcs/0185-redistribute-redistributable.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0185-redistribute-redistributable.md b/rfcs/0185-redistribute-redistributable.md index 4df8bee..44e7051 100644 --- a/rfcs/0185-redistribute-redistributable.md +++ b/rfcs/0185-redistribute-redistributable.md @@ -3,8 +3,8 @@ feature: redistribute-redistributable start-date: 2024-12-15 author: Ekleog co-authors: (find a buddy later to help out with the RFC) -shepherd-team: (names, to be nominated and accepted by RFC steering committee) -shepherd-leader: (name to be appointed by RFC steering committee) +shepherd-team: @Mic92, @roberth, @Lassulus +shepherd-leader: @Mic92 related-issues: https://github.com/NixOS/nixpkgs/issues/83884 ---