Bug 466379

I have done a Koji build at

http://koji.fedoraproject.org/koji/taskinfo?taskID=872167

We need a legal review here to check for potential licensing incompatibility and patent issues. Blocking FE-Legal

Since I work at Sun, I can try to mediate this issue. The word I'm getting here is that Sun uses patents defensively only (on patent claims against Sun products). Sun would never do patent claims against Linux. ZFS has porting and integration effort in Mac OS X and Windows, and there is no patent agreement between the parties because it is not necessary if you're reusing Sun's work under the terms of the code license, not "reimplementing" ZFS or a different filesystem that's very similar to ZFS...

If you have more specific questions, I can track down an authoritative answer from the powers-that-be over here.

So, what would be very useful from Sun is some sort of explicit patent grant, rather than some handwaving about how Sun "would never" do things. If Sun were to hit hard times in a year, sell all the ZFS patents to someone else, who then sues Fedora for patent infringement, we're screwed, but if we have an irrevocable patent grant from Sun, we're covered.

I'm being told to look at the patent CDDL FAQ:

Q. What does the CDDL say about patents?

The CDDL provides an explicit patent license for code released under the license. This means that you can use, modify, and redistribute code released under CDDL without worrying about any patents that the contributors of the code (including Sun) might have on the contributed technology. The license also includes a provision to discourage patent litigation against developers by revoking the rights to the code for anyone initiating a patent claim against a developer regarding code they have contributed.

I exchanged emails with Sun's Open Source Community Manager and Sun's Open Source Chief Officer (Simon Phipps). The message I got from them is very clear:

- Sun would love to see fuse-zfs being added to the Fedora distribution

- There should be *no* legal issues, neither license nor patents related, that should block the review and acceptance of this package in Fedora.


To be more precise:

1) There are no license issues between Fuse-ZFS and ZFS itself. http://fuse.sourceforge.net/wiki/index.php/FAQ#Under_what_conditions_may_I_distribute_a_filesystem_which_uses_libfusex3f

2) Fuse-ZFS has no patent issues in regards to ZFS.

