Linux 6.18 Will Further Complicate Non-GPL Out-Of-Tree File-Systems

[-]

Opheltes@reddit

Eli5: why does this only apply to non-gpl filesystems?

[-]

LexaAstarof@reddit

The alternative, writeback_iter, is exported for GPL only. Whereas the defunct one was not restricted to GPL only.

[-]

Opheltes@reddit

What does it mean to be exported for GPL only?

[-]

foobar93@reddit

It means only GPL compatible software is allowed to use it. So no ZFS

[-]

Existing-Tough-6517@reddit

Which is a completely nonsensical difference completely unsupported by law or the licence.

[-]

mrtruthiness@reddit

Which is a completely nonsensical difference completely unsupported by law or the licence.

Not true. Copyright law isn't clear about the exact situation when linking to code creates a "derivative work". The kernel is trying to make that line clear: If you are using these exports, you are creating a derivative of our work and, thus, must be GPLv2 compatible.

[-]

Existing-Tough-6517@reddit

Copyright isn't clear about CODE at all and if we talk about what it was designed to cover making something functional that interoperates without copying anything doesn't appear to be covered at all.

If you wanted it to be you would have to write an extension of the law.

[-]

mrtruthiness@reddit

Copyright isn't clear about CODE at all ...

Copyright is not specifically written in regard to code. But copyright is clear about "derived works". If a copyright owner wants to make clear about what they consider a derived work that will have some force. And the fact is that a copyright owner's intent does matter in regard to what they consider unique and what makes an extension of it "derived".

I hope you are aware that the FSF's opinion is that any linking (static or dynamic) should be considered a derived work and since the FSF is the owner of the text of the GPLv2 license that matters. At least the kernel copyright owners have made it clear -- i.e. they have specified intent -- which exported symbols for linking they consider to be "generic use and not considered to be derived use" and which should be considered "derived use".

[-]

Existing-Tough-6517@reddit

Absolutely not what is considered a derived work is fully and only a matter of law that the copyright holder has no say whatsoever on.

Consider. If a work is not considered a derived work then it is entirely outside the authors ability to regulate. This should be fairly obvious.

[-]

mrtruthiness@reddit

... the copyright holder has no say whatsoever on.

You're wrong. If the copyright holder explicitly lays out ahead of time what they consider their "protected elements" that absolutely has a bearing in the result of the case.

If a work is not considered a derived work ....

The whole case relies on whether it's a derived work or not --- you've just presumed "it's not". If the copyright owner of the original work is clear when licensing their work about what they consider to be a "derived work" that is absolutely considered in regard to the decision of whether use is "fair use" or "derived work". Does it override any legal precedent or laws? No, but since there is not yet any real legal precedent in regard to linking, it would absolutely be considered favorably.

[-]

Existing-Tough-6517@reddit

No I'm presuming that what IS derivative is wholly and totally defined in law. If its not derivative the declaration of a protected element cannot make it derivative. Seems you aren't getting this.

[-]

mrtruthiness@reddit

No I'm presuming that what IS derivative is wholly and totally defined in law.

It isn't defined by law. Haven't you seen cases of copyright violation in regard to music? It's a judgment on what is a derived work or not.

[-]

Existing-Tough-6517@reddit

Law herein means the totality of written law and cases providing interpretation of said law. Requiring such cases to understand how the law actually applies is the norm. None of this provides any room whatsoever for the author to have any input whatsoever on what the legal defuntioj

[-]

mort96@reddit

Honestly, that's not wrong. The plain reading of the license would make no such distinction, no symbol would be available to non-GPL users. There's really no argument for why the CDDL-licensed OpenZFS should be able to link against any part of Linux.

[-]

asrtaein@reddit

It's not so simple, since the GPL is a Free Software copyright license the problem only arises when you are making a derived work. (If not it wouldn't be Free Software since there are arbitrary restrictions on how you can use the software)

The question is thus when something becomes a derived work, and there's just not a simple answer to that.

At least that's how I understand it, if I'm wrong someone will probably correct me :)

[-]

mort96@reddit

My understanding is that the GPL and the free software movement is built on the assumption that if your software links against some other software and calls functions from the other software, the combination of the two is a derived work of that other software. Kernel modules necessarily link against the kernel and call functions from the kernel. So my understanding is, either you deny the validity of the entire free software movement and the concept of a copyleft license, or you agree that kernel modules are derived works of the kernel.

To my knowledge, no court of law has struck down the assumption that linking against a library creates a combined work that's a derivative of the library, even though there have been plenty of relevant court cases across over 3 decades. So I would say that the concept behind copyleft licenses is on relatively firm footing. (Hell, the European Commission even made their own copyleft license!)

[-]

Existing-Tough-6517@reddit

So all software that runs on Linux is derivative and therefore must be GPL?

[-]

mort96@reddit

No, the Linux license has a syscall exception.

[-]

Existing-Tough-6517@reddit

which again isn't real because a license cannot decide what is derivative

[-]

torsten_dev@reddit

Copyright fair use still applies. So ala Oracle v Google if you're merely making your Filesystem interoperable by adjusting to an exposed or standard API you're good.

[-]

mort96@reddit

Yes, but we're not talking about re-implementing an API here, we're talking about calling functions which are implemented by the Linux project.

