[PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

This patch allows copying of out-of-tree kernel modules to the Linux

initrd.

For out-of-tree modules to found, an extra slot has been added to

‘operating-system’: ‘initrd-extra-module-paths’, which contains a list

containing items of either FILE-LIKE or (FILE-LIKE OUTPUT) which will be

searched for modules in addition to the standard Linux module path. The

required modules can then be added to ‘initrd-modules’ as normal and all paths

will be searched for it, including for any modules depended on.

DIRECTORIES. Now takes a list of directories to search, rather than a single

one.

field and accessor. Takes a list of file-like objects.

argument to PACKAGES. Now contains a list of file-likes to search for modules.

(raw-initrd): Add LINUX-EXTRA-MODULE-PATHS keyword argument. Pass it

to (flat-linux-extra-module-paths) along with the selected LINUX package.

(base-initrd): Add LINUX-EXTRA-MODULE-PATHS keyword argument. Pass it

to (raw-initrd).

---

gnu/build/linux-modules.scm | 19 ++++++++------

gnu/system.scm | 5 ++++

gnu/system/linux-initrd.scm | 52 +++++++++++++++++++++++++------------

3 files changed, 51 insertions(+), 25 deletions(-)

Brian Cully via Guix-patches via schreef op ma 02-05-2022 om 15:11 [-

0400]:

This needs some information in the manual -- when does the field need

to be set? For what kernel modules? Is this required by v4l2loopback-

linux-module and librem-ec-acpi-linux-module? Things like that.

As-is, this functionality is hard to discover.

Greetings,

Maxime.

Maxime Devos <maximedevos@telenet.be> writes:

I knew I missed something. How’s this look?

---

doc/guix.texi | 42 ++++++++++++++++++++++++++++++++++--------

1 file changed, 34 insertions(+), 8 deletions(-)

I've read through the original patch and the doc patch, and based on my own tinkering with guix initrd generation, the patches look good to me. I'm also happy to see the functionality being added, and already have plans for using it with zfs (to further the goal of an encrypted multi-disk zfs root).

Cheers,

Kaelyn

(for whatever reason, looks like this didn't end up in my inbox)

As-is, I don't think this is a good example, because

'expression->initrd' does not set #:substitutable? #false,

the 'zfs' package has the comment (*)

`(;; The ZFS kernel module should not be downloaded since the

license

;; terms don't allow for distributing it, only building it

locally.

#:substitutable? #f [...])

and IIUC, the code inside expression->initrd copies the kernel module

into

the new store item, so it looks like this accidentally suggest people

to

commit copyvios, and copyvios are currently against the law.

Greetings,

Maxime.

(*) Though I don't understand that comment: Guix is a distribution, so

by definition

it's distributing zfs -- unless it's only talking about the binaries

and not the

source code ...

This patch allows copying of out-of-tree kernel modules to the Linux

initrd.

For out-of-tree modules to found, an extra slot has been added to

‘operating-system’: ‘initrd-extra-module-paths’, which contains a list

containing items of either FILE-LIKE or (FILE-LIKE OUTPUT) which will be

searched for modules in addition to the standard Linux module path. The

required modules can then be added to ‘initrd-modules’ as normal and all paths

will be searched for it, including for any modules depended on.

DIRECTORIES. Now takes a list of directories to search, rather than a single

one.

field and accessor. Takes a list of file-like objects.

argument to PACKAGES. Now contains a list of file-likes to search for modules.

(raw-initrd): Add LINUX-EXTRA-MODULE-PATHS keyword argument. Pass it

to (flat-linux-extra-module-paths) along with the selected LINUX package.

(base-initrd): Add LINUX-EXTRA-MODULE-PATHS keyword argument. Pass it

to (raw-initrd).

---

This version includes both the previous patch and the documentation.

doc/guix.texi | 42 ++++++++++++++++++++++++------

gnu/build/linux-modules.scm | 19 ++++++++------

gnu/system.scm | 5 ++++

gnu/system/linux-initrd.scm | 52 +++++++++++++++++++++++++------------

4 files changed, 85 insertions(+), 33 deletions(-)

As the earlier patch discussion seemed to have focused on ZFS licensing issues that are largely orothogonal to the functionality being added, I'd like to again voice my support for the proposed patch. While ZFS is indeed a bad example due to open questions about module licensing and redistribution, it isn't the only out-of-tree module currently packaged in Guix which could be used with the extra initrd support (not counting future packages or external channels). Within the guix repo, the packages using the `linux-module-build-system` aside from zfs are:

- acpi-call-linux-module

- bbswitch-module

- ddcci-driver-linux

- rtl8812au-aircrack-ng-linux-module

- rtl8821ce-linux-module

- ttyebus-linux-module

- v4l2loopback-linux-module

- vhba-module

- wiregard-linux-compat

Of those nine, at least four look to be for specific hardware, and I can come up with theoretical use cases for why someone might want those or wiregard-linux-compat (though the cases are definitely contrived straw-men that may or may not be implementable in practice or actually useful in an initrd context, such as network booting with an older kernel and the root filesystem can only be accessed over a wireguard connection).

Cheers,

Kaelyn

Hello Brian,

Brian Cully <bjc@spork.org> skribis:

Nice, it looks like a welcome addition.

I wonder if we could reuse the ‘kernel-loadable-modules’ field for this

purpose instead of introducing a new field. We’d need to pass it to the

initrd procedures and have them search in there in addition to the

kernel package, pretty much like this patch already does actually.

WDYT?

Nitpick: the GNU convention is to use “path” to denote “search paths”,

and other “file”, “file name”, or similar. In this case, that’d be

“kernel module” or “Linux module”.

Thank you!

Ludo’.

Ludovic Courtès <ludo@gnu.org> writes:

This sounds like it could be made to work as you suggest. My

feeling is that the two contexts are slightly different, though,

as the Linux modules are a superset of the initrd modules, so I’d

prefer not to mix them as it might be confusing to people who are

used to other Linux distros where the initrd modules are called

out separately. I admit I’m probably being silly here, and don’t

have any serious objection in principle.

I struggled with this a fair amount, actually. What these

file-likes actually represent is an element of a search path, even

if they come in the odd form of a file-like object, which is why I

used ‘path’. ‘file’ seems wrong, as it implies (to me) that it’s

the ‘initrd-extra-module-files’ option itself that would include

the module, rather than the ‘initrd-modules’ option.

Of course, all this goes away if we just reuse

‘kernel-loadable-modules’ as an additional input, rather than

adding another option, so that’s a distinct mark in favor of doing

that.

When I get some time (hopefully soon!) I’ll try to thread

‘kernel-loadable-modules’ through instead and see how far I can

get with that approach. Do you think the documentation for it will

need to be updated to specify that it’s also used as a search path

for initrd building? Or maybe the better option is to update the

documentation for ‘initrd-modules’ to say that it uses

‘kernel-loadable-modules’ as input?

-bjc

Hi,

My $0.02 on 'initrd-extra-module-paths' vs 'kernel-loadable-modules': if the initrd code is smart enough to not include the entire packages and only includes the requested modules from the packages (which I think is already true based on behavior observed some time ago), then not having to duplicate the list would be preferable.

I found this issue in the tracker after being surprised that the initrd builder ignored 'kernel-loadable-modules' with 'initrd-modules' only working for modules that are included in the primary linux kernel package. That surprise over the incompatibility between 'initrd-modules' and 'kernel-loadable-modules' is also why I've been relatively vocal about the patch. ;)

Cheers,

Kaelyn

Hi,

Brian Cully <bjc@spork.org> skribis:

Right. Here, we want the initrd machinery to search for modules in any

place where they can be found, which is either ‘kernel’ or

‘kernel-loadable-modules’.

One could define ‘initrd-extra-module-paths’ to be different from

‘kernel-loadable-modules’, for example if you can be sure the module

will be loaded from the initrd and not after, but in general both are

likely to have the same value, no?

Hmm right, you have a point! :-)

I think you should update the documentation in the commit that changes

things, so that the patch is self-contained.

It may be enough to state in the documentation of the ‘initrd-modules’

field that its value is a list of module names that are searched for in

‘kernel’ and ‘kernel-loadable-modules’.

WDYT?

Thanks,

Ludo’.

With this patch, modules for ‘initrd-modules’ will not only be searched for in

the in-tree Linux modules, but also any additional modules specified in

‘kernel-loadable-modules’.

DIRECTORIES. Now takes a list of directories to search, rather than a single

one.

argument to PACKAGES. Now contains a list of file-likes to search for modules.

(raw-initrd): Add LINUX-EXTRA-MODULE-PATHS keyword argument. Pass it

to (flat-linux-extra-module-paths) along with the selected LINUX package.

(base-initrd): Add LINUX-EXTRA-MODULE-PATHS keyword argument. Pass it

to (raw-initrd).

definition's kernel-loadable-modules into (make-initrd) as

LINUX-EXTRA-MODULE-PATHS.

---

I've removed the new operating-system slot in preference to re-using

kernel-loadable-modules, as discussed.

I did leave the old argument names for the lower level routines in place,

as I feel that they more accurately represent how the data are being

used.

I've also pulled out the documentation. Once this patch set is beaten

into acceptability, the documentation can be adjusted if that's deemed

necessary.

gnu/build/linux-modules.scm | 19 ++++++++------

gnu/system.scm | 2 ++

gnu/system/linux-initrd.scm | 52 +++++++++++++++++++++++++------------

3 files changed, 48 insertions(+), 25 deletions(-)

Hi Brian,

Brian Cully <bjc@spork.org> skribis:

Alright!

It looks great to me. I have two cosmetic comments:

I think you can remove this definition and use ‘gexp-input’ directly.

Nitpick: I’d call it #:linux-extra-module-path (singular, as in “search

path”) or simply #:linux-extra-module-directories.

If you could introduce a couple of lines in doc/guix.texi to explain

where modules are searched for, that’d be perfect.

Thanks for taking the time to prepare this revision!

Ludo’.

With this patch, modules for ‘initrd-modules’ will not only be searched for in

the in-tree Linux modules, but also any additional modules specified in

‘kernel-loadable-modules’.

DIRECTORIES. Now takes a list of directories to search, rather than a single

one.

argument to PACKAGES. Now contains a list of file-likes to search for modules.

(raw-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (flat-linux-module-directory) along with the selected LINUX package.

(base-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (raw-initrd).

definition's kernel-loadable-modules into (make-initrd) as

LINUX-EXTRA-MODULE-DIRECTORIES.

---

This version removes the redundant (package+out->input) procedure, and

renames ‘linux-extra-module-paths’ to ‘linux-extra-module-directories’.

gnu/build/linux-modules.scm | 19 ++++++++------

gnu/system.scm | 2 ++

gnu/system/linux-initrd.scm | 49 ++++++++++++++++++++++++-------------

3 files changed, 45 insertions(+), 25 deletions(-)

---

doc/guix.texi | 13 +++++++++++++

1 file changed, 13 insertions(+)

Brian Cully via Guix-patches via schreef op za 18-06-2022 om 15:11 [-

0400]:

As written previously, this is not a good example, because:

and because the defense for not considering the ZFS license to be a

problem consists of the ZFS module not being distributed in binary

form, whereas this suggestion would in some situations cause it to be

distributed in binary form.

Greetings,

Maxime.

If you have another example, I'll put it in instead. I used this

one, because I know this one works, and that's all.

That said, I'm not sure how this would cause the module to be

distributed as a binary. In order for it to be added to the

initrd, it will still need to built using the DKMS mechanism, and

thus compiled on (or at least for) the target Guix installation.

If the complaint is that one could generate a USB stick, or some

such, with ZFS in the initrd, then yes, that's possible. But

that's also possible by using the existing

‘kernel-loadable-modules’ mechanism to generate an image with

‘guix system image’ and distributing that. I don't think it's our

job to try and prevent such things, since, even if desirable, it's

not really feasible.

If the complaint is merely that it's in the documentation, then

ok, I'll change it to whatever module you want.

-bjc

Brian Cully schreef op za 18-06-2022 om 16:43 [-0400]:

Because #:substitutable? isn't set appropriately in dependents,

substitute servers exist, ZFS can be used on substitute servers and

someone using the substitute server might have a sufficiently similar

system configuration to do substitution of a store item containing a

copy of the ZFS binary.

Greetings,

Maxime.

Maxime Devos <maximedevos@telenet.be> writes:

So, simply using ZFS in ‘kernel-loadable-modules’ would be enough

to trigger this misbehavior? That sounds like a pretty serious

issue. Would it be possible to have the substitute servers filter

on the #:substitutable flag?

This is getting out of scope, though. I don't really want this

patch to go in without /some/ documentation regarding how modules

get looked up, so if anyone has an alternate module and use-case,

I'll just swap it in for the ZFS one.

-bjc

Brian Cully schreef op za 18-06-2022 om 19:11 [-0400]:

That's exactly what the #:substitutable flag is for (IIUC)!

However, the problem is that currently, that flag isn't set for

derivations that make a copy of the ZFS module. As I wrote previously:

I don't have any.

Greetings,

Maxime.

Hi again,

Regarding the documentation example, one (contrived) alternative is:

"""

For example, if you need the driver for a Realtek RTL8821CE wireless network adapter for mounting the root filesystem over NFS, your configuration might include the following:

@lisp

(operating-system

;; @dots{}

(initrd-modules (cons "8821ce" %base-initrd-modules))

(kernel-loadable-modules (list (list rtl8821ce-linux-module "module"))))

@end lisp

"""

While I don't have the hardware, I did verify the kernel module name by building the rtl8821ce-linux-module package.

Cheers,

Kaelyn

With this patch, modules for ‘initrd-modules’ will not only be searched for in

the in-tree Linux modules, but also any additional modules specified in

‘kernel-loadable-modules’.

DIRECTORIES. Now takes a list of directories to search, rather than a single

one.

argument to PACKAGES. Now contains a list of file-likes to search for modules.

(raw-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (flat-linux-module-directory) along with the selected LINUX package.

(base-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (raw-initrd).

definition's kernel-loadable-modules into (make-initrd) as

LINUX-EXTRA-MODULE-DIRECTORIES.

---

gnu/build/linux-modules.scm | 19 ++++++++------

gnu/system.scm | 2 ++

gnu/system/linux-initrd.scm | 49 ++++++++++++++++++++++++-------------

3 files changed, 45 insertions(+), 25 deletions(-)

---

doc/guix.texi | 15 +++++++++++++++

1 file changed, 15 insertions(+)

Hi,

I just want to say that the latest v4 of the patches look good to me, and has removed the example with the questionable licensing situation. I have also been using this patch quite successfully, in a slightly modified version (mostly module name changes) imported into a local channel, for almost 2 years now.

Also, if needed, I would be happy to rebase the patches against the current master.

Cheers,

Kaelyn

With this patch, modules for ‘initrd-modules’ will not only be searched for in

the in-tree Linux modules, but also any additional modules specified in

‘kernel-loadable-modules’.

DIRECTORIES. Now takes a list of directories to search, rather than a single

one.

argument to PACKAGES. Now contains a list of file-likes to search for modules.

(raw-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (flat-linux-module-directory) along with the selected LINUX package.

(base-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (raw-initrd).

definition's kernel-loadable-modules into (make-initrd) as

LINUX-EXTRA-MODULE-DIRECTORIES.

---

gnu/build/linux-modules.scm | 19 ++++++++------

gnu/system.scm | 2 ++

gnu/system/linux-initrd.scm | 50 ++++++++++++++++++++++++-------------

3 files changed, 45 insertions(+), 26 deletions(-)

---

doc/guix.texi | 15 +++++++++++++++

1 file changed, 15 insertions(+)

I've made a (hopefully acceptable) attempt to rebase the patches on the newest master of the Guix repo. If there's anything preventing these patches from being merged, please let me know.

Best,

Morgan

Hi Morgan,

Morgan Arnold via "Development of GNU Guix and the GNU System

distribution." <guix-devel@gnu.org> writes:

It does seem that #55231 ended up in a place where there was

concensus that it was acceptable, but didn’t get merged for some

reason or other. I definitely could be wrong, but I suspect the

issue is that when non-#:substitutable? packages are used in

places other than package inputs, the downstream derivations don’t

carry that information. I believe when used as a package input,

non-#:substitutable? packages do, in fact, poison all downstream

derivations. Happy to be corrected if I’m wrong here.

I think it’s reasonable to merge this after it’s rebased on

current master, and would be willing to do that unless Maxime or

Ludo’ raise an objection.

However, you resent a v1 patch to a bug where four versions has

already been sent. If you’d be willing to resend as v5 (with `git

format-patch -v5 -2'), I can get it pushed.

Thanks,

-- Ian

On 9/02/2025 2:06, Ian Eure wrote:

No. See the stuff about #:substitutable?. The reason I didn't answer

back then, is that I don't want to keep being a broken record.

If 'make-linux-libre' in the presence of ZFS leads to #:subsitutable?

problems, that doesn't mean it's fine to ignore the law for #52231. It

means you need to:

 (a) remove ZFS

 (b) or adjust 'make-linux-libre' (whether code or documentation,

preferably code) to do the #:substitutable? thing

More generally, legality > convenience (except in case of revolution,

but that's not applicable to Guix, and it seems inadvisable to talk

about such matters in the open).

More specifically, ZFS proponents (at least as a group, and when limited

to those visible in Guix) tend to be rather incoherent in their

positions, in the sense that simultaneously do:

 (1) consider GPL and ZFS license to be compatible,

 (2) with caveat about "no binary distributions"  (legal restriction)

 (3) want to get ZFS in a distribution

 (4) their method to get ZFS in the distribution doesn't address point (2)

 (5) and they refuse to fix the legal issue (4) when pointed out to

them, with as reason:

 (5a) previous versions of Guix already violate restriction (2)

 (5b) it's technically slightly inconvenient

Like, (5a) just makes things _worse_ (as now would be _knowingly_  in

violation of the law, and the duration of the violation increases) and

(5b) is utterly irrelevant to the law - Guix is subject to the law, not

the other way around.

And pointing this out to them doesn't seem to ever work.

It has been some time ago, but I probably suspected it wouldn't work in

this case either.

Not quite - to my understanding, the downstream derivations _also_ don't

carry that information when it's in package inputs (at least, last time

I checked there didn't seem to be any mechanism to set #:substitutable?

to #false when any of the inputs are unsubstitutable (whether non-bag(?)

derivation inputs, implicit inputs, native-inputs, ...)).

