On Monday, June 29, 2020, John M. Harris Jr <johnmh@splentity.com> wrote:
On Monday, June 29, 2020 9:26:09 AM MST Matthew Miller wrote:
> On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote:
>
> > > We cannot include ZFS in Fedora for legal reasons. Additionally, ZFS is
> > > not really intended for the laptop use case.
> >
> > Has that actually been explored? How does Canonical get around the legal
> > issues with OpenZFS' licensing?
>
>
> I can't really speculate on Canonical's legal stance and I encourage
> everyone else to also not.
>
> I can point to Red Hat's, though: the knowledge base article here
> https://access.redhat.com/solutions/79633 says:
>
> * ZFS is not included in the upstream Linux kernel due to licensing
> reasons.

> * Red Hat applies the upstream first policy for kernel modules (including
>   filesystems). Without upstream presence, kernel modules like ZFS cannot
> be supported by Red Hat.
>
> and "due to licensing reasons" links to
> https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ which is quite
> interesting and quite long. If you have just time to read one section, the
> two paragraphs at the end under "Do Not Rely On This Document As Legal
> Advice" seem like the _most_ interesting to me.

I've both read that page, and linked to it further down in this thread. Yes, I
believe that Canonical's implementation is a GPL violation, but it doesn't
need to be. So long as the source is in a separate package, and it's packaged
as a kmod, it wouldn't be a GPL violation. It's worth considering, in my
opinion, whether or not it'd be available for RHEL. It wouldn't be the first
package RHEL doesn't have, but Fedora does. :)



That's not how the GPL work - using that argument you can link anything to a GPL only library as long as it is in a separate source tree (which is mostly the case).

It's either a derived work of the kernel and thus is bound by the GPL restrictions or it isn't. Does not matter in which tarball or rpm or $whatever it is in.