Bcachefs also has plenty of features which ZFS does not.
Only because I've read this story more than a few times before? See: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
>Oracle could relicense ZFS at any time, or make an explicit statement about its legal status. They have not done so after 10 years.
Any legal difficulty remains from the GPL side, and no suit has been brought in the years upon years of the GPL hair shirts screaming about non-compliance. Unfortunately, the GPL hair shirts don't have much (any) credibility on the subject of what the GPL means.
Bring the suit or STFU. I have no patience for armchair legal opinions from people who won't put their money where their mouth is. Stop spreading legal FUD!
Sorry, if we are looking at the same thing, the earliest time of a HN entry of bcachefs trying to be merged upstream was not even 1 month ago. All the other entries are related to features that are called "merge" and not actual merge requests or the author declaring that the code was up to be merged but not an actual merge request.
1 month ago is nothing in terms of kernel time, so I don't think your argument holds up.
The article also makes it clear that it's not ready. And for a big patch like this, you're going to "start talking" long before actually submitting.
The only thing that supports your point is the incorrect title that was submitted to HN. But this submission got 6 upvotes and 0 comments, so almost nobody saw this title.
> Notably, Oracle does not include ZFS with Oracle Linux. As I said, they could easily clear this up, but they haven't.
> Oracle could relicense ZFS at any time, or make an explicit statement about its legal status. They have not done so after 10 years.
That would make this easy, but unfortunately easy is not the case we have here. Just as RH has chosen strict compliance with the GPL re RHEL, I think strict compliance with the GPLv2 is what is required here. Someone, I wish it was RH, should say "We've made a mistake. The GPL is not a suicide pact." For instance, interpreting any object which dynamically links to a GPL licensed work as a derived work is fundamentally anti-business, anti-interoperability, and, I'd argue, anti-FOSS. Being GPL compliant does not mean blithely accepting whatever legal claptrap FSF and SFC can summon.
Frankly, it is more likely, distributions will add/ solidify infrastructure for making OpenZFS really hassle-free and well integrated and cloud/ VPS providers will have alternative images built with Root-on-ZFS. Until then, it is not that hard to convert a VM from EXT4 to OpenZFS or to build your own image. Shameless plug, I have done a video about a procedure how to convert EXT4 to OpenZFS from within the VM: https://www.youtube.com/watch?v=KoRVFRufZI0 Or you can just open the notes and copy&paste from there: https://github.com/KaliszAd/ext4-to-zfs-conversion
> And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd.
> Other people think it can be ok to merge ZFS code into the kernel and that the module interface makes it ok, and that's their decision. But considering Oracle's litigious nature, and the questions over licensing, there's no way I can feel safe in ever doing so.
https://www.realworldtech.com/forum/?threadid=189711&curpost...
For me, ZFS beats other approaches with snapshots/ rollbacks and send/ receive. It really hits you, when you develop something using a database or a lot of files. If you want to test something, just do a snapshot (even without shutting down the database) and just try it out. If you mess up, you can at the very least shut the DB down, rollback (which is instant) and start the DB again. It will be in the state before you messed up. You can also make a clone and spin up another instance and compare. With files, you can even diff snapshots, so as to extract e.g. a deleted file. Also this is a great mitigation against ransomware, if your network drives are backed by ZFS. Also in the case of a database, compression and the integrity guarantees help a lot. You can do some tuning because of it that might make your performance better/ more consistent - because backups can get a lot more efficient and you can cache more data in RAM when it is compressed or buy better SSDs when they don't need to be that large. Now you can probably do something similar with btrfs, e.g. Turris Omnia is using btrfs internally and it saved me once while I was doing some broader reconfiguration. Otherwise, I don't know about it - it is probably reliable enough. You can do LVM snapshots. There are many approaches to solve a particular problem. ZFS was just designed to do some of these things and has about 15 years of production use in some of the most serious settings.
XFS or EXT4 is a decent choice for systems that you just don't want to think about. They are available by default, don't usually need any kind of tuning/ configuration. XFS is probably the better choice instead of EXT4, if you have a typical mdadm/ lvm RAID for e.g. surveillance camera recordings. For VMs that do some computation but the data is stored elsewhere, you can use the usually default EXT4 for the base filesystem. Converting such systems to ZFS might not be worth it. For the company database, filer, archive, backup ZFS should be something you evaluate as the first option. Just be sure you know a bit about how ZFS stores its data and how to configure the values for your use case. ZFS is more rigid in some places however extremely flexible in others be sure to understand where the rigid parts might be a problem to you.
I just want to pause for a moment to explain how unhinged this reply is. First, never said Linux (or Oracle for that matter) was operating in bad faith. Second, my comment calls ZFS a "hair shirt" for the kernel. A "hair shirt" is an uncomfortable undergarment which religious people/GPL fanatics use to punish themselves.
From: https://opensource.stackexchange.com/questions/2094/are-cddl...
> The CDDL is a license that does not try to enforce restrictions that would not stand in court but disallows relicensing of code. The fact that on the other side, the CDDL explicitly limits its scope to the files that contain CDDL'd code, allows us make our first conclusion:
> Code under the CDDL and code under the GPL cannot be mixed in a single file.
>The GPL is a license that limits its scope to the so called "work" limit and forbids relicensing of code. This allows us to make the next conclusion:
> Code under the CDDL and code under the GPL cannot be mixed in a single work.
So, that would seem to leave two options - either re-license Linux under a CDDL-compatible license or re-license ZFS under a GPL-compatible license. Clearly re-licensing ZFS would be much easier as it's controlled by a single entity - Oracle.
My opinion is that Oracle are acting in bad faith (probably a default assumption with Oracle to be fair) and deliberately don't want the code to be in Linux.
Oracle's ZFS code is controlled by a single entity, but OpenZFS (which is what you probably want) is a community fork with copyrights owned by a huge list of people and companies.
In hindsight, an explicit "GPL compatibility clause" like the EUPL has would clearly been a wiser choice, but that wasn't clear in 2005, and it's too late for that now, unfortunately.
On the other hand, you could also blame the GPL for not recognizing that other copyleft licenses exist; they also could have written a compatibility clause in GPL 3. "CDDL is incompatible with the GPL" could also be phrased as "GPL is incompatible with the CDDL".
Yes, I agree; there's a few other topics like this. I call this "hacker conspiracy theories", because at this point that's basically what they are.
I mostly comment on these things for the benefit of innocent onlookers, who were not yet around when all of this went down, and not to convince the person who posted it.
Popped onto DDG just now, and the explains right there. Also "cilice" within the first few links.
After my unexpected laughter, I had to click. The first 2 hits align with my prior misunderstanding - cue more laughter. One is a t-shirt with a graphic of a very hairy chest/abdomen, the other has the likeness of Chewbacca with "Messy hair / don't care".
No need for anyone else to see for yourselves; saved you a click.
There is a bunch of explanations and legal opinions here.
Oh? And let me tell you there is more than a boat load of lawyers who disagree.
See the links on page you linked to (!): http://www.networkworld.com/article/2301697/smb/encouraging-...
> There is a bunch of explanations and legal opinions here.
Did you read the text of that page or any of the linked articles? The OpenZFS position is clear: "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."
I guess that alone could be enough to come to the conclusion that it is not worth the trouble.
Linux had ~5 years to try and add ZFS before it was bought by Oracle, and did not do so. As much as Oracle is often the villain, I don't think they're what the Linux team fears here.
My current/primitive understanding:
* CDDL is 'BSD-like'- allowing the right for CDDL code to co-exist in perhaps proprietary/closed source codebase, so long as the CDDL parts remain CDDL. It does not make demands for non-CDDL parts, allowing dual-license scenarios?
* GPL demands all code in the same codebase are subject to GPL. e.g. This excludes a scenario where some parts are open source, and others proprietary/closed.
* All contributions to the Linux kernel are subject to GPL
* Say OpenZFS is merged into Linux, CDDL demands that OpenZFS parts remain CDDL?
Now the resulting codebase has more restrictions than the spirit of the CDDL allows for. Is this not a conflict?
If you could attempt to ELI5 how I'm potentially getting part of this wrong, or point me to some article, I'd appreciate it! I honestly find this stuff pretty confusing.
> CDDL is 'BSD-like'- allowing the right for CDDL code to co-exist in perhaps proprietary/closed source codebase, so long as the CDDL parts remain CDDL. It does not make demands for non-CDDL parts, allowing dual-license scenarios?
It's more like halfway between GPL and BSD. Importantly, BSD licenses impose sufficiently limited conditions that BSD code can be subject to GPL conditions at the same time without violating either license. CDDL makes mutually exclusive demands with GPL.
(But yes, CDDL does allow for mixed CDDL+proprietary systems; that's what it was created for. Sun wanted to open source Solaris, but needed to be able to keep some parts of it closed-source (because they didn't actually own all the code, having licensed some of it from third parties).)
> All contributions to the Linux kernel are subject to GPL
There's actually non-GPL code in there, but it's all under GPL compatible licenses, so the final result is GPL. But for instance, if someone wanted to put in the work and there was interest, you could almost certainly get HAMMER2 from dragonfly BSD included into Linux because it'll be under a BSD license that's GPL compatible.
> Now the resulting codebase has more restrictions than the spirit of the CDDL allows for. Is this not a conflict?
Yes, that's basically the conflict. Note that there is some difference of opinion on the situation; Canonical, for instance, seems to believe that they can ship ZFS kernel modules under the CDDL without making them part of the GPL kernel and thus not mix the licenses. Others say that compiling the ZFS modules against the kernel makes the result a derivative work of the kernel and therefore is a conflict. Until someone actually tries to file a lawsuit over it, I don't know that we definitively know.
Suffice to say: a shallow reading of the GPLv2 might lead one to believe that the CDDL and the GPLv2 are incompatible. And I believe SFC and FSF's readings of the GPLv2 and copyright law, which the GPL incorporates by reference, is shallow. There are quite a few reasons to believe a CDDL and ZFS combination would not be incompatible. If you want learned legal opinions expressing my/this contrary view there are a few. [0], [1], [2]. Moreover, I'd warn that SFC and FSF are not disinterested parties. They have agendas which extend beyond whether ZFS is actually incompatible to what that might mean for the GPL.
If you want my unschooled personal understanding -- most generally, there is no reason to believe that dynamic linking creates a derived work. Without further reasoning, FSF's analysis obliterates this boundary without reference to case law, and without an argument as why this must be the case. Whereas I think there are sound copyright law reasons to think where one creates an API boundary, through the use of dynamic linking or otherwise, fair use allows one make use of software at that boundary.
This is a difficult pill to swallow for many FOSS advocates because this would mean closed source software modules would be permissible in combination with the Linux kernel. And while I understand their political reasoning for disfavoring this view, I think their legal reasoning is weak. I also think the FSF view makes it much harder to build software which interoperates with other software.
I'm just not sure your copyright license has this kind of power. Imagine you build some software which links to MegaEvil Corp's libc, whose license specifically states, if you link to this libc, you forfeit all copyright to MegaEvil Corp. My feeling is any court would say building any such software at an API boundary is fair use and copyright law simply does not grant any court the power to enforce this copyright term.
More specifically re: ZFS module itself, I'd dig into what is a "derived work". The GPLv2 after all incorporates the copyright term by reference at Section 0 when describing a "work based on the Program". I'd consider the ambiguity of what is the "whole" work as described in Section 2 and how that might be construed in light of the long held copyright distinction between derived and combined works. I'd also consider recent copyright jurisprudence when asking whether any court would take the view that distributing the Linux kernel and ZFS module is a copyright violation. [3], [4].
[0]: https://softwarefreedom.org/resources/2016/linux-kernel-cddl... [1]: http://www.networkworld.com/article/2301697/smb/encouraging-... [2]: https://www.linuxjournal.com/article/6366 [3]: https://en.wikipedia.org/wiki/Sega_v._Accolade [4]: https://en.wikipedia.org/wiki/Lewis_Galoob_Toys,_Inc._v._Nin....
I've said it 1000x -- OpenZFS is already free and open source. Linux kernel developers should just stop punching themselves in face. The ZFS hair shirt is self imposed by semi-religious Linux wackadoos.
[0]: https://lore.kernel.org/lkml/20230626214656.hcp4puionmtoloat...