FreeBSD/Linux License Differences Concerning ZFS

L

lubos

Hello,

I have been reading an article about ZFS saying that GNU license is not compatible with the ZFS' one, contrary to FreeBSD's license. Could someone involved briefly explain the license differences enabling/disabling inclusion of ZFS? I am just curious.

Thank you in advance,

Lubos
 
How I understand is that the way ZFS is licensed now allows you to create your own closed source proprietary (for example) NAS software that uses FreeBSD and ZFS as building blocks. You would have to recognize the copyrights of FreeBSD and ZFS but you wouldn't be obliged to publish the source code for your own proprietary software components and you could keep those bits as closed source.

If ZFS was GNU GPL licensed everything you use it for would become subject to the redistribution clauses of the license requiring you to publish the full source code including your own proprietary code.

Then there's of course the question if CDDL licensed code can be included in a GPL licensed system without a conflict, I don't have a good answer for that :p
 
lubos said:
I have been reading an article about ZFS saying that GNU license is not compatible with the ZFS' one
Click to expand...
True.

lubos said:
Could someone involved briefly explain the license differences enabling/disabling inclusion of ZFS? I am just curious.
Click to expand...
The 'code linking' clause in the GPL2 license, every piece of code that You want to link GPL2 with also MUST be under GPL2.

LGPL2 does not have that limitation (linking clause), but Linux kernel is GPL2, not LGPL2 ... and GPL2 is incompatible with LGPL2 if that helps ;)
 
Please note that there is also an implementation of ZFS for linux (apart the FUSE one). The idea is to build a kernel module under the CDDL and not to ship that as part of the linux kernel (see the FAQ).
 
THe bigger problem with ZFS on Linux imho, is the NIH (Not Invented Here) syndrome that is so chronic in Linux.

It wasn't developed originally as GPL, and thus the Linux guys need to reinvent the wheel. See: DTRACE, ZFS, etc.

For what its worth (from what I've read), the Sun developers of ZFS appear to believe there's nothing in the CDDL itself that would prevent inclusion in Linux.


If the GPLv2 is so stringent on linking (only link to GPL code) then surely this would also preclude the operation of non-GPL binaries on Linux as well?

The Linux guys appear to have no problem linking to binary blobs for Nvidia driver support?
 
throAU said:
If the GPLv2 is so stringent on linking (only link to GPL code) then surely this would also preclude the operation of non-GPL binaries on Linux as well?

The Linux guys appear to have no problem linking to binary blobs for Nvidia driver support?
Click to expand...

Uhm...modules that are not gpl compliant have a minimal access to the system internals, that is how Linux enforces the use of the license in which its developers believe.
 
I may be wrong on this one; but, it may be the GPLv3 that has the code linking clause.
The Linux kernel remains under the GPLv2 for this reason.

Simplest explanation of license difference are:
  1. GPL licenses are more detailed.
  2. BSD licensing requires giving credit to UCBerkely/FreeBSD foundation.
  3. BSD licenses are more permissive, allowing the recipient the option of contributing back.
  4. GPL licensing is geared towards keeping changes transparent.

There are exceptions in practice to theses rules such as:
  1. The BSD flavors letting others see changes in code; this is practiced the most by OPenBSD followed by FreeBSD, and the NetBSD. (If I am wrong on this, someone please correct this post.)
  2. Mention of Stallman and others allowing companies to link/ certain exceptions. ( Again as before, feel free to correct this statement if it is not true.)
 
And what exactly are you pointing me to in that FAQ?

@phoenix beaten to it while typing...

I don't see much in 1.11. I read it but I'm still not sure what the problem is with policies.
 
Read the last line in the list, which is specifically about ZFS. Then click the link to "policy" and read them. :)
 
fluca1978 said:
Uhm...modules that are not gpl compliant have a minimal access to the system internals, that is how Linux enforces the use of the license in which its developers believe.
Click to expand...

"Minimal access" is still linking to GPL code.


Telling Nvidia to get stuffed doesn't suit the 3d desktop crowd, but ZFS isn't sexy for the general public, so people use it as a scapegoat.

As far as I've seen, the Linux kernel is still GPLv2 because changing it would require consent of all who have committed code to it. And some of them are dead.
 
NVIDIA's 3D drivers aren't part of the Linux kernel. They're third-party drivers which can be loaded into memory later. The GPL doesn't have anything to say about that.

Much in the same way a ZFS module can be created which, if shipped independently, can be loaded into the Linux kernel as needed. The ZFS code just can't be included in the Linux kernel source tree due to the licensing conflict. This means we won't see a "native" ZFS implementation in Linux, but we could see ZFS modules provided by various distributions if someone is willing to maintain a ZFS module.
 
throAU said:
"Minimal access" is still linking to GPL code.


Telling Nvidia to get stuffed doesn't suit the 3d desktop crowd, but ZFS isn't sexy for the general public, so people use it as a scapegoat.
Click to expand...

Beside minimal access, modules is the solution for not gpl code. Modules are not subject to be released with the source code, and therefore are not going to be always distributed as part of the official kernel. This is also why most distributions today ask the user to allow third part software to be installed from proprietary places.

I think this way of working is at least coherent, as well as OpenBSD way is (even if more restrictive) and FreeBSD is too. They are looking at the problem from different angles.
 
You must log in or register to reply here.
Back
Top