does removing EXPORT_SYMBOL(__kernel_fpu_end); [0] - which broke ZFS, count as removing stuff or changing the API?
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.
Sun doesn't exist anymore, and while openzfs is compatible with older versions of any of Oracle's life support Solaris, it's not the same ecosystem. Yes, the same licensing issues still exist, but openzfs has been developed by LLNL for Linux ever since it was called "zfs for Linux".
If that ecosystem have changed their values/opinions on that topic, the it wouldn't be an impossible task to dual-license it with a compatible license.
They could rewrite all the code, and then change the license. Patents might still apply (but patents are short enough that I expect if any existed they have expired). However ZFS is a lot of code that is often tricky to get right. It will be really hard to rewrite in a way that the courts don't (reasonably/correctly) say wasn't a rewrite it was just moving some lines so you can claim ownership, but it is possible. By the time anyone knows enough about zfs that they could attempt this they are also too tainted by the existing code.
And how hard it is proves that zfs didn't make a bad choice in not trying the same. (though it would be interesting if either had a goal of a clone - that is same on disk data structures. Interesting but probably a bad decision as I have no doubt there is something about zfs that they regret today - just because the project is more than 10 years old)
Ok, please explain. ZFS is licensed under CDDL, which is incompatible with GPL, aka Kernel license. Sun owned copyright and could easily change license or dual license. They didn't... for reasons (likely related to Solaris).
Sun leadership wanted to license OpenSolaris under GPLv3. However, GPLv3 work was dragging on at FSF and the license was not released in time. Moreover, there was opposition from Solaris dev team due to belief that GPLv3 will lock out reuse of OpenSolaris code (especially DTrace and ZFS) in Free/Net/OpenBSD.
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
So... as I said "Sun explicitly did not want". They chose not to license it under GPLv2 or dual license GPLv2 + GPLv3 for... reasons.
> 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.
Sun is dead and the ZFS copyright transferred to Oracle who then turned it into a closed source product.
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.
Reading the kernel mailing lists wrt/ bcachefs, it looked more like a cattle prod than an olive branch to me… Kent didn't do nothing other maintainers don't do except make one filesystem that doesn't get irrecoverably corrupted on brownout.
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…?
I have no idea if you read the right parts because that's not what happened at all.
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.
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.
It wasn't designed to be hostile to Linux - insider claims they expected integration within weeks, the license kerfuffle was a surprise.
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.
You are ascribing motives to the OpenZFS project that aren't there. Sun was the one that licensed it CDDL, and OpenZFS is a fork that was created when Oracle bought Sun and decided to close source ZFS. Oracle has zero involvement with OpenZFS.
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.
I doubt the OpenZFS team would move to GPLv2 if they were able to relicense to anything they wanted. Given their close association with FreeBSD, BSD-2 or a similar permissive license wouldn't shock me.
But it's an academic exercise anyway, since it seems Oracle has no intention of allowing them to relicense.
> 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.
