Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

[Denis 'GNUtoo' Carikli]

On Wed, 24 Nov 2021 13:03:18 +0100
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> 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.

pgpxWp2M_2PC6.pgp
Description: OpenPGP digital signature