Effectively force all GNOME users to locally compile ZFS?

Effectively force all GNOME users to locally compile ZFS?

[Mark H Weaver]

Hello Guix,

Regarding the following commit, recently pushed to our 'master' branch:

--8<---------------cut here---------------start------------->8---
commit 61ccd756e5ff73b2f8dc3449df537f1c5adb5872
Author: Tobias Geerinckx-Rice <me@tobias.gr>
Date:   Thu Jul 1 18:46:49 2021 +0200

    gnu: libvirt: Support ZFS.
    
    * gnu/packages/virtualization.scm (inputs): Add zfs.
--8<---------------cut here---------------end--------------->8---

If I understand correctly, this will effectively force all GNOME users
to locally compile ZFS.  The reason is that our 'gnome' package depends
on 'gnome-boxes', which depends on 'libvirt', which now depends on
'zfs', and our 'zfs' package includes the following argument:

--8<---------------cut here---------------start------------->8---
   ;; The ZFS kernel module should not be downloaded since the license
   ;; terms don't allow for distributing it, only building it locally.
   #:substitutable? #f
--8<---------------cut here---------------end--------------->8---

Am I mistaken?  Are there opinions about whether this is desirable?

Before the commit above, the only package that depended on 'zfs' was
'zfs-auto-snapshot', so presumably the only people who had to compile
ZFS were people who explicitly wanted ZFS.

      Regards,
        Mark

Re: Effectively force all GNOME users to locally compile ZFS?

[Tobias Geerinckx-Rice]

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

Hi Mark,

‘Force’ is a poor choice of word, both factually and rhetorically.

Mark H Weaver 写道：
> The reason is that our 'gnome' package depends
> on 'gnome-boxes'

To me (a non-GNOME user), this is the problem.  GNOME Boxes is a 
wonderful front-end for creating and running virtual machines 
using libvirt.  Why is it installed by default for every GNOME 
desktop user?

Conversely, it would be unfortunate to leave libvirt users with a 
less useful package because of that.

How about moving libvirt_storage_backend_zfs.so to a separate 
output?  Fortunately libvirt appears to be modularly 
well-designed, although I haven't tried myself.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Ludovic Courtès]

Hi,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> Mark H Weaver 写道：
>> The reason is that our 'gnome' package depends
>> on 'gnome-boxes'
>
> To me (a non-GNOME user), this is the problem.  GNOME Boxes is a
> wonderful front-end for creating and running virtual machines 
> using libvirt.  Why is it installed by default for every GNOME desktop
> user?

Yeah, default GNOME should probably not depend on GNOME Boxes.

> Conversely, it would be unfortunate to leave libvirt users with a less
> useful package because of that.
>
> How about moving libvirt_storage_backend_zfs.so to a separate output?
> Fortunately libvirt appears to be modularly well-designed, although I
> haven't tried myself.

That wouldn’t really help, would it?

I would rather have nothing depend on ZFS by default, but we could have
“libvirt-with-zfs” etc.

I agree that GNOME Boxes and libvirt should not depend on ZFS by default
because (1) ZFS is an optional feature and probably not widely used, (2)
ZFS combination with GPL code is problematic and as such we’d rather
limit it to a minimum, and (3) having users systematically build a
dependency locally should be avoided in general.

WDYT?

Ludo’.

Re: Effectively force all GNOME users to locally compile ZFS?

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> I would rather have nothing depend on ZFS by default, but we could have
> “libvirt-with-zfs” etc.
>
> I agree that GNOME Boxes and libvirt should not depend on ZFS by default
> because (1) ZFS is an optional feature and probably not widely used, (2)
> ZFS combination with GPL code is problematic and as such we’d rather
> limit it to a minimum, and (3) having users systematically build a
> dependency locally should be avoided in general.
>
> WDYT?

I agree that having a separate 'libvirt-with-zfs' would be preferable.

I see now that there's a problem even on the userspace side:
'virt-manager' is a GPLv2+-licensed program based on 'libvirt'.  If I
understand correctly, it would be a GPL violation for us to distribute
'virt-manager' linked with CDDL-licensed component(s) of ZFS.

For now, I think that commit 61ccd756e5ff73b2f8dc3449df537f1c5adb5872
should be reverted until we can evaluate the situation more carefully.

What do you think?

    Regards,
      Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

Re: Effectively force all GNOME users to locally compile ZFS?

[Tobias Geerinckx-Rice]

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

Hi Mark,

Something about this virt-manager reasoning strikes me as bogus, 
but it's complicated by how Guix works in practice…  I think any 
perceived (pseudo-)(cosplay-)(that includes me)‘legal’ issues are 
a distraction.

Mark H Weaver 写道：
> For now, I think that commit 
> 61ccd756e5ff73b2f8dc3449df537f1c5adb5872
> should be reverted until we can evaluate the situation more 
> carefully.

I reverted it already.  Anything else is a waste of all our 
valuable time.

Thanks,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Mark H Weaver]

Hi Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> writes:
> Something about this virt-manager reasoning strikes me as bogus, 

According to <https://www.gnu.org/licenses/license-list.html#CDDL>,
"a module covered by the GPL and a module covered by the CDDL cannot
legally be linked together."

     Regards,
       Mark

--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

Re: Effectively force all GNOME users to locally compile ZFS?

[Tobias Geerinckx-Rice]

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

Ludovic Courtès 写道：
>> How about moving libvirt_storage_backend_zfs.so to a separate 
>> output?
>> Fortunately libvirt appears to be modularly well-designed, 
>> although I
>> haven't tried myself.
>
> That wouldn’t really help, would it?

No.  I meant package.

> I would rather have nothing depend on ZFS by default, but we 
> could have
> “libvirt-with-zfs” etc.

Who knows, but I'd rather just revert the commit and be done with 
it.  ‘Nothing depend on ZFS by default’ is clear and unambiguous. 
Thanks!

> I agree that GNOME Boxes and libvirt should not depend on ZFS by 
> default
> because (1) ZFS is an optional feature and probably not widely 
> used,

Yeah, this is still a bug, but it's up to the GNOME users to deal 
with :-)

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Maxime Devos]

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

