Ubuntu Is Planning To Make The ZFS File-System A "Standard" Offering

[phoronix]

Phoronix: Ubuntu Is Planning To Make The ZFS File-System A "Standard" Offering

While the ZFS file-system isn't supported by the mainline Linux kernel due to the Oracle-owned file-system being under the GPL-incompatible CDDL license, Canonical is making plans to offer ZFS on Ubuntu in some standard way...

http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-ZFS-Standard-Plans

[ryao]

Michael's prediction that 15.10 will use a DKMS package is likely correct, but that is for technical reasons that should be resolved by 16.04 rather than legal reasons as Michael suggests. Specifically, a DKMS package should be planned for ease of initial integration and is a good idea because the /dev/zfs ioctl interface is not officially stable yet. Canonical would have no technical blocker against putting ZoL into their kernel source tree like Sabayon did once those issues are resolved.

That said, there is no legal issue preventing the sources from being combined because neither the CDDL nor the GPL place restrictions on aggregations of source code, which is what putting ZFS into the same tree as Linux would be. Binary modules built from such a tree could be distributed with the kernel's GPL modules under what the GPL considers to be an aggregate. These concepts have passed legal review by many parties.

As for actually putting ZFS into Linus' tree (mainline), neither Linus nor the ZoL developers are fans of the idea. Being tightly coupled to the kernel would mean bug reports from ancient versions on enterprise systems because backporting is up to the distribution developers and they do not do it very often. That is a situation that the ZoL project would prefer to avoid. I expect that we will be able to avoid this in Ubuntu through micro-releases under the Stable Release Update policy:

https://wiki.ubuntu.com/StableReleaseUpdates

As for Linus, he is not interested in having CDDL code in his tree, which is okay and works out better for everyone in this instance.

[unixfan2001]

That toxic license is, once again, making things more complicated for everyone involved.
Here's hoping someone will eventually beat the FSF/RMS in court, turning their overly complicated (it has more in common with corporate EULAs/TOS' than most liberal open source licenses), lawyer-speak of a license agreement into finely grained dust.

ryao

Is the following chart no longer correct?

I assumed that since CDDL based code is usually retaining its license that it could not be merged into a GPL codebase.

https://lh5.googleusercontent.com/_M4tgZoR5nPA/TU7LriFAXsI/AAAAAAAAG7s/CkqNQVYF2t8/s800/copyrights-patents-licenses.png

[ryao]

That toxic license is, once again, making things more complicated for everyone involved.
Here's hoping someone will eventually beat the FSF/RMS in court, turning their overly complicated (it has more in common with corporate EULAs/TOS' than most liberal open source licenses), lawyer-speak of a license agreement into finely grained dust.

ryao

Is the following chart no longer correct?

I assumed that since CDDL based code is usually retaining its license that it could not be merged into a GPL codebase.

https://lh5.googleusercontent.com/_M...s-licenses.png

Strictly speaking, that was never correct from what I know from speaking to lawyers. You must only put things under GPL-compatible licenses when they are derived works of GPL code. Since ZFS is from OpenSolaris, a port of ZFS to Linux is not a derived work of GPL code in the legal sense and it is therefore not subject to that restriction.

That said, that chart is correct (with the adjustment that it must be under a GPL-compatible license) in almost all cases involving binary copies of GPL code. Ports of software from other platforms are the main area where that is not the case.

[ElectricPrism]

What's interesting is that a project like WordPress claims that all plugins and extensions are subject to the oppression of the GPL - so strictly speaking, all paid plugins are technically illegal. Yet morally, those plugins are not derivative works even though they include various hooks into the WP system, etc... as WordPress operates in source form at run-time and not binary.

It seems to be a common misconception that the GPL is a liberal license - the reality is the exact opposite. Like a cancer it requires all derivatives and anything that interacting on a non-binary level to adopt its oversight. This is fantastic for users, but not for developers or commercial interests. MIT or BSD or even the WTFPL are truly liberal. That said, I myself have contributed GPL code and I believe there's a time and place for it.

My understanding is the only barrier that separates it is using say a compiled GPL Library (SDL2) and your access is limited to DLL calls so that the GPL object is a seperate library and not an extension of a GPL product. Of course, it's like FSF throwing sh1t at a wall - you make the most outrageous claims you can and see what sticks to the wall in court (this is an American Law thing unfortunately.)

As someone using BTRFS - I really don't see the benefits of ZFS over the former other than advertising a draw for unintelligable corporate contacts who are hooked on the technology.

[johnc]

I've been wanting to build a ZFS-based NAS for awhile now, and never really did settle on an OS. At this point I might as well just go with Linux.

[andre30correia]

What's interesting is that a project like WordPress claims that all plugins and extensions are subject to the oppression of the GPL - so strictly speaking, all paid plugins are technically illegal. Yet morally, those plugins are not derivative works even though they include various hooks into the WP system, etc... as WordPress operates in source form at run-time and not binary.

It seems to be a common misconception that the GPL is a liberal license - the reality is the exact opposite. Like a cancer it requires all derivatives and anything that interacting on a non-binary level to adopt its oversight. This is fantastic for users, but not for developers or commercial interests. MIT or BSD or even the WTFPL are truly liberal. That said, I myself have contributed GPL code and I believe there's a time and place for it.

