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 <i...@retrospec.tv> wrote: > > > Hi Maxime, > > Maxime Devos maximede...@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@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.
