On Wed, 24 Nov 2021 13:03:18 +0100 "pelzflorian (Florian Pelz)" wrote: > On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli > wrote: > > If that's the case then it would also be legal to redistribute > > binaries too as long as they are dynamically linked as the linking > > happens at runtime. > > The FSF is unable to have such a position. What I didn't understand is what magically made source exempt of the GPLv2 requirement while binaries aren't. For instance if I make a module for Linux and uses symbols for Linux: - The source code uses code from Linux. But if it's distributed separately both are not combined. To be compilable, the source needs to use headers or function definitions from Linux. - Modules being linked dynamically (=m) also use code from Linux and during the compilation, as I understand it, it only uses the headers and/or functions definitions that I mentioned above. So this case is not very different from the source code. - Binaries being statically linked (=y) are being included in the Linux binary. So from the GPLv2 side, I don't see what could make source code and dynamically linked module that different as to justify different applications of the GPL. That article states that: > Pure distribution of source with no binaries is undeniably different. > When distributing source code and no binaries, requirements in those > sections of GPLv2 and CDDLv1 that cover modification and/or binary > (or “Executable”, as CDDLv1 calls it) distribution do not activate. > Therefore, the analysis is simpler, So is it legal because zfs-on-linux is distributed as source and that the CDDL license incompatible requirements are waived when it is distributed as source? And that combining that work with GPLv2 code in source form is OK because GPLv2 is not violated because the incompatible CDDL requirements are only activated when distributed in executable form? If that's the case that would be the first explanation that doesn't undermine copyleft that I come across, and that is OK for me. If it's not the case then we have an issue and I think that we still need to find a valid explanation that doesn't undermine copyleft and/or get rid of the ZFS kernel module. It also states that it's risky legally: > Nevertheless, there may be arguments for contributory and/or indirect > copyright infringement in many jurisdictions. We present no specific > analysis ourselves on the efficacy of a contributory infringement > claim regarding source-only distributions of ZFS and Linux. However, > in our GPL litigation experience, we have noticed that judges are > savvy at sniffing out attempts to circumvent legal requirements, and > they are skeptical about attempts to exploit loopholes. Furthermore, > we cannot predict Oracle's view — given its past willingness to > enforce copyleft licenses, and Oracle's recent attempts to adjudicate > the limits of copyright in Court. Downstream users should consider > carefully before engaging in even source-only distribution. But as long as the rationale behind doesn't undermine copyleft, I've no issue with it. > It seems unrelated to the FSDG, so GNU Guix need not care. The issue here is that I think that we need to find a valid and plausible explanation that makes the ZFS kernel module source code legal in a way that doesn't undermine copyleft. And in some cases, laws or interpretations of laws that are undermine copyleft might be good if they also brings systemic advantages to free software: for instance if new laws makes all software free in theory and in practice too (by also making sure that we have the corresponding source code, or because we have tools to derive it from binaries). But here if we don't have a rationale that doesn't undermine copyleft, what we gain here is just the ability to use a filesystem in the kernel instead of using it through FUSE, so it's an awful tradeoffs for free software. But if we do have a rationale that doesn't undermine copyleft, it just brings some legal risk, but doesn't undermine copyleft, so I'm OK with that. In the past and present, distributions also had/have to deal with patents, anti DRM circumvention legislation, and many other legal risks, and the consensus in the FLOSS community (at least for patents and anti DRM circumvention) is that the choice of distributing risky packages is to be made by the individual distributions and not the whole FLOSS and/or free software community at large. Denis.