Mark H Weaver schreef op za 03-07-2021 om 15:33 [-0400]:
> [...]
> 
>     gnu: libvirt: Support ZFS.
>     
>     * gnu/packages/virtualization.scm (inputs): Add zfs.
> --8<---------------cut here---------------end--------------->8---
> 
> If I understand correctly, this will effectively force all GNOME users
> to locally compile ZFS.  The reason is that our 'gnome' package depends
> on 'gnome-boxes', which depends on 'libvirt', which now depends on
> 'zfs', and our 'zfs' package includes the following argument:
> 
> --8<---------------cut here---------------start------------->8---
>    ;; The ZFS kernel module should not be downloaded since the license
>    ;; terms don't allow for distributing it, only building it locally.
>    #:substitutable? #f
> --8<---------------cut here---------------end--------------->8---
> 
> Am I mistaken?  Are there opinions about whether this is desirable?

Perhaps the "zfs" package can be split in an userspace package (containing
userspace binaries and libraries) and a kernelspace component (containing
the kernel module)? And let the kernelspace component be unsubstitutable
and the userspace component substitutable?

If so, GNOME users won't have to compile ... unless they also use the
kernel module of course.

Or do the licensing concerns also apply to the userspace component?

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Tobias Geerinckx-Rice]

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

Maxime,

Maxime Devos 写道：
> Perhaps the "zfs" package can be split in an userspace package 
> (containing
> userspace binaries and libraries) and a kernelspace component 
> (containing
> the kernel module)? And let the kernelspace component be 
> unsubstitutable
> and the userspace component substitutable?

That's a very good idea if possible.

> Or do the licensing concerns also apply to the userspace 
> component?

I don't think so, but I'm no expert.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Domagoj Stolfa]

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

Hi:

On Sat, Jul 03, 2021 at 10:16:54PM +0200, Tobias Geerinckx-Rice wrote:
> Maxime,
> 
> Maxime Devos 写道：
> > <snip>
> 
> That's a very good idea if possible.

Why can substitutes not be offered for ZFS as a standalone module? I'm not a
lawyer nor do I understand much lawyerese, but AIUI, the problem stems from
the FSF lawyers thinking it wouldn't stand up in court to distribute CDDL
software linked against GPL'd software as one big binary. Could someone please
explain why it would not be acceptable to distribute substitutes of ZFS as a
*standalone kernel module*, rather than as a part of linux-libre?

Thanks!

--
Domagoj



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

Re: Effectively force all GNOME users to locally compile ZFS?

[Tobias Geerinckx-Rice]

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

Domagoj Stolfa 写道：
> Why can substitutes not be offered for ZFS as a standalone 
> module? I'm not a
> lawyer nor do I understand much lawyerese, but AIUI, the problem 
> stems from
> the FSF lawyers thinking it wouldn't stand up in court to 
> distribute CDDL
> software linked against GPL'd software as one big binary. Could 
> someone please
> explain why it would not be acceptable to distribute substitutes 
> of ZFS as a
> *standalone kernel module*, rather than as a part of 
> linux-libre?

The question assumes there's such a thing as a *standalone [Linux] 
kernel module*.

This is not a given, and according to all lawyers the FSF has 
talked to, a fiction.  Or so the FSF states in the last paragraph 
of the ‘What Constitutes the Entire Work?’ section of 
<https://www.fsf.org/licensing/zfs-and-linux>.

(Sorry for the link!  I couldn't resist ;-)

My understanding was (and still is) that this is specific to 
CDDL+GPL only, not CDDL+LGPL, so distributing a dynamically linked 
libvirt with ZFS support is allowed.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 243 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Tobias Geerinckx-Rice]

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

Tobias Geerinckx-Rice 写道：
> My understanding was (and still is) that this is specific to 
> CDDL+GPL
> only, not CDDL+LGPL, so distributing a dynamically linked 
> libvirt with
> ZFS support is allowed.

Do note that I did not consult my lawyer on this matter, partly 
because the man's an idiot.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Denis 'GNUtoo' Carikli]

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

On Sat, 3 Jul 2021 21:46:29 +0100
Domagoj Stolfa <ds815@gmx.com> wrote:

> Hi:
> 
> On Sat, Jul 03, 2021 at 10:16:54PM +0200, Tobias Geerinckx-Rice wrote:
> > Maxime,
> > 
> > Maxime Devos 写道：
> > > <snip>
> > 
> > That's a very good idea if possible.
> 
> Why can substitutes not be offered for ZFS as a standalone module?
> I'm not a lawyer nor do I understand much lawyerese, but AIUI, the
> problem stems from the FSF lawyers thinking it wouldn't stand up in
> court to distribute CDDL software linked against GPL'd software as
> one big binary. Could someone please explain why it would not be
> acceptable to distribute substitutes of ZFS as a *standalone kernel
> module*, rather than as a part of linux-libre?
- The ZFS kernel module is a derived work of Linux.
- Linux is under the GPLv2 and compatible licenses.
- The ZFS kernel module has code that is only available under the
  CDDL license.
- The CDDL license is incompatible with the GPLv2.

So while I can change the license of Linux for any license I want and/or
make derived work under incompatible licenses for fun on my laptop, I
can't redistribute that work. Even in source code form[1].

The same applies to the ZFS kernel module source code and binaries.

And so because of that images with gnome can't be redistributed without
violating the GPL. And the corresponding source of the ZFS package is
also violating the GPL.

So the question is how to deal with it in Guix. 

We need to remove that kernel module from Guix, but the question is how.

In Parabola there is a mechanism to produce patched source releases of
software. 

Is there something in Guix that could produce a modified source code
tarball (without the kernel module code) that users could download with
guix build --source? Or do we need to patch the source?

I think we really need to fix that, at least in FSDG distributions
because if for some reason we start depending functionalities that
violates the GPL GPL, we would then have some strong interest in having
the GPLv2 be void and unenforcable.

Alternatively we could start working on and/or funding a ZFS driver for
Linux that is compatible with the GPLv2+, but I really wonder if it's a
good use of resources given that we now have an equivalent filesystem
(BTRFS), and that doing that is probably a lot of work which might even
never get done in the first place.

In addition, that ZFS kernel module doesn't build for i686 because
apparently there is no Makefile for that architecture. So depending on
it probably makes gnome only usable for architectures supported by that
kernel module.

Denis.

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

Re: Effectively force all GNOME users to locally compile ZFS?

[Tobias Geerinckx-Rice]

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

Hi Denis,

