7 ms·

GPL only forbids ZFS to be distributed alongside Linux, it doesn't prevent users from installing it manually. (IANAL)

by maxloh 3y ago

deleted 3y ago
[deleted]
mustache_kimono 3y ago
> GPL only forbids ZFS to be distributed alongside Linux But does it even do that? You might be surprised when/if you read a little more widely. Position of OpenZFS project[0] is which I find persuasive (my emphasis added): In the case of the Linux Kernel, this prevents us from distributing OpenZFS as part of the Linux 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. [0]: https://openzfs.github.io/openzfs-docs/License.html https://openzfs.github.io/openzfs-docs/License.html You might see also: [1]: https://www.networkworld.com/article/836039/smb-encouraging-closed-source-modules-part-1-copyright-and-software.html https://www.networkworld.com/article/836039/smb-encouraging-... [2]: https://law.resource.org/pub/us/case/reporter/F2/977/977.F2d.1510.92-15655.html https://law.resource.org/pub/us/case/reporter/F2/977/977.F2d...
- lmz 3y ago
  It doesn't matter what the project thinks as long as there is code owned by Oracle in the FS.
  - mustache_kimono 3y ago
    > It doesn't matter what the project thinks as long as there is code owned by Oracle in the FS. Might we agree then that the only thing that really matters is the law? And we should ignore other opinions coughlike from the FSF/the SFCcough which don't make reference to the law? Or which ignore long held copyright law principles, like fair use? Please take a look at the case law. The so far theoretical claim of OpenZFS/Linux incompatibility is especially weak re: a binary kernel module.
    - wtallis 3y ago
      What matters in practice isn't the law, but how much trouble Oracle could cause should the lawnmower veer in that direction. Even a complete rewrite of ZFS would have some risk associated with it given Oracle's history.
      - mustache_kimono 3y ago
        > What matters in practice isn't the law, but how much trouble Oracle could cause should the lawnmower veer in that direction. Veer in what direction? The current state of affairs re: Canonical and Oracle is a ZFS binary kernel module shipped with the Linux kernel. Canonical has literally done the thing that which you are speculating is impermissible. And, for 8 years, Oracle has done nothing. Oracle's attorneys have even publicly disagreed with the SFC that a ZFS binary kernel module violates the GPL or the CDDL.[0] Given this state of affairs, the level of legal certainty re: this question is far greater than the legal certainty we have re: pretty much any other open IP question in tech. What matters is practice, is that you stop your/the SFC's/the FSF's torrent of FUD. > Even a complete rewrite of ZFS would have some risk associated with it given Oracle's history. I'd ask "How?", but it'd be another torrent of "What if..."s. [0]: https://youtu.be/PFMPjt_RgXA?t=2260 https://youtu.be/PFMPjt_RgXA?t=2260
        deleted 3y ago
        [deleted]
        wtallis 3y ago
        I said that what matters is not the law, to which you responded by doubling down on your argument about what the law says, accused me of disagreeing with you on an issue I did not take a position on, and then went for the personal attacks. In case my lawnmower reference confused you enough that you were unable to make an appropriate response to the point I actually made, I'll try to state it a bit more clearly: It does not matter how confident you are that Oracle would eventually lose a lawsuit over using or distributing ZFS with the Linux kernel. If Oracle decides to attempt to exert control over ZFS and interfere with the use or distribution of ZFS with Linux, they have ample resources to make a lot of very expensive trouble for various users and organizations. Oracle's history—most importantly, their history vs Google re Java in Android—means it would not be much of a stretch for them to decide to start behaving like The SCO Group. I do not think this risk is large. But I do think it is a real risk that a cautious Linux distro can reasonably be worried about. If you truly believe that Oracle's lack of action thus far against ZFS on Linux and their public statements of their beliefs about the effects of the CDDL and GPL would prevent them from starting shit, then you are simply wrong about how our legal system works, and there are plenty of examples. The things you point to to bolster your arguments about what the law says are things that would make it hard for Oracle to win a lawsuit on its merits, but the eventual judgement is hardly the only thing that matters when assessing a legal risk—especially if your pockets are not as deep as Oracle's.