[-]

torsten_dev@reddit

Using symbol names that a linker can point to functions that are in the kernel so that it can choose that implementation.

Only the header information needs to be copied. So the out of tree work only needs to copy as much of the API as to make interop possible which is a now well established exception to copyright.

Since the out of tree work does not violate copyright it does not need to respect the GPL terms.

[-]

mort96@reddit

Nobody is causing that the ZFS-on-Linux (ZoL) project is a derived work of Linux. It's the combination of ZoL + Linux that's a derived work of both Linux and ZoL.

[-]

torsten_dev@reddit

Thanks, yes that was missing in the bigger picture.

The difference between Non gpl and gpl exports are how intertwined the components become so Saying GPL EXPORT means if you use this you're probably a derived work if we run together on a machine, I guess?

[-]

Existing-Tough-6517@reddit

Ya that is basically probably a fantasy because its not clear that has any meaning in copyright

[-]

Existing-Tough-6517@reddit

But the developers of ZFS do not distribute the combined work nor do repos that support installation of same. They give you zfs which on the user side is used to create a module via DKMS

[-]

mrlinkwii@reddit

depends on the country , in frace its a contract issue not copyright

[-]

CrazyKilla15@reddit

So my understanding is, either you deny the validity of the entire free software movement and the concept of a copyleft license, or you agree that kernel modules are derived works of the kernel.

Then the kernel community has decisively answered that the free software movement is null and void.

You dont see anybody suing NVIDIA over their kernel modules, do you?

[-]

Existing-Tough-6517@reddit

Presumably trying to enforce such a ban would result in the ambiguity being dispelled after they also destroyed a good chunk of their community and spend millions of dollars that nobody who has millions of dollars would ever deploy for such a purpose.

[-]

asrtaein@reddit

Any software running on an operating system calls functions from that operating system but it's generally accepted that they are not derived works.

So my understanding is, either you deny the validity of the entire free software movement and the concept of a copyleft license, or you agree that kernel modules are derived works of the kernel.

I don't see why it should be so black and white. There is no concept of kernels, modules, drivers, linking, functions, etc in copyright law.

The question usually boils down to, does the work stand on its own or not? ZFS was not developed for Linux and also still runs on other operating systems, so the case that it's not a derived work is strong. But it's also possible to change it enough so that it would become one. Is ZFSonLinux that? I don't think anyone knows for sure.

EXPORT_SYMBOL is a crude way of Linux developers to say "we consider software using this function not a derived work", but it's not for them to decide what is a derived work and I don't know if this way of working was ever tested in court.

[-]

mort96@reddit

Any software running on an operating system calls functions from that operating system but it's generally accepted that they are not derived works.

Is that generally accepted? Linux has a syscall exception specifically to avoid the question, are you saying that Linux could remove the syscall exception tomorrow and it would be generally accepted to have no effect?

[-]

Existing-Tough-6517@reddit

The license can't define how copyright works so it specifically has no meaning.

[-]

asrtaein@reddit

IANAL, but yes.

This is the syscall exception:

NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".

What is considered a derived work is for the courts to decide, the license has no say over this. So this looks like just a clarification to me.

[-]

foobar93@reddit

Any software running on an operating system calls functions from that operating system but it's generally accepted that they are not derived works.

Totally irrelevant as software running on the operating system uses the exposed interfaces to the user space from the kernel, not the kernel internal calls.

You can write a program that runs under different kernels which all implement POSIX so obviously your work is not derived work.

Here, we are talking about kernel internal interfaces inside modules which directly link each other.

I don't see why it should be so black and white. There is no concept of kernels, modules, drivers, linking, functions, etc in copyright law.

Yes and no. The concept in copyright is the derived work. Linking for example usually creates a derived work. Calling a syscall that is present in many different OSes not.

EXPORT_SYMBOL is a crude way of Linux developers to say "we consider software using this function not a derived work", but it's not for them to decide what is a derived work and I don't know if this way of working was ever tested in court.

Exactly this. That is also why there is so much opposition to the non GPL symbols.

[-]

foobar93@reddit

Which would make all kernel modules derived works and make ZFS or the proprietary nvidia drivers impossible.

The only reason the non GPL symbols exist in the first place was to make this possibel by marking some symbols as mere interactions with the kernel.

ow, historically, that was required, if this is legal in the first place is hard to say.

[-]

Existing-Tough-6517@reddit

Well on the other hand its odd to argue that something that existed before Linux support was added and supports multiple OS is now a derived work of Linux when distributed alone with the intention that the end user combine but not distribute them.

[-]

Ape3000@reddit

Why would it be exported for GPL only?

[-]

foobar93@reddit

Wrong question, the default is GPL only as all linking is regarded as creating a derived work. The question is, why would it not be a derived work and thus could be marked as usable for non GPL modules.

[-]

Nyattokiri@reddit

Christoph Hellwig

Oh, that's the dude from the Rust for DMA drama. Keeps sabotaging

[-]

Helmic@reddit

There's no reason to make this into new drama. Even if I disagree with Hellwig's position or how he conducted himself prior, that doesn't mean we need to pretend every little thing Hellwig does that might inconvenience someone is done with malicious intent.

[-]

LexaAstarof@reddit

https://lkml.org/lkml/2024/4/3/650