Denis 'GNUtoo' Carikli 写道：
> Even in source code form[1].

That's not the general consensus at all, but did you mean to 
include a reference to someone who disagrees?

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Denis 'GNUtoo' Carikli]

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

On Sat, 20 Nov 2021 03:34:26 +0100
Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> Hi Denis,
Hi,

> but did you mean to include a reference to someone who disagrees? 
I forgot to look for references on that.

> Denis 'GNUtoo' Carikli [wrote]:
> > Even in source code form[1].
> That's not the general consensus at all
On what part precisely is there no consensus?

In my statement here, the and/or conflates several issues together:
> So while I can change the license of Linux for any license I want
>and/or make derived work under incompatible licenses for fun on my
>laptop, I can't redistribute that work. Even in source code form[1].

Here I assume that the fact that the GPL and the CDDL are incompatible
as the FSF already made a statement about that[1]. I didn't check that
in details but I assume that there is some consensus on that.

Also, if I take Linux source and I change the license to CDDL, for
instance by changing all licenses headers to add the CDDL instead of
the GPL and redistribute it as-is, I hope that at least on that there
is some consensus[2] on the fact that this is not legal.

If instead I take Linux source code and add files under the CDDL (like
the ZFS driver in it) and says that this version of Linux is under both
the combination of the CDDL and the GPL, this is not legal either
because both licenses are incompatible[2]. I hope there is some
consensus here too.

If I take individual drivers from Linux which are under the GPLv2 or
the GPLv2 or later, and I combine them in a new combined work on a new
git repository with code under the CDDL license, this is not legal
either. And here too I hope that there is some consensus on that too.

So the question here is probably (if I understood correctly): if I
write a driver for Linux under an incompatible license (like a nonfree
license or the CDDL), and that it's clear that this driver is deeply
linked to Linux (it's not an userspace program like ls or cp that simply
uses Linux syscalls), and that I distribute the driver source code in a
separate way (like in a different tarball or in separate git?), is it
still a derived work of Linux? Does the Linux license still applies?.

Here I don't see how the mode of distribution is changing things at
all: I don't see why distributing code in a different tarball or
git repository makes any difference. Code from Linux is still being
used even if it's not redistributed within the tarball or git
repository.

How both project (Linux and the ZFS driver) are interfaced together is
what define the derived work boundary, not the way it's distributed, and
if we add the projects licenses to the equation, we can therefor know if
it's legal or not.

As for the boundary, Linux makes it clear (in the form of a
license exception[3]) that userspace programs using syscalls are not
derived work from Linux, so here we have a practical example[8] that
show the impact, not of the way it's distributed, but the impact of the
interface between programs / code.

And in general projects statements[4][5] can be important to know what
is considered a derived work or not.

And here, to work, that ZFS module has to be compiled with the Linux
kernel and it has to be linked to it at runtime. And it can only work
with code that is part of Linux, so I really don't see how it cannot be
considered as a derivative work.

If instead I want to write a driver for a nonfree operating system like
(for instance Microsoft Windows or any other nonfree operating system)
under the GPLv2, I can still do it if I'm the author of that driver: to
do that I would license my code under the GPLv2 with an exception that
enables anyone to link it to that nonfree operating system or kernel.

For a more concrete example, I can release code under the GPLv2 that
use a library under the Apache2 license if I wrote the GPLv2 code by
adding an exception for that. For instance I did that in a program
that I wrote to enable people to also use it under the GPLv2[6].

The key point here is that I can only do that because I'm
the copyright owner (I wrote that code, and I'm not employed by
anyone). So I can add the license I want on that code, and that license
isn't the GPLv2 (or later), instead it's the GPLv2 (or later)
with an exception (to enable to link against code under the Apache
license).

If I don't own the copyright on code, I cannot change the license of
that code. So I can't simply take Linux and add exceptions to it. Or I
can't take ZFS code under the CDDL and add exceptions to it.

And as I understand it, we cannot even change the licenses and
copyright of code released under non copyleft free software licenses
like the MIT/Expat license or the various BSD licenses.

I don't recall the details but I think that this happened during the
integration of the ath5k driver in Linux at some point (it came from
OpenBSD): At the end the original code had to stay under the original
license[7] but that license is compatible with the GPLv2, so it's not
an issue, and the combined work (here Linux) is under various licenses
compatible with the GPLv2.

And you can combine work under compatible free software licenses so
it's not an issue.

So if you only use the individual files[7], you can still use them under
their original licenses.

So for instance here you could take CDDL files from ZFS on Linux and
use them in userspace, or on one of the Open Solaris forks /
distributions, but you can't combine them with Linux.

So, given all that I guess that the confusion here is that people
probably think that the way of distribution (what is included in the
tarball or git repository) is what define derivative work, while
instead it's how programs or code are interfaced together.

As I understand, when you link against a GPL library, your program is
expected to also be under a license compatible with the GPL.

So I don't see why this should be different with Linux.

Summary:
--------
You can't combine work under incompatible free software licenses in a
combined or derived work, and if you want to do that you need either
work to be re-licensed under compatible free software licenses (like
GPLv2 with an exception), but to do that you need to own the copyright
on that work.

References:
-----------
[1]https://www.fsf.org/news/interpreting-enforcing-and-changing-the-gnu-gpl-as-applied-to-combining-linux-and-zfs
[2]Here having some consensus doesn't mean that the consensual
interpretation is the right one. But in general not having consensus on
the right interpretation can be problematic, so it's a problem per se
as ideally both should match somehow.
[3]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES/exceptions/Linux-syscall-note
[4]http://faif.us/cast/2013/mar/26/0x39/
[5]Note that this talk is specific to the Europen Union laws and date
   from 2013.
[6]https://git.replicant.us/infrastructure/wiki-migration-scripts/tree/redmine2git.py
[7]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath5k/dma.c
[8]An example is not a proof, here I'm referencing it to show an
   example of how a project can make statements / declarations that
   explain what is the boundary of derived works.

Denis.

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

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

[pelzflorian (Florian Pelz)]

Hello Denis.  Thank you for your write-up.

raid5atemyhomework wrote patches to add ZFS to Guix
<https://issues.guix.gnu.org/45692>.  I put them in CC.  That there is
no decision on ZFS and their patches is bad.  Maybe their patches
would be for the RFC model to decide?

