On Sat, 20 Nov 2021 03:34:26 +0100 Tobias Geerinckx-Rice <m...@tobias.gr> wrote:
> Hi Denis, Hi, > but did you mean to include a reference to someone who disagrees? 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/redmine2git.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.
pgpjATtNlHCQ5.pgp
Description: OpenPGP digital signature