vladvasiliu 3y ago
In addition to what mustache_kimono said, there apparently seem to be issues with kernel functions moving / changing and breaking ZFS which then needs a while to catch up. For the latest reoccurrence of this, see https://github.com/openzfs/zfs/pull/15931 https://github.com/openzfs/zfs/pull/15931 for Linux 6.8 compatibility. There's also the fact that not everything is OOB compatible with ZFS. For example, newer versions of systemd have been able to use the TPM to unlock drives encrypted with LUKS. AFAIK it doesn't work with ZFS. I use ZFS on my daily driver Linux box and mostly love it, but as long as these things happen, I can see why people may want to try to find an in-kernel solution. I personally use Arch so expect for bleeding edge updates to not work perfectly right away. But I recall seeing folks complaining about issues on Fedora, too, which I expect to be a bit more conservative than Arch.
- didntcheck 3y ago
  LUKS and the associated systemd hook shouldn't care about the filesystem, right? It's just block layer But presumably you meant native ZFS encryption, which unfortunately is considered to be somewhat experimental and neglected, as I understand. Which surprised me, since I thought data at rest encryption would be pretty important for an "enterprise" filesystem Still, apparently lots of people successfully run ZFS on LUKS. It does mean you don't get zero-trust zfs send backups, but apparently that's where a lot of the bugs have been anyway
  - vladvasiliu 3y ago
    Yes, I was talking about ZFS native encryption. > But presumably you meant native ZFS encryption, which unfortunately is considered to be somewhat experimental and neglected, as I understand. Which surprised me, since I thought data at rest encryption would be pretty important for an "enterprise" filesystem. Yeah, I've happened about someone saying something similar, but I've never seen anything about that from "official" sources. Wouldn't mind a link or something if you have one on hand. But there is the fact that this encryption scheme seems limited when compared to LUKS: there's no support for multiple passphrases or using anything more convenient, like say, a U2F token. > Still, apparently lots of people successfully run ZFS on LUKS. It does mean you don't get zero-trust zfs send backups, but apparently that's where a lot of the bugs have been anyway I'd say I'm one of those people, never had any issue with this in ~ten years of use. And, indeed, the main reason for using this on my laptop is being able to send the snapshots around without having to deal with another tool for managing encryption. Also, on my servers on which I run RAIDZ, having to configure LUKS on top of each drive is a PITA.

GPL only forbids ZFS to be distributed alongside Linux, it doesn't prevent users from installing it manually. (IANAL)

by maxloh 3y ago

GPL only forbids ZFS to be distributed alongside Linux, it doesn't prevent users from installing it manually. (IANAL)

deleted 3y ago

[deleted]

mustache_kimono 3y ago

> GPL only forbids ZFS to be distributed alongside Linux But does it even do that? You might be surprised when/if you read a little more widely. Position of OpenZFS project[0] is which I find persuasive (my emphasis added): In the case of the Linux Kernel, this prevents us from distributing OpenZFS as part of the Linux 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. [0]: https://openzfs.github.io/openzfs-docs/License.html https://openzfs.github.io/openzfs-docs/License.html You might see also: [1]: https://www.networkworld.com/article/836039/smb-encouraging-closed-source-modules-part-1-copyright-and-software.html https://www.networkworld.com/article/836039/smb-encouraging-... [2]: https://law.resource.org/pub/us/case/reporter/F2/977/977.F2d.1510.92-15655.html https://law.resource.org/pub/us/case/reporter/F2/977/977.F2d...