As for Denis’ arguments
<https://lists.gnu.org/archive/html/guix-devel/2021-11/msg00101.html>:

IANAL but I would dispute this:

On Sun, Nov 21, 2021 at 02:33:24AM +0100, Denis 'GNUtoo' Carikli wrote:
> If I take individual drivers from Linux which are under the GPLv2 or
> the GPLv2 or later, and I combine them in a new combined work on a new
> git repository with code under the CDDL license, this is not legal
> either. And here too I hope that there is some consensus on that too.

If we are talking about source code, the GPLv2 files and the CDDL
files are not intertwined into a combined work at all.  They are just
in the same git repo on the same file-system.

However I agree that ZFS is unsafe territory; courts might decide
otherwise.

Regards,
Florian

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

[Denis 'GNUtoo' Carikli]

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

On Sun, 21 Nov 2021 11:54:15 +0100
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> Hello Denis.  Thank you for your write-up.
Hi,

> raid5atemyhomework wrote patches to add ZFS to Guix
> <https://issues.guix.gnu.org/45692>.  I put them in CC.  That there is
> no decision on ZFS and their patches is bad.  Maybe their patches
> would be for the RFC model to decide?
> 
> As for Denis’ arguments
> <https://lists.gnu.org/archive/html/guix-devel/2021-11/msg00101.html>:
> 
> IANAL but I would dispute this:
> 
> On Sun, Nov 21, 2021 at 02:33:24AM +0100, Denis 'GNUtoo' Carikli
> wrote:
> > If I take individual drivers from Linux which are under the GPLv2 or
> > the GPLv2 or later, and I combine them in a new combined work on a
> > new git repository with code under the CDDL license, this is not
> > legal either. And here too I hope that there is some consensus on
> > that too.
> 
> If we are talking about source code, the GPLv2 files and the CDDL
> files are not intertwined into a combined work at all.  They are just
> in the same git repo on the same file-system.
Just adding GPLv2 and CDDL files in the same repository should not be a
problem as far as I know. 

For instance you can have a kernel module under the GPLv2, and a
userspace tool under the CDDL license that doesn't use code from the
GPLv2 driver, and in that case both don't constitute a combined work.

If the userspace tool uses syscalls from the kernel, the kernel headers
license has an exception for that so it shound't be an issue either.

However I've reviewed a bit the ZFS kernel driver and some files are
under the CDDL license, and that driver also uses functions from the
Linux kernel, and it needs to be directly linked to Linux to uses these
functions.

I didn't take into account the fact that the ZFS driver also has
GPLv2(+?) code or the structure of the repository because having
files under the CDDL licenses that are compiled in the ZFS driver and
having that driver use Linux function (through linking) is sufficient
to make sure that this is a combined work of Linux and that driver.

And since Linux's GPLv2[1] and the CDDL[2] are incompatible, even in
source code form the ZFS driver is not legal as it violates Linux's
GPLv2 license.

Adding extra layer(s) of indirection with code under GPLv2 compatible
licenses won't change anything here as the ZFS driver links with Linux
anyway and it uses functions in Linux.

As for the GPLv2 in the ZFS driver, in the module directory of
zfs-2.1.1, we have several files under the GPLv2 license or compatible
licenses.

If I "grep -i gpl" in the module directory, it gives several files, but
all the files I found are OK with that are OK with regard with the
GPLv2:
- lua/lapi.c has 'ZFS_MODULE_LICENSE("Dual MIT/GPL")', so we can can
  probably assume that GPL is the GPLv2 and use it under the GPLv2 here.
- The following files are under the GPLv2 or BSD 2 clauses, here we can
  use them under the GPLv2, so it's OK:
  - zcommon/zfs_fletcher_aarch64_neon.c
  - zcommon/zfs_fletcher_intel.c
  - zcommon/zfs_fletcher_sse.c
  - zcommon/zfs_fletcher_superscalar4.c: 
  - zcommon/zfs_fletcher_superscalar.c
- Finally, zstd/zfs_zstd.c is under the BSD 3 clauses, and also has
  "ZFS_MODULE_LICENSE("Dual BSD/GPL");" inside. In any case that BSD
  license isn't incompatible with the GPL, and we can use the GPL in
  "Dual BSD/GPL", so we're good in either cases.

As for the problematic symbols, for instance dequeue_signal is exported
by Linux and it's used by the ZFS driver.

To find about that you can use the following command in a Linux git
checkout to find the list of exported symbols:
> git grep -P "EXPORT_SYMBOL(_GPL)?\(.*\);"

And then the idea is to grep for them in the module directory, and
check if they are reimplemented by the ZFS module or not.

Another way to do that check would be to look at the module (the .ko
file) with nm or a similar tool and look at the undefined symbols (U).

As I understand from what Bradley Kuhn told me, the EXPORT_SYMBOL_GPL
macro name is misleading and It doesn't mean that one can use symbols
exported by EXPORT_SYMBOLS without having to abide by the GPL, and I
need to look at EXPORT_SYMBOLS_GPL history to understand that in more
details.

