From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id mENmDjpDnmHk5QAAgWs5BA (envelope-from ) for ; Wed, 24 Nov 2021 14:50:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 8LjyCTpDnmHHOwAAbx9fmQ (envelope-from ) for ; Wed, 24 Nov 2021 13:50:50 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BEF75D581 for ; Wed, 24 Nov 2021 14:50:49 +0100 (CET) Received: from localhost ([::1]:46608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpsfg-00038U-TD for larch@yhetil.org; Wed, 24 Nov 2021 08:50:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpsOj-00038d-9N for guix-devel@gnu.org; Wed, 24 Nov 2021 08:33:17 -0500 Received: from cyberdimension.org ([80.67.179.20]:47478 helo=gnutoo.cyberdimension.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1mpsOh-00012o-1b; Wed, 24 Nov 2021 08:33:17 -0500 Received: from gnutoo.cyberdimension.org (localhost [127.0.0.1]) by cyberdimension.org (OpenSMTPD) with ESMTP id 50a82795; Wed, 24 Nov 2021 13:32:21 +0000 (UTC) Received: from primarylaptop.localdomain (localhost.localdomain [::1]) by gnutoo.cyberdimension.org (OpenSMTPD) with ESMTP id 76efc856; Wed, 24 Nov 2021 13:32:21 +0000 (UTC) Date: Wed, 24 Nov 2021 14:33:00 +0100 From: Denis 'GNUtoo' Carikli To: "pelzflorian (Florian Pelz)" Subject: Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?) Message-ID: <20211124142836.7c7a318d@primarylaptop.localdomain> In-Reply-To: <20211124120136.l2dmta332z7c6bmx@pelzflorian.localdomain> References: <87eecfrw25.fsf@nckx> <20211120020940.5efaa2b2@primary_laptop> <87v90no8n1.fsf@nckx> <20211121023324.0a3ba29a@primarylaptop.localdomain> <20211121103548.yi5lo6ymcnm22gfm@pelzflorian.localdomain> <20211122180255.ipauqebmoiyw4bb3@pelzflorian.localdomain> <87bl2aixvx.fsf@gnu.org> <20211124005004.109ef096@primarylaptop.localdomain> <20211124014519.1e227941@primarylaptop.localdomain> <20211124120136.l2dmta332z7c6bmx@pelzflorian.localdomain> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/ftiN/r5.zTNQqjLIQYnckfW"; protocol="application/pgp-signature"; micalg=pgp-sha256 Received-SPF: pass client-ip=80.67.179.20; envelope-from=GNUtoo@cyberdimension.org; helo=gnutoo.cyberdimension.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, raid5atemyhomework@protonmail.com, Domagoj Stolfa Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1637761849; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=0nPugPf614gkVUi5dzgqIIexNfKYHCxtYi+x+1Ko2Hg=; b=EQTBt0OwraTf6lOYBo/hNxxmbBnGQoW7uitTVaTHcvBqlttRL0BW6kRntCG6ffhrLzv+Lq skGuq1owhytRc8CbjLOejEecCSaSGN0O/9tdj5/k1zB8++Opj98ZdxFk6pYDjZN1/3IEv2 fws5hslwfq5ZAGtNBUSUP58BTdZc4STNAEwuJSHYbgkgPxwdjXXuWWdAvsnbDirY7Rul4K BnJxWRwcnoN4HcExGIoeV40cYFHVJ3IFJIUdpEW6cmSJFSlnCm4ee0nEBYN48JNWZMt/6e IWLq7YoTNqgONB1XYa3wHjjJ9lEPYboMa8kemq2mV1+DFhn0cp8r3a6PY5haNg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637761849; a=rsa-sha256; cv=none; b=c2oQmXg3+d1u2GZXL0z9nV36kPZgmX9bEv17s6q3/YBBBkZin9NjhH9OpCbYnYpGoh1+vj UF+zAhhuwYFKe7rmRXWqXIk+Jcfz9EOap4UHCoztwtRlyjARqGkGFHK6Fsj7Eyzc9DYlYm WiYKRvqL+xeF4fmdJ4af3peXG4Mpilan4wnb4ciCdwpK+Jz+4FSBGLp+ClSHc8CqXtLIMS GxLIup7z5hxv848stnvEKNT8BrcUtmCcQRUhX7LwqwSMjLn0245nh2iwfPHTCtOTr3R9bY qzDD/krBk1YdiRj+ytkuJZBf8JOqLkCFsewhf6Q34sl46KAuS67ryznW25EJ4g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.99 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: BEF75D581 X-Spam-Score: -4.99 X-Migadu-Scanner: scn0.migadu.com X-TUID: o4Q4+qB5d88I --Sig_/ftiN/r5.zTNQqjLIQYnckfW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 (=3Dm) 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 (=3Dy) 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 =E2=80=9CExecutable=E2=80=9D, as CDDLv1 calls it) distribution do not= activate. > Therefore, the analysis is simpler,=20 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 =E2=80=94 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.=20 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=C2=A0Guix 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. --Sig_/ftiN/r5.zTNQqjLIQYnckfW Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmGePw8ACgkQX138wUF3 4mN51w/+IVnnURvsGhpdjE7kRpSA44KCBYBzJMQxHQ6qqL7PdrTjNHPtSfuYdZI8 160rZPausERiYSu3CmFE2GbJgfPLrEk8K75b8F+nFz570iiCxEtGtBk3Nk16WsdU JTkwEElJGxq6TLLlVEr/v3L/SbMVu6k/v1wj+g3/TO4gew01escV5m54BnmvGrzL rxn3FeOKCd2MT1OyHaTumkva+v2fkievYtp0HO6I9AK4RwBrfZAfAqkuqgBkVndm iMyvRT7yAGfM36y1900HvH0W0DmZRkWDQ5lsgg0duibJs6FYguexZkIT2IdmUCh1 oCrf7FyM3ZpEdlYmEziK3UQjAz4tsOlEIueh4KsqfmnYh3dYQkhp0zuZJh746Akm wuwlZQjbm2PoAiTo75olrTHLzd+JNvcGrqtoWSgNvj4SivqnnJ/jiPZSo0lFAx5y +qeATdAVTk7EhvSuwidmIwv92uXYT72JxkhNmK6yBCoLnHKOOVfSAhTIBU3Gn72l JR5Rgf2VDWigF5Brr6sBUOQiChWoknMzCMFsAffQmD6O0EREJQE9G46cStCR3Y2J ER8ueXzZZFZBTp1dYCl+DUmKh6lMEe+gcbd5w3bgo5y3bC2MLvqMttNTR5T+V6Jn phv7rH2pOsZO3d8qbLw1t4Z6RVdCbvdGCvvrCdiKqS42B+/Op40= =ro2n -----END PGP SIGNATURE----- --Sig_/ftiN/r5.zTNQqjLIQYnckfW--