From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id oKzuD5xuM2Ib7wAAgWs5BA (envelope-from ) for ; Thu, 17 Mar 2022 18:23:40 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 2IdRDZxuM2K4IQAA9RJhRA (envelope-from ) for ; Thu, 17 Mar 2022 18:23:40 +0100 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 AFB2143B7 for ; Thu, 17 Mar 2022 18:23:39 +0100 (CET) Received: from localhost ([::1]:33632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nUtqc-0002vd-CG for larch@yhetil.org; Thu, 17 Mar 2022 13:23:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45318) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nUtq2-0002CW-Ib for guix-patches@gnu.org; Thu, 17 Mar 2022 13:23:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:32959) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nUtq2-0004s6-9S for guix-patches@gnu.org; Thu, 17 Mar 2022 13:23:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nUtq2-0008Vw-4G for guix-patches@gnu.org; Thu, 17 Mar 2022 13:23:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#45692] [PATCH 0/3] Better Support for ZFS on Guix Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 17 Mar 2022 17:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45692 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler , raid5atemyhomework Cc: "45692@debbugs.gnu.org" <45692@debbugs.gnu.org> Received: via spool by 45692-submit@debbugs.gnu.org id=B45692.164753773532651 (code B ref 45692); Thu, 17 Mar 2022 17:23:02 +0000 Received: (at 45692) by debbugs.gnu.org; 17 Mar 2022 17:22:15 +0000 Received: from localhost ([127.0.0.1]:55089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUtpH-0008UY-6q for submit@debbugs.gnu.org; Thu, 17 Mar 2022 13:22:15 -0400 Received: from baptiste.telenet-ops.be ([195.130.132.51]:47160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUtpD-0008UJ-Ra for 45692@debbugs.gnu.org; Thu, 17 Mar 2022 13:22:13 -0400 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by baptiste.telenet-ops.be with bizsmtp id 7VN92700Z4UW6Th01VN9Nq; Thu, 17 Mar 2022 18:22:10 +0100 Message-ID: <1e72240bff6b2c5986cc26a3af5fe9517ad4db74.camel@telenet.be> From: Maxime Devos Date: Thu, 17 Mar 2022 18:22:04 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-rAP1QkpOEuBcd4bhKyu0" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1647537730; bh=s40eu1855VRowvjGtSlzc5wKdfm7sTnho0ZKRILX4jo=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=WkkfIooxHHMkkQwz2GcgNa2C/RgBvSTm89ciEx3t6A4YLqFs0CGNuaRi1NuFtO4VL MVOCJ3KQQIzoyOBj6i5CL0SNomncih/ndldFK2jz6gDW0ttOVf2YkRLOg9CV8Kjeq3 QNap9AsLdlxYsGSjJbmCFLJRLo7FlmyjYliTiTq0xjV5M1bakyCRcHb1hv2/9hpyCO DOeK92bL9xjg0mmowvKTxnwwriEPNYfeEEVLdbOVAL3lxky2LQaj+QqJZEUoPdK4xx Rlpr5VHoeUmPnHoxgFV7W+OxBiTw4zqyJcGtR2bKIc1ov3WEPKIfND+0IIonCLK3Tv ysrdtejf4aESQ== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1647537819; 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:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=s40eu1855VRowvjGtSlzc5wKdfm7sTnho0ZKRILX4jo=; b=POjaRiBZYZvdrcOKezj2hC1kTUcKlNkdSvenFSMOHDdpOb9dnWG8OYMLZ5UnHgQtX1jLd+ 6Doa6z7LuTvHD2aCK4Wa2uFGLrziU5iVcXyooyfSnWfDWX3nsvgCu1U7vFzfz6tQtU1kij dHPAJjCl0sBTywQCwVtGNZ237tTjyXhAkFctkSr5h6x5Bkr88flSIpD+lZwbNPn+UASmF3 z8ycUxZopkIjJzJvXDYQLFAAZiH5kWYP0EA1++XlRvO+mO6wJegcPrgq9FdqP1szrkk508 ZSmJFAsmF4lYtx6F3a6Kl71omephdncB5uSv86JsX5qRBCMHjkS7DBlwrdiByA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1647537819; a=rsa-sha256; cv=none; b=aTdzclevHmxgLMA4W22GIvUHqOok67qeBYuuPYClqjAe4uxs5nZ0FTX81QQhaam0pTeTTv s3O+7ZfKbWYJ7+lQdfE12FCQ3Hf1ycBCm26tCYHB59x69F93bgRI+49VrOMvEF5ecRAMKa XvYPMDkbV8AI1cQfheEMz/DAHob+wTmjF/rblQ1jm1lSbNXSqMttGJZ2ey0y1N8B0/6sCE nFuJwPq8dISY+W20r9gmO0cOBYn6CABnPhKBPL4x5Xw2CyuDGSzD3nVT5077JHrVvFLiDz G4MavoSfPMjng52bQFS2wmWNYetCKEP7qTGMdUQZV0YpnBDnOiITxJYiG6fp7Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r22 header.b=WkkfIoox; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 2.85 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r22 header.b=WkkfIoox; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: AFB2143B7 X-Spam-Score: 2.85 X-Migadu-Scanner: scn0.migadu.com X-TUID: lGaSmjwlMEbH --=-rAP1QkpOEuBcd4bhKyu0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Liliana Marie Prikler schreef op do 17-03-2022 om 09:24 [+0100]: > In any case, I've added Maxime to CC so they can have a closer look at > it. I have been more-or-less ignoring the ZFS patches since some time after . If ZFS people(^), after a disagreement about licensing concerns, directly jump to accusations of gaslighting and sabogate, completely ignoring my previous arguments (*) without trying to refute any of them or bringing new arguments, then I don't want to be involved with ZFS. (^) So far only Mason Loring Bliss, _not_ raid5atemyhomework!=20 Also, the various =E2=80=98work-arounds=E2=80=99 around the GPL<->CDLL inco= mpatibility still seem super fishy to me even if they _might_ be technically correct. To me, this makes reviewing the code practically pointless -- why review the zfs service patches if they will have to be reverted due to incompatibility concerns anyway? Summarised: * The =E2=80=98Oracle does not care so no legal risk=E2=80=99 argument: - Oracle might not care, but there are other parties involved as well (e.g. the Linux people and contributors to OpenZFS). - Not getting caught doesn't mean things are above board. It just means you haven't got caught, and you might get caught later. - Has anyone actually ever asked Oracle for some official =E2=80=98yes, go ahead=E2=80=99 / =E2=80=98no, here's a DMCA notice / see you at YY= YY-MM-DD in court=E2=80=99 / =E2=80=98no, but you're too small fry to bother s= o you'll get away for it ... for now=E2=80=99 response? AFAICT, this has not been done. - Even if it would be very strange for Oracle to try to stop (the Linux part of(*)) OpenZFS, why would that stop Oracle and how would the odd behaviour actually legally matter? * The =E2=80=98zfs package is already in Guix=E2=80=99 argument (https://issues.guix.gnu.org/45692#47): then it should be reverted when the incompatibility is discovered. Also, the incompatibility issue has been noted before: https://lists.gnu.org/archive/html/guix-devel/2019-04/msg00404.html though it appears to have been forgotten in https://lists.gnu.org/archive/html/guix-patches/2019-12/msg00543.html presumably because different people were involved? * The =E2=80=98Guix is not distributing the source code, it's only pointi= ng to the source code=E2=80=99 argument: - We do distribute the source code, at https://ci.guix.gnu.org - probably also via our friends at SWH - and via the Wayback Machine fallback - possibly also to any Guix users on the local network, when using '--advertise' and '--discover' - and by delegating the distributing to the OpenZFS project - even if pointing to the tarball OpenZFS web would not count as distribution, assuming there's a license incompatibility (and hence, the Linux part of OpenZFS is illegal (*), wouldn't this pointing count as facilitation of a crime (or misdemeanor or contract breach or whatever's the local terminology), wouldn't this make Guix or individuals behind Guix accomplishes? - even if it's all legal, what about freedom 3 -- the freedom to distribute the program? - also, not being able to distribute the source code by ourselves seems rather inconvenient * The =E2=80=98we're not doing binary distribution=E2=80=99 argument: - That seems rather inconvenient, why not use BTRFS instead which seems quite capable and doesn't have this weird restriction? - Freedom 3=C2=A0is: =E2=80=98The freedom to redistribute copies so you can help others (freedom 2).=E2=80=99 Guix redistributes copies is a convenient form= , to help all users (=E2=80=98others=E2=80=99). To help the users, it = not only redistributes in source form, but also in binary form (substitutes). But the CDDL+GPL combination stops us from helping others by redistributing binary copies! Basically, if there's the freedom to redistribute copies, shouldn't this include _binary_ copies, especially when binaries are convenient? - We _are_ doing binary distribution: (here, =E2=80=98we=E2=80=99 includes all relevant users of Guix) An uninitiated user might do "guix system image ..." to produce an image (that happens to include a binary ZFS), dutifully uses "guix build --sources=3Dtransitive" and share the sources+binary with other people, and accidentally commit a violation. All the initrd, system image and "guix pack" would need to propagate unsubstitutability (and the top-level tools might need to error out) and this needs to be tested, AFAIK this has not been done. * The =E2=80=98we're not distributing _modified_ source code=E2=80=99 arg= ument: Freedom 4! We should be able to (legally) distribute modified source code as well. * Various =E2=80=99technically, because of Section 1 (bis) alpha Z of thi= s license, Paragraph 2 beta 3 of that license, this and that clause do not apply=E2=80=99 arguments: This seems to be missing the spirit, and the law is, to my limited knowledge, not a deterministic automaton with an exact mathematical formulation without any bit flips. Greetings, Maxime. (*) The BSD modules are presumably fine though (unverified)! But Guix does _not_ (currently) support BSDs. --=-rAP1QkpOEuBcd4bhKyu0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYjNuPBccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7ul6AP9hwXMBalE0IATLZ2kCVy1qKfJZ mk04zvITh5Q8u5WPOwEA1Wh4xwFKr8O5K9DodAu86xVPHM4Kd2Ogpyuu6oOIXg8= =ghTU -----END PGP SIGNATURE----- --=-rAP1QkpOEuBcd4bhKyu0--