That's patently untrue. They do not remove stuff, they just keep changing the APi which means that the modules need to keep evolving.
AFAIK that change didn't add functionality or fix any existing issues, other than breaking ZFS - which GKH was absolutely fine with, dismissing several requests for it to be reverted, stating the "policy": [1]
> Sorry, no, we do not keep symbols exported for no in-kernel users.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [1] https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.co...
> 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?
Why would you accommodate someone who explicitly went out of their way to not accommodate you?
It took many conflicts with bcachefs developer to reach this state. Olive branch has been extended again and again...
I am not kernel developer, but less exposed API/functions is nearly always better.
The removed comment of function even starts with: Careful: __kernel_fpu_begin/end() must be called with
(Hard and tedious work, but not impossible).
So of course they won't, but it isn't impossible.
I agree that based on that source, it's more like "meh, we don't really care" (until they do)
The modern OpenZFS project is not part of Oracle, it's a community fork from the last open source version. OpenZFS is what people think of when they say ZFS, it's the version with support for Linux (contributed in large part by work done at Lawrence Livermore).
The OpenZFS project still has to continue using the CDDL license that Sun originally used. The opinion of the Linux team is the CDDL is not GPL compatible, which is what prevents it from being mainlined in Linux (it should be noted not everyone shares this view, but obviously nobody wants to test it in court).
It's very frustrating when people ascribe malice to the OpenZFS team for having an incompatible license. I am sure they would happily change it to something GPL compatible if they could, but their hands are tied: since it's a derivative work of Sun's ZFS, the only one with the power to do that is Oracle, and good luck getting them to agree to that when they're still selling closed source ZFS for enterprise.
Making /home into a btrfs filesystem would be an opening salvo.
IBM now controls Oracle's premier OS. That is leverage.
I'm just sorry for the guy and perhaps a little bit sorry for myself that I might have to reformat my primary box at some point…
Also unrelated, but Sun was a very open source friendly company with a wide portfolio of programs licensed under GNU licenses, without some of which Linux would still be useless to the general public.
Overall, designing a good filesystem is very hard, so perhaps don't bite the hand that feeds you…?
The maintainer kept pushing new features at a time when only bugfix are allowed. He also acted like a child when he got asked to follow procedures. Feel sorry for his bad listening and communication abilities.
The "new features" were recovery features for people hit by bugs. I can see where the ambiguity came from.
CDDL was a compromise choice that was seen as workable for inclusion based especially on certain older views on what code will be compatible or not, and it was unclear and possibly expected that Linux kernel will move to GPLv3 (when it finally releases) which was seen as compatible with CDDL by CDDL drafters.
Alas, Solaris source release could not wait unclear amount of time for GPLv3 to be finalized
> it was unclear and possibly expected that Linux kernel will move to GPLv3
In what world? Kernel was always GPLv2 without the "or later" clause. Kernel had would tens of thousands of contributors. Linus made it quite obvious by that time kernel will not move to GPLv2 (even in 2006).
Even if I gave them benefit of the doubt, GPLv3 was released in 2007. They had years to make license change and didn't. They were sold to Oracle in 2010.
The CDDL is actually very permissive. You can combine it with anything, including proprietary licences.
Is moving a symbol from EXPORT_SYMBOL(some_fun) to EXPORT_SYMBOL_GPL(some_func) actually changing the API? Nope, the API is exactly the same as it was before, it's just changed who is allowed to use it.
From the perspective of an out of tree module that isn't GPL you have removed stuff.
I'm honestly not sure how one outside the kernel community could construe that as not removing something.
No, it was always designed to be hostile to Linux from the outset. It's a project that doesn't want to interoperability with Linux so I'm not entirely sure why you think the Linux folks should maintain an API for them.
Since the pre-fork code is from Sun, Oracle owns the copyright, and they won't re-license it.
The idea that the OpenZFS team wants CDDL out of spite for Linux is an absurd conspiracy theory. Their hands are tied - I'm sure they'd move to a compatible license if they could, but they can't.
So the OpenZFS team is not exactly interested in moving to GPLv2, because it would break multiple platforms.
But it's an academic exercise anyway, since it seems Oracle has no intention of allowing them to relicense.
The choice of creating a new license was because of two reasons:
- Internally people wanted for the code to be usable by not just Linux and Solaris (lots of BSD fans, for example)
- Sun was insisting on mutual patent protection clauses because GPLv2 didn't support them, and GPLv3 was not yet available to discuss viability at all.
Linux and OpenZFS are pretty much locked into their licenses, regardless of what people might want today. There are too many contributors to Linux to relicense, and while OpenZFS has fewer, I don't think there's any reason to think Oracle would relicense, given they went back to closed source with Solaris and ZFS on Solaris.
> It's a project that doesn't want to interoperability with Linux.
Regardless of the original intent of Sun in picking the license, it's hard to imagine a project called ZFS on Linux (which was merged into OpenZFS) doesn't want to interoperate with Linux.
> They could always move to a compatible license? > No, it was always designed to be hostile to Linux from the outset. It's a project that doesn't want to interoperability with Linux
I'm not sure why you've jumped here. I didn't mention a specific project or licence.
But, nonetheless I'm going to assume you mean OpenZFS.
1. No they can't change the license. Much like Linux contributors retain their own copyright, OpenZFS can't just change the license. The only group that could hypothetically change it is Oracle given the clause the steward of the license can release a new version, but that's unlikely and Oracle has absolute nothing to do with the existing project.
2. Staying on the license and compatibility. It's really quite confusing on what's compatible in the eyes of Linux. The very fact they have separate export and export GPL symbols suggest Linux as a project sanctions non GPL modules, and considers them compatible if they only use those symbols, perhaps in the same vein as they consider the syscall boundary to be the compatible with non GPL? If someone who is actually in the know about why there are two sets of exports if love to be know.
3. Always designed to be hostile to Linux. Whether that's true or not is the debateable, there are conflicting opinions from those who worked at Sun at the time. Also the comment criticises a community that had no hand in whether or not it was intended to be hostile to Linux or not. In the end is copyleft software, very similar in spirit to the Mozilla public license. And by definition copyleft licenses are inherently incompatible without specific get out of the jail clauses to combine them (see MPLv2 for example).
4. Re interoperability. Strongly disagree. OpenZFS takes great strides to be compatible with Linux. Each release a developer sends hours pouring over Linux changes and updating a compat layer, and the module remains compatible to compile against multiple Linux versions at any one time, there are even compat patches to detect distro specific backports that while the version hasn't changed the distro have back ported things that change behaviour. That's a serious commitment to interoperability. And a large number of openzfs devs do their work against Linux as their primary platform, hence why the FreeBSD rebased their ZFS upstream on ZFS on Linux, leading it to become the official upstream OpenZFS. I can't see how anyone could say in good faith they don't care about Linux compatibility unless they haven't looked over at the openzfs project for over a decade.
4. Re why do I think Linux folks should maintain APIs for them.
The way you worded this strongly implies I was saying Linux should maintain an API for them. In no way did I say that. I was replying to a post that was adament that Linux doesn't remove things. I provided a perspective that Linux does in fact remove things. I wasn't arguing for maintaining any API, Linux doesn't even guarantee internal APIs for themselves. I was pointing out changing a symbol export from export to everyone to export GPL only isn't changing it, given it's the exact same API they've just simply removed it for some groups.
None the less I think it'd be great if Linux could maintain some APIs for out of tree modules. But they don't and that's fine. I just find changing exports from open for everyone tomorrow GPL only to be rather hostile.
Really, no one in either of these communities had any say in their license (sans Torvalds). Both creating great stuff for we as users to run. And it'd be great if people working on free software could get along, and those in the peanut gallery didn't prescribe malcontent between them because of a difference in license they didn't pick.