Licensing issues are always a big problem for any community, you can look at the whole tivoization debacle for an example in the linux community specifically. Changing a copyfree project to copyleft is a huge problem. Projects deliberately choose a license that works with their business model, An upside to the copyfree model is incorporating the code into a proprietary project without releasing the code. It is of course in the best interest of the one using the code to keep it in sync and submit their patches with the open source project for security and performance reasons. But they are not forced to do so.
I've only experienced "Linux zealotry" from Free Software Foundation types, and I make an effort to avoid them as well because I find it just as odious. However there's a massive chunk of Linux community who aren't interested in licensing debates and seemingly just want to get things done.
Case in point: I've been using various Linux and BSD distros off and on for about 15 years and have never experienced the zealotry you are referring to coming from the Linux side of the fence. Not saying it doesn't happen, but it seems a far smaller proportion of the Linux community is spending their time arguing (loudly, obnoxiously) about minor philosophical issues and blasting those opinions into the internet than compared to BSD.
Maybe you met the wrong people, from my PoV the BSD peoples like the BSD2/MIT/ISC/FreeBSD-License, but have no problem too import the CDDL the Apache or the GPLx (at least in the pkg), whatever works. On the other hand with Linux, CDDL absolutely NOT acceptable (hi Linus) but ultra-proprietary Firmware-Blobs are ok.
Some zealotry experience from a Linux foundation guy?
> BSD peoples like the BSD2/MIT/ISC/FreeBSD-License, but have no problem too import the CDDL the Apache or the GPLx (at least in the pkg), whatever works.
If by "BSD peoples" you mean the FreeBSD/NetBSD community, then yes. But OpenBSD devs deem CDDL to be unacceptable:
The proprietary firmware is in another git repository [1], there are no blobs in the mainline kernel to my knowledge. Further, distributions ship this firmware as a separate package, so it's not bundled with the kernel. This approach appears to be fairly similar to what OpenBSD does [2]. This doesn't seem too different from how the Linux community treats other licence-incompatible software such as OpenZFS.
I'm not sure what you mean by ZFS being such a big problem, the CDDL license is considered incompatible and therefore OpenZFS isn't going to be considered for upstreaming. Also, most of OpenZFS development is driven by companies that use it with the Linux kernel, so clearly there isn't that much of a problem with using OpenZFS and Linux. It's pretty similar to how the BSDs may not allow something in base due to licensing, but will allow it in ports/pkg.
If you're asking why OpenZFS is not hosted kernel.org, why would kernel.org host an out of tree kernel module that is never going to be upstreamed? Firmware on the other hand is needed to initialize and use a ton of hardware, and so it makes sense to have a central repository for vendors to submit required firmware. More importantly, why would the OpenZFS community even want to be on kernel.org when they support multiple operating systems and have also not pushed for upstreaming? I really don't think OpenZFS is being treated any better or worse than other license-incompatible kernel modules.
I just don't see how you can characterize it as zealtory any more so than FreeBSD wanting to remove all GPL'd software from base [1], or OpenBSD sticking with Clang 8 in base because of the switch to the Apache 2.0 license [2]. It's pretty normal for software projects to care about licensing.
> My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?
Sure, but that's been Greg KH's stance on pretty much every kernel module that has no chance of going upstream [1].
"Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech)."
Also in the post you are citing, the technical change makes no reference to ZFS [2] or implies that the motivation is to break out of tree modules. The upstream community simply doesn't even consider out of tree projects when making changes. Whether that's good or bad is another discussion, but I don't see anything that's specific to ZFS.
I should also note that to my knowledge, OpenZFS (formerly ZoL) was the only (open source) ZFS implementation that utilized vectorized checksums. At the very least FreeBSD's in-tree ZFS did not have vectorized checksums, as that was listed as one of the features FreeBSD would gain by moving to OpenZFS [3]. So the cited change didn't break ZFS, it just meant those checksums weren't as fast as they used to be.
The way they are handling ZFS reminds me of the way they handled Reiser4, Tux3 and Reiserfs.
Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied. Of course, the only filesystems they can make are all crap like ext4 and btrfs.
Fortunately, there's the BSDs, and there's the likes of HAMMER2 from Dragonfly.
And, with seL4[0], Fuchsia and HarmonyOS making progress, Linux is going to fall into irrelevance, sooner than most think.
Reiserfs is in-tree. Reiser4 failed after losing its lead dev, but my impression was that it was on-track to become the next Linux filesystem of choice. I have no clue about Tux3.
> Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied.
Linux has XFS from IRIX and JFS from AIX; the only way to have that and a "filesystem establishment" conspiracy is to resort to no-true-scotsman.
> Of course, the only filesystems they can make are all crap like ext4 and btrfs.
I'll agree that BTRFS is ... suboptimal, but what do you have against ext4? I'd like it to have data checksums and maybe CoW, but it's been the workhorse of the Linux world for ages and performs quite well, and even has some nice new features like encryption in recent times.
Yes it is, but it got bullied either way. Linux filesystem devs made incompatible changes to it against the ReiserFS teams' wishes, breaking it. IIRC it had to do with ACL support.
> The way they are handling ZFS reminds me of the way they handled Reiser4, Tux3 and Reiserfs.
The latter file systems were trying to be upstreamed and ultimately did not succeed, I don't know of any interest or attempts at upstreaming ZFS. Their handling of ZFS reminds me how they handle any kernel module that will never be upstream, not because some file system establishment sees it as a threat.
> Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied.
What/who is the "establishment (and their friends)"?
f2fs from Samsung was added in 3.8, erofs from Huawei was added in 5.4, and exfat from Samsung was added in 5.7. Before those file systems were upstreamed I don't think many people would list Samsung and Huawei as part of the filesystem "establishment".
Yes true and check-summing for metadata too, but not for the data. I have bigger hopes for XFS then bcachefs (maturity and really great dev's) but hopefully not that Stratis-thing from redhat....that sound's like a terrible idea.
>If you're asking why OpenZFS is not hosted kernel.org
No im asking why Linus thinks its acceptable to distribute proprietary Firmware, but needs a personal letter from Lord Elison and ZFS needs to be GPL'd....otherwise just don't use it.
>I just don't see how you can characterize it as zealtory any more so than FreeBSD wanting to remove all GPL'd software from base
That is because you can close and still distribute BSD licensed Software, but not when it contains GPL'd Software, thats why you dont want it in the Base-System, no one has something against GPL there, but FreeBSD wants to distribute a complete Operating-system under the BSD (or compatible like Apache/MIT etc) License.
What matters is if the upstream Linux community is comfortable enough with the license to allow it upstream, which is why I said "considered".
> No im asking why Linus thinks its acceptable to distribute proprietary Firmware, but needs a personal letter from Lord Elison and ZFS needs to be GPL'd....otherwise just don't use it.
There's a big difference between these two things. The first is redistributing proprietary firmware in a completely separate repository from the Linux source code. All firmware included in the linux-firmware repository is explicitly allowed to be redistributed [1], which is why they do not have fears about distributing those binary files.
I'll quote the readme: "If your commit adds new firmware, it must update the WHENCE file to clearly state the license under which the firmware is available, and that it is redistributable."
The second is introducing CDDL licensed code into a GPLv2 project, where that project considers the CDDL license to be incompatible, along with worries (however unfounded) about a notoriously litigious company.
> That is because you can close and still distribute BSD licensed Software, but not when it contains GPL'd Software, thats why you dont want it in the Base-System, no one has something against GPL there, but FreeBSD wants to distribute a complete Operating-system under the BSD License.
Yes the FreeBSD community does not want GPL code in the base system as it prevents them from from distributing a 100% permissively licensed system, and it's understandable why that is a goal. But how is that meaningfully different than the Linux community not wanting code with a license they feel is incompatible with their goals?
Again NO one wants ZFS being in the mainline kernel, but being openly hostile against it, but accept closed Firmware (because they have to...who is the leech now?) is not completely honest.
I've already said that the OpenZFS community is not trying to upstream it, why do you keep thinking that I'm suggesting otherwise?
You continue to conflate support for out of tree kernel modules as being similar to having a separate repository for firmware when they aren't the same thing at all. The Linux developers are not accepting firmware into the kernel at all, so there is no contradiction. The firmware is kept separate, just like OpenZFS is kept as a separate project from Linux. In both instances the user can choose to install an out of tree module such as OpenZFS as well as choose to install firmware on their system.
Furthermore it is not the Linux kernel developers that are packaging and shipping the firmware, it is the various Linux distributions who do that (or not in the case of FSF-approved distributions).
Yeah see the difference is that I just don't care about software licenses. At all. It's such an inconsequential issue that gets a small frothy-mouthed minority so worked-up that I find it baffling how anyone could spend so much time and energy worrying about.
Absolutely, at the beginning of my career i was a big fan of Stallman and the FSF, until i realized that he loves to hear himself and repeat's over an over the same stuff.
What he says is the only truth and nothing else.
I want cool technologie with a free license and ZERO lawyer's involved.
Detected means you see a device at a certain port or address. Works means that after detection you can actually interact with the device and do things.
Yes, openconnect was just one example that I know well because I work on it, and I know we don't report to these survey sites. If we did, we would make up a sizable percent of bsdstats.org, and over 99% of the BSD Hardware Database in the title.
And I'm sure there are others (like your infrastructure manufacturers) that could say the same.
Very disappointed by BSDs and FreeBSD in particular. The other day I wanted to build a pihole set-up using it - do you think it works seamlessly with raspberry pi? It doesn't. Wanted to install it on my UEFI bios - have to take more steps than I should. Wanted to run it on an nvidia jetson i have lying around. Good luck with that! Basically it only works with very common or old hardware. A shame really. I don't want to sound entitled, would have been happy to allocate time to build eyecandy apps to make it more suitable for a desktop (had an app included in the ports tree in the past), but I simply can't without spending too much time to even make it work. I wish this would change, as FreeBSD is my first "love", and for good reason - it's tidy and logically organised.
rpi and many other boards use proprietary drivers that are not open to the community. the hardware vendor makes a Linux blob and that's it. What can FreeBSD do about it?
That's a good question, and I don't have a clue. I know my comment sounds a bit entitled, because now that I think of it FreeBSD has provided that platform for vendors and the wider community to port drivers, or reverse engineer where possible. If i could do it I would do it myself, but I lack the skill and time. So i'll rephrase my statement: s/Very disappointed by BSDs and FreeBSD in particular/Very disappointed that vendors do not provide better hardware support for BSDs and FreeBSD in particular/. It really is a shame that such a great OS doesn't have wider support and adoption.
Tried NetBSD and OpenBSD in the past, and had worse issues in terms of compatibility. However, I had to rephrase my comment based on someone else's comment, and based on the realization that it's not FreeBSD and BSDs at fault:
s/Very disappointed by BSDs and FreeBSD in particular/Very disappointed that vendors do not provide better hardware support for BSDs and FreeBSD in particular/
True, yes true, but it is there for entirely different reason than in the term "Linux distribution". Even more, if we follow your argument it makes even less sense, "distribution distribution". There some genuine "distibutions" among BSD, such as NomadBSD, PC-BSD etc (FreeBSD derived systems), but in most cases, BSDs are very different OSes, incompatible with each other, with very different kernels (OpenBSD, NetBSD, FreeBSD, DragonFlyBSD).
I think they’re pointing out the duplication in “Berkeley Software Distribution disto/distribution”; similar to “ATM machine”, “PIN number”, “LCD display/screen”, etc.
No I am not. I am saying that BSD world is not distro driven. You would not call Android or ChromeOS a Linux distro. The difference between BSDs is very serious, and they are not by any means distros. They are variants for sure, but not "distros".
What in the world were they thinking. This is now how you appeal to the BSD community.