Followed by

https://lkml.org/lkml/2024/4/3/850

It would be as simple as removing "_GPL" from the export macro name. But no, he does not like it, therefore he NAKs it.

[-]

gordonmessmer@reddit

> It would be as simple as removing "_GPL"

I really worry that copyright and licensing issues are not covered in software development education, because every single developer needs to understand them.

Those macros are copyright management information in the USA, defined in 17 U.S. Code § 1202 (c), and they can only be changed by the copyright holder.

[-]

CrazyKilla15@reddit

The problem is that this is literally not true at all. There is no basis in US case law, or GPL license text, for this position. The FSF itself, and hellwig here, holds that linking at all to Linux makes you a derivative, and thus no proprietary kernel module is legal, period.

Linux does not have any legal exception to this for "EXPORT_SYMBOL(_GPL)" macros, never has, and fundamentally never will, because doing so would require the permission of literally all linux kernel contributors. The GPL and FSF position is clear: Linking = derivative work. The only even tangentially related formal exception to exist is for the syscall interface that user-space programs use, the syscall exception. This is not used by kernel modules.

Adding a new linking exception for "EXPORT_SYMBOL" marked symbols would require every existing contributor ever to agree to re-license from "GPL + Syscall Exception" to "GPL + Syscall + Module Exception". This has not happened.

This is not new, to quote LWN from 2014, emphasis mine

It is worth noting that nobody has said that symbols exported with plain EXPORT_SYMBOL() can be freely used by proprietary code; indeed, a number of developers claim that all (or nearly all) loadable modules are derived products of the kernel regardless of whether they use GPL-only symbols or not. In general, the kernel community has long worked to maintain a vague and scary ambiguity around the legal status of proprietary modules while being unwilling to attempt to ban such modules outright.

See also the official GNU FAQ regarding the GPL license

https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux

Does distributing a nonfree driver meant to link with the kernel Linux violate the GPL? (#NonfreeDriverKernelLinux)

Linux (the kernel in the GNU/Linux operating system) is distributed under GNU GPL version 2. Does distributing a nonfree driver meant to link with Linux violate the GPL?

Yes, this is a violation, because effectively this makes a larger combined work. The fact that the user is expected to put the pieces together does not really change anything.

Each contributor to Linux who holds copyright on a substantial part of the code can enforce the GPL and we encourage each of them to take action against those distributing nonfree Linux-drivers.

https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)

No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?

And especially https://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface

How can I allow linking of proprietary modules with my GPL-covered library under a controlled interface only? (#LinkingOverControlledInterface)

Add this text to the license notice of each file in the package, at the end of the text that says the file is distributed under the GNU GPL:

Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of ABC give you permission to combine ABC program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with ABC solely through the ABCDEF interface. You may copy and distribute such a system following the terms of the GNU GPL for ABC and the licenses of the other code concerned, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code and provided that you do not modify the ABCDEF interface.

Note that people who make modified versions of ABC are not obligated to grant this special exception for their modified versions; it is their choice whether to do so. The GNU General Public License gives permission to release a modified version without this exception; this exception also makes it possible to release a modified version which carries forward this exception. If you modify the ABCDEF interface, this exception does not apply to your modified version of ABC, and you must remove this exception when you distribute your modified version.

This exception is an additional permission under section 7 of the GNU General Public License, version 3 (“GPLv3”)

This exception enables linking with differently licensed modules over the specified interface (“ABCDEF”), while ensuring that users would still receive source code as they normally would under the GPL.

Only the copyright holders for the program can legally authorize this exception. If you wrote the whole program yourself, then assuming your employer or school does not claim the copyright, you are the copyright holder—so you can authorize the exception. But if you want to use parts of other GPL-covered programs by other authors in your code, you cannot authorize the exception for them. You have to get the approval of the copyright holders of those programs.

I invite you to prove me wrong, and link to this exception within the Linux Kernel. However, I do not believe you can, as it simply does not exist.

This will likely never go to court in the US, because the chances of destroying the legal fiction that EXPORT_SYMBOL_GPL exists is too high. Thats why for example NVIDIA is never sued for violating it, upstream just changes it, maybe publicly complains, and moves on. If they sued, they know they would lose.

As for the EU, AIUI this is simply nonsense from the get go, linking to APIs for interoperability is simply always allowed regardless of copyright. For example, from the EUPL FAQ, "Moreover, European law considers that linking two independent works for ensuring their interoperability is authorised regardless of their licence and therefore without changing it: no "viral" effect."

[-]

gordonmessmer@reddit

> There is no basis in US case law, or GPL license text, for this position

It doesn't need to be "in case law" or in the GPL, because the basis is in the text of US law.

17 U.S. Code § 1202 (c) defines copyright management information, including "Terms and conditions for use of the work". Those macros indicate the terms and conditions for the use of each function, indicating whether it is GPL or GPL with an exception for linked work. A change to the macro is a change to copyright management information, which is the exclusive right of the author.

Your comment is very confusing, because almost everything you have written or quoted supports the comment you replied to, but you begin and and as if you do not agree with me. I really don't know what to make of any of that.

[-]

georgehank2nd@reddit

The problem isn't that it is not taught, the problem is that people (like the person you replied to) didn't give a fuck. Convenience and being able to do whatever they want, that's what they care about.

[-]

foobar93@reddit

"As simple as removing _GPL from the symbol"

As _GPL is used to signal a license boundary, you cannot just remove it willy nilly. By the same token, you could ask for the Linux kernel to drop the GPL al together and just use MIT or something similar.

[-]

hkric41six@reddit

Rust is a toxic community. Was so glad to hear Karnigan's views on that.

[-]

i509VCB@reddit

Is it really a surprise that the guy who wrote the book for C, doesn't like things that aren't C?

[-]

hkric41six@reddit

I think he's experienced enough to dislike it for entirely other reasons that are not so petty as that.

Honestly shame on you for suggesting someone as distinguished as him would dislike Rust for such a petty reason.

[-]

i509VCB@reddit

I don't see how it is petty. Someone who has written something like Java for a living will come to expect other programming languages to behave like Java. Same with any other programming language.

I could see a world where the guy is okay with C++, but would not use most of it.

[-]

hkric41six@reddit

This is a naïve take.

[-]

SEI_JAKU@reddit

Naive is pretending this isn't how the world works in general.

[-]

hkric41six@reddit

I can reverse your argument and it is just as valid.

[-]

SEI_JAKU@reddit

You can't magically "reverse my argument", because that kind of childish "I'll just replace this word with another word and completely change the statement!" internet argument doesn't actually work.

[-]

cgoldberg@reddit

FWIW, his only comments about Rust werr that he tried it once and the compiler and code it produced was slow. Hardly a deep dive on its technical merit.

[-]

buttux@reddit

He removed an unused function. That's completely normal for anyone to do.

[-]

Damglador@reddit

But it is used, even if by out of tree modules.

[-]

foobar93@reddit

So it is not used. Should the kernel contain any function that may be used out of tree? No, the out of tree module can juat pull it if they need it.

[-]

Damglador@reddit

I think if people already actively use it, the kernel should keep it. Removing it for me looks irrational. It only harms the out of tree filesystems and doesn't help anyone. If no one wants to maintain it - don't, but leave it be.

[-]

foobar93@reddit

Again, noone the kernel is aware off (as in is in-tree) uses it. Why should the kernel care about some random out of tree system? I still have a out-of tree branch with derivative of IrDa, should the kernel also keep the IrDa functions because I am using them? No, I have to pull these and maintain them myself.

And no, you should be removing dead functions. They make code harder to read and see no testing because of no useage.

"Just leave it" also does not work as maintenance is done per subsystem or driver. There is no "oh this function is unmaintained so we just leave it". Like, what does that even mean? No refactors anymore so it may just break at any time? What do you do if the function does not compile anymore because of external changes? You have to maintain it if it is there.

[-]

TheOneTrueTrench@reddit

As long as there's a path forward, like giving out of tree modules the ability to maintain the function externally, that's fine.

Hell, I rely on ZFS, if need be, I'd start maintaining that function as part of the OpenZFS project just to keep using it.

Pretty sure someone else associated with the OpenZFS project is probably more qualified, and I'm generally not a kernel developer, but if need be, ugh, fine.

[-]

Far_Piano4176@reddit

the openZFS summit is apparently coming up in october, so they'll have something to talk about

[-]

Hytht@reddit

Never break userspace is their principle - they don't care about out of tree stuff or have to.

[-]

SilentLennie@reddit

The Linux kernel has a clear policy: kernel internal API can be changed any time, only userspace compatibility is what they care about.

[-]

macromorgan@reddit

No, they shouldn’t. Out of tree should just maintain the additional function themselves.

[-]

buttux@reddit

Keeping the kernel internal API clean for in kernel use has been a guiding coding principle since the very beginning.

[-]

sshfs32@reddit

By the kernel policy, out-of-tree drivers are entirely unsupported. See the kernel docs.

Kernel interfaces are cleaned up over time. If there is no one using a current interface, it is deleted. This ensures that the kernel remains as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.)

[-]

Business_Reindeer910@reddit

That's entirely too recent to point to: He's been on this particular crusade for a long time https://lwn.net/Articles/696764/ when he sued VMware.

But it is silly to blame just him if Linus himself is the one who merges it upstream.

[-]

davis-andrew@reddit

A mastodon post from robn, a zfs developer that does a lot of the new Linux version enablement the last few years.

I have a build of #OpenZFS working just nicely against #Linux next-20250911. You know, the one with the "Linux hates out-of-tree filesystems" change slated for 6.18, that is filling my DMs today.

This is not magic or heroism, just looking at the changes, thinking for a while, and doing the work. It took a morning.

Don't be sucked in by the noise and nonsense. Instead, trust that we've got your back, and are working hard to give you a filesystem that you can trust to take care of your data long into the future.

I'll also take a tip, if you're offering 💚 https://despairlabs.com/sponsor/

https://social.lol/@robn/115189135969338619

I'll take his word that it's overblown given he's the one in the thick of it.

[-]

bobj33@reddit

This is really the person's opinion that matters. The other hundreds of people here and on the phoronox thread are all freaking out. The person actually writing the code is already on top of it.

[-]

mrlinkwii@reddit

honestly why ? the kernal support 50 year old cpus and manages to preserve support , why could they perserve support for non gpl out of tree file system , as linus says never break userspace