lmz 3y ago
It doesn't matter what the project thinks as long as there is code owned by Oracle in the FS.
- mustache_kimono 3y ago
  > It doesn't matter what the project thinks as long as there is code owned by Oracle in the FS. Might we agree then that the only thing that really matters is the law? And we should ignore other opinions coughlike from the FSF/the SFCcough which don't make reference to the law? Or which ignore long held copyright law principles, like fair use? Please take a look at the case law. The so far theoretical claim of OpenZFS/Linux incompatibility is especially weak re: a binary kernel module.
  - wtallis 3y ago
    What matters in practice isn't the law, but how much trouble Oracle could cause should the lawnmower veer in that direction. Even a complete rewrite of ZFS would have some risk associated with it given Oracle's history.
    - mustache_kimono 3y ago
      > What matters in practice isn't the law, but how much trouble Oracle could cause should the lawnmower veer in that direction. Veer in what direction? The current state of affairs re: Canonical and Oracle is a ZFS binary kernel module shipped with the Linux kernel. Canonical has literally done the thing that which you are speculating is impermissible. And, for 8 years, Oracle has done nothing. Oracle's attorneys have even publicly disagreed with the SFC that a ZFS binary kernel module violates the GPL or the CDDL.[0] Given this state of affairs, the level of legal certainty re: this question is far greater than the legal certainty we have re: pretty much any other open IP question in tech. What matters is practice, is that you stop your/the SFC's/the FSF's torrent of FUD. > Even a complete rewrite of ZFS would have some risk associated with it given Oracle's history. I'd ask "How?", but it'd be another torrent of "What if..."s. [0]: https://youtu.be/PFMPjt_RgXA?t=2260 https://youtu.be/PFMPjt_RgXA?t=2260
      - deleted 3y ago
        [deleted]
      - wtallis 3y ago
        I said that what matters is not the law, to which you responded by doubling down on your argument about what the law says, accused me of disagreeing with you on an issue I did not take a position on, and then went for the personal attacks. In case my lawnmower reference confused you enough that you were unable to make an appropriate response to the point I actually made, I'll try to state it a bit more clearly: It does not matter how confident you are that Oracle would eventually lose a lawsuit over using or distributing ZFS with the Linux kernel. If Oracle decides to attempt to exert control over ZFS and interfere with the use or distribution of ZFS with Linux, they have ample resources to make a lot of very expensive trouble for various users and organizations. Oracle's history—most importantly, their history vs Google re Java in Android—means it would not be much of a stretch for them to decide to start behaving like The SCO Group. I do not think this risk is large. But I do think it is a real risk that a cautious Linux distro can reasonably be worried about. If you truly believe that Oracle's lack of action thus far against ZFS on Linux and their public statements of their beliefs about the effects of the CDDL and GPL would prevent them from starting shit, then you are simply wrong about how our legal system works, and there are plenty of examples. The things you point to to bolster your arguments about what the law says are things that would make it hard for Oracle to win a lawsuit on its merits, but the eventual judgement is hardly the only thing that matters when assessing a legal risk—especially if your pockets are not as deep as Oracle's.

vladvasiliu 3y ago

In addition to what mustache_kimono said, there apparently seem to be issues with kernel functions moving / changing and breaking ZFS which then needs a while to catch up. For the latest reoccurrence of this, see https://github.com/openzfs/zfs/pull/15931 https://github.com/openzfs/zfs/pull/15931 for Linux 6.8 compatibility. There's also the fact that not everything is OOB compatible with ZFS. For example, newer versions of systemd have been able to use the TPM to unlock drives encrypted with LUKS. AFAIK it doesn't work with ZFS. I use ZFS on my daily driver Linux box and mostly love it, but as long as these things happen, I can see why people may want to try to find an in-kernel solution. I personally use Arch so expect for bleeding edge updates to not work perfectly right away. But I recall seeing folks complaining about issues on Fedora, too, which I expect to be a bit more conservative than Arch.

didntcheck 3y ago
LUKS and the associated systemd hook shouldn't care about the filesystem, right? It's just block layer But presumably you meant native ZFS encryption, which unfortunately is considered to be somewhat experimental and neglected, as I understand. Which surprised me, since I thought data at rest encryption would be pretty important for an "enterprise" filesystem Still, apparently lots of people successfully run ZFS on LUKS. It does mean you don't get zero-trust zfs send backups, but apparently that's where a lot of the bugs have been anyway
- vladvasiliu 3y ago
  Yes, I was talking about ZFS native encryption. > But presumably you meant native ZFS encryption, which unfortunately is considered to be somewhat experimental and neglected, as I understand. Which surprised me, since I thought data at rest encryption would be pretty important for an "enterprise" filesystem. Yeah, I've happened about someone saying something similar, but I've never seen anything about that from "official" sources. Wouldn't mind a link or something if you have one on hand. But there is the fact that this encryption scheme seems limited when compared to LUKS: there's no support for multiple passphrases or using anything more convenient, like say, a U2F token. > Still, apparently lots of people successfully run ZFS on LUKS. It does mean you don't get zero-trust zfs send backups, but apparently that's where a lot of the bugs have been anyway I'd say I'm one of those people, never had any issue with this in ~ten years of use. And, indeed, the main reason for using this on my laptop is being able to send the snapshots around without having to deal with another tool for managing encryption. Also, on my servers on which I run RAIDZ, having to configure LUKS on top of each drive is a PITA.