For packages, in typical situations the #:substitutable? #false of any

'native-inputs' of a package shouldn't impact the substitutability of

the package. For 'inputs', it rather depends (e.g. static/dynamic, the

particulars of the license, is it because of license reasons or

something else). Since it somewhat depends on the situation, if you

implement a thing like this, I would recommend making it a _default_ for

#:substitutable?(*), that can be overridden by some method.

First you say you suspect the issue is that #:substitutable?-related

behaviour isn't right yet, and immediately in the next paragraph you say

it's reasonable to merge it. Given that the patches haven't been

adjusted to solve this, this is rather incongruent.

I already raised the objection several times in the past (including

_before_ #55231), and none of the patch revisions attempted to deal with

the objection.  Issues don't simply magically resolve themselves. I

believe you can infer whether I would object to the current state of

#55231 or not.

Regards,

Maxime Devos

Hi,

On Sunday, February 9th, 2025 at 9:11 AM, Maxime Devos <maximedevos@telenet.be> wrote:

While I do not wish to chime in on either side at this time as I am most definitely not a lawyer, I want to share a few references and the result of a bit of recent research. As far as I can tell (as a layman), the legality of distributing a binary ZFS module is currently a matter of differing opinions, and a bit of searching has not revealed case precedent for deciding the matter. The closest to that which I found was a lawsuit against VMware in Germany over vmklinux within vSpere, which was dismissed on procedural grounds and for which VMware voluntarily announced the removal of vmklinux (https://sfconservancy.org/news/2019/apr/02/vmware-no-appeal/).

Regarding distributing ZFS, Ubuntu and their legal team concluded about 9 years ago that they can distribute ZFS kernel modules and still comply with both licenses. I also did not find mention of Ubuntu reversing their decision, or of legal issues around ZFS that have arisen for them in that time period. Again, I want to emphasize that IANAL and that there is not a clear decision on the legality of such distribution.

Here are a few useful links I found, both for and against ZFS binary distribution:

* https://blog.dustinkirkland.com/2016/02/zfs-licensing-and-linux.html

* https://blog.hansenpartnership.com/are-gplv2-and-cddl-incompatible/

* https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

* https://softwarefreedom.org/resources/2016/linux-kernel-cddl.html

Not to be offensive, but I find these statements to be very dismissive of those who disagree with you about ZFS distribution as well as both their reasoning for their position and their openness to differing viewpoints or new information.

As an aside, I can and do accept that the Guix maintainers hold the view that distributing binary ZFS modules is a license violation, and that they have rejected the patches in issue #55231 on the basis it could inadvertently allow for official substitutes to be made available containing a binary zfs.ko or spl.ko. I have worked around the absence in a satisfactory way for my needs by overriding much of the initrd generation within my local channel to effectively integrate #55231 there. However, responses like the one above (as well as some of the general sentiments raised in this email thread) have largely discouraged me from contributing to Guix aside from the occasional package bump or bug fix. Basically, I no longer have any opinion on the fate of the patches in #55231 or on how Guix wishes to deal with ZFS (and despite no discouraging responses on the issue, there's a good chance I won't find the motivation again to follow up on the single reply to https://issues.guix.gnu.org/71482,given the community attitudes I've observed regarding matters touching on ZFS).

Regards,

Kaelyn

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

Could you help me understand the case where this becomes a

problem? Is it:

- If you have one machine with an operating-system which includes

a non-#:substitutable? out-of-tree kernel module in its initrd,

and

- A second machine with an identical initrd configuration, and

- The first machine is configured to serve substitutes, and

- The second machine uses the first as a substitute server

Then the non-#:substitutable? module would be distributed,

violating its license?

I’d also find it helpful to understand the line for specific acts

and entities in play, on a matrix of: allowing violations,

encouraging violations, or committing violations; and by

individual Guix users, or by the Guix project itself. For

example, I think the Guix project encouraging or committing a

violation is unacceptable.

I think this would help a great deal to make the bounds of the

problem clear, which is needed to solve them.

Could you please help me understand how `make-linux-libre' is in

scope? I don’t believe any in-tree kernel modules have the

problematic license terms, so I think the issue is purely

out-of-tree stuff, whether that’s ZFS, nVidia drivers, "endpoint

protection" security systems, etc. Perhaps you meant

`make-initrd'?

I appreciate your perspective, however, I’m more interested in

understanding the problems so they can be solved. Any help in

that area would be greatly appreciated.

Ah, hmm. So these kind of violations are implictly prevented by

Guix not shipping things in combinations which would violate the

license terms?

That’s a good suggestion, thank you.

While I agree that the fundamental #:substitutable? mechanism of

Guix could use improvement, I don’t believe these patches need to

wait for that work, becasue:

- This is a generic mechanism useful for any out-of-tree module

regardless of license[1].

- They won’t cause the Guix project to commit a license violation.

- They don’t encourage individuals to commit license violations.

- While they could /allow/ individuals to commit violations, many

things in Guix already do, because it’s infeasible to forbid.

To the last point:

- Right now, Guix allows a user to make a system image containing

compiled ZFS modules and distribute it.

- Guix ships DVD rippers and programs which can copy files, which

a user can commit copyright violations with.

- Guix ships numerous programs for file sharing, whose /primary/

purpose is committing copyright violations. The nicotine+

package is one example[1].

I am struggling to square objections to a patch whose intent and

primary use would be within the bounds of

non-binary-redistribution licenses, but which might enable an

individual to (most likely inadvertently) commit a license

violation with the significantly riskier things which are already

permitted. If I’m misunderstanding the situation here, I’d

appreciate further insight.

Some examples of other modules that could be used with this

facility are:

lttng, a GPL’d out-of-tree kernel tracing system

ddcci, a GPL’d out-of-tree module for controlling monitor settings

OpenRazer, a GPL’d out-of-tree module to suppot Razer HID hardware

I’m certain there are other cases where it’d be useful.

I haven’t been involved in this stuff in the past and don’t use

ZFS on Guix[2]. The issue I read, which this patch is for, it

appeared that your last objection was that the documentation gave

ZFS as an example, which is the Guix project obliquely encouraging

users to commit inadvertent violations. This problem was

addressed, therefore I believed your objections were resolved. I

apologize for midunderstanding the situation.

Thanks,

-- Ian

[1]: I distinguish between things with both legitimate and

illegitimate purposes (such as BitTorrent clients), and those

whose main purpose is clearly copyright violation.

[2]: I do use ZFS on Debian, where this issue is moot.

This isn't the place for that. If you believe there are some new and

correct arguments for/against compatibility, that's something for a

separate thread. Some of these are old news.

This is a mischaracterisation - both of what I said in the mail you are

responding to, and the reality of what happened in the ZFS discussions.

It is indeed dismissive, but the dismissiveness is not 'because I

disagree with them', it's because of:

 * their slander(*) (see: Mason Loring Bliss) (also, to a much lesser

extent, right now you - I don't think this quoting out

context+misinterpretation _technically_ counts as slander, but it's

something bad nonetheless)

 * their rudeness (see: raid5atemyhomework) (also Mason Loring Bliss,

since slander is rude)

 * their hypocrisy as a group (see: they claim it can be fine because

of non-binary distribution, but they never change Guix to _make_ the ZFS

stuff non-binary)

 * repeating _old_ information as an argument/counter-argument, even

though it has already been made and replied to, without providing more

explanation or another interpretation (see: Mason Loring Bliss. Maybe

others, but in particular I recall Mason Loring Bliss doing this).

(*) In ordinary sense, without distinguishing between exact forms of

defamation, and not evaluating whether illegal or legal.

Sometimes, being dismissive, is a perfectly reasonable response. As long

as it's for the right reasons, well-founded, and with evidence.

Also, the 'dismissiveness to [others with different viewpoint]' is the

other way around (see: previous points).

Regards,

Maxime Devos

Hi all,

I haven't had time to read all of this and go through the legal considerations that Kaelyn linked (thanks!), but just wanted to clarify that I was the one who brought up `make-linux-libre`, probably erroneously. I think that I misunderstood `make-linux-libre` as being capable of including out-of-tree kernel modules in the kernel, so I proposed that it was subject to the same licensing concerns. This, however, seems to have been a misunderstanding of `make-linux-libre` on my part. Anyway, Maxime reasonably points out that this is effectively irrelevant to whether or not the changes proposed here ought to be included in Guix.

I agree that it would be helpful to clarify the matrix mentioned here, and that Guix encouraging or committing a violation is unacceptable. I further agree that Guix allowing violations is inevitable, and I fail to see how the proposed changes either encourage a violation (modulo the changes made to the documentation) or commit a violation. I am very much not a lawyer, so I may be missing the violation entirely, and am trying to get up to speed on some of the legal concerns.

Best,

Morgan

On Sunday, February 9th, 2025 at 20:37, Ian Eure <ian@retrospec.tv> wrote:

Hi Maxime and everyone,

(As a I hope neutral bystander that knows nothing about nor has any

particular opinions about the ZFS topic but felt it necessary for

general "good Guix community" to chime in.)

I understand tone and all of that is difficult in these communications,

and we all have differing language familiarity/interpretations. And we

can all have strong opinions. I give everyone the benefit of the doubt

here, but I do want to (very politely I hope) course correct for this to

stay a good environment for all to discuss.

On Sun, Feb 09, 2025 at 08:46 PM, Maxime Devos wrote:

[snip]

This is not productive to say the least. Let's please all refrain from

such escalation. Certainly point out when you disagree or ask for

evidence in discussions, but this is taking us off track.

Also, please be mindful that these are different people in the current

thread. Many of the people from the older ZFS threads don't seem to be

active on Guix, at least publicly. In any event, please be aware this is

a wide group on guix-devel with many opinions. Let's keep from

generalizations as much as possible.

If one feels that they are saying the same things and it is not going

anywhere new, I would encourage them to simply let the discussion

continue without them for others that may be finding this useful and

productive towards a path forward. Previous objections have been noted

and are available in this thread and previous issue discussions.

I hope guix-devel will continue to be a great place to discuss all

things Guix, whether in strong agreement, disagreement, or anywhere in

between. Tough discussions are welcome, but please keep this from

derailing further.

Thanks,

John

On 9/02/2025 20:37, Ian Eure wrote:

Yes (assuming typical ZFS+GPL compatibility argument) (and assuming the

two machines are by different people - if it's by the same person, I

imagine it may simplify the legalities).

Well, it wouldn't be distributed as the module itself, as it's embedded

in the initrd. But the initrd is substitutable, so the initrd is

distributed.

I'd say:

Allowing violations by the Guix project: pretty much never. (Like,

_maybe_ in some cases it can be determined it's a dead law not worth

following in jurisdiction X at time [T,T+?), but then this needs to be

repeated for all the jurisdictions, and may need to be reevaluated

often, now consider that most of us probably aren't lawyers, let alone

in a sufficient number of jurisdictions, and that there may be

disagreements, and that evaluating the situation takes time+effort ...

Doesn't seem worthwhile.)

Encouraging violations: never. (Encouraging law breaking seems illegal.)

Allowing violations - depends, we're not going to install spyware and

constantly monitor them or something, so they probably could do things

out-of-sight. But "hint hint, don't add activate X (whose purpose is to

make Y), or the illegal substance Y will result" (**) doesn't seem like

something to have in Guix.

And while documenting "The default configuration of adding X (ZFS) to

your Y (operating-system kernel-modules) might be illegal, so also

modify the initrd to mark it as non-substitutable" is worth _something_,

it's much better to just automatically mark the initrd as

non-substitutable, as this is an easy pitfall and entirely automatable.

(**): this is reference to prohibition era in US

What I think Guix should (try to) ensure to be the case, is:

If users tag their custom stuff (including from channels) that shouldn't

be distributed with #:substitutable? #false, and they intentionally

change things to violate the law, then users can legally run their

substitute servers without worrying about the particulars of their

configuration, and without having to look closely at the manual (you

_should_ read the manual, but you might not known in advance which parts

you should have read, and might easily miss something). If Guix knows

that some of this isn't automated in some known situations, then in

those known situations it should produce some kind of error message,

such that they know they need to resolve the situation in some matter.

I meant 'make-linux-libre'. This is a comment about

https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00061.html:

Going the the above, it might be possible to add nominally out-of-tree

modules to be compiled from within the tree.

Do note that this is an 'if X then Y' construction, I did not claim that

'X' is the case.

I do not know whether make-linux-libre supports such a thing.

The incoherency is the problem. If you want ZFS, and your belief ok ZFS

being legally OK is based on P being true, then it follows you have

 (a) ensure that P is true/rectify !P situations,

 (b) or give up on ZFS

 (c) (third alternative) or find another justification and ensure its

preconditions are met.

Yet, as a group, people that want ZFS in Guix have added ZFS without (a)

and (c).

... no? Guix _does_ ship things in bad combinations(*) (Linux-with-ZFS

initrd, by users running a substitute server, in the case that this

combination is in their configuration somewhere), without marking that

initrd combination as nonsubstitutable (IIRC).

(*) actually, I don't recall whether the Linux is part of the initrd,

but there also are other similar situations, e.g. system images. Same

problem.

And one of these out-of-tree modules is ZFS, where it is not useful

as-is because of the license.

In fact, ZFS support is the purpose of #55231. (Evidence: (1) the

example in the manual, (2) Kaeylen mentioning plans for using this for ZFS)

It does encourage them ... see, all the previously mentioned stuff about

substitute servers.

It's not, and has never been, a matter of forbidding of allowing users

to do something. It's  a matter of not leading to user (whether project

or individual user) to _accidentally_ perform a violations.

