GNU bug report logs - #55231
[PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

Previous Next

Full log

Message #95 received at 55231 <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: "Morgan Arnold via Development of GNU Guix and the GNU System
 distribution." <guix-devel <at> gnu.org>, Morgan Arnold <morgan.arnold <at> proton.me>,
 Ludovic Courtès <ludo <at> gnu.org>,
 55231 <at> debbugs.gnu.org
Subject: Re: Understanding #:substitutable? and #55231
Date: Sun, 09 Feb 2025 11:37:13 -0800

Hi Maxime,

Maxime Devos <maximedevos <at> telenet.be> writes:

> On 9/02/2025 2:06, Ian Eure wrote:
>
>> Hi Morgan,
>>
>> Morgan Arnold via "Development of GNU Guix and the GNU System
>> distribution." <guix-devel <at> gnu.org> writes:
>>
>>> Hello,
>>>
>>> If the issue is simply that the patch has not been rebased 
>>> against a
>>> new enough version of Guix to be merged, I am happy to do that
>>> rebasing. Additionally, please correct me if I have made any 
>>> incorrect
>>> assertions above.
>
> 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.

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.


> 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:

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'?


> 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:
>
>  (snip)

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.


>> 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.
>
> 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,
> ...)).

Ah, hmm.  So these kind of violations are implictly prevented by 
Guix not shipping things in combinations which would violate the 
license terms?


> 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.

That’s a good suggestion, thank you.

>> 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.
>
> 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.

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 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.
>

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.