To understand this topic fully, we have to talk about opensource licenses in general. Every License has a purpose, specially when you do free software. There are several versions out there, which the blog post from Whitesource summarize pretty well.
So every programmer or company can choose their way on how to license their software most likely freely, if they code their application as a single self-contained piece of software. If you however work on a driver and reuse parts of other given software or source you have to follow the same license as the source you reuse not to go into a conflict with licensing.
Some of you might have heard of the GPL condom. A patch from a Facebook developer for utilizing Nvidia GPU hardware in their network stack started a discussion upstream around the new NetGPU code in regard of license conflicts and a potential loop-hole since day one. The kernel module loader refuses to link modules against symbols which are exported with EXPORT_SYMBOL_GPL() and tagged that way are tainting the kernel with the âPâ flag, as cannot be used for modules with source code in the kernel tree.
To fix that issue a patch got added to the Linux-Mainline kernel:
So we have to follow the kernel 5.9 development more closely and see how Nvidia will find a way to provide their drivers still. A potential solution would be to recreate the features they used from GPL licensed code on their code-base, so a reveal of their code is not needed. However, old unmaintained driver series wonât be supported, unless a community developer finds a way to work around this now fixed issue in a legal manner.
Yeah. I feel like NVIDIA might just say, âwell⌠since youâre not supporting our proprietary drivers anymore⌠I guess weâll just drop Linux as a wholeâ.
This is good. Most servers, and that includes machine learning servers, run linux.
NVidias biggest market is actually servers. That applies to AMD as well, their gaming GPUs are just failed attempts or cheaper versions of the âactualâ ones.
I doubt they will throw away a chunk of the ML server market.
Now, I just know most servers use linux, I do not know if most applies to ML servers and science ML as well. But it would not surprise me if a lot of them run linux, and that is their biggest market afaik. Gamers/consumers are not their main audience. The big companies pay many thousands of dollars for their accelerators.
So speculating leads me to think that they most likely will allow open source drivers.
Hopefully thisâll motivate Nvidia to start opening up their drivers in some capacityâŚ
Iâm using their card right now, and really not willing to move on to AMD offerings yet.
Before I give my thoughts, I would like to say that I have used NVIDIA for my graphics most of my time with computers. I plan on going AMD next time I upgrade, but the proprietary drivers are tolerable (aside from my OCD about running proprietary software).
Anyways, some people see this as a way to get NVIDIA to act reasonably, but I donât think that this would be a remotely possible outcome. Yes NVIDIA profits off of Linux servers, but there are certainly ways that they could avoid open source while making things hell for both the Linux desktop user and distro maintainer.
One possibility is that they still provide support, but distributions would have to patch their kernels to remove this. Then, the distro would have to choose between having their kernel patched by default or having two separate kernel packages. Likely, the first one would have to be the case for most distro-bases that focus on efficiency like Arch/Manjaro. But for more upstream oriented distro-bases like Debian, OpenSUSE and Fedora, they may either have the patched kernel in their nonfree repos or, more concerningly, drop proprietary drivers all together.
The (relatively) more concerning possibility is that NVIDIA creates a fork of Linux with their proprietary code enabled. In this case, their driver might not just be a kernel module, rather a necessary part of the code. This could lead to other companies creating their own kernels with proprietary drivers enabled as well, creating an almost Android-like situation. For those who donât know, install media on Android (ROMs) is device specific since the kernel itself is patched by the OEM to work with the phone. This would set a precedent for this becoming the case for Linux, although in a slightly different manner. This would make life a living hell for the devs of distributions.
I know my ideas might seem a bit outlandish, but NVIDIA having been checkmated in this situation seems unlikely.
If i understand well, this is about disabling normally GPL modules, if they import symbols from proprietary modules.
What i donât grasp is: how does this also disable proprietary drivers?
This is explicitly forbidden by the GPL, and would be actionable in a court of law. Others have tried it before, and they were sued by the FSF, and they either lost or settled the matter out of court.
More people move (back) to Ubuntu which may not have this flag implemented in their kernel
More people check out alternative kernels like Liquorix which could have this removed
More people give up on Linux and return to the proprietary wonderland which is Microsoft Windows
For the first, as I have experience in Ubuntu it wouldnât be so bad for me, but I would miss the AUR.
For the second, there are lqx kernels and headers available in the AUR, so people could use that to check it out if lqx team choose to pivot more toward proprietary support, or add in another repository and use Pacman / Pamac to fetch a forked alternative intent on supporting proprietary hardware if itâs not possible to use with either default or lqx.
For the third, well⌠thatâs what we get for being judgmental about user choices and make it harder for anyone to use a piece of hardware, especially if they spent USD$1,400 on an RTX 3090. If someone has that kind of money to sink into a GPU, they most certainly can ditch us and flip the bird while doing it.
Yâall wonder how Canonical made a brand which represents Linux in Microsoft Windows? They allowed proprietary code to function because kernel developers and system distributors were not strictly the arbiters of what functioned and what didnât. This feels like a move which is giving people who want whatâs available from the current best graphics rendering and arithmetic compute hardware brand going a really hard time.
If this so happens to make nVidiaâs hardware cease to function on mainline kernels, then we best be praying that AMD has a big navi to pull out the hat before long, else weâre going to see a precipitous drop of persons within the Linux userlandâŚ
As I understand it, the Windows subsystem for Linux runs the GNU/Linux system in a virtual machine, and in addition to that, Microsoftâs Hyper-V is open source. They had to open up the source code because â this was still under Steve Ballmerâs reign â they had been caught red-handed hard-linking a GPLâd network driver into Hyper-V.
Ballmer claims to stand by Linux now. Then again, that man doesnât have a spine to stand on because everything heâs ever done had been a business decision and it took over 90% market share of Linux on web servers for the past five years to agree with Microsoftâs current CEO that his company was on the wrong side of history.
This doesnât give the Linux userland any foothold to influence hardware purchasing decisions, and for this thing to potentially make nVidia hardware no longer function because of nVidia being too big to change may will put us on the wrong side of history.
This provides the interface between the netgpu core module and the
nvidia kernel driver. This should be built as an external module,
pointing to the nvidia build. For example:
export NV_PACKAGE_DIR=/w/nvidia/NVIDIA-Linux-x86_64-440.64
make -C ${kdir} M=`pwd` O=obj $*
When ever a Nvidia or other proprietary external module doesnât compile, community developers tend to temporally change the license so a compile is possible. However there is always a way to avoid usage of GPL-licensed when the same patch gets properly written. More or less with every new kernel the nvidia_uvm is most likely affected to have GPL issues and need a rework to function.
So far the community developers always find a way to get proprietary drivers compiled. Letâs hope that also for 450xx series a working version for Kernel 5.9 will emerge one way or the other.
In other words: that supposedly GPL module currently uses non-GPL code (symbols) from Nvidiaâs non-free driver, rather than properly interfacing with it (such as providing a free API to the driver). Did i get that right?
Yep. Is more or less a proposed feature to be able to utilize some proprietary code with an open licensed part. Main part is that using GPL-code exported in a proprietary code is not given by the license. It is like the man in the middle principal: Are you GPL? - Yes he is - OK. So the combination of mixed code is always a burden you have to verify with the law. In simple terms: it is always better to only use parts of the kernel code for your driver you are allowed to with the proper licensing.