But we don't need to do that either here as the dequeue_signal is
exported with EXPORT_SYMBOL_GPL anyway (it's in kernel/signal.c Linux)
and AFAIK it's not reimplemented by the ZFS driver either.

And I didn't check how many symbols from Linux are used but one is
enough to be an issue.

References:
-----------
[1] Many files that are being compiled in Linux are under the GPLv2
    only or compatible licenses.
[2] The ZFS driver has code under the CDDL license that is compiled in
    the ZFS driver.

Denis.

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

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

[pelzflorian (Florian Pelz)]

On Sun, Nov 21, 2021 at 11:54:15AM +0100, pelzflorian (Florian Pelz) wrote:
> raid5atemyhomework wrote patches to add ZFS to Guix
> <https://issues.guix.gnu.org/45692>.  I put them in CC.  That there is
> no decision on ZFS and their patches is bad.  Maybe their patches
> would be for the RFC model to decide?

Maybe there is consensus that adding ZFS is a legal risk.

There is no consensus on the amount of risk.

Are there two camps,

- one unwilling to impose any such risk on users (i.e. close as
  won’t-fix <https://issues.guix.gnu.org/45692> and remove traces of
  ZFS)

- one “Worse is better” camp that likes to move fast and break things?
  I think of
  <https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00220.html>,
  even though Katherine Cox-Buday did not get involved here at all.

Then who decides?

I don’t actually care about ZFS myself, but there should be a decision
because I think current badly supported ZFS makes people here unhappy.

Regards,
Florian

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

[Denis 'GNUtoo' Carikli]

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

On Mon, 22 Nov 2021 19:10:48 +0100
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> I don’t actually care about ZFS myself, but there should be a decision
> because I think current badly supported ZFS makes people here unhappy.
For people that really want the ZFS kernel module, would using an extra
channel for that be a big issue?

As I understand the ZFS module is already built from source so
maybe there is a way to make sure that everything that depends on zfs is
not rebuilt.

Or would there be other concerns for users of the ZFS kernel module if
the module is moved in an unofficial channel?

As long as the module isn't provided, it should also be safe to
maintain the rest (like the services), though I've no idea if doing
that in Guix is desirable or not.

Denis.

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

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

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> On Sun, Nov 21, 2021 at 11:54:15AM +0100, pelzflorian (Florian Pelz) wrote:
>> raid5atemyhomework wrote patches to add ZFS to Guix
>> <https://issues.guix.gnu.org/45692>.  I put them in CC.  That there is
>> no decision on ZFS and their patches is bad.  Maybe their patches
>> would be for the RFC model to decide?

The decision to include zfs-on-linux, but not provide substitutes, was
made long ago.

Then there was a discussion in this very thread where I think (but I
don’t remember precisely) there was consensus on not having GNOME depend
on zfs-on-linux, because that’s just inconvenient as everyone would have
to build zfs-on-linux from source.

As for raid5atemyhomework’s patches, it’s just that reviewing such
patches takes time, a number of round trips, and that it’d be better to
get input from zfs-on-linux users.  I don’t think the patches change
anything to the initial decision above.

> Then who decides?

When consensus cannot be met, maintainers have the last say.

But again, my understanding is that there’s no new decision to be made
here.

Rather, there’s review work to be completed—Maxime already did a lot of
that—and commitment from ZFS-savvy people to maintain it going forward.

I hope this clarifies the situation a bit!

Ludo’.

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

[Denis 'GNUtoo' Carikli]

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

Hi,

On Tue, 23 Nov 2021 18:29:22 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

> When consensus cannot be met, maintainers have the last say.
> 
> But again, my understanding is that there’s no new decision to be made
> here.
If I understood correctly Florian, the argument here is that it is safe
to redistribute source code under a GPL incompatible license that links
to GPL code because it's in source form?

Denis.

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

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

[Denis 'GNUtoo' Carikli]

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

On Wed, 24 Nov 2021 00:50:04 +0100
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:

> Hi,
> 
> On Tue, 23 Nov 2021 18:29:22 +0100
> Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > When consensus cannot be met, maintainers have the last say.
> > 
> > But again, my understanding is that there’s no new decision to be
> > made here.
> If I understood correctly Florian, the argument here is that it is
> safe to redistribute source code under a GPL incompatible license
> that links to GPL code because it's in source form?
After having thought about it, I think I think I found a rationale that
could make sense.

Maybe it's because if the code is in source form, both code are not
combined in the same binary. 

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.

And that should also not be limited to Linux. 

We could then through dlopen or any similar method reuse code from
one binary in the other because the linking is dynamic as long as both
binaries are not linked together statically?

Or am I on the wrong track here?

Denis.

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

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

[pelzflorian (Florian Pelz)]

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.

It seems unrelated to the FSDG, so GNU Guix need not care.

Regards,
Florian

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

[pelzflorian (Florian Pelz)]

On Wed, Nov 24, 2021 at 01:03:29PM +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.
> 
> It seems unrelated to the FSDG, so GNU Guix need not care.

Sorry I misunderstood.  I think your claim is that the ZFS decisions
listed by Ludo i.e. to disallow binary substitutes but to allow
patches for a ZFS file-system object (once reviewed) are inconsistent.
Right?

I don't know if that convinces maintainers to change decisions.

Regards,
Florian

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

[zimoun]

Hi Florian,

On Wed, 24 Nov 2021 at 13:32, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> I don't know if that convinces maintainers to change decisions.

This decision is consistent with the analysis [1] done by Software
Conservancy Freedom, at least.

I have not read a clear position by the FSF.  They only analyses [2] the
incompatibilities of licenses but their analysis is not fine enough to
conclude what is their position about distributing ZFS; although they
say «ZFS is free software», thus nothing prevent Guix to distribute
source code of ZFS.


1: <https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/>
2: <https://www.fsf.org/news/interpreting-enforcing-and-changing-the-gnu-gpl-as-applied-to-combining-linux-and-zfs>

Cheers,
simon

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

[pelzflorian (Florian Pelz)]

On Wed, Nov 24, 2021 at 01:32:56PM +0100, pelzflorian (Florian Pelz) wrote:
> Sorry I misunderstood.  I think your claim is that the ZFS decisions
> listed by Ludo i.e. to disallow binary substitutes but to allow
> patches for a ZFS file-system object (once reviewed) are inconsistent.
> Right?
> 
> I don't know if that convinces maintainers to change decisions.
On Wed, Nov 24, 2021 at 01:51:08PM +0100, zimoun wrote:
> This decision is consistent with the analysis [1] done by Software
> Conservancy Freedom, at least.

I did not speak about one decision.

What I meant is that maybe Denis argued “dynamic linking creates a
derivative work” if and only if “ZFS source code is a derivative
work of Linux”.

Case 1, “ZFS source code is a derivative work of Linux” is true, then
it does not have a valid license, i.e. no free software license.

Case 2, “dynamic linking creates a derivative work” is false, then we
should offer binary substitutes as well.

It would follow that Guix’ decisions are inconsistent.

Then again, from Denis’ new mail,

On Wed, Nov 24, 2021 at 02:33:00PM +0100, Denis 'GNUtoo' Carikli wrote:
> 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.

Maybe Denis argued that any support for ZFS is at odds with the FSF
opinion that “dynamic linking creates a derivative work”.

On Wed, Nov 24, 2021 at 02:33:00PM +0100, Denis 'GNUtoo' Carikli wrote:
> 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?

That the CDDL has terms specific to source code distribution
complicates things further and it is hard to tell if copyright law can
even impose all of CDDL’s terms.

Regards,
Florian

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

[zimoun]

Hi Florian,

On Wed, 24 Nov 2021 at 15:40, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

>>> I don't know if that convinces maintainers to change decisions.
>>
>> This decision is consistent with the analysis [1] done by Software
>> Conservancy Freedom, at least.
>
> I did not speak about one decision.

About which decision are you talking about?  I am sorry if I have
misread or misunderstood.  From my readings, the second part of that
thread is an appeal about previous clear decisions:

 1. distributing source of ZFS
 2. not-distributing substitutes of ZFS

Both are consistent with the legal analysis of SFC [1].

1: <https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/>


> What I meant is that maybe Denis argued “dynamic linking creates a
> derivative work” if and only if “ZFS source code is a derivative
> work of Linux”.

I have no opinion; because IANAL.  As Jelle jokingly said on IRC [2], it
is a typical WANAX session*. :-)  As I suggested here [3], because WANAL,
I do not understand what we are discussing and on which legal basis this
discussion tries to appeal the decision made by Guix long time ago about
ZFS based on [1], among other things.

