all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
To: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
Cc: guix-devel@gnu.org, raid5atemyhomework@protonmail.com,
	Domagoj Stolfa <ds815@gmx.com>
Subject: Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)
Date: Wed, 24 Nov 2021 14:33:00 +0100	[thread overview]
Message-ID: <20211124142836.7c7a318d@primarylaptop.localdomain> (raw)
In-Reply-To: <20211124120136.l2dmta332z7c6bmx@pelzflorian.localdomain>

[-- Attachment #1: Type: text/plain, Size: 4612 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2021-11-24 13:50 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-03 19:33 Effectively force all GNOME users to locally compile ZFS? Mark H Weaver
2021-07-03 19:53 ` Tobias Geerinckx-Rice
2021-07-05  9:53   ` Ludovic Courtès
2021-07-05 17:48     ` Mark H Weaver
2021-07-07 11:59       ` Tobias Geerinckx-Rice
2021-07-11 20:07         ` Mark H Weaver
2021-07-07 11:34     ` Tobias Geerinckx-Rice
2021-07-03 20:01 ` Maxime Devos
2021-07-03 20:16   ` Tobias Geerinckx-Rice
2021-07-03 20:46     ` Domagoj Stolfa
2021-07-03 21:38       ` Tobias Geerinckx-Rice
2021-07-03 21:53         ` Tobias Geerinckx-Rice
2021-11-20  1:09       ` Denis 'GNUtoo' Carikli
2021-11-20  2:34         ` Tobias Geerinckx-Rice
2021-11-21  1:33           ` Denis 'GNUtoo' Carikli
2021-11-21 10:54             ` ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?) pelzflorian (Florian Pelz)
2021-11-22 16:50               ` Denis 'GNUtoo' Carikli
2021-11-22 18:10               ` pelzflorian (Florian Pelz)
2021-11-23 16:37                 ` Denis 'GNUtoo' Carikli
2021-11-23 17:29                 ` Ludovic Courtès
2021-11-23 23:50                   ` Denis 'GNUtoo' Carikli
2021-11-24  0:45                     ` Denis 'GNUtoo' Carikli
2021-11-24 12:03                       ` pelzflorian (Florian Pelz)
2021-11-24 12:32                         ` pelzflorian (Florian Pelz)
2021-11-24 12:51                           ` zimoun
2021-11-24 14:40                             ` pelzflorian (Florian Pelz)
2021-11-24 20:25                               ` zimoun
2021-11-24 13:33                         ` Denis 'GNUtoo' Carikli [this message]
2021-11-24 20:02                           ` ZFS part of Guix? RFC? Vagrant Cascadian
2021-11-26 15:28                             ` Denis 'GNUtoo' Carikli
2021-11-26 20:02                               ` Denis 'GNUtoo' Carikli
2021-11-26 20:34                                 ` Vagrant Cascadian
2021-11-27 15:19                                   ` Denis 'GNUtoo' Carikli
2021-11-30 15:22                               ` raid5atemyhomework
2021-11-30 21:22                                 ` Denis 'GNUtoo' Carikli
2021-11-24  1:24                     ` ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?) zimoun
2021-11-24 17:24                 ` Leo Famulari
2021-11-21 22:18             ` Effectively force all GNOME users to locally compile ZFS? zimoun
2021-07-04 20:11     ` Mark H Weaver
2021-07-05 10:21       ` Giovanni Biscuolo
2021-07-05 17:59         ` Mark H Weaver
2021-07-07 12:20       ` Tobias Geerinckx-Rice

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211124142836.7c7a318d@primarylaptop.localdomain \
    --to=gnutoo@cyberdimension.org \
    --cc=ds815@gmx.com \
    --cc=guix-devel@gnu.org \
    --cc=pelzflorian@pelzflorian.de \
    --cc=raid5atemyhomework@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.