this is like a big f you to non gpl stuff

[-]

MooseBoys@reddit

I agree it's stupid to remove something that has important oot uses, but this isn't a userspace interface, and kernel-level implementations are supposed to be checked in to Linux itself.

There's an infamous post on this topic here: https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst tl;dr: "you're stupid for wanting stable kernel interfaces or wanting out of tree code at all". There are probably a substantial number of Linux die-hards who would love to see DKMS disappear altogether.

[-]

CrazyKilla15@reddit

HTML link: https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html

[-]

chibiace@reddit

yeah its kinda sus

[-]

james2432@reddit

truenas might be sweating bullets rn

[-]

1T-context-window@reddit

TrueNAS non-scale, back to freebsd i guess

[-]

Appropriate_Ant_4629@reddit

Or just look at being portable across filesystems, so they don't dump all their eggs in one basket.

[-]

spacelama@reddit

Might be time for us to move back to *BSD.

[-]

Novero95@reddit

Why? ZFS is really an outstanding file system and it's what makes TrueNAS so good, people using TrueNAS use it because of ZFS. I know BTRFS is out there, i use it in my laptop, but it's nonsense to spend resources on supporting other FSs when your current one is what people want to use.

[-]

minus_minus@reddit

This is why I wish the "MIT License" got more use in important projects.

The way it was characterized politically, you had copyright, which is what the big companies use to lock everything up; you had copyleft, which is free software's way of making sure they can't lock it up; and then Berkeley had what we called ‘copycenter’, which is ‘take it down to the copy center and make as many copies as you want’

- Marshall Kirk McKusick, BSDCon 1999

[-]

vaynefox@reddit

Nah, permissive licenses like MIT are a cancer to open source. It makes companies become leaches to your work, profitting off it without even contributing back. It should just die off for good....

[-]

not_some_username@reddit

Well GPL licences are literally cancer. I avoid them. Being force to choose this licence to your tools just because you use a part of a lib if the reverse of freedom for me. At least LGPL doesn’t have such nonsense.

[-]

vaynefox@reddit

At least GPL forces you to actually contribute and avoid open source projects to become stagnant or die. We open source developers are already giving you a tool that you can use to profit off for free. What we are only asking is for you to contribute back so that you can also help improve the very same tool that you're profitting off. We arent asking for a cut to your profits, and contributing back will only cost you a fraction of your profits. Freedom isnt always free. There is always a trade-off to get the freedom you want. Otherwise, you're living in a delusional world....

[-]

The_Bic_Pen@reddit

Open source does not prevent software from getting stale and dying. There are thousands if not millions of examples out there, but I'll use GNU Hurd as the most obvious one

[-]

mrlinkwii@reddit

|>At least GPL forces you to actually contribute and avoid open source projects to become stagnant or die

actually GPL dosent force anyone to to actually contribute ,

[-]

not_some_username@reddit

If I use the library for a product, I don’t see the reason the entire project should be force to change the license. That’s why I mentioned LGPL, it lets you use it as you want as long as you contribute back if you make change to the library. Also, as long as your library is good, it will be use and not die. Look at SQLite -> public domain.

Either way, I contribute more on actually MIT/apache/bsd libs since I prefer to use them.

For me, your library is either good and gets contributors or it’s not. Being GPL isn’t what will avoid that.

[-]

GoDaftWithEBK@reddit

That's because you might be too lazy to choose a correct license for your project. Instead of go MIT or GPL blindly, think of your project future, reachness and profitness and then choose a right one.

[-]

minus_minus@reddit

Leaching has its own penalties. If someone forks the code then they have to maintain the whole code base without other peoples fixes and features automatically included.

[-]

Appropriate_Ant_4629@reddit

No.

They already tried that.

Remember in the 1990s, when BSD was arguably ahead of Linux -- with BSD forks and derivatives like SunOS 4.x, MacOS, Playstation3's OS, DEC Ultrix, and many more.

All those vendors invested vastly more money and man-hours into BSD than all the Linux supporters combined.

But thanks to the BSD-license being MIT-license-like, they kept the good parts to themselves; and all had to independently re-implement advances; and the features died as the vendors died.

Don't make that mistake again.

[-]

Maykey@reddit

TL/DR: The GPL is why Linux beat BSD in the 1990s

The reason why why linux beat BSD is linux was not sued by AT&T

[-]

Albos_Mum@reddit

Nah, that's the reason Linux was created and able to start competing with it in the first place. It took years for Linux to properly catch up with BSD to the point where it's more or less supplanted it from most systems.

[-]

Maykey@reddit

Whole idea of Linux creation is "a better minix that minix"

[-]

Albos_Mum@reddit

And the whole reason minix 1/2 was ever used as anything more than an educational tool in the first place is because the gnu project had gotten loads of people hyped on the concept of a free unix-like OS and minix was the closest thing without any legal questions hanging over it at the time. The reason Linux beat BSD is because the amount of hobbyist interest it garnered thanks to the legal situation and Andrew Tanenbaum actively trying to get rid of the hobbyist minix userbase allowing it to mature quickly enough that it didn't fall too far behind in any metric until some large corporations got interested enough to sponsor it fully, for the early 90s Linux was seen as the kernel the gnu project couldn't make while BSD was the future for corporate Unix until there was a push to port to alternative architectures and support SMP among other more mainframe-focused projects, and then it became clear Linux was just the future for Unix in general when IBM, Compaq and Oracle all announced they were backing it in 1998.