Fuse-ZFS is CDDL, and as such receives all the patent protection that CDDL grants. This is explicit in the CDDL license, 2.1.b and 2.2.b (http://www.sun.com/cddl/cddl.html). The patent protection applies to ZFS modifications and derivative works as well. This means that Fuse-ZFS can be modified, can be redistributed, or even forked for that matter. As long as the modifications are made public, just as with the GPL.

CDDL as a patent grant is fine. Lifting FE-Legal.

Denis Leroy - Thanks for taking the time to address some of the concerns.

Spot - Have you confirmed that the license incompatibility between CDDL and GPL does not affect us here?

I am concerned that we are setting precedent for vendors to create proprietary drivers that use the fuse interface to bypass GPL requirements.

The fuse libraries are LGPLv2+, so there should not be any license compatibility concerns.

(In reply to comment #8)

> I am concerned that we are setting precedent for vendors to create proprietary
> drivers that use the fuse interface to bypass GPL requirements.

Yes, well, I'm not a big fan of this move either. I wish Sun would learn to play nice with the Linux kernel, but I'll just have to add this to my long list of "someday" items. There's no legal barrier here.

To be clear, I am not talking about the FUSE library itself but the actual kernel module that sits on top of the library. That module itself is under CDDL since this is not a rewrite but a port of the original codebase. GPLv2 and CDDL are incompatible. I don't think sticking a LGPL library in-between otherwise incompatibly licensed code bases would free them of the requirements of one of the licenses. I would like Red Hat Legal to confirm this. Have they?

> but the actual kernel module that sits on top of the library

Rahul, you're misunderstanding the situation. There is no kernel module sitting on top of FUSE. This is a user-space library.

Also your comment #8 seems to imply you consider ZFS to be a "proprietary" driver. This is simply not true. CDDL is a free and open-source license.

Let's not argue about terminology. Call it whatever you want, my main point is this: There is CDDL licensed codebase (zfs) using the LGPL'ed libraries (fuse) which in turn uses a GPL'ed licensed codebase (ie) the Linux kernel. 

If the CDDL/GPL incompatibility can be bypassed by sticking a LGPL'ed library in between, we are setting precedent for others to do the same thing including proprietary kernel drivers. No, that does not imply ZFS is proprietary. I am very well aware that is it under a free and open source but GPL incompatible license aka CDDL.

Well, there is a kernel module in this stack:

/lib/modules/2.6.27.4-61.fc10.x86_64/kernel/fs/fuse/fuse.ko

Sun is clearly working around the incompatibility between CDDL and GPL (one they explicitly created), but circumventing license incompatibility like this is not forbidden, in fact, it is almost certainly the main reason why the Fuse userspace is not GPL. In fact, they explicitly permit the scenario that Rahul is so concerned about in Comment #13: http://fuse.sourceforge.net/wiki/index.php/FAQ#Under_what_conditions_may_I_modify_or_distribute_FUSEx3f.

There was never any requirement that any userspace code that leverages kernel code be compatible with the kernel license, for anything, otherwise, we'd have nothing but GPL compatible userspace. If it linked to GPL code, this would be a different scenario, but it does not.

Nevertheless, I bounced this issue to RH Legal to get their feedback.

Rahul, your reasoning is not correct. There's a difference between "using" and "linked with". If the fuse user-space libraries were "linked" with the fuse kernel module (assuming this were technical possible, which it is not), your reasoning would be correct. Except they are not. The fuse user-space library interacts with the fuse kernel module, in much the same way all user-space components interact with kernel components, like NetworkManager interacts with wireless drivers for example.

Derivative work is not merely confined to "linking" and IMO, there is a difference between a ported kernel module and other user-space applications regardless of anything in between like the stubs that Nvidia proprietary driver uses or others using fuse libraries. Anyway, there is no pointing in us arguing about it. I have expressed my concern and I will defer to Red Hat Legal who has the final say in this matter.

Uwe, some initial comments.

First of all, this looks very good. You did a thorough job following the Fedora guidelines.

- I wish the package were called "fuse-zfs" to be more similar with existing fuse packages, but in the absence of Fuse-specific package guidelines, it probably makes more sense to follow the upstream name for now...

- Are you sure about the ppc* ExcludeArch's ? Existing fuse packages don't do it. Did you run into ppc-specific build issues ?

- I wouldn't package the contrib init file, since you provide your own LSB-compliant one.

(In reply to comment #14)

> Nevertheless, I bounced this issue to RH Legal to get their feedback.

RH Legal confirms that this is not a problem.

I have talked to the upstream project, and renaming the upstream project seems unlikely, but they encourage us to rename our package if it makes a positive difference.  I'll keep the name until there is a Fuse naming guideline.  OK?

Regarding the ExcludeArch's I got this from upstream:

"Yes, zfs-fuse doesn't have PPC and PPC64 implementations for atomic
instructions, hence it won't build on those architectures. It will only
build on x86, x86-64 and sparc64 at the moment."

I'll look at removing the contrib init file.

But really, the package is good to go?

I'll do the formal review within the next couple of days. The package will be officially reviewed and accepted when I set the "fedora-review" flag to "+".

MUST item:

- rpmlint output OK (init incoherent-subsys warning is a false positive)
- name is according to guidelines
- spec file name is ok
- package meets packaging guidelines
- license is CDDL
- spec file is legible
- source URL following svn snapshot guidelines
- compile and builds
- builds in mock
- ldconfig called property
- owns all directories
- no duplicates
- file props ok
- clean section cleans buildroot
- no libraries, header fiels or GUI apps
- no ownership conflicts
- filenames are UTF-8
- ppc Archexclude ok, not supported by upstream


Package is APPROVED.

(please remove contrib directory as mentioned in comment #17).


Uwe, you should now go into https://admin.fedoraproject.org/accounts/ and create yourself an account.

Oops sorry, incorrectly set the flag, not sure how that happened...

New Package CVS Request
=======================
Package Name: zfs-fuse
Short Description: ZFS is an advanced modern general-purpose filesystem from Sun
Microsystems, originally designed for Solaris/OpenSolaris.
Owners: donv
Branches: F-10
InitialCC:

I don't see donv in the packager group. 

Denis: Do you intend to sponsor them?
Please reset the cvs flag once they are sponsored.

Kevin, yes I sponsored him.

cvs done.

Uwe, now that the package was pushed to the testing repo, you should close this ticket. Thanks!

Package Change Request
======================
Package Name: zfs-fuse
New Branches: F-12 EL-5
Owners: donv

There's already an F-12 branch for this package; I'm not sure why it's being requested here.  Make sure you do "cvs update -d" to get any newly created directories when you update.

I've made the EL-5 branch.

I forgot the -d option on cvs update...

Thank you for the EPEL-5 branch.