LinuxQuestions.org
Page 3 of 3 12 3
Show 50 post(s) from this thread on one page

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   ZFS: Myths and Misunderstandings (by Jesse Smith) (https://www.linuxquestions.org/questions/slackware-14/zfs-myths-and-misunderstandings-by-jesse-smith-4175540213/)

bassmadrigal 05-18-2016 08:07 AM
Quote:
Originally Posted by ReaperX7 (Post 5546620)
If you've found the golden loophole, I will gladly try to buy you a beer.
Why is including the source without a compiled module the "golden loophole"? I don't see it being any different than just downloading the (probably newer) source from the their website except that there might be a SlackBuild script by Pat available. It still doesn't allow you to install Slackware with ZFS.

ReaperX7 05-18-2016 09:03 AM
Depends on how you install it, but the point is, if a partition can be created by the installer and the framework exists to have it bootable, all you need to do is chroot into the system from the boot media and compile the prepatched source, and install the custom kernel.

bassmadrigal 05-18-2016 09:12 AM
And how is that any different than just compiling it while you're actually booted into Slackware? Both methods prevent you from using ZFS as your primary filesystem during install.

I'll admit, if ZFS is your thing, then having the source and SlackBuild on the install media under extra/ would be beneficial, but I fail to see how this is the "golden loophole". It really isn't that much better than installing it after you've finished booting your freshly installed Slackware (and possibly getting a newer version than what was on the install media).

jens 05-18-2016 09:20 AM
Quote:
Originally Posted by ReaperX7 (Post 5547213)
Depends on how you install it, but the point is, if a partition can be created by the installer and the framework exists to have it bootable, all you need to do is chroot into the system from the boot media and compile the prepatched source, and install the custom kernel.
In Debian 's case, it's simply using DKMS.
Having to enable "contrib" just means it's NOT officially in Debian (the main archive) but still accessible when adding "contrib" from an outside source and therefor not violating the GPL'd and official parts (Ubuntu does add a .ko that might(/or might not?) violate the GPL).

volkerdi 05-18-2016 02:18 PM
Quote:
Originally Posted by Jeebizz (Post 5547052)
Well thats what that article states, including the source only in a testing directory, so maybe those who want to play with ZFS on Slackware without FUSE, this could be an option, whether or not it is still possible and if Pat will even consider it is another question.
For ZFS to appear in Slackware I'm going to need to see license compatibility, not a loophole that allows people to violate the GPL on their personal machines.

ReaperX7 05-18-2016 03:21 PM
Quote:
Originally Posted by volkerdi (Post 5547372)
For ZFS to appear in Slackware I'm going to need to see license compatibility, not a loophole that allows people to violate the GPL on their personal machines.
Yup, and it's still a vast grey area. The distribution model of Slackware is different than Debian and Funtoo also, so again, another problem. The Software Freedom Law Center wasn't also exactly 100% clear:

Quote:
ZFS is licensed under the Common Development and Distribution License (CDDL), and the Linux kernel is licensed under the GNU General Public License Version 2 (GPLv2). While both are free open source licenses they are restrictive licenses. The combination of them causes problems because it prevents using pieces of code exclusively available under one license with pieces of code exclusively available under the other in the same binary. In the case of the kernel, this prevents us from distributing ZFS as part of the kernel binary. However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code.
For further reading: https://www.softwarefreedom.org/reso...rnel-cddl.html

For the TDLR people:

Quote:
When, in this mode of employment, the CDDL-licensed code implementing the filesystem is combined with the module-specific translation layer and the result is then statically or dynamically linked into the Linux kernel, the resulting binary is licensed to all users under the terms of GPLv2, and only GPLv2, as the license requires. This happens because CDDL gives permission for binary forms of the code it licenses to be released under any license, and the license terms in effect are those of GPLv2. The making of the binary itself does not result in infringement of the kernel copyrights, or a violation of GPLv2's terms.
First you have this, but then... there's this...

Quote:
But GPLv2 section 3 requires for compliant distribution of such a binary that "complete and corresponding source code" be provided or offered. GPLv2 section 2(b) requires that the source code must be made available under "the terms of this license." The source trees of many GPL-licensed works, including the Linux kernel, contain files originally published by their authors under other free software licensing terms. In these cases, where the licenses involved are "permissive" licenses---such as a GPL-compatible BSD license, the MIT/X11 license or the equivalent---it can be said that GPLv2 section 2(b) is literally complied with, because those licenses permit the source code to be placed under other license terms, and those files are "relicensed" to GPL when they are included in the larger project's source tree. Though this is literally satisfactory from the GPL perspective, it raises equitable concerns of another kind. The improvements or modifications made to that code within the context of the GPL'd project can now not be picked up and used by the original projects or other downstream developers, unless they are prepared to place their entire work under GPL copyleft terms. This "traps" the improvements to the original contribution where they cannot be reused by the original contributors under their preferred terms. This is legitimate conduct on the part of the GPL-using project, but it unnecessarily deteriorates comity among free software developers. A better approach than the "relicensing" approach is to keep the files so employed within the GPL-licensed project's source tree with their additional licensing material intact, even when modified, so that if those files, or any parts thereof, are removed from the GPL'd project they can be reused under the original license, with the improvements made in the GPL'd context fully available under those terms. This is the official advice of SFLC to its GPL-using clients. See Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers

In the present case, the files containing the code of the ZFS filesystem are available under free software license, but the terms offered are CDDL, not GPLv2. So although complete and corresponding source code for the GPLv2-licensed kernel binary is available under free license, some files are available only under terms of CDDL, which is inconsistent with the literal meaning of GPLv2 section 2(b). For a community of copyright holders whose consensus intention is to limit their permission to the literal meaning of GPLv2's words, this is a sufficient basis for an objection to the combination.
Which in turn, means what it means...

ChuangTzu 05-18-2016 04:00 PM
too muddled for such a pristine distro.


All times are GMT -5. The time now is 11:30 PM.
Page 3 of 3 12 3
Show 50 post(s) from this thread on one page