It's worth noting that by the time the BSD legal encumbrance was over Linux had barely reached version 1.0, didn't support multi-processors, was still very much focused on the 386, wasn't backed by virtually any large corporate sponsors with even Red Hat's distro launching v1.0 in the same year 386BSD was legally clear and that the 386BSD developers themselves were free to continue development and even release their code provided they stripped out the code being fought over in court, admittedly producing a non-functional system unless you could add in the code.

[-]

Appropriate_Ant_4629@reddit

And the whole reason minix 1/2 was ever used as anything

Not quite!

Minix is used more than Linux -- partly because its license is very compatible with spyware and backdoors:

https://www.networkworld.com/article/964650/minix-the-most-popular-os-in-the-world-thanks-to-intel.html

[-]

davidnotcoulthard@reddit

Minix is used more than Linux -- partly because its license is very compatible with spyware and backdoors:

https://www.networkworld.com/article/964650/minix-the-most-popular-os-in-the-world-thanks-to-intel.html

That not "minix 1/2" as you quoted.

[-]

DazzlingAd4254@reddit

That is a myth. Linux was started in '91. The lawsuit(s) came in '93. By then, Linux's lead was insurmountable. Besides, it's been decades since and any 3-year advantage from back then, ought to have been wiped out by now. Yet that has not happened.

[-]

postmodest@reddit

USL vs Berkeley went to court in 1992 and was settled before Linux hit 1.0.0.

[-]

DazzlingAd4254@reddit

Sorry, I stand corrected with respect to the date. However, I wonder why, in the intervening 30 years, the *BSDs haven't caught up to Linux in terms of ecosystem size and general adoption. Might it be the licence?

[-]

bobj33@reddit

I've been running Linux almost exclusively since 1994. The big thing then was hardware support.

I installed Linux and it supported most of my hardware and within 2 months it supported all of it. My motherboard had this RZ1000 / CMD640 IDE chip that waas determined to have a data corruption bug. Linux quickly had a workaround but at the expense of a small performance loss.

https://en.wikipedia.org/wiki/CMD640

I went on the FreeBSD Usenet forums and basically I was told my new $3800 PC was junk and IDE was crap and that I should buy a SCSI card, SCSI hard drive, SCSI CD-ROM, external modem, new sound card, PostScript printer, and more. They also said to get a new graphics card although within 2 months XFree86 supported it and that was used on both Linux and FreeBSD.

As a college student without a job I couldn't afford any of that. I used every penny from my summer job to help pay for the computer in the first place.

I felt like the FreeBSD crowd was very elitist, were older, and had jobs. If they saw some cheap piece of hardware they tended to ignore it and call it junk. The Linux hackers on the other hand saw it as a challenge to get it to work on Linux.

When one OS installs and works with all of your hardware and the other says you should spend another $2000 which are you going to run?

[-]

postmodest@reddit

I'd say it's both: during that period from '92-'94, people put a lot of effort into Linux because it was provably free from Bell Labs code, and wouldn't get sued.

I think the big problem BSD faced is that it's much more vertically integrated. All the BSD Utils are in the tree, and you don't see "distributions" in the same way Linux has, so it's harder to monetize and compete. I mean, there's FreeBSD, OpenBSD, then, maybe Dragonfly and NetBSD? So the ecosystem didn't blow up like Linux did. And maybe part of that is that GPL gave people a greater feeling of ownership, whereas BSD means you can't stop someone from using your code without sharing. Plus, everything ends up in one silo and not a hundred distros.

[-]

Maykey@reddit

The lawsuit(s) came in '94

That's what when it ended

[-]

minus_minus@reddit

Thanks for making the point before I could. The bickering over 386BSD didn’t help either. While Linus, et al were rapidly catching up, BSD people were fragmenting into multiple tribes.

[-]

edparadox@reddit

Remember in the 1990s, when BSD was arguably ahead of Linux -- with BSD forks and derivatives like SunOS 4.x, MacOS, Playstation3's OS, DEC Ultrix, and many more.

Pretty sure, some of these did not happen during the 90's.

[-]

Albos_Mum@reddit

Honestly that just further proves the point /u/Appropriate_Ant_4629 is making.

Heck, just look at what the people reverse engineering Sony's OS software have figured out about the changes vs vanilla BSD. It's entirely possible that if BSD was GPL or if Sony had used Linux as the base that we'd be viewing them in a similar light to how we view Valve, assuming Sony would be happy to still have done all of that work if they had to make it publicly available.

[-]

wildcarde815@reddit

Im generally of the opinion that viral licensing shouldn't be used in places like the kernel but that boat was launched before I ever knew what Linux even was.

[-]

dantheflyingman@reddit

Some would argue that if a more permissive license was used, none of us would know what Linux was.

[-]

wildcarde815@reddit

Sure, and then there are those that argue Linux isn't actually FOSS because of the GPL. This is why llvm clang was created to displace gcc, why busybox exists as it does, and why zsh replaced bash on Mac. There's a lot of places using the GPL where the LGPL would be more appropriate.

[-]

dantheflyingman@reddit

Corporations views about FOSS has changed significantly since then, in large part due to the success they have had using open source software such as Linux. While it is cumbersome to deal with certain aspects of GPL license, it is hard to argue with Linus' claim that releasing Linux as GPL was the best thing he ever did.

[-]

wildcarde815@reddit

And theres seemingly some relucance to adopt the toddler fit of gpl3. That's not really convincing me that LGPL wouldn't have been better for the kernel.

[-]

elatllat@reddit

ZFS

[-]

buttux@reddit

It's been years since I looked into zfs, so might be wrong, but I recall a major design point of contention was how it bypassed the page cache and reimplemented a similar thing internally. Removing a page cache function from the kernel wouldn't be a problem for that filesystem, at least.

[-]

MarzipanEven7336@reddit

Yuuuup, ARC. Fuck ZFS.

[-]

dontquestionmyaction@reddit

Literally a core part of it

What are you talking about

[-]

Avamander@reddit

I mean, it could be nice if it just enhanced page cache instead of adding an another layer.

[-]

dontquestionmyaction@reddit

You can't really do that. ARC does a lot more than page caching, it's an entire large system that cannot just serve as an extended large cache.

Linux page caching has no support for compression, data integrity checksums, filesystem metadata (arc is aware of prefetch patterns) and a lot more.

The OS would need to provide many features to support it at that layer, and that is simply not the case.

[-]

dontquestionmyaction@reddit

This was especially true when ZFS was first being ported to Linux, but it still is. It just doesn't provide the needed hooks.

[-]

bilegeek@reddit (OP)

The out-of-tree OpenZFS file-system is among the users of write_cache_pages.

[-]

dagbrown@reddit

And that's likely exactly what they'll do.

The OpenZFS guys are so used to Linux kernel releases breaking ZFS that it's just a matter of course as far as they're concerned. ZFS just lags a release or two behind the kernel itself.

If you like OpenZFS, you use a kernel that's at least a release or two behind. If you like the latest kernel, you don't use ZFS. Seems pretty straightforward to me.

[-]

FunAware5871@reddit

TBF it's usually only an issue when a new major/minor drops, but after a few weeks of initial panic usually you get maybe 3-4 days of lag

[-]

Holiday_Floor_2646@reddit

If you like openzfs and latest kernel you can build it yourself together

[-]

matjam@reddit

Ack

I guess I’ll be rebuilding my zfs nfs server on btrfs soon. Yikes.

[-]

danburke@reddit

I'd rather move to BSD than give up ZFS, TBH

[-]

Thermawrench@reddit

Not in the know here. What is ZFS good for that BTRFS doesn't do?

[-]

Carnildo@reddit

Feature-wise, they're pretty similar. The big advantage of ZFS is an additional decade of large-scale deployments to shake the bugs out.

[-]

yakuzas-47@reddit

Btrfs's raid6 implementation still causes data corruption

[-]

postmodest@reddit

Yeah, if they do this I'd be looking at FreeBSD + bHyve + docker. Linux is slowly being subsumed into the Corporate Hellworld.

[-]

matjam@reddit

its a tough call but generally prefer debian on my servers after several decades ... I just don't have issues with it.

[-]

dontquestionmyaction@reddit

If you care enough about integrity to use ZFS, btrfs is just about the worst possible choice.

[-]

matjam@reddit

Clearly

[-]

ThatSwedishBastard@reddit

RAID5 is still broken in btrfs after almost 10 years, and I can't risk any of my data.

[-]

FryBoyter@reddit

RAID5 is still broken in btrfs after almost 10 years,

As someone who hasn't used RAID for many years, I would ask how widespread the use of RAID 5/6 actually is?

and I can't risk any of my data.

Backups? Because RAID is generally not a backup

[-]

dantheflyingman@reddit

Raid 5 is pretty common for homelab servers. People don't spend 2x for redundancy in their filesystem at home, and Raid 5 at the cost of an extra drive is worthwhile.

[-]

spacelama@reddit

"I don't use it, therefore it doesn't exist".

That's certainly a... take.

[-]

ThatSwedishBastard@reddit

I run RAID6 at work, RAID5 at home (raidz2 and raidz1 actually). When you outgrow a mirrored drive pair, it’s the way to go.

Backups exists because I’m not a lunatic, but restoring from them takes time and requires downtime.

[-]

edparadox@reddit

Any link towards the issue tracker?

[-]

ThatSwedishBastard@reddit

It’s in the official documentation.

”The RAID56 feature provides striping and parity over several devices, same as the traditional RAID5/6. There are some implementation and design deficiencies that make it unreliable for some corner cases and the feature should not be used in production, only for evaluation or testing. The power failure safety for metadata with RAID56 is not 100%.”

https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

The userspace tools warn you if you try to create a RAID5/6 filesystem now as well.

[-]

Albos_Mum@reddit

It's partially an over-reaction to the premature stable tag for btrfs as a whole, the actual details make it clear that the safety issues are completely avoidable if you're following relatively routine data integrity practices.

There's a good reason why the amount of people who pop out of the woodwork with real world experience using btrfs parity raid keeps increasing, although personally I'm happier with MergerFS + SnapRAID for my bulk storage than any typical RAID solution simply because I get all the functionality I want out of a RAID set up but have none of the drawbacks especially with upgrades, I just replace drives as necessary and have every possible byte of storage not dedicated to parity available to me.

[-]

Ullebe1@reddit

Note that one can do different RAID types for data and metadata. Doing RAID56 for data and RAID1 for metadata should be safe AFAICT.

[-]

SanityInAnarchy@reddit

Yeah, the safe thing to do is RAID1, which is a bit sad.

I guess the good news is, if RAID5/6 ever becomes safe, you should be able to migrate to it in-place with a balance.

[-]

spacelama@reddit

I prefer data integrity, so my personal move for my fileserver would be one of the *BSDs.

[-]

kongkr1t@reddit

after I lost 4 mirrored pools metadata to btrfs ~simultaneously~, no more btrfs for me, like ever. been on zfs ever since and there hasn’t been a single hitch. replaced a damaged device in a degraded zpool. rebuilt itself. lost no data.

after all this, I think my fs data integrity is more important than the OS. if OpenZFS people can’t make it run on Linux any longer, I’ll switch the OS and run stuff needed to be run on Linux in a VM.

[-]

acdcfanbill@reddit

I'm sure OpenZFS will re-implement it. A few years back the kernel team cut off non-gpl access to several SIMD command fucntions and OpenZFS had to re-implement those too.

[-]

chibiace@reddit

does it seem just a little suspicious that this is chosen to be removed so soon after bcachefs was.

much of the bcachefs hate seems manufactured and its well known that openzfs is disliked aswell.

[-]

Business_Reindeer910@reddit

nobody with any decision making power hates bcachefs. Don't make stuff up.

They just don't want to work with Kent Overstreet specifically. If Kent were to allow someone to manage the patches for him, things could go back to normal.

And as someone else mentioned, bcachefs is GPL2, so there is no problem there either.

Please don't allege things you clearly don't know anything about.

[-]

RRgeekhead@reddit

Where can I read up on the bcachefs drama? From what I happened to see Kent's behavior wasn't great, but not bad enough to warrant nobody wanting to work with him.

[-]

acdcfanbill@reddit

phoronix probably covered most of it, jsut search their site for bacachefs and i'm betting it will link you to the relevant lkml posts.

https://www.phoronix.com/search/bcachefs

[-]

Business_Reindeer910@reddit

probably search lwn

[-]

chibiace@reddit

woosh i guess.

[-]

Booty_Bumping@reddit

This doesn't affect bcachefs, since bcachefs is licensed under GPLv2 and intends to remain that way.

[-]

chibiace@reddit

After the NTFS3 and Bcachefs in-tree users of the iterator were moved off of it, for Linux 6.18 the "write_cache_pages" will be removed that is depended upon by out-of-tree, non-GPL file-systems.

other way around.

[-]

NotReallyFromTheUK@reddit

I'm a casual Linux user and have no idea what this means so I hope it doesn't affect me :)

[-]

kudlitan@reddit

It wont. Casual Linux users only use the default filesystem, usually ext4, which is GPL. This only affects non-GPL filesystems.

[-]

james_pic@reddit

If you're a casual Linux user, it almost certainly doesn't affect you. If you're using a casual-user-friendly distro, and you left everything at at the default settings, you won't be using anything affected by this.

[-]

FunAware5871@reddit

Days until Oracle will either dual license original zfs code or sign a legally binding document outlining how using zfs in Linux doesn't break the cddl: NaN

[-]

SilentLennie@reddit

I would say: copy the function to a GPL-licensed out-of-tree module.

But it's probably not that easy.

[-]

meskobalazs@reddit

The so-called GPL condom does not work.

[-]

SilentLennie@reddit

I'm talking about making a second module.

[-]

meskobalazs@reddit

And AFAIK that's exactly what is referred to as a GPL condom (ot at least one type of it). It's a big no-no.

[-]

Booty_Bumping@reddit

The GPL doesn't have such a loophole - it is supposed to infect everything, transitive or not.

But... the kernel itself is ignoring this reality by even providing exports that allow non GPL usage in the first place. It's a legal fiction that we only abide by because we assume nobody's going to start suing everyone.

[-]

SilentLennie@reddit

I'm just talking about making a second module with just that function.

[-]

Booty_Bumping@reddit

That doesn't solve the licensing problem. It would have to depend on lower level functions that would 'infect' it with GPL obligations. So you're right back where you started.

[-]

vythrp@reddit

My zfs pools are core to my ecosystem. :\

[-]

Appropriate_Ant_4629@reddit

Relying on one vendor as a core to your ecosystem seems a bit risky.

[-]

Novero95@reddit

OpenZFS is open source so if you consider it a "vendor" I guess you shouldn't be relying on Linux

[-]

TheOneTrueTrench@reddit

Not sure about the other person, but I use OpenZFS with Linux. If the Linux kernel makes using ZFS with it impossible/makes me stick with the 6.12 LTS (or even 6.6 or 6.1) kernel, well, I'll move to FreeBSD for my infrastructure, and switch my other stuff to BTRFS and use its similar functionality to backup to zvols on my server zpools.

Switching away from ZFS has HUGE data integrity implications. I understand the licensing implications of non-GPL DKMS modules, but for me, the filesystem is more important than the specific kernel.

[-]