Hi, Leo Famulari <l...@famulari.name> writes:
> On Fri, Feb 14, 2025 at 04:10:22PM +0000, Morgan Arnold wrote: >> Maxime's concern seems to me to be more about the fact that this >> change facilitates (and arguably encourages) the accidental commission >> of copyright violations. This issue is not necessarily specific to >> Linux+ZFS, but is the primary example being discussed because >> facilitating Linux+ZFS systems would be a major application of this >> patch. > > Thanks Morgan. I agree that if we are not understanding Maxime's point, > I hope we will be corrected. > > If Maxime's concern is that Guix should not make it too easy for users > to distribute software for which they do not have the license, I hear > that concern, but I argue that we shouldn't go very far with it. Of > course, Guix itself should not do that kind of thing, but we shouldn't > go out of our way to prevent users from doing so. > > Sure, let's not make a special variable "Linux with ZFS" that a user > only needs to tweak a single line in order to build and distribute. > > But we shouldn't prevent users from adding kernel modules to their > initrd, because that is explicitly not a problem from a licensing > standpoint. And if users choose to redistribute the compiled result, > that is their mistake / decision, not ours. > > Again, I don't see what is special with this combination, compared to > things like the incompatibility of the OpenSSL and GPL licenses. OpenSSL > could not be distributed linked with GPL code for many years of Guix, > and we didn't combine the licenses ourselves. But it was trivial for > users to do it, even on the command line by using package > transformations. That was okay, and I think this is a similar situation > that is also okay. > > To all, remember, my earlier message clarified the distinction between > combination and distribution. I hope further discussion will keep that > distinction in mind, if it is correct. Of course copyright is only > concerned with "copying" and distribution. If I've followed correctly, I think Maxime's last reservation to this change was that currently, even if the ZFS module is marked as non-substitutable, after it gets embedded in a binary initrd via this proposed change, it could become available as a binary substitute that lacks any of the 'non-substitutable' metadata, as (I assume) the initrd keeps no reference to the non-substitutable modules and Guix currently has no other means to know. Maxime's suggestion was to turn every initrd derivation into non-substitutable, which would work around that, but it'd means that everyone would also be building their initrd locally from source, which doesn't sound too great as it makes the current experience worst to satisfy a niche requirement (using out-of-tree kernel modules with incompatible licenses). Perhaps there could be some special case code that could be inserted at the right place to do the right thing; it'd need to be investigated. -- Thanks, Maxim