My understanding is the only barrier that separates it is using say a compiled GPL Library (SDL2) and your access is limited to DLL calls so that the GPL object is a seperate library and not an extension of a GPL product. Of course, it's like FSF throwing sh1t at a wall - you make the most outrageous claims you can and see what sticks to the wall in court (this is an American Law thing unfortunately.)

As someone using BTRFS - I really don't see the benefits of ZFS over the former other than advertising a draw for unintelligable corporate contacts who are hooked on the technology.

one good reason to use ZFS?

[ryao]

What's interesting is that a project like WordPress claims that all plugins and extensions are subject to the oppression of the GPL - so strictly speaking, all paid plugins are technically illegal. Yet morally, those plugins are not derivative works even though they include various hooks into the WP system, etc... as WordPress operates in source form at run-time and not binary.

That is a different situation unless you are talking about plugins that were made for something other than wordpress and then were somehow later ported to WordPress.

My understanding is the only barrier that separates it is using say a compiled GPL Library (SDL2) and your access is limited to DLL calls so that the GPL object is a seperate library and not an extension of a GPL product. Of course, it's like FSF throwing sh1t at a wall - you make the most outrageous claims you can and see what sticks to the wall in court (this is an American Law thing unfortunately.)

If you think that the GPL applies to things are not derived works, your understanding of the GPL is wrong. I suggest that you read the GPLv2, which is the relevant version. It is quite clear that it only requires GPL-compatible licensing for derived works. To give a small excerpt:

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

...

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

https://www.gnu.org/licenses/old-lic...pl-2.0.en.html

If what I am saying is not clear to you after reading the GPLv2, I suggest getting a lawyer to go over it with you.

As someone using BTRFS - I really don't see the benefits of ZFS over the former other than advertising a draw for unintelligable corporate contacts who are hooked on the technology.

If you are talking about Oracle, btrfs is probably a larger advertisement for them than ZFS given that btrfs was invented by an Oracle engineer. Oracle has has far less to do with ZFS than btrfs.

[p91paul]

Strictly speaking, that was never correct from what I know from speaking to lawyers. You must only put things under GPL-compatible licenses when they are derived works of GPL code. Since ZFS is from OpenSolaris, a port of ZFS to Linux is not a derived work of GPL code in the legal sense and it is therefore not subject to that restriction.

That said, that chart is correct (with the adjustment that it must be under a GPL-compatible license) in almost all cases involving binary copies of GPL code. Ports of software from other platforms are the main area where that is not the case.

That chart is correct without adjustments: derived works of GPL code must be released under the GPL, not under a GPL-compatible license, as the GPL licence states in section 5:

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
...
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.
....

From my understanding, the GPL allows to distribute "the modifications to produce it from the Program" under a GPL-compatible license, since those modifications are your own copyright; however, the whole derived work (the program + the modifications) must be under the GPL, as reads the above quote. The point of GPL-compatible licenses is that you can combine a GPL-compatible work and a GPL work, and release the combination as GPL code. If the work you want to combine is GPL-incompatible, then you can't combine it with GPL code, under no license. Compatible does not mean that GPL code can be redistributed with a BSD license (as an example).

However, as you said, GPL makes an exception for aggregates, which could be used to aggregate Linux and ZFS in a single codebase. I would never do that, since it is an "aggregate" if non-GPL parts "are not combined with it [the GPL program] such as to form a larger program", and I would have serious doubts if Linux with ZFS included could be considered a single larger program, instead of two programs. I mean, it makes sense, but I believe the choice from both sides not to merge them is a good one.

[p91paul]

My understanding is the only barrier that separates it is using say a compiled GPL Library (SDL2) and your access is limited to DLL calls so that the GPL object is a seperate library and not an extension of a GPL product. Of course, it's like FSF throwing sh1t at a wall - you make the most outrageous claims you can and see what sticks to the wall in court (this is an American Law thing unfortunately.).

The GPL does not allow you to distribute a GPL library together with non GPL-code using it: in that case, the parts are combined to form a larger program, a single work; as such, the whole must be licensed under the GPL.

You can still license your work under any license of your choice, demanding the user to separately obtain the library. GPL is strict in terms of redistribution: copyright law reserves all rights to the author, so there is nothing except the license itself allows you to redistribute the code, so any requirement it poses on redistribution is valid.

The main difference from EULAs and GPL is not in the complexity, and should not be; it is all about freedom of the code and the user (not freedom of the corporation who wants to turn it into a product). GPL states that you are not required to accept the license to use the software. States that you, as an user, must be able to get the source code, and that you can modify and run it in every way you can possibly imagine. But it requires you, if you produce a work based on the software and you want to redistribute it, to keep the same license.

The FSF and Stallman explicitly stated that using more permissive licenses might get a broader diffusion for your work. But people throwing hate to the FSF, to RMS and to anyone releasing GPL code must remember that the fact that companies cannot make money embedding GPL code in their commercial non-free products (which is the only big issue with GPL and other copyleft licenses) is not a concern for the author. If the author wants anyone who obtains a copy of his software to be able to get and modify the source, GPL is the right choice: a BSD/Apache/MIT/whateveriscoolforcompaniesnowadays license means the user might obtain from someone a modified version of the software without any option to receive the corresponding source code. GPL, like any other license, is the expression of the will of the author, which, unless it is paid for his work, has no obligations towards anyone.

If you dislike GPL, there are entire operating systems with many applications under different licenses, a popular example is called Windows and is produced by a firm called Microsoft. They don't use GPL. Good luck with your freedom there.