Package: guix-patches;
Reported by: Brian Cully <bjc <at> spork.org>
Date: Mon, 2 May 2022 19:55:02 UTC
Severity: normal
Tags: moreinfo, patch
View this message in rfc822 format
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: [bug#55231] 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.