And it's entirely feasible to prevent this: see, the stuff about

#:substitutable? changes.

s/allows an user to/lets an user accidentally/

This is a problem. This should be resolved this by (a) removing ZFS or

(b) modifying the image producer to mark it as non-substitutable.

(unlikely option (c): ZFS people adjust license). If people won't do (b)

yet, it follows that (a) needs to be done for now.

This argument, essentially, is 'X already does the bad thing

Y(nicotine+).  So, it's fine to do Z (improper ZFS support) as well.'.

This really doesn't follow. Like, if I were to burn down a house

(illegal), that doesn't make it legal to steal a chair from the house.

Also, nowhere did I claim that #55231 purpose is committing copyright

violations.

ZFS _is_ the primary use, see previous remarks. Even if it weren't the

primary use, it's still a main use, and will likely be advertised as

such (if not in Guix proper manual, then likely in outside guides). Even

it it weren't, ZFS is nevertheless a Linux kernel module in Guix, and

#55231 deals with kernel modules in Guix, so #55231 needs to deal with ZFS.

Just because X has good uses Y1 ... Yn (lttng, etc.), doesn't mean it's

fine to neglect the currently bad use Y0 (current implementation of

#55231 + ZFS support).

Best regards,

Maxime Devos

On 9/02/2025 21:04, John Kehayias wrote:

It _is_ on track. I replied to someone making a negative remark about my

behaviour, and defended myself.

If defending oneself is a form of 'off track', then 'off track' is a

good thing to do.

Please be aware that I mentioned in the parentheses who.

Do note, that I didn't mention other people from the ZFS discussion.

This is, again, a mischaracterisation. Just, like, look at the ZFS

discussion, and in particular my response to Mason Loring Bliss' slander.

And there, I did let the discussion continue, and we did talk about new

things (except Mason Loring Bliss, who suddenly jumped in with slander,

and as basis mentioned old arguments ... in the form of a link, that has

been discussed already, without further interpretation). It's not an

exact fit, but if there's anything you need to give this advice to, it's

them, not me.

It's not a great place. Every so often I have to defend myself against

false insinuations and sometimes people conveniently ignore previously

mentioned issues.

I wasn't doing any derailing. It was:

but derailing isn't quite the right word there since they started with

the metaphorical rails) (maybe others, but those I recall in particular)