The appeal cannot happen here but it has to be raised to FSF lawyers.
IMHO.  I mean, it appears sane to openly discuss any topic, for sure,
and freely rehash previous decisions.  However, here I miss what could
be the conclusion because a) it is legal speculations since the case
have never been pleaded in Court and b) many of us are not qualified to
parse all lengthy judicial documents – what a lawyer is daily doing,
IIUC friends’ job. :-)

2: <http://logs.guix.gnu.org/guix/2021-11-24.log#172129>
3: <https://lists.gnu.org/archive/html/guix-devel/2021-11/msg00107.html>


Cheers,
simon

*pattern of WANAX session: «I am not a X but my strong opinion on
related-to-X is …». :-)

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

[Denis 'GNUtoo' Carikli]

[-- 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 --]

Re: ZFS part of Guix? RFC?

[Vagrant Cascadian]

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

On 2021-11-24, Denis 'GNUtoo' Carikli wrote:
> 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:

https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

> 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?

Rather than "waived", they are simply not applicable. There is basically
an "if" statement in the CDDL that triggers the incompatibility, and in
the case of source-only distribution, the conflicting parts of the
licenses do not come into play.


> 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.

This is exactly the case, as I understand it...

It is precisely because the terms of the GPLv2 and CDDL licenses do not
conflict in terms of source code, the only conflict arises when you
actually distribute binaries.

It is by no means *ideal* by Free Software principles and goals. It is
so nuanced, non-obvious, tricky and complicated, which is why it keeps
getting rehashed over the years.

It is a bit obnoxious in my personal opinion, but as a layman/non-lawyer
reading it, seems technically and legally permissible, as long as you do
not distribute the compiled binaries.


The fact that GNU Guix can technically handle this issue correctly by
marking the package as not substitutable, in other words "do not
distribute binaries of this package", is a very interesting
workaround. Thankfully there are very few cases like this!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: ZFS part of Guix? RFC?

[Denis 'GNUtoo' Carikli]

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

On Wed, 24 Nov 2021 12:02:11 -0800
Vagrant Cascadian <vagrant@debian.org> wrote:

> On 2021-11-24, Denis 'GNUtoo' Carikli wrote:
> > 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:
> 
> https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
> 
> > 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?
> 
> Rather than "waived", they are simply not applicable. There is
> basically an "if" statement in the CDDL that triggers the
> incompatibility, and in the case of source-only distribution, the
> conflicting parts of the licenses do not come into play.

I've not checked that in details yet but for now I'll assume that this
holds (until proven otherwise).

While thinking about this very weird case of combining GPL and CDDL
code together, I wonder if the fact that we can't redistribute binaries
still makes it free software.

At least the free software definition doesn't have anything that cover
this specific case:
> The freedom to run the program as you wish, for any purpose
> (freedom 0).

> The freedom to study how the program works, and change it so it
> does your computing as you wish (freedom 1). Access to the source
> code is a precondition for this.

> The freedom to redistribute copies so you can help your neighbor
> (freedom 2).

> The freedom to distribute copies of your modified versions to others
> (freedom 3). By doing this you can give the whole community a chance
> to benefit from your changes. Access to the source code is a
> precondition for this.

But I wonder if a license that forbid binary redistribution would still
be considered free or not. 

And also conditions may apply to the specific case, for instance here
nobody has an alternative (including Oracle) for redistributing
binaries unless Oracle releases ZFS under a license fully compatible
with the GPL or that Linux is re-licensed (that would probably be more
complicated than rewriting ZFS from scratch).

Other cases like a vendor forbidding binary distribution to make its
users pay for nonfree licenses might be way more problematic.

Denis.

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

Re: ZFS part of Guix? RFC?

[Denis 'GNUtoo' Carikli]

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

On Fri, 26 Nov 2021 16:28:04 +0100
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:
> But I wonder if a license that forbid binary redistribution would
> still be considered free or not.
When we'll have more infos on if that is free or if we consider it as
free until proven otherwise, we still have two remaining issues to deal
with:
- On some architectures (for instance i686) the kernel module doesn't
  build. Should we disable the module? Add support for these
  architectures? Or disable zfs as a dependency of Gnome?
- Images with the zfs modules won't be redistributable. So if we keep
  the ability to build the zfs module, would it be possible to add
  opt-in or opt-out settings to make sure that the images are still
  redistributable without violating the GPL?
  Or will all users always need to use transformations for that?

Here's the build error I have with i686:
> make -C
> /gnu/store/c5n1drdj3j780r6yxnqfldifkmwdz01d-linux-libre-module-builder-5.14.21/lib/modules/build
> M=`pwd`  CONFIG_ZFS=m modules make[3]: Entering directory
> '/gnu/store/c5n1drdj3j780r6yxnqfldifkmwdz01d-linux-libre-module-builder-5.14.21/lib/modules/build'
> arch/x86/Makefile:78: arch/x86/Makefile_32.cpu: No such file or
> directory make[3]: *** No rule to make target
> 'arch/x86/Makefile_32.cpu'.  Stop.

Denis.

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

Re: ZFS part of Guix? RFC?

[Vagrant Cascadian]

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

On 2021-11-26, Denis Carikli wrote:
> Or disable zfs as a dependency of Gnome?

