From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6PPKK4WjmWGiVgAAgWs5BA (envelope-from ) for ; Sun, 21 Nov 2021 02:40:21 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id eMl9J4WjmWEuDwAAB5/wlQ (envelope-from ) for ; Sun, 21 Nov 2021 01:40:21 +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 40FFF13F21 for ; Sun, 21 Nov 2021 02:40:21 +0100 (CET) Received: from localhost ([::1]:58552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mobq8-0000No-D3 for larch@yhetil.org; Sat, 20 Nov 2021 20:40:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52994) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mobpk-0000NX-7F for guix-devel@gnu.org; Sat, 20 Nov 2021 20:39:57 -0500 Received: from [2001:910:1314:ffff::1] (port=60850 helo=gnutoo.cyberdimension.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1mobph-00013Z-9e for guix-devel@gnu.org; Sat, 20 Nov 2021 20:39:55 -0500 Received: from gnutoo.cyberdimension.org (localhost [127.0.0.1]) by cyberdimension.org (OpenSMTPD) with ESMTP id b9fff841; Sun, 21 Nov 2021 01:32:56 +0000 (UTC) Received: from primarylaptop.localdomain (localhost.localdomain [::1]) by gnutoo.cyberdimension.org (OpenSMTPD) with ESMTP id 68e9be68; Sun, 21 Nov 2021 01:32:56 +0000 (UTC) Date: Sun, 21 Nov 2021 02:33:24 +0100 From: Denis 'GNUtoo' Carikli To: Tobias Geerinckx-Rice Subject: Re: Effectively force all GNOME users to locally compile ZFS? Message-ID: <20211121023324.0a3ba29a@primarylaptop.localdomain> In-Reply-To: <87v90no8n1.fsf@nckx> References: <87r1gfgpjc.fsf@netris.org> <292def7687859350b6f1cd95a8cd385b70bbe830.camel@telenet.be> <87eecfrw25.fsf@nckx> <20211120020940.5efaa2b2@primary_laptop> <87v90no8n1.fsf@nckx> 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_/Zf_zrZM0uITpeo=zu7CZpyt"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:910:1314:ffff::1 (failed) Received-SPF: pass client-ip=2001:910:1314:ffff::1; envelope-from=GNUtoo@cyberdimension.org; helo=gnutoo.cyberdimension.org X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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, 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=1637458821; 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=qj+YoLRtNz+/nAPjGGhBruEheqmfj9gI9SYM2yapT0I=; b=XRC4WotW1AhZ3qfxQmDZ1pdY/tkDVI1Ff1CFq7v5XeSZV8PaNiPSWFzksg1akCItZoUHoI 49XSlptBDRiH9RVQlqUWvAVRN/76YVyKpAb3QTvSvF/Zlms1g+gUc9YMOaNzRDtypNPd0H F/2B0hgWdSgFzS/mb0fZlAWsokbLSOQ+9QtL7PgULWEGS3yREykNaCj9DMtC+KYMhSmSrP m7+IyuAnsrfFv2XbSpLAsbObwZcO2vdGj812EosEs+nCFjEvk4J3Tr7WZhC4dQydZ4+J+6 vkk7ZMLWgpBY9CzAFSCAAANQ49cuhGcztauXjmZL0V53Wb1RkHlWyQ4o0pSHyA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637458821; a=rsa-sha256; cv=none; b=ir/sW27XlkkJdSA+klptsi88Yuc9/p3xOQwSi9eTM+UH/oEDRDFqTUIhtQShp0Y3MUxl+f UA/JjfkUFaQpxvWeibiT1vlqV41L4USTMTAA6ORUSJSNw2MeUuPq9exitnpwshv07QClna 2/JXSvmN0iqpPyiHL9MdQLrHt3FrZh6AX7K5+kBbxRQw/Sflffdft2t1ENx9j4So3erD+W IN7Firt8m8OPTKhyGduh0kn/41zxjp1Z26rDyGbvroIB3Ip8GqVeS7dQwTEI5X4WBFD6X7 7jPU6sXoxAka45YAczFX7TmC5KAvnNdQ2sp9aROADLUI08OwCEWAWzP4V9QF9Q== 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.97 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: 40FFF13F21 X-Spam-Score: -3.97 X-Migadu-Scanner: scn1.migadu.com X-TUID: OdCNcUfRMRMN --Sig_/Zf_zrZM0uITpeo=zu7CZpyt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 20 Nov 2021 03:34:26 +0100 Tobias Geerinckx-Rice wrote: > Hi Denis, Hi, > but did you mean to include a reference to someone who disagrees?=20 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/redm= ine2git.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. --Sig_/Zf_zrZM0uITpeo=zu7CZpyt Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmGZoeQACgkQX138wUF3 4mNXcQ//b2+M8WpEC0tT39uI6qtekW/6F9gUS9NwalBQaRovoE9qwyZJBBsCG6vV el3gJd0TQ36LZsmevEVzWZpzMaLCoyrzCevJiHkkdPY78WuZY/YIHnlgkl1gVZoB xnhgCF05rNFB7fO/Or32Vg2pXYCKq/d6eate/mFZK/hw/SmHX7+3ow5f6/PTXNwg zKEeZ82uoxKPGIKuZWok373FGI7/MXOTJGFckVrAYK6cYRPpUC2VtN0NAJPnYrZJ pg85fAve9pqNnqD9vkrSYi9K8SdPE2skDw84Y4H5gIFX+bPiz5x8uWtjut6y1MHy +GvGy1p2PIL1PA2D7pRKx5YfX2cYJM+JcdgBzzIc4jm8xoOmiJ0bPQXKeNo/KTmm rkI8Xn9g92wq72F8C0vG0lWrgWnp3FDx4GKaMpvb1pygySgtLys/gKr71NyLsUG9 m0OnRghs6ClBx7k6b4K2S0A6nF/v7ZQtNPoL1kyQWyuaMs4L0AVu+6LOyYBYee0o w+RwCT/y3yCHgKhCS7v8QbL1BYsb0dm0fkuFzXBaytVcupknQ9rqCt+GO8b7mkdJ gy5vKThEhLBgZjjCgKIoqPLRzNBZfksH0yEIFkpa3TgzMYLF2JRO6M44wgOqb8JT F3qEjk+zfjCfwQffP3yKqH0rWmysnek+eWtt3GM0wv1xbpyY8zM= =fdd7 -----END PGP SIGNATURE----- --Sig_/Zf_zrZM0uITpeo=zu7CZpyt--