Like, if you a going to criticize someone's defense, at least bother to

look up their evidence ... (the posts by Mason Loring Bliss and

raid5atemyhomework are easy to find and speak for theirselves).

If the act of defending oneself against an accusation is, intrinsically,

a form of derailing, then derailing sometimes is a good thing.

Having to ever so often defend myself, is one of the reasons I avoid

Guix nowadays.

With all due respect,

Maxime Devos

Hi all,

As a bit of an aside, I'm wondering if it wouldn't be possible to eliminate the possibility of even potential copyviols by a change to the `derivation` function? It currently sets environment variable for the builder daemon by setting `allowSubstitutes = 0` if `(not substitutable?)`. If non-substitutability were propagated by doing something like instead setting `allowSubstitutes = 0` if `(not substitutable?)` or if `(not (every substitutable-derivation? inputs))`, wouldn't this suffice to ensure that an initrd which contains non-substitutable inputs is properly marked non-substitutable?

It might be more correct to allow derivations built with non-substitutable native inputs to be substitutable nonetheless. The alternative seems like it could cause issues, in particular with the non-substitutable texlive package being used as a native input to build documentation.

Best,

Morgan

On Sun, Feb 09, 2025 at 10:13:51PM +0100, Maxime Devos via Guix-patches via wrote:

I want to try to clarify my understanding of something. My impression is

that the problem would be distribution of the combination of Linux and

ZFS, as the GPL and CDDL both limit distribution, not use:

For the GPL2:

"Activities other than copying, distribution and modification are not

covered by this License; they are outside its scope."

And the CDDL 1.0:

"3.1. Availability of Source Code. Any Covered Software that You

distribute or otherwise make available in Executable form must also be

made available in Source Code form and that Source Code form must be

distributed only under the terms of this License."

So, It would never be "illegal" to add ZFS to my operating-system

kernel-modules, right? The violation of the licenses would only arise

when distributing the combined work to a 3rd party?

My apologies if this has already been discussed, but it stuck out to me.

Hi Leo,

On Sun, Feb 09 2025, Leo Famulari wrote:

That's also my understanding. Cloud images would be a problem, but Guix

makes those unnecessary!

Please do not rely on this message. I have no legal training.

Kind regards

Felix

On 9/02/2025 23:42, Morgan Arnold wrote:

This has effectively already been answered.

Best regards,

Maxime Devos

Hello,

Am Sun, Feb 09, 2025 at 10:42:26PM +0000 schrieb Morgan Arnold via Development of GNU Guix and the GNU System distribution.:

just to clarify, texlive (or more precisely, texlivetexmf) is marked as

