From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id QNULB4LKm2HDyAAAgWs5BA (envelope-from ) for ; Mon, 22 Nov 2021 17:51:14 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id AJ6qAoLKm2HrLwAAB5/wlQ (envelope-from ) for ; Mon, 22 Nov 2021 16:51:14 +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 B17C5E0D4 for ; Mon, 22 Nov 2021 17:51:13 +0100 (CET) Received: from localhost ([::1]:50578 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpCXA-0002oy-Uu for larch@yhetil.org; Mon, 22 Nov 2021 11:51:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpCX0-0002oj-4X for guix-devel@gnu.org; Mon, 22 Nov 2021 11:51:02 -0500 Received: from cyberdimension.org ([80.67.179.20]:47462 helo=gnutoo.cyberdimension.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1mpCWx-00083R-Fm for guix-devel@gnu.org; Mon, 22 Nov 2021 11:51:01 -0500 Received: from gnutoo.cyberdimension.org (localhost [127.0.0.1]) by cyberdimension.org (OpenSMTPD) with ESMTP id e3a83aa8; Mon, 22 Nov 2021 16:50:22 +0000 (UTC) Received: from primarylaptop.localdomain (localhost.localdomain [::1]) by gnutoo.cyberdimension.org (OpenSMTPD) with ESMTP id ef953c80; Mon, 22 Nov 2021 16:50:22 +0000 (UTC) Date: Mon, 22 Nov 2021 17:50:49 +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: <20211122175049.27479125@primarylaptop.localdomain> In-Reply-To: <20211121103548.yi5lo6ymcnm22gfm@pelzflorian.localdomain> References: <87r1gfgpjc.fsf@netris.org> <292def7687859350b6f1cd95a8cd385b70bbe830.camel@telenet.be> <87eecfrw25.fsf@nckx> <20211120020940.5efaa2b2@primary_laptop> <87v90no8n1.fsf@nckx> <20211121023324.0a3ba29a@primarylaptop.localdomain> <20211121103548.yi5lo6ymcnm22gfm@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_/RRldf4_N2DjITZvyY0_UAD4"; 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1637599873; 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=9t6mis7ffCucVLv1NDbig4DCLufQDA9QJcSMo9LF0v8=; b=eQ/dn1TqEqbtwrvhc0NZQFDEff8SCKVpqFhF438Eqovwg0BZUgjCPq3eqXWp7JJU+uxuHy B7/KnLU3Vlx7B5zd6N9atEYKRmgd3E2CYbkQ191zscO1tEPBeYfdybL0XjyYk5jjNYu4Vz sJhAFRhWjHttcm6ys2tYb/ra5Ll1CQWAImnWJMHvkeEYAjMpYPhIrRDEMTFQJgyYn/qWTi 7sQ1WKrs+Df5hI67XHwDfeRY+NUGFiKbC1LtJ4DqOMUSGhvpD9+PCpgsCBhgvrg6KAaTH5 bHy3L07jVj0qSNciT8WwKdpPVQSViGi6KnHSyF6UpIgzXPnXvJSjNZIz+Iq3Ag== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637599873; a=rsa-sha256; cv=none; b=Ih5BFMX3PD3FDg7I2mqZbmLacvA4yTDKr5YIMCyR+/2qH+ZIHz0AbKA5YDn90F1t/jym4G K0KYLQgUEZ4ce9t+0wJr+dNyEBEIcEl8Jgta+7pg0PDqVZ63MVEPUYo6xxJqN7+TW9Z0GZ /ldOZkb22I9ZjdP/jpcQeQqqgLdjoWALZ4yn2WOVBhqCJFTocLMWZBoNRgko+7RlUgR8ln Qp2kZGgrMCv8KYy3ZUBmE9z45XPXDHn5DlK5jPInF2OfVEeT9Bw+OywGSbxteYPaGxB0XO 9kIKw0tSrGGCCh6WCAkBO2ZjqlgRUs9h1/VsgKib8DFE+hMh9mXs6LQtIywMvQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -3.48 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: B17C5E0D4 X-Spam-Score: -3.48 X-Migadu-Scanner: scn1.migadu.com X-TUID: C/VPDYNec2u6 --Sig_/RRldf4_N2DjITZvyY0_UAD4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 21 Nov 2021 11:54:15 +0100 "pelzflorian (Florian Pelz)" wrote: > Hello Denis. Thank you for your write-up. Hi, > raid5atemyhomework wrote patches to add ZFS to Guix > . 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? >=20 > As for Denis=E2=80=99 arguments > : >=20 > IANAL but I would dispute this: >=20 > 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. >=20 > 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.=20 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:=20 - 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. --Sig_/RRldf4_N2DjITZvyY0_UAD4 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmGbymkACgkQX138wUF3 4mM1ug/+MDRYcaKL9vl82/rm5Dy2OEEOjQQo5Za3v3wIi/2qorh2Q4I8MNiBH35V X9B4Q8VpiktEgnWMxnj09ttwrWGIcGQZMXaYk/ZD+fd7suBF3+vEKZs9OSbtU8OW r3A9wSI/zEcDSww2w5qPKbQTtB1/c4yWb2Gadb9PL/Xn0nUYhQylS1zgcGvCfget 36lViBxIQFKVwYBZK/ZPS5QFx1YoreQ/103ilvFmI2XEN8wFW8JpMuLoE/jAF/jc S269UMfd9U5Vrd3fS9eFbXK+NrL/rOM5nbhA02F1m31l/0St98y7DiI3xoxg7g4V fsz2MfeLlO3h1xvrXs2Lo33dE05bfamF7k2evrBkkeuz+ZxdUYhH9l8A6jaFZD5M 5BdhQhm35SZBHuwzNKNIe1PlwaoUWZhdgjI4V8IYnbQ6rCbbwXvRV4KbWavH4bs/ 06MqIkydIFsp36AMa7ziRuWRaKquS5YLRCItrsoq76rXMh6HxwQam3xTQjaAVNs4 DPAdNjNI7qn6dNH8J4NYo0+F6lkUu+quHTyNYOdm8LIvS5MOaXrFOTyFbKpvhCOL SVKrI5C9TtqLK4H0qko/7kCQB0awU3gRA4Dpb0IaMVG09K0qru1RRXG/2QvbWyHh PqiCu0RSBFlLeeR0EA2mgdNBlX+1VLJDyoIqPtZ4V/7z6RS8bQI= =D8pT -----END PGP SIGNATURE----- --Sig_/RRldf4_N2DjITZvyY0_UAD4--