This specific point is a bit dated; the issue was both introduced and
shortly after reverted in early July:

  61ccd756e5ff73b2f8dc3449df537f1c5adb5872 gnu: libvirt: Support ZFS.
  3fb6c96106df85ba47f8fea34b224071bd75a1b4 Revert "gnu: libvirt: Support ZFS."

Basically libvirt is a dependency of gnome-boxes, which is a dependency
of gnome, as I understand it, which is why the initial topic was
mentioning GNOME at all...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: ZFS part of Guix? RFC?

[Denis 'GNUtoo' Carikli]

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

On Fri, 26 Nov 2021 12:34:55 -0800
Vagrant Cascadian <vagrant@debian.org> wrote:

> On 2021-11-26, Denis Carikli wrote:
> > Or disable zfs as a dependency of Gnome?
> 
> This specific point is a bit dated; the issue was both introduced and
> shortly after reverted in early July:
> 
>   61ccd756e5ff73b2f8dc3449df537f1c5adb5872 gnu: libvirt: Support ZFS.
>   3fb6c96106df85ba47f8fea34b224071bd75a1b4 Revert "gnu: libvirt:
> Support ZFS."
> 
> Basically libvirt is a dependency of gnome-boxes, which is a
> dependency of gnome, as I understand it, which is why the initial
> topic was mentioning GNOME at all...
Thanks a lot for the info. I had that issue long after July, like I
still had it few months ago.

I've now retried to use guix system reconfigure and the issue is now
gone. It might be becuase of some issue / bugs with or within my
setup[1] though.

References:
-----------
[1]I've a dual boot between Parabola i686 (that also has Guix) and Guix
SD i686 and I share /gnu and my home between both. 

Denis.

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

Re: ZFS part of Guix? RFC?

[raid5atemyhomework]

Hello Denis,


> While thinking about this very weird case of combining GPL and CDDL
> code together, I wonder if the fact that we can't redistribute binaries
> still makes it free software.

AS I understood from early writings of GNU ---

"Freedom" here is the freedom to modify how *the hardware you purchased, which is supposedly your own*, works.

In principle, "binaries are enough", because you *can* modify executable binaries, and until Tivoization you could thus modify how the hardware you purchased and is supposedly owned by you works.  However, early GNU writers (RMS I think?) noted that binaries are really awful and that you need source code in order to modify how your hardware work, unless you are willing to sacrifice a ridiculous portion of your life reverse-engineering executable binaries.

As long as the source code is redistributable, users can modify the source code (without having to sacrifice too much of their limited lifetimes to the gods of extreme programming) and thereby modify how the hardware they purchased works.

Thus, the essential freedom is preserved (users can fork ZFS and point their personal ZFS package definition at their fork), even if a legal snag prevents redistribution of binaries.


I am well aware that *somebody* at Sun Microsystems screwed up by inventing the CDDL and putting the excellent ZFS under the CDDL and that is certainly a very cringey decision, but I want my hardware to work how I want it (i.e. without RAID5 write holes and memory buffer corruption bugs like in BTRFS "RAID5" mode) and not having ZFS on Guix is not helping that essential freedom.

Thanks
raid5atemyhomework

Re: ZFS part of Guix? RFC?

[Denis 'GNUtoo' Carikli]

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

On Tue, 30 Nov 2021 15:22:04 +0000
raid5atemyhomework <raid5atemyhomework@protonmail.com> wrote:

> Hello Denis,
Hi,

> > While thinking about this very weird case of combining GPL and CDDL
> > code together, I wonder if the fact that we can't redistribute
> > binaries still makes it free software.
> 
> AS I understood from early writings of GNU ---
> 
> "Freedom" here is the freedom to modify how *the hardware you
> purchased, which is supposedly your own*, works.
> 
> In principle, "binaries are enough", because you *can* modify
> executable binaries, and until Tivoization you could thus modify how
> the hardware you purchased and is supposedly owned by you works.
> However, early GNU writers (RMS I think?) noted that binaries are
> really awful and that you need source code in order to modify how
> your hardware work, unless you are willing to sacrifice a ridiculous
> portion of your life reverse-engineering executable binaries.

In case of binaries, when some people have the source code and you
don't, there is also an inequality and power dynamic: people with
source code have more power to modify the software than people without.

We can see some mention of a somewhat similar power dynamic in the GPLv3
for instance:
> But this requirement does not apply if neither you nor any third
> party retains the ability to install modified object code on the User
> Product (for example, the work has been installed in ROM).

And it seems that in the weird case of zfs-on-linux, that power dynamic
at least doesn't apply directly as nobody can redistribute binaries
unless they are the copyright holder of ZFS and redistribute it all
under licenses fully compatible with the GPLv2.

Though one could also argue that not everybody is equals when breaking
the law (so here when redistributing binaries) but that's probably out
of scope here as we only (re)distribute source code here.

> Thus, the essential freedom is preserved (users can fork ZFS and
> point their personal ZFS package definition at their fork), even if a
> legal snag prevents redistribution of binaries.
Good point.

> I am well aware that *somebody* at Sun Microsystems screwed up by
> inventing the CDDL and putting the excellent ZFS under the CDDL and
> that is certainly a very cringey decision, but I want my hardware to
> work how I want it (i.e. without RAID5 write holes and memory buffer
> corruption bugs like in BTRFS "RAID5" mode) and not having ZFS on
> Guix is not helping that essential freedom.

I also wonder if we have a way to fix that issue for good somehow.

It would be neat if somehow the copyright holder of ZFS redistributed
zfs-on-linux binaries at some point (for instance by redistributing the
Ubuntu kernel). As I understand this wouldn't automatically make that
code GPL compliant but we could probably manage to force the copyright
holder to re-release the ZFS code under GPL compatible licenses.

Rewriting the ZFS code under GPLv2 compatible licenses also looks
possible as GRUB has a GPLv3 implementation of ZFS, but it's probably
still a lot of work. It would have been a way better idea for Canonical
to hire people to do that (like the people that worked to add ZFS to
GRUB) rather than trying to circumvent the GPLv2[1][2].

References:
-----------
[1]https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
[2]https://ubuntu.com/blog/zfs-licensing-and-linux

Denis.

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

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

[zimoun]

Hi Denis,

On Wed, 24 Nov 2021 at 00:51, Denis 'GNUtoo' Carikli
<GNUtoo@cyberdimension.org> wrote:

> If I understood correctly Florian, the argument here is that it is safe
> to redistribute source code under a GPL incompatible license that links
> to GPL code because it's in source form?