non substitutable not because it would not be allowed, but because it is

huge and essentially just an unpacked big tarball. So people had better

build the package by themselves.

And it should not be used as a (native-)input to other packages: We have

the much smaller modular texlive packages for this, which make it

possible to depend precisely on what is needed to build the

documentation.

Andreas

Maxime Devos <maximedevos@telenet.be> writes:

Please refrain from calling me incoherent. This patch was specifically

designed to work within the bounds of Guix' restrictions, and has been

pointed out, has general use, not just for ZFS even if that was my

initial motivation. It was designed to be of general use, which also

would allow me my own particular uses.

I did not understand your objections over the substitutable flag at the

time, and I still don't completely. That's not incoherency, that's

because a) this is inherently complicated, and b) ‘#:substitutable?’ has

arguably broken default behavior and no way to currently fix it.

I'm staying out of this otherwise. This patch has been a particular sore

point for me and was a major reason I stepped back from Guix. I'm glad

others are finding it useful, and I wish them well in getting it

integrated, but I don't have it in me anymore to deal with the patch

process in this project.

-bjc

Hi Maxime,

On Sun, Feb 09 2025, Maxime Devos wrote:

This kind of thing happens on technical lists from time to time. It's

not good to use perseverance, which is great when solving bugs, to

address social issues. Goodwill (or silence) are better for those.

Sometimes we just have to laugh at ourselves---and at all the compulsive

behavior that makes us human. Be friends, everyone!

Peace,

Felix

P.S. Your last message was in HTML format, so it was hard for me to sort

out who replied to whom (and the quotes above may be misattributed).

Hi Andreas,

Thanks for the clarification. If this is the case, and texlive is unlikely to be used as a native input, it seems reasonable to me that setting `allowSubstitutes = 0` if `(not (and substitutable? (every substitutable-derivation? inputs)))` would entirely eliminate the possibility of ZFS-based copyviols, as any derivation depending on it could not be substituted, and so neither Guix nor anyone using Guix could commit a copyviol. A user who wishes to use ZFS will then download the source code, compile the kernel module, and include it in their initrd, and this initrd will not accidentally be distributed. To the best of my non-lawyer understanding, this would not constitute any kind of copyviol.

This seems to me to implement a maximally conservative (in terms of avoiding possible copyviols) approach to incorporating ZFS into Guix. If this makes sense, I would be happy to include that change to `derivation` in this patch set.

Best,

Morgan

On Monday, February 10th, 2025 at 14:42, Andreas Enge <andreas@enge.fr> wrote:

Hi,

Morgan Arnold <morgan.arnold@proton.me> writes:

I'm not sure exactly where in the daemon code this would be implemented?

Would you have a pseudo-code draft of where it'd be done? Few of us are

knowledgeable about the daemon code base.

The idea is logical to me, but the implementation, if it touches how a

derivation is computed/changes its result, IIUC, would invalidate all

past derivations ever computed by Nix/Guix, which would be highly

undesirable/disruptive.

--

Thanks,

Maxim

With this patch, modules for ‘initrd-modules’ will not only be searched for in

the in-tree Linux modules, but also any additional modules specified in

‘kernel-loadable-modules’.

DIRECTORIES. Now takes a list of directories to search, rather than a single

one.

argument to PACKAGES. Now contains a list of file-likes to search for modules.

(raw-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (flat-linux-module-directory) along with the selected LINUX package.

(base-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (raw-initrd).

definition's kernel-loadable-modules into (make-initrd) as

LINUX-EXTRA-MODULE-DIRECTORIES.

---

gnu/build/linux-modules.scm | 19 ++++++++------

gnu/system.scm | 2 ++

gnu/system/linux-initrd.scm | 50 ++++++++++++++++++++++++-------------

3 files changed, 45 insertions(+), 26 deletions(-)

---

doc/guix.texi | 15 +++++++++++++++

1 file changed, 15 insertions(+)

This commit changes the conditions under which derivations, as constructed by the `derivation` function, are made substitutable, to prevent potential copyright violations related to the construction of substitutable initrds including non-substitutable derivations (in particular, ZFS).

This change prevents such copyright violations by only marking a derivation as substitutable if it is marked substitutable and all of its inputs are marked as substitutable. This means that non-substitutable derivations have a "poisoning" effect, preventing derivations which take them as input from being substitutable.

Change-Id: I80ba4a371ee0c55a1294aff311d4e7b151055fac

---

guix/derivations.scm | 5 ++++-

1 file changed, 4 insertions(+), 1 deletion(-)

Hi Maxim,

Thanks for the input. I think that I communicated the idea that I'm proposing poorly, although I'm not sure if what I'm proposing would actually work. I sent a new version of the patchset with the change that I'm proposing implemented, which should hopefully clarify what I mean. Of course, it's very possible that what I'm suggesting here is unacceptable for some reason that I haven't noticed.

Let me know if this doesn't adequately clarify things!

Best,

Morgan

On Tuesday, February 11th, 2025 at 14:09, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Hi all,

How prophetic.

I did some more testing with the proposed change to `derivation`, and it seems to be causing a weird issue. I didn't think that propagating non-substitutability would be much of a problem, since there are very few non-substitutable packages, but I was surprised to find that this change makes almost all packages non-substitutable! I did some REPL-ing to find the culprit, and it when I traced it back, I found that all of my non-substitutable derivations appeared to be so because their dependency graph included a derivation called `#<derivation /gnu/store/qbrwrmdgnfx3p9gl499f5pyhv0fcnw0a-gcc-11.4.0.drv => /gnu/store/d69awcc5wahh71amx0dmgaimsdvvp2bg-gcc-11.4.0-lib 7fc7c9bb99b0>`.

Unfortunately, I cannot for the life of me figure out what this derivation is, or why it isn't substitutable (all of its inputs are substitutable, and I can't find any relevant package explicitly marked as non-substitutable). I wonder if maybe it has something to do with the `gnu-build-system`? It appears to be an input of `bash-minimal`, which is what leads me to that suspicion. If I could figure out what this derivation is and why it's non-substitutable, I think that the change that the proposed change to `derivation` would work (and, in some sense, implement what ought intuitively to be the default behaviour, as Brian noted).

Any and all relevant thoughts would be much appreciated.

Best,

Morgan

On Sun, Feb 09, 2025 at 08:27:59PM -0800, Felix Lechner wrote:

If it is the case, then I don't think that Guix needs to do anything

about this except prevent our CI infrastructure from building the ZFS

module. We wouldn't need to hardcode any restrictions into the Guix

codebase. We have created these kinds of CI restrictions in the past.

Already it's possible to create combinations of programs with

incompatible free software licenses, as a user. Is this particular

combination (ZFS and Linux) special in some way?

Hi Leo,

Thanks for your interest!

I think that Maxime has argued against the idea that this is a sufficient guardrail. To (hopefully accurately) summarize Maxime's position, the issue is not simply preventing Guix's CI infrastructure from serving the combined work, but that this change would make it easier for users of Guix to accidentally serve the combined work by use of `guix publish`. Maxime's position is, to the best of my understanding, that this change should not be introduced to Guix, as it makes it easier for an end user to accidentally commit a copyright violation. If I have misrepresented Maxime's position here, I would welcome a correction.

I personally believe that the odds of a user accidentally committing a copyright violation due to this change are sufficiently low that it would be acceptable to merge the patch as-is, but reasonable minds can and of course do differ on this point. My attempts to make `#:substitutable? #f` "poisoning" are an attempt to fix this, but I have found that my lack of experience has made it difficult for me to figure out how to test that this change is behaving appropriately. It currently seems that more packages than I expected are "poisoned" for reasons that I do not really understand. Any help with understanding this would be hugely appreciated.

As discussed (in particular by Ian), it is already very possible to commit copyright violations with Guix. Maxime's concern seems to me to be more about the fact that this change facilitates (and arguably encourages) the accidental commission of copyright violations. This issue is not necessarily specific to Linux+ZFS, but is the primary example being discussed because facilitating Linux+ZFS systems would be a major application of this patch.

Best,

Morgan

P.S. In my proposed patch to `derivation`, I accidentally fat-fingered an extra closing parenthesis at the end of the changed line. I haven't bothered to submit a v6 of the patch set which fixes this, since I'm not sure if the corrected version of the patch even works as intended (or, if it is working as intended, why so many more packages than expected seem to be poisoned).

On Fri, Feb 14, 2025 at 04:10:22PM +0000, Morgan Arnold wrote:

Thanks Morgan. I agree that if we are not understanding Maxime's point,

I hope we will be corrected.

If Maxime's concern is that Guix should not make it too easy for users

to distribute software for which they do not have the license, I hear

that concern, but I argue that we shouldn't go very far with it. Of

course, Guix itself should not do that kind of thing, but we shouldn't

go out of our way to prevent users from doing so.

Sure, let's not make a special variable "Linux with ZFS" that a user

only needs to tweak a single line in order to build and distribute.

But we shouldn't prevent users from adding kernel modules to their

initrd, because that is explicitly not a problem from a licensing

standpoint. And if users choose to redistribute the compiled result,

that is their mistake / decision, not ours.

Again, I don't see what is special with this combination, compared to

things like the incompatibility of the OpenSSL and GPL licenses. OpenSSL

could not be distributed linked with GPL code for many years of Guix,

and we didn't combine the licenses ourselves. But it was trivial for

users to do it, even on the command line by using package

transformations. That was okay, and I think this is a similar situation

that is also okay.

To all, remember, my earlier message clarified the distinction between

combination and distribution. I hope further discussion will keep that

distinction in mind, if it is correct. Of course copyright is only

concerned with "copying" and distribution.

Hi Leo,

I am inclined to agree with this point of view, but it is my understanding that Maxime does not, and it seems like (at a minimum) rather bad form to merge this patch over entirely reasonable objections, even if we happen to disagree with the reasoning behind those objections. This, of course, being subject to the assumption that I am interpreting Maxime's objections correctly. My hope in making `#:substitutable? #f` propagate to dependents was to resolve this issue by simply implementing user protection from any accidental copyright-violating distribution. This seems to me like the most feasible path to assembling a patch set which would satisfy the expressed concerns, and so the most feasible path to the merging of this patch set.

I would be very open to finding another way to address these concerns, but `#:substitutable? #f` propagation was the only solution which presented itself to me. There may be a simpler way to deal specifically with the case of initrds, since those are what are being changed here, but the only scheme which I was able to devise for implementation required working at the level of derivations (essentially, because one has to be able to access the inputs of the initrd as derivations to be able to speak of their substitutability, since substitutability is a property of derivations).

Best,

Morgan

Hi,

Leo Famulari <leo@famulari.name> writes:

If I've followed correctly, I think Maxime's last reservation to this

change was that currently, even if the ZFS module is marked as

non-substitutable, after it gets embedded in a binary initrd via this

proposed change, it could become available as a binary substitute that

lacks any of the 'non-substitutable' metadata, as (I assume) the initrd

keeps no reference to the non-substitutable modules and Guix currently

has no other means to know.

Maxime's suggestion was to turn every initrd derivation into

non-substitutable, which would work around that, but it'd means that

everyone would also be building their initrd locally from source, which

doesn't sound too great as it makes the current experience worst to

satisfy a niche requirement (using out-of-tree kernel modules with

incompatible licenses).

Perhaps there could be some special case code that could be inserted at

the right place to do the right thing; it'd need to be investigated.

--

Thanks,

Maxim

Hi Morgan, Brian and all,

Morgan Arnold <morgan.arnold@proton.me> writes:

This change looks reasonable to me, *if* we can make the possible

copyright violation fix that Morgan is working on work correctly. I've

applied it locally and made the following small changes, also

normalizing the commit message a bit and squashing the documentation

change along the actual change commit:

I'll now take a look at the initrd substitutability issue/potential fix

from Morgan.

--

Thanks,

Maxim

Hi Morgan,

Morgan Arnold <morgan.arnold@proton.me> writes:

That's probably the GCC implicitly added by gnu-build-system, which is

listed in the %final-inputs variable.

I'm not sure what's wrong, but I think we could start by investigating

why this changes causes 29 new failures when running:

--

Thanks,

Maxim

Hi Maxim,

I did figure out that this was the GCC implicitly added by `gnu-build-system`, although unfortunately examining this more carefully didn't help me a whole lot with understanding why it seemed to be non-substitutable.

I accidentally added an extra closing parenthesis to the changed line in `derivation`, but didn't bother submitting an updated patch set because even with that typo fixed, the change still didn't seem to work. You may have noticed and fixed this yourself. I had trouble running the test suite while working on the changes, as I was away from home and my laptop seemed to be somewhat underpowered for the purpose. I'm back at home with access to my PC now, so I'll try to have a look at why the tests are failing.

Best,

Morgan

Hi Maxim,

I found the cause of these failed tests, although unfortunately it doesn't seem to resolve the problem with implicit inputs from `gnu-build-system` being non-substitutable. The failing tests pass a `derivation` as input to the derivations that they construct, rather than a `derivation-input`. My added code then fails upon attempting to apply `derivation-input-derivation` to something which is not `derivation-input?`. I think that this might arguably be a flaw in the tests, but it can be resolved by simply checking that an input is `derivation-input?` before attempting to apply `derivation-input-derivation`. I'll send over the patch in a moment.

Best,

Morgan

This commit changes the conditions under which derivations, as constructed by the `derivation` function, are made substitutable, to prevent potential copyright violations related to the construction of substitutable initrds including non-substitutable derivations (in particular, ZFS).

This change prevents such copyright violations by only marking a derivation as substitutable if it is marked substitutable and all of its inputs are marked as substitutable. This means that non-substitutable derivations have a "poisoning" effect, preventing derivations which take them as input from being substitutable.

Change-Id: I80ba4a371ee0c55a1294aff311d4e7b151055fac

---

guix/derivations.scm | 6 +++++-

1 file changed, 5 insertions(+), 1 deletion(-)

With this patch, modules for ‘initrd-modules’ will not only be searched for in

the in-tree Linux modules, but also any additional modules specified in

‘kernel-loadable-modules’.

DIRECTORIES. Now takes a list of directories to search, rather than a single

one.

argument to PACKAGES. Now contains a list of file-like objects to search for

modules.

(raw-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (flat-linux-module-directory) along with the selected LINUX package.

(base-initrd): Add LINUX-EXTRA-MODULE-DIRECTORIES keyword argument. Pass it

to (raw-initrd).

definition's kernel-loadable-modules into (make-initrd) as

LINUX-EXTRA-MODULE-DIRECTORIES.

used.

Change-Id: Ic39f2abcfabc3ec34a71acce840038396bf9c82e

Modified-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>

---

doc/guix.texi | 15 ++++++++++++

gnu/build/linux-modules.scm | 22 +++++++++++------

gnu/system.scm | 2 ++

gnu/system/linux-initrd.scm | 49 +++++++++++++++++++++++--------------

4 files changed, 62 insertions(+), 26 deletions(-)

Change-Id: I2407b59788ce335c21c181d9f9e3f26a359e9bf5

---

guix/derivations.scm | 46 ++++++++++++++++++++++----------------------

1 file changed, 23 insertions(+), 23 deletions(-)

'with-store'.

Change-Id: If30c2d457504b8524cd167f1a145fbbea61b513c

---

tests/derivations.scm | 45 +++++++++++++++++++++----------------------

1 file changed, 22 insertions(+), 23 deletions(-)

This commit changes the conditions under which derivations, as

constructed by the `derivation' procedure, are made substitutable, to

prevent potential copyright violations related to the construction of

substitutable initrds including non-substitutable derivations (in

particular, ZFS).

This change prevents such copyright violations by only marking a derivation as

substitutable if it is itself marked substitutable along all of its inputs.

This means that non-substitutable derivations propagate to other derivations

using them as input.

Change-Id: I80ba4a371ee0c55a1294aff311d4e7b151055fac

Modified-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>

---

guix/derivations.scm | 53 +++++++++++++++++++++++--------------------

tests/derivations.scm | 16 +++++++------

2 files changed, 37 insertions(+), 32 deletions(-)

Hi Morgan,

I needed to do some changes and adjust one test, but in v6 the

derivations tests now pass, and the regular operation of

Guix appears otherwise unaffected, which is good (I don't need to

rebuild say, Libreoffice).

Could you test?

--

Thanks,

Maxim

Hi Maxime,

Some of your replies in this thread are overly aggressive, in clear

violation of our Code of Conduct. Please refrain from singling out a

group of people and assigning labels to them, or calling out someone

specifically in a negative light.

Since this is not the first time this has happened and has been flagged

by the community, the Guix co-maintainers are putting you on a 2-week

temporary ban starting now and ending on *March 2nd, 14h00 UTC*. This

should give you ample time to re-read our Code of Conduct.

Please refrain from all interaction with the community during this

period, including sending mails to public Guix lists or the bug tracker,

or on the project IRC channels. This includes responding to any

messages that may (also) be addressed to you. Attempting to evade this

short ban will result in a longer one.

Maxim,

On behalf of the Guix co-maintainers.

Hi Maxim,

Your help is much appreciated! The changes all look good, but there is one thing which is alarming me somewhat. Perhaps I am misunderstanding how the `substitutable-derivation?` function actually operates, but if I apply these patches and then run, say:

```

(use-modules (guix) (gnu) (gnu packages bash))

(define store (open-connection))

(display (substitutable-derivation? (package-derivation store bash-minimal)))

```

it prints `#f`, which seems quite contrary to what I would expect. Oddly enough, despite this, Guix still seems to fetch a substitute for `bash-minimal` from Cuirass. In this sense it doesn't cause a problem, but I don't understand why the above script prints `#f` despite Guix fetching a substitute.

Hopefully this is just a misunderstanding on my part and the changes are actually completely fine.

Best,

Morgan