Subject: Re: Understanding #:substitutable? and #55231

From: Morgan Arnold <[email-masked]>
Date: Sun, 09 Feb 2025 20:03:37 +0000

Hi all,

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

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’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 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 <[email-masked]> wrote:

> 
> 
> Hi Maxime,
> 
> Maxime Devos [email-masked] writes:
> 
> > On 9/02/2025 2:06, Ian Eure wrote:
> > 
> > > Hi Morgan,
> > > 
> > > Morgan Arnold via "Development of GNU Guix and the GNU System
> > > distribution." [email-masked] 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.