From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id gLqAAy5PnmEpCgEAgWs5BA (envelope-from ) for ; Wed, 24 Nov 2021 15:41:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id QOmgOi1PnmFDZAAAbx9fmQ (envelope-from ) for ; Wed, 24 Nov 2021 14:41:49 +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 AE39D9465 for ; Wed, 24 Nov 2021 15:41:49 +0100 (CET) Received: from localhost ([::1]:43742 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mptT2-00026e-R5 for larch@yhetil.org; Wed, 24 Nov 2021 09:41:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mptST-0001zx-Js for guix-devel@gnu.org; Wed, 24 Nov 2021 09:41:14 -0500 Received: from pelzflorian.de ([5.45.111.108]:56090 helo=mail.pelzflorian.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mptSR-0008UP-Ic for guix-devel@gnu.org; Wed, 24 Nov 2021 09:41:13 -0500 Received: from pelzflorian.localdomain (unknown [5.45.111.108]) by mail.pelzflorian.de (Postfix) with ESMTPSA id BC6FB3606B4; Wed, 24 Nov 2021 15:41:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pelzflorian.de; s=mail; t=1637764868; bh=/RJ7m/FETlnEGDymAqgt4akZjkFsyS047cMYH14tWj4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=4UDa/3PtvZgPKmQnl57r6JOxx3tFKMJG5Q0DXdbWEfc7RHTAraeacEcso0wDAzkIi 8iRrrE4zGK8nh8qbphVTYHw5Yi5/mcQgHp11bnUsaDa5d98Jlggm6mpcJjxCkEwCf2 AOEohDdNl2vmtaZH33noJ7la/QK1V2D1x39EHl1Q= Date: Wed, 24 Nov 2021 15:40:59 +0100 From: "pelzflorian (Florian Pelz)" To: zimoun Subject: Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?) Message-ID: <20211124144059.t36mensuqxx7ug5l@pelzflorian.localdomain> References: <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> <20211124123256.guutnb6zgskejbya@pelzflorian.localdomain> <867dcxu37n.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <867dcxu37n.fsf@gmail.com> Received-SPF: pass client-ip=5.45.111.108; envelope-from=pelzflorian@pelzflorian.de; helo=mail.pelzflorian.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=1637764909; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=OnG639w344d3E5nwHGOtmjWd5e8Es7l/oewGyk/UVUk=; b=aoVSz7OJZDl4diWiGsdVhEXiAzAbgiE1AC9OFH7QYOhU9ZhEmCuuIG91e//5IesCv7ohdO qEy0d/FLRcHNQrUGYK7ntQV9jbNUuNjKJshVZCWUK88VnPfo30Q1XoGtZt+a4ANCcWq3+r 4o5Mv6n6afLb+puPARWnYuvPE49auoHli4oPMYMFk/ZvPUQLIDPWOMzXWVg6jpAAZzhmIo BGLRiiezmO6kRSLZ6qLzWz3a8MYvPUUXPOebs4K0pGDL0fQKiZC3SDehTOVGUavokgj1WF YcK44Q4MqCfi4OaX61FwVjTxxwUj0Qrp+jmGKrvCiLQxrrl+OAhzIeEHJE8SHg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637764909; a=rsa-sha256; cv=none; b=e4qi//Jd2X3/vQ4b3CzETOENZ47EUUumhrxUvQVdbpPFGG88gsaS4XufTjfnK1hK1Hb7vS hz+9rmElS194LjDEb2gPxub0UYzzMKAZtmPU8mmCgkxcFMueBpInA1Hcxu9D+EimZtGl5t 91FLfmpK0lkc36qKgMHhgqprPMxXlOxnTKdWib4vmeLEr6aYwHVyIl+5BUvApO6iGx+MHA xx61079eEG0Rf5DJ5moyYcjlf/Cngj5XwxPxWT5ZHVALkDAQyJ72wyaUteXAChH+NnUAfv 8adksJPlSIFI5XX2kC45u6upbYHeOgOhB+bDqf6OJdO+XF5sXnMwxyH4YFjKfw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=pelzflorian.de header.s=mail header.b="4UDa/3Pt"; 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: -0.39 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=pelzflorian.de header.s=mail header.b="4UDa/3Pt"; 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: AE39D9465 X-Spam-Score: -0.39 X-Migadu-Scanner: scn1.migadu.com X-TUID: G04DeomkgtsB 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