Maybe you could be interested by these explanations:

<https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/>

Cheers,
simon

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

[Leo Famulari]

On Mon, Nov 22, 2021 at 07:10:48PM +0100, pelzflorian (Florian Pelz) wrote:
> Maybe there is consensus that adding ZFS is a legal risk.

I assume we are talking about the risk of litigation from Oracle (ZFS
owner), right?

Canonical decided in 2016 that the risk was low enough to take a chance
and include ZFS in Ubuntu:

https://ubuntu.com/blog/zfs-licensing-and-linux

Canonical earned $138 million in revenue in 2020, after earning more
than $100M in previous years as well [0]. So, they have a lot at stake
when taking that chance.

There are disagreements about whether or not the licenses in question
are compatible, but there is no definitive answer, only speculation and
rhetoric. Until then, all we can do is apply our values, balance our
options, and make a decision.

[0] Refer to "Group of companies' accounts made up to 31 December 2020":
https://find-and-update.company-information.service.gov.uk/company/06870835/filing-history

Re: Effectively force all GNOME users to locally compile ZFS?

[zimoun]

Hi Denis,

On Sun, 21 Nov 2021 at 02:33, Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:

>> That's not the general consensus at all
> On what part precisely is there no consensus?

Consensus about distributing ZFS as source code but not as binary.

As the comment says, IIUC:

--8<---------------cut here---------------start------------->8---
    (arguments
     `(;; The ZFS kernel module should not be downloaded since the license
       ;; terms don't allow for distributing it, only building it locally.
--8<---------------cut here---------------end--------------->8---

<https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/file-systems.scm#n1184>


> Summary:
> --------
> You can't combine work under incompatible free software licenses in a
> combined or derived work, and if you want to do that you need either
> work to be re-licensed under compatible free software licenses (like
> GPLv2 with an exception), but to do that you need to own the copyright
> on that work.

A complete analysis [1] of the situation is exposed by Software Freedom
Conservancy.  As pointed [2] by Florian, this discussion about ZFS
license had been recently opened, again.  And closed [3]. :-)

(When reviewing the still pending contribution for adding ZFS service)

For what my opinion is worth, first this case has never been pleaded in
Court, so it is impossible to claim a clear line for this grey area.  It
is only speculation on what could perhaps happen in Court; even more
precisely in US Court – I am not convinced these arguments hold
similarly in European Courts or elsewhere; another story.  Second, I am
not qualified to interpret what lawyers write, I mean jokingly, « I
think any perceived ‘legal’ issues are a distraction » – quoting Tobias
[4]. ;-)

Thanks for sharing your concerns.  I am not sure to share them but
indeed it could probably be worth to ask FSF or SFC or <name-it> lawyers
a clear question on this case and get a clear answer.

1: <https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/>
2: <https://issues.guix.gnu.org/45692#43>
3: <https://issues.guix.gnu.org/45692#57>
4: <https://yhetil.org/guix/878s2iiae1.fsf@nckx/>


Cheers,
simon

Re: Effectively force all GNOME users to locally compile ZFS?

[Mark H Weaver]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Maxime Devos 写道：
>> Perhaps the "zfs" package can be split in an userspace package
>> (containing userspace binaries and libraries) and a kernelspace
>> component (containing the kernel module)? And let the kernelspace
>> component be unsubstitutable and the userspace component
>> substitutable?
>
> That's a very good idea if possible.

I agree that this would be a fine solution.

     Thanks,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

Re: Effectively force all GNOME users to locally compile ZFS?

[Giovanni Biscuolo]

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

Mark H Weaver <mhw@netris.org> writes:

> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>
>> Maxime Devos 写道：
>>> Perhaps the "zfs" package can be split in an userspace package
>>> (containing userspace binaries and libraries) and a kernelspace
>>> component (containing the kernel module)? And let the kernelspace
>>> component be unsubstitutable and the userspace component
>>> substitutable?
>>
>> That's a very good idea if possible.
>
> I agree that this would be a fine solution.

AFAIK the licensing problem is just for the kernel modules binaries
(re)distribution, (obviously) not for the userspace binaries, so AFAIU
this would be a fine solution.

Meanwhile, what do you think about a temporary revert of commit
61ccd756e5ff73b2f8dc3449df537f1c5adb5872 to avoid causing GNOME users
ZFS compilation upon update (if I correctly understand the issue)?

Best regards, Giovanni.

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: Effectively force all GNOME users to locally compile ZFS?

[Mark H Weaver]

Hi,

Giovanni Biscuolo <g@xelera.eu> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>>
>>> Maxime Devos 写道：
>>>> Perhaps the "zfs" package can be split in an userspace package
>>>> (containing userspace binaries and libraries) and a kernelspace
>>>> component (containing the kernel module)? And let the kernelspace
>>>> component be unsubstitutable and the userspace component
>>>> substitutable?
>>>
>>> That's a very good idea if possible.
>>
>> I agree that this would be a fine solution.
>
> AFAIK the licensing problem is just for the kernel modules binaries
> (re)distribution, (obviously) not for the userspace binaries, so AFAIU
> this would be a fine solution.

Sorry, I spoke too soon above.  It seems that there is a problem with
including CDDL-licensed ZFS code on the userspace side.  'virt-manager'
is distributed under GPLv2+ and links with 'libvirt'.

> Meanwhile, what do you think about a temporary revert of commit
> 61ccd756e5ff73b2f8dc3449df537f1c5adb5872 to avoid causing GNOME users
> ZFS compilation upon update (if I correctly understand the issue)?

Agreed, both for the reason you mentioned and also to avoid violating
the GPL when we distribute 'virt-manager'.

      Thanks,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

Re: Effectively force all GNOME users to locally compile ZFS?

[Tobias Geerinckx-Rice]

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

Mark H Weaver 写道：
>> Maxime Devos 写道：
>>> Perhaps the "zfs" package can be split in an userspace package
>>> (containing userspace binaries and libraries) and a 
>>> kernelspace
>>> component (containing the kernel module)? And let the 
>>> kernelspace
>>> component be unsubstitutable and the userspace component
>>> substitutable?
>>
>> That's a very good idea if possible.

I suggested splitting *libvirt*, not ZFS.  How would splitting ZFS 
into two identically-licenced halves help?

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]