Hi, On Sunday, February 9th, 2025 at 9:11 AM, Maxime Devos <maximede...@telenet.be> wrote:
> > > 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. > > 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. 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 > 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 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 > > 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, ...)). > > 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. > > > 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. > > 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
