Since the Linux kernel linker code is designed to enforce Linus Torvalds's opinion of how the GPL plus a syscall exception should work, he likely has a legal claim against Nvidia for circumvention of copyright protection (DMCA 1201). This is obviously something Linus would never do, and it would be patently awful for the FOSS ecosystem as a whole if he did... but I kinda want to see him do it anyway just because of Nvidia's shenaniganery over the years.
There's a pretty good argument to be made that Linux, the most high-profile GPL project in existence, not trying to enforce its license/copyright terms on reasonable grounds, is far, far worse for the FOSS ecosystem than the alternative of being sort-of-mean to corporation XYZ (where XYZ = Nvidia, VMWare, RandomHardwareCorp Inc, whatever). If the biggest 800lb Gorilla in the room isn't willing to go to court over it, that doesn't paint a very rosy picture for the rest of us.
If Linux is going to just use "soft" mechanisms to force the hands of MegaCorps when they do blatant license/copyright violations, then they might as well put a fork in the GPL, call it done, and switch to BSD3 or MIT+Apache or something. And before people yell at me, this is precisely how LLVM operates; the project does not use strong copyleft licensing, but purely technical means, to "force" upstream cooperation, due to factors like APIs churn and extremely high development velocity. And it seems to work pretty well, actually, without watering down their respective chosen license.
If someone starts the ball rolling, it's a long and expensive legal battle with tons of parties involved. Consider the Oracle v Google lawsuit which started in 2010 and was resolved in 2021.
With the number of companies involved in the kernel you are looking at a much longer and more expensive trial all around.
This has always been the weakness of both the GPL and the US civil justice system.
Are they? Because big companies seem to sue each other all the time, even while actively collaborating in other areas. Is Linus suing NVIDIA for blatantly working around technical measures to prevent copyright infringement really worse than Apple suing Samsung for selling phones that look like theirs, or than Oracle suing Google because they made Java-compatible APIs?
> If someone starts the ball rolling, it's a long and expensive legal battle with tons of parties involved. Consider the Oracle v Google lawsuit which started in 2010 and was resolved in 2021.
Sounds more like normal "war". Yeah, you'd have to figure out who would finance Linus' side, but it doesn't seem like it should be that difficult.
> With the number of companies involved in the kernel you are looking at a much longer and more expensive trial all around.
Why would other companies be involved? Linus doesn't have to sue everyone, he can just sue NVIDIA. Other companies might submit briefs, but that would be voluntary.
> Why would other companies be involved? Linus doesn't have to sue everyone, he can just sue NVIDIA. Other companies might submit briefs, but that would be voluntary.
In a civil lawsuit, both parties are entitled to "discovery" which means knowing what the other party knows about the controversy in question. It would be reasonable discovery for nVidia to want interviews with engineers in HP that have contributed to kernel development. Whether these companies want to be involved in the lawsuit or not, they'll get dragged in because they've directly participated in kernel development and/or governance.
Now, discovery isn't unlimited, so it's possible for a judge to say "actually, this steps too far, you only need to talk to linus" but that's in no means a guarantee.
The remedy is only one part of the cost of lawsuits.
Discovery and attorney fees would be a big portion of the picture here. If there's no settlement reached, each party will have a right to collect and comb through documents related to the lawsuit. Further, they'd have the right to interview (take a deposition of) everyone involved in decisions surrounding the controversy.
That means, nVidia would (likely) have the right to start talking to people in HP, Intel, AMD, Oracle, broadcom, On semiconductor, etc. Practically anyone involved with kernel development and decision making around kernel development.
The US civil legal system is designed to try and force parties into settlement. However, when you have a major corporation with cash to burn, they can win simply by dragging everything out.
nvidia are in compliance, they are working around it with a shim, that is why he says the new guards are put in place to enforce the "intention" of the original changes. There is no case
That's not really how licences work. "Ha, ha I have a workaround that negates the intent of your license with a clever hack" is not a defensible position.
Counterargument: The FSF would get very mad if you made a DMCA 1201 claim based off GPL code. In fact, they explicitly put a "this software is not DRM" clause in GPLv3, to prevent exactly this kind of lawsuit.
That being said, even in the alternate universe where Linus decided to relicense to GPLv3 + syscall exception[0], they could still make a normal infringement claim on the GPL copyleft. DMCA 1201 claims are just a really ironic thing to add to such a lawsuit.
Reportedly, LLVM, while initially successful, has severely slowed down its development lately, with many historical contributing companies having abandoned LLVM in order to focus on their own company-specific languages. So LLVM may no longer be the beacon of permissive licensing that it once seemed to be.
Afaik the only notable departure has been Google for Carbon, but afaik even they use llvm as the backend. I believe the only negative consequence has been to clang not llvm itself.
I seem to recall seeing mentions elsewhere, but this was all I could find. However, as I don’t have any first-hand knowledge myself, I’ll gladly yield to your superior experience.
It's not a bad claim to have in case Nvidia ever decides to take legal action against the Linux foundation. Launching a viable counter suit with a serious impact on Nvidia's business opportunities should work as a nice deterrent against future problems.
> Given that symbol_get was only ever intended for tightly cooperating modules using very internal symbols it is logical to restrict it to being used on EXPORY_SYMBOL_GPL and prevent nvidia from costly DMCA circumvention of access controls lawsuits.
Which is such a lovely way of putting it. Of making a mock of Nvidia obviously flouting all intent & regard & doing whatever the heck they want.
If Linus is happy to literally give NVIDIA the finger [1], then maybe he/Linux Foundation would be willing to give NVIDIA the legal spanking they deserve (IMO)? We can only dream :)
>Let's be clear about this: lawsuits destroy. They don't "protect". Lawsuits destroy community. They destroy trust. They would destroy all the goodwill we've built up over the years by being nice.
Opinions can change. We should all know by now that appeasement only works as long as the other party is acting in good faith and harsher solutions exist for a reason.
At some point, when you have a trillion dollar entity acting in bad faith for that long, maybe your only option left (besides giving them the finger) is to pursue them in courts.
nVidia is actually a Silver Member of the Linux Foundation[0], meaning they (and 1200 other Silver companies) contribute $5000/year. I wonder how a lawsuit would work, given that some portion of Linux's legal costs would be paid with nVidia's own money. Plus a majority of the LF's members are probably partners or customers of nVidia, and some members are competitors.
"Given that symbol_get was only ever inteded for tightly cooperating
modules using very internal symbols it is logical to restrict it to
being used on EXPORY_SYMBOL_GPL and prevent nvidia from costly DMCA
circumvention of access controls law suites."
This is literally an attempt to claim the protection of the DMCA's anticircumvention law (which makes it illegal to "circumvent" DRM) for the Linux kernel, an open source project. It's also a tacit admission that EXPORT_SYMBOL_GPL is blatantly a DRM scheme (which it is).
Personally I loathe NVIDIA and have no particular interest in defending their behaviour; however, I find it extraordinary here that the Linux project is trying to claim the DRM anti-circumvention law applies to an open source project. It's pretty bizarre given there are few laws which seem more universally opposed by the open source community, and seems to me quite at odds with the values of FOSS - as is any DRM scheme.
Why would that be pretty bizarre? The entire goal of the GPL was to use copyright law against itself (hence the term copyleft): the stronger copyright law gets, the stronger GPL protection gets. So to me, it's pretty much in the spirit of the GPL to wield additional copyright legislation to protect open source software.
Sure - I think there's a hair to be split here where we could argue that weaponizing anti-circumvention logic in GPLv2 is generally in the spirit of the GPL as a whole, but then also say they in GPLv3 we decided to remove it because while it's in the spirit, it's too dangerous, and net-better for user freedom if using GPLv3 software doesn't carry the risk of accidentally tripping up anti-circumvention laws.
I get the impression that GPLv2 is (perhaps unintentionally) in the spirit of open source, whereas GPLv3 is in the spirit of Free Software. Thus Linus's famous "I just want the code" rant.
GPLv2 was created by and for the free software movement. The notion that it is somehow more aligned with a depoliticized, whitewashed ancestor of that movement than it is with the real deal is absurd.
It's absurd, but true. I do think it's unintentional, but due to historical reasons GPLv2 doesn't prevent tivoization, which is more aligned with open source than with free software.
Again, I'm not discussing what the intentions were, nor what the practical effects used to be 20 years ago, I'm referring to it's position today.
Suppose a hypothetical that GPLv2 never existed and that the GPLv3 was written in 1990, then someone came along today and wrote a variant of GPLv3 that specifically permitted tivoization and firmware blobs; surely such a license would be seen as moving from open-source to free software.
>3. Protecting Users' Legal Rights From Anti-Circumvention Law.
>No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
>When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.
kernel taint is obviously a DRM scheme, that's not a secret. GPL isn't a permissive license, it's a strong copyleft license that has teeth. there's nothing hypocritical about the taint mechanism - it's open-source, and as long as your code is GPL you can do anything you like. it literally just enforces the linking provision of the GPL license.
> it literally just enforces the linking provision of the GPL license.
Which provision are you referring to? The word "link" is only in one spot in GPL 2.0 and isn't talking about this situation.
But assuming you mean it's just enforcing the text about derived works, that would only be true if the GPL exports were consistently linux-specific enough that using them makes your code a derived work.
> It's pretty bizarre given there are few laws which seem more universally opposed by the open source community, and seems to me quite at odds with the values of FOSS - as is any DRM scheme.
Even if we don't like a law, it's a law, and you live in reality where it applies — and you should use it when needed. I don't find it bizarre at all.
I don't understand what porting from other architectures has to do with anything. If Linux has some code for amd64, and then Linux developers port that code to aarch64, why would the aarch64 code be different from a licensing perspective than the amd64 code?
I don't know why they have non-GPL symbols. My understanding is that they could have marked every symbol as GPL. There's presumably some desire to allow limited closed-source drivers. You'd have to ask someone involved or find some writings from someone who knows. Maybe Google can help.
LGPL sets out better, clearer boundaries. And it allows some things that might arguably be derived code, while the GPL would hedge much closer to that line. So it has a use.
Also FSF tends to overstate the importance of linking.
You're right, it is open source. As such, this doesn't violate user freedom since if Nvidia, the user in this context, don't like this, they can fork the kernel and change the behavior however they want. Of course, nothing compels anyone else to use such a kernel.
The check is just enforcing the legal interpretation of the rights holders, the check code itself doesn't matter legally. Just like how stripping some DRM doesn't mean you now own the copyright to the video.
That raises an interesting question: Is modification of the source that is used to produce the executable software necessarily modification of software from a DMCA perspective? Or does the circumvention have to involve influencing an extant binary in some way? The legal answer, in either direction, isn't obvious to me.
Especially since the GPL license does explicitly allow you to modify the source.
> there are few laws which seem more universally opposed by the open source community, and seems to me quite at odds with the values of FOSS - as is any DRM scheme.
My reading is that this is obviously a half-serious and half-sarcastic remark.
The serious message is that the author believes it's a genuine case of copyright violation. The sarcastic message is that - given the context that the bar of invoking DMCA is so low that almost every trivial check can be classified as "anti-circumvention devices" (including the GPL symbol check in the Linux kernel), making it universally opposed by the FOSS community - Thus, the author thought it would be fun to flip the table here to make the exact same legal threat back to proprietary software vendors.
It's simultaneously a copyright infringement accusation, a sarcastic comment on the excessively broad scope of DMCA, and a half-serious revenge in the form of a hypothetical legal threat.
It reminds me of a song about cryptography called Alice and Bob, which made a similar joke. The lyrics read:
> Sending data across the network in a safe way
> Protecting messages to make my pay
> If you hack me you're guilty under the DMCA
The joke of the song is that proprietary software vendors often use DMCA to suppress vulnerability disclosure from security researchers, thus, a security researcher who implements an insecure data encryption protocol can theoretically make use of the same legal threat to cover up their own incompetence - which is absurd from a technical perspective but also the point of the joke.
Linux's license is GPLv2 plus a syscall exception. If it was GPLv2 alone, proprietary modules would probably be infringing. However, since Linus specifically said syscalls don't trip GPL copyleft, kernel symbols that are syscall equivalents also don't trip GPL copyleft. So they have to have a loader that checks license data to know what symbols can and can't be linked to avoid a license violation under Linus's interpretation of their GPL exceptions.
You are correct that this is kernel level DRM[0], and Linus might even have a legal claim against Nvidia for circumvention of copy protection here. GPLv3 explicitly disclaims any form of copy protection in covered code, which would at least theoretically prevent this kind of lawsuit, except the clause isn't court-tested and Linus specifically hates GPLv3 for adding the TiVo clause[1].
This was implemented decades ago, and the original goal was actually just to stop getting bug reports relating to crashes in the Linux kernel caused by proprietary modules they can't fix. Enforcing the GPL was a side benefit.
[0] Not to be confused with the other DRM in the kernel, the Direct Rendering Manager.
[1] He doesn't hate the TiVo clause itself, he just doesn't like retroactively adding it to v2 software and changing the deal, because he doesn't like what he feels is Linux being co-opted by the FSF.
> Linux's license is GPLv2 plus a syscall exception.
Did Linus really sought to have every contributor of Linux that licensed their contribution as GPLv2 agree to this specific exception, and relicense it as GPLv2 plus syscall exception? This sounds unbelievable.
> 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".
This just seems like a legal opinion of Linus that states that userland programs are not derivative from the kernel (and thus don't need to be licensed as GPLv2 themselves), but this is kind of obvious and expected, right? I mean, userland Windows programs aren't derivative from the Windows kernel either, or macOS programs from XNU, or etc.
Also note that at the moment Linux was created, all Linux programs were originally made for other operating systems. Programs like bash and gcc predate Linux. They couldn't be derivative works of the kernel, even if they wanted to, because the kernel didn't exist when they were created.
I highly doubt that any kernel developer could successfully sue authors of userland programs for copyright infringement, regardless of what Linus thinks about it. So this isn't really an exception of the GPLv2 but just a _clarification_ that the wording of the GPLv2 shouldn't be interpreted in a way to make userland programs infringing (because they aren't, and wouldn't be even if Linus didn't clarify)
This means that Linux is free to incorporate any GPLv2 code it wishes without asking people to relicense it as "GPLv2 plus syscall exception" because Linux itself is just GPLv2.
The exception is necessary because the GPL is designed to be viral. The OpenJDK project has a similar exception (the Classpath exception), else anything on the classpath would count as a derivative work. Proprietary licenses don't need those exceptions because they have a completely different objective to begin with.
> Also note that at the moment Linux was created, all Linux programs were originally made for other operating systems. Programs like bash and gcc predate Linux. They couldn't be derivative works of the kernel, even if they wanted to, because the kernel didn't exist when they were created.
That might be true for those applications. However, not having the syscall exception would make Linux-specific syscalls such as IO_uring accessible to GPL software only.
> I highly doubt that any kernel developer could successfully sue authors of userland programs for copyright infringement, regardless of what Linus thinks about it.
That would be the intent of the GPL, which is designed to extend its effects to every other software the original work is "linked" with. Remember, the GPL has been tested in Court before.
> If it was GPLv2 alone, proprietary modules would probably be infringing
I'm not so sure, at least in the US. There were several cases in the '80s and 90s or thereabouts involving video game cartridges which might be relevant.
The consoles back then did not have memory protection or multiple address spaces or user/system modes. The ROM in the cartridge simple appeared at a fixed place in the address space, and typically the firmware in the console would do some system initializing, then call an entry point in the cartridge.
The code in the cartridge had full access to the hardware and to the firmware in the console.
The console manufacturers wanted to control the cartridge market. Among the many ways they tried to keep third parties from making compatible cartridges was copyright. The firmware in the console was copyrighted by the console manufacturer, and the code in the cartridge (in most cases [1]) extensively called into that firmware.
Since the third parties had figured out the firmware by reverse engineering (usually in violation of the console's license) in many cases they even called into firmware code that authorized games did not use because that was not part of the firmware's API.
My recollection is that the third parties won in most of those cases.
[1] I believe that there were some third party games where the game maker had not been able to figure out how the firmware worked but they did know how the hardware worked, and so they made their cartridges completely take over. The console firmware was effectively just a boot loader for them.
How would proprietary drivers work on a GPL microkernel like the Hurd? Presumably the driver would be a userspace program. Is there something else that would prevent proprietary userspace drivers on the Hurd? Seems like this must have been something that people have considered before. Otherwise it would be pretty amusing if GNU/Hurd could have NVidia proprietary drivers that Linux wouldn't allow.
Right, and how would you go about circumventing this protection? By using syscalls. So you could argue that you only used syscalls, and thus adhered to the rule.
> Why shouldn't a proprietary driver be able to interact with a free kernel?
Proprietary drivers can interact with the Linux kernel.
Provided they only use fairly generic OS-functions, which are to be found in many similar kernels. Such drivers, which do not rely on Linux-specific functions, cannot be considered "derived works" of the Linux kernel, and are therefore free to choose whatever license they like.
However, any driver which makes use of Linux-kernel-specific interfaces, which are not found in other OSs (even in other Unix-like kernels) are, pretty much by definition, a "work based on the program" of the kernel and therefore must be licensed similarly. See the text of the GPL-2, which the kernel is licensed under:
> This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law:
> These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Note that the LGPL exists specifically to allow the linking of separate Free and proprietary software, which is forbidden by the GPL. But Linux is licensed under the GPL-2, so those extra permissions do not apply.
If the Nvidia driver stuck to the generic kernel API, it would be fine. But it doesn't. It tries to use Linux-only APIs, which are marked for use by license-compatible GPLd drivers, without itself being GPLd.
This is a clear violation of the Free Software license that Linux is made available under.
> This is a clear violation of the Free Software license that Linux is made available under.
I don't see why. The "Linux-only APIs" are a feature imposed by the Linux kernel developers, not by the GPL. Trying to circumvent it is of course contrary to the wishes of the Linux kernel developers, but that doesn't mean it's a violation of the GPL. The GPL does not say that no program that interfaces with a GPL-licensed work can do anything the authors of the GPL-licensed work don't like.
It would be a violation of the GPL if NVidia tried to ship its own Linux distro including its proprietary drivers. But it's not doing that. NVidia doesn't ship Linux at all. Linux users install NVidia's drivers alongside the Linux that they install.
> This is a clear violation of the Free Software license that Linux is made available under.
This is your opinion.
My opinion is that it is a clear violation of the GPL if a program provides two sets of interfaces, one set to be used by other GPL programs and one set with crippled performance for non-GPL programs.
This is a restriction on use that has nothing to do with GPL, which says: "This License explicitly affirms your unlimited permission to run the unmodified Program.".
Crippling the performance for the users who choose to use the GPL program together with a non-GPL program is definitely incompatible with "unlimited permission to run".
Whoever has written the original GPL program has no right to impose limits on the users of the program. If they want to impose limits, they must choose a different license, not GPL.
The restrictions imposed by GPL are based on copyright, i.e. they refer to transferring copies of the covered work, but not to how it should be used.
The GPL does not prevent users from running the Linux kernel in any manner they choose.
What it does disallow is for users to write code which is "based on" Linux code, and then distribute that code to other users on terms which are incompatible with the GPL.
You can run whatever mix of GPLd and non-GPLd code you want. You can even edit your Linux sources in a way that removes the GPL license checks for modules and build your own kernel, and run it, and no-one can legally stop you - not even Linus himself.
But you're not allowed to distribute work-based-on-GPLd-code-that-isn't-licensed-under-the-GPL to anyone else. And neither is Nvidia.
Unfortunately, suing Nvidia over this would cost millions, if not tens of millions, if not hundreds of millions, of dollars. So creating a technological barrier to fuck with them and their bullshit business model instead is a much more achievable goal.
Writing a program "based on" an API, i.e. which invokes the provided functions, is not a derivative work.
If this theory would be accepted almost all the existing programs that have been written since the first electronic computers would be derivative works and no software companies would have ever existed, because they could never have claimed copyright protection.
NVIDIA has never distributed any derivative of the Linux kernel in their GPU drivers. They distribute their own kernel modules, which are loaded by the end user and this is perfectly compatible with the GPL.
Some kernel developers try to cripple the NVIDIA modules by preventing them to find the symbol addresses that must be used, but this is a use restriction imposed by these developers on the Linux users and which has nothing to do with what is written in the GPL.
Indeed, the LGPL should never have been needed, because LGPL is the correct variant of GPL and the standard GPL should have been identical to what LGPL is now.
Even with its illogical theory about the coverage of "combined" works, not even the GPL covers the programs that use an interface provided by a GPL program, but which are distributed only separately from it, like a shared library or a kernel module.
So the NVIDIA kernel modules have never been incompatible with the GPL.
The fight against non-GPL kernel modules has nothing to do with the GPL, but it is strictly the creation of certain kernel developers.
With static linking you take someone elses code and put it into your own artifact and then distribute that to users. This means that you need a license to distribute their code. Not just that, because of the way static linking works, you need a license to distribute modified version of the code.
With dynamic linking you never distribute someone else's code so you don't need a license to distribute it.
> Crippling the performance for the users who choose to use the GPL program together with a non-GPL program is definitely incompatible with "unlimited permission to run".
How so? It says "run the unmodified Program". The checks the Linux kernel does are part of the unmodified program. If that unmodified program doesn't meet a particular user's needs, they can go find some other program. The GPL does not impose any requirement that the unmodified Program must meet all of the needs of all users. Nor does it impose any requirement that the unmodified Program must treat all other programs equally. Nor does it impose any requirement that the unmodified Program cannot have any restrictions on use that are not explicitly imposed by the GPL.
> Proprietary drivers can interact with the Linux kernel.
> Provided they only use fairly generic OS-functions, which are to be found in many similar kernels. Such drivers, which do not rely on Linux-specific functions, cannot be considered "derived works" of the Linux kernel, and are therefore free to choose whatever license they like.
> However, any driver which makes use of Linux-kernel-specific interfaces, which are not found in other OSs (even in other Unix-like kernels) are, pretty much by definition, a "work based on the program" of the kernel and therefore must be licensed similarly.
Now given that, can you explain why the "save the FPU state" function is marked as one of those special interfaces?
> However, any driver which makes use of Linux-kernel-specific interfaces, which are not found in other OSs (even in other Unix-like kernels) are, pretty much by definition, a "work based on the program" of the kernel and therefore must be licensed similarly
GPLv2 defines a "work based on the program" thusly: "a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language"
To be a derivative work of another work under US copyright law the work must contain sufficient copyrightable elements copied from that other work to require permission from the owner of that other work's copyright owner.
If all you've copied is a few function names and data structure layouts in order to call those functions that seems unlikely to be enough to make your work a derivative work. It doesn't really matter whether or not those functions do things found in many other works or just one, because you aren't copying the functions themselves.
> Note that the LGPL exists specifically to allow the linking of separate Free and proprietary software, which is forbidden by the GPL.
Linking GPL and proprietary software together is not forbidden by the GPL. If you do so though GPL imposes requirements on you if you distribute the result, and those requirements will likely be impossible to meet.
If you are just linking the GPL and proprietary software for you own use GPL does not care.
i am all for promoting GPL code and i prefer that non-free kernel modules would not exist, but is there any reason other than promoting the GPL why a non-free module should not use linux-only APIs?
or the reverse, if getting rid of non-free modules is the goal, why even have a syscall exception? why not force all modules to be GPL?
> but is there any reason other than promoting the GPL why a non-free module should not use linux-only APIs?
I think this question illustrates something of an invisible generation gap in software. GPL is not a utilitarian license. There is no materialistic value in choosing to use the GPL whatsoever. The text of the GPL is itself a legal edifice specifically designed to dismember the very framework in which it exists, rendering it anti-utilitarian.
This is all to say that the GPL is politics. One chooses the GPL specifically for political reasons. In politics, you do not go out of your way to aid your ideological adversaries; you either convert them or destroy them.
> if getting rid of non-free modules is the goal, why even have a syscall exception? why not force all modules to be GPL?
Despite what I just said about GPL as ideology, the GPL is simultaneously a legal construct which necessarily must bend to the rules of the framework it exists within. The logic of GPL extending through syscalls is based in a legal argument similar to that used in the Google vs. Oracle debacle -- we created the "shape" of this API, so we have certain rights regarding it. The "shape" of the Unix syscalls predate Linux and are therefore beyond the project's reach, legally speaking.
The best analogy for the GPL that I've seen is to consider what happens with a typical for-profit corporation. If you join the company (they have to agree to hire you for this to happen), then in the work you do for the company, you have free access to all the IP of the company, to whatever extent is it useful in the tasks you are undertaking within the company. You must, of course, promise not to leak the IP outside the company.
Now consider that there is a similar organization: a not-for-profit organization of programmers for which the only qualification for entry is that you agree to use the same license as everybody else. Once you do, you are free to use all the IP of the organization. You may not, however, use the IP of the organization for things you might do under different licenses, since that is not considered to be within the scope of the organization.
In short: if you don't want to join the GPL "organization", don't. But just as you don't expect to get access to Nvidia's internal IP unless you join Nvidia, don't expect to get access to the GPL organization's IP.
The "syscall exception" is there to make clear that userspace acting on the defined ABI/API boundary between userspace and the kernel doesn't need to be GPL, even if it is using linux specific userspace APIs that might otherwise plausibly cause such a binary to be a derived work.
That is, yes, you're allowed to port non-GPL code to Linux.
On the other hand: the real practical concern that kernel developers have is needing to debug NVidia's closed source code, or people developing an expectation that such code (or the code of a hundred other vendors) won't be broken between kernel releases.
the exception for userspace obviously makes sense. but why and how are non-free kernel modules allowed at all? i'd think that userspace is a boundary that is easy to define, so it should have been possible to allow non-free userspace without allowing non-free kernel modules.
The non-free kernel modules are never included in the kernel. They are loaded by the end user, so they are not covered by GPL.
Except for the fact that the CPU is in privileged mode, there is no difference between loading a kernel module and launching a dynamically-linked user-mode executable file.
Not all non-GPL modules or executables are non-free. Many have licenses that are more permissive than GPL, e.g. BSD or MIT, but they are still affected by these anti-non-GPL measures.
If non-GPL kernel modules were not permitted, then by the same reasoning no non-GPL executable files should be permitted, so in such Linux computers absolutely all programs, libraries and modules would have to be GPL.
Perhaps there are people who dream to use such a computer. I have been using Linux for decades and I have never seen a single computer that would have remained useful for anything after the instant when all the non-GPL programs would have been deleted from it.
ah yes, of course. kernel developers can not control what modules i load, they can only control if the module violates the GPL which it only does if it is a derivative work which is only the case if linux specific APIs are used.
I have been using Linux for decades and I have never seen a single computer that would have remained useful for anything after the instant when all the non-GPL programs would have been deleted from it.
if that includes any non-GPL FOSS, sure, but most such software would have switched to GPL very quickly if that would have been the case.
> is there any reason other than promoting the GPL [...]
Isn't that reason enough?
> why even have a syscall exception?
Because Linus is more pragmatic than RMS.
Also, syscalls are generally not Linux-specific, so it would be hard to argue that programs that use them are "works based on" Linux. Making the syscall exception explicit is, IMO, mostly a historic reassurance for proprietary driver/program vendors that code they wrote for AIX/Solaris/HP-UX/etc... can be recompiled for Linux without risking any compliance issues.
he probably is, but that is not the reason here. even RMS fully agrees that using it in the normal USING fashion does not trigger copyleft. This is why you can compile proprietary software with gcc, and similarly, when gcc had a java class library project, it was GPL+classpath exception
> However, any driver which makes use of Linux-kernel-specific interfaces, which are not found in other OSs (even in other Unix-like kernels) are, pretty much by definition, a "work based on the program" of the kernel and therefore must be licensed similarly. See the text of the GPL-2, which the kernel is licensed under
Does that follow? If someone makes a program that uses an API that's only found in NT or XNU, does that program become a derivative work of those kernels?
Surely this argument could also apply to hardware. A piece of hardware's interface would be its API, which would surely mean that any software written to use that interface (drivers) would be a derivative work.
Which in the case of proprietary hardware, using non-standard interfaces, would mean that software would need a license from the manufacturer to be distributed.
> Linux is literally implementing kernel level DRM, the thing free software swore to destroy.
Free software enforcing its own principles is in no contradiction of free software. Why should proprietary software be able to get all the benefits of free software and play by none of its rules and free software is supposed to just take it?
Even democratic societies have mechanisms to protect themselves that are restrictions of some kind on expression.
There are plenty of proprietary OSes out there that give zero shits. Why there can't be some that do? Or does everything need to be just cold, industry serving tool without any human care behind it?
> Why shouldn't a proprietary driver be able to interact with a free kernel?
Because the kernel is licensed under GPL, that's kind of the whole point of Linux. The intention of the license is that anything linked and loaded into the kernel is released under a compatible copyleft license.
Technically that's wrong. Anything you distribute to another person needs to be GPL. You can link and load anything you want into the kernel for your own purposes.
Personally, I'm not persuaded that a loadable proprietary kernel module would constitute a derivative work, I don't see how the GPL could be enforced on a 3rd party like that. I think the courts and juries would be very sympathetic to Nvidia.
If the GPL status wasn't a problem, Nvidia wouldn't be so nice to Linux. They could just as easily patch out the GPL symbol routines in a malware like fashion, yet the billion dollar company decides to play nice.
All Linux would need is for one court in one relevant jurisdiction to interpret GPL like they do. If a French court forces Nvidia to stop making selling data centre products in France, that'd be enough to seriously hurt Nvidias's bottom line. Maybe the Texas it Hamburg courts will side with Nvidia, but Nvidia needs to win everywhere and Linux only needs to win once.
IANAL, but I suspect you're right. The GPL restricts redistribution, but does it impose any restriction on someone who downloads and compile their own kernel and downloads and links the NVIDIA driver against it, then never redistributes it?
However the Linux devs are still allowed to do whatever they want to make it harder on NVIDIA. Also I assume the distros count as redistributors so they probably can't combine NVIDIA and GPL parts of the kernel.
Nvidia wants to distribute their proprietary driver separate from the kernel. GPL is a copy-left license, meaning any derivative works are subject to the GPL.
Currently Nvidia creates a proprietary driver that is not specific to linux, thus is not a derivative work. Then, they create a 'shim' layer that links their driver into the kernel. While the shim is a derivative work, the driver is not, thus copy-left doesn't apply to the driver.
I think many/most would consider the ability to write loadable kernel modules an "API". Google v Oracle decided in the US Supreme court that APIs are not copyrightable. From [1]:
> Supreme Court ruled in a 6–2 decision that Google's use of the Java APIs fell within the four factors of fair use, bypassing the question on the copyrightability of the APIs.
IMO, Nvidia doesn't even need a shim layer, they're just playing nice. If push comes to shove, I think Nvidia will win in court.
> Google v Oracle decided in the US Supreme court that APIs are not copyrightable.
This is not true. The appeals court ruled that the API was copyrightable, and the Supreme Court opted not to rule on whether or not APIs are copyrightable.
What the Supreme Court actually ruled on is that in this specific instance, Google's use of the API would qualify as fair use - and thus it didn't matter if the API is copyrightable or not.
Anyway, Google re-implemented the Java API in many areas, not just wrote code to interact with it. Either way, I think a loadable module would fall under similar treatment.
This isn't DRM, it's regular old software licensing.
> the requirement that proprietary drivers do not interact with GPL-only code would in my opinion be considered an EULA.
The requirement that proprietary code does not ""incorporate"" GPL code is the GPL, and the entire point of it. However, it might be reasonable to argue to what extent merely linking against an API is infringing. I can see that going in either direction, and such a ruling would have a big impact on GPL either way.
While this requirement may really be in the GPL, there is no way to enforce it if the party creating a proprietary driver does not distribute the Linux kernel itself. In other words, as far as I understand, Nvidia does not exercise the rights of distribution that GPL provides, so they do not have to follow any additional rules of the GPL. GPL regulates distribution, not _use_ of software (see free software freedom 0).
I think the core argument is that distributing a proprietary driver that's obviously meant to be loaded into the Linux kernel to be useful is distributing a derived work -- since the Linux kernel has a syscall exception, but not a linking exception. So the problem isn't that Nvidia may or may not be distributing the kernel itself; it is distributing a derived work of the Linux kernel, and that must be licensed accordingly.
But I may have misunderstood/misremembered the details. It's been years since I cared enough to do a deep dive on this.
> I think the core argument is that distributing a proprietary driver that’s obviously meant to be loaded into the Linux kernel to be useful is distributing a derived work
Whether functional elements needed for interoperability are not covered by copyright (so that a work that seems “derived” through its use of them is not a “derivative work” at all) or whether using them is Fair Use (such that while a work using them might be a derivative work that would, but for Fair Use, require a license, it is nonetheless legal without a license due to Fair Use) seems to be a bit of a mixed bag, but either way using copyright to prevent functional interaction (except when you get into DMCA coverage of technical anti-circumvention measures, which is also part of copyright law, but not really applicable here) seems to be a difficult battle for copyright holders, in US law, at least.
> seems to be a difficult battle for copyright holders, in US law, at least.
heh, I wonder if you could argue that the catalog of functions/methods/symbols is a database and should thus be copyrightable under EU law.
it would obviously be hugely destructive if upheld, but, I think "database right" is fairly incoherent as a concept anyway, other than as an attempt to uphold "sweat of the brow doctrine" (ie "anything I worked to make should be mine by law"), which is already discredited in US law.
DRM refers to code which enforces (or attempts to enforce) license restrictions. So, by definition, writing code which attempts to enforce GPL compliance from kernel modules is DRM.
The GPL itself is just an idea. I can download GNU emacs, strip out any reference to freedom, and distribute that to others under my own proprietary license. I would be violating the license, obviously, and a court could prevent me from doing so, but nothing in Emacs itself would.
As their code is running in ring0, from experience I know that Nvidia has a lot more fun tricks they can use, but are probably holding back for now. Ditto for the Linux developers.
This stupid DRM crap helps no one and only fuels more cat-and-mouse games that waste everyone's time.
I don't understand why Nvidia puts so much effort into keeping their drivers as proprietary blobs. It's not like their software is part of their defensibility; they're a hardware company. Not only will opening their kernel modules have zero impact on their hardware sales, but it will actually improve their stability and also earn goodwill from developers who might otherwise go out of their way to purchase a GPU from AMD.
They want to be more than a hardware company, because commodification is antithetical to fat profit margins. They have ~80% of the GPU market, their only way to increase profit margins is to start gouging (which is easier if they control the stack higher up, e.g. if the main GPGPU language is built around their GPU architecture) or to branch into a different field entirely (which is why Nvidia has been going so hard into AI - they could leverage their GPU dominance to gain an early lead in the field).
CUDA is the basis for the entire “AI revolution.” Their entire stock price now is from the extreme demand for A100/H100 to power AI and other supercomputing needs. That’s possible because the software stack (CUDA drivers, etc) are incredibly powerful at turning the silicon into value. AMD also has ok hardware, but almost no adoption due to software. If they give up the software the huge advantage they have will erode.
I'm skeptical of the argument that Nvidia's superiority to AMD is due to their software. But even if it were, what would AMD gain by having access to the source code of Nvidia drivers? It's not like they can use it to speed up their own chips.
Just a reminder that it's only "illicit" in theory, until that has been proven in court. What they're talking about is essentially a DRM within the kernel code that tries to prevent a loadable kernel module from guessing where the kernel data structures are in memory. They know that people are likely to push the envelope, and they're trying to make it as hard as possible as a deterrent. However you could argue that ALL closed-source loadable kernel modules are violating the GPL equally, with or without a "shim", and people have argued that, but we've mostly forgotten about it and use this DRM fiction as a stand-in for legal fiction. Or perhaps the GPL-tagged functions within the kernel count as an "API" in the Google vs Oracle sense and none of this matters.
I hope this won't result in some kind of battle ending up in no or worse nvidia drivers for linux, without them my favorite OS would suddenly be less useful due to less games and AI.
I'm not sure Nvidia needs Linux 6.6+. If this change is indeed a dealbreaker, they can very well fork it at the last working version and offer it in combination with their own distro.
Even if they're unable to make significant further contributions, today's kernel is likely to work just fine for the next decade. Any improvements could happen at the hypervisor layer (because of cloud, x86_64 effectively became the new API, with the true "OS" being the cloud and its hypervisor & managed services) or userspace to not make any changes to the kernel itself and thus avoid tripping up licensing issues.
This kind of bullshit pettiness will end up making the situation worse for desktop Linux users and consumers, while enterprises reliant on Nvidia equipment in Linux-based server systems will just jump to Nvidia's fork and distro.
Nvidia is the default option because it's convenient at all levels of the stack. Close to two decades of investment into CUDA made sure that GPGPU with Nvidia is extremely smooth, and AMD support is a lot more spotty and less maintained. But add arbitrary restrictions like needing some outdated kernel or a special distro, and suddenly getting an AMD card to work with your favorite framework doesn't seem like so much more work. And once that reaches critical mass and patches are upstreamed, the convenience advantage of Nvidia is gone and competition will get a lot more fierce.
You greatly underestimate amount of work that would be needed to hard fork and maintain Linux kernel (even powerhouse like Google doesn’t do it, and they’ve build multiple operating systems), in a state that would be attractive to AI, where you care a lot about performance, latest drivers (for thing like networking cards and other bleeding edge stuff that comes with AI gold rush).
And willingness of others to follow. NVIDIA needs Linux to sell their HW. For Linux NVIDIA isn’t even 1% of their market.
Possibly. But I think from the legal point of view it could be much more direct “I’m doing this to break the license” approach, where it can viewed as them try to freeload off up to date work. For older version they had some possible explanation that they just used an API.
Hardware can be abstracted away by a hypervisor, as it's already done in most use-cases since a significant amount of machines are just cloud VMs nowadays. The only API the "hardware" has to implement is VirtIO (which real hardware could also start implementing if needed).
This kind of fork would of course mean death to the Linux desktop, since the only reason the Linux desktop is relevant and (somewhat) modern is because it's enjoying the improvements that are made to Linux by companies who primarily use it on servers.
If this fork happens, this VM-based distro is what enterprises will switch to and build upon, with conventional Linux being relegated to niche use-cases with much less activity and manpower.
There’s this bubble where people who work with AI seem to assume that everyone else also wants to work with AI on their PC. It’s strange. Let NVIDIA have their CUDA and their datacenter GPUs, most of us just want to put pixels on a screen.
And a decade ago most users didn't need a GPU at all because they weren't doing 3D. I still have a laptop with a Vista compatibility card in it that was outdated on release because the push for using GPU accelerated graphic back ends didn't stop at the OS and everyone's grandparents also wanted to have a look at things like google earth and street view.
Unlikely. AI projects are tied to Nvidia not to Linux. They just port their driver to FreeBSD or Solaris or whatever. The AI crowd will follow. But they can also just release drivers that as part of the driver install patches the end user's kernel to remove this janky stuff.
i'm out of the loop on this one. i did a good deal of HPC -- specifically electromagnetics simulation -- about a year ago and Spir-V worked OOTB for GPGPU on AMD processors. hell, i wrote my kernels in _Rust_ and they compiled and ran just fine (Embark Studio's `rust-gpu` shim), which is about as edge-casey as i can imagine.
how is AI stuff tied to nvidia? what would make it difficult to port (or to be portable)?
AFAIK the vast majority of ML training/inference on the GPU runs on CUDA, and has done so for many years, while other vendor-specific GPU backends are slowly gaining support.
It doesn't help that AMD's equivalent open toolchain, ROCm, is barely even supported by their own GPU lineup.
Almost anything; they won’t GPL their driver like they ought to, because they made unwise decisions surrounding the use of material covered by software patents and non-Free licenses, and thus are unable to do so.
Aren't they re-architecting & creating a new, free software driver that's only responsible for memory management & conveying requests from the user through to to the _real_ computer running on the GPU?
The new ones crash constantly and have new crash bugs every release and still 2 years later don't properly support 120hz @ 4k or anything HDMI 2.1 despite being advertised that they a) worked on linux and b) supported HDMI 2.1
HDMI 2.1 is not currently compatible with an open driver (although there were rumors that AMD was working on the licensing issues). In the same vein as it's not really productive to complain about NVIDIA wanting to link proprietary code, it's also not really productive to complain about AMD wanting to link proprietary code.
Buy a DP to HDMI active converter and stay open, or else accept the proprietary software into your stack. If that is not possible, look elsewhere for your software, GPL is not for you.
>HDMI 2.1 is not currently compatible with an open driver
This is a false narrative, it's literally just not implemented.
>Buy a DP to HDMI active converter and stay open, or else accept the proprietary software into your stack. If that is not possible, look elsewhere for your software, GPL is not for you.
This is just so... user hostile. The paid amd developers can't get around to finishing their drivers so use a proprietary dongle with closed source everything in between your screen and your computer, and if I don't accept this "GPL" isn't for me. Lol.. just.. no.
Like it literally does come down to the same thing as people say about nvidia: this is closed source and it’s not compatible with copyleft licensing. GPL can’t touch proprietary symbols any more than proprietary code can touch GPL symbols.
Nvidia can support it because they have a closed firmware and the symbols are buried in blobs. And that has its advantages too, like this situation!
If you can chase HDMI forum to open a minimal set of symbols, fine, and it sounds like AMD has been working on that. But there is a lot of closed IP in the audiovisual/graphics world that will simply never be opened and it’s unlikely that the closed driver will ever be opened up as a result (NVIDIA's open driver will be a rewrite without IP taint just as AMD did with their open driver). Graphics IP is just not a world compatible with copyleft and they’re ok with that, if copyleft suffers consequences oh well, Linux is probably <1% of their revenue base.
Copyleft is fundamentally about inventing a new, joyfully communist codebase, not gluing proprietary code onto community code. That’s why it’s GPL and not BSD - Nvidia’s license or hdmi forum’s license is not a problem on FreeBSD! And in this case you simply must invent your own 48gbps display standard, but with hookers and blackjack, and then drive sufficient adoption in the market, just as Linux had to do for software. Or someone already did that and it’s called DisplayPort.
But hdmi is proprietary license and you can’t use it unless and until they relicense to something GPL compatible. That’s the price of the Linux kernel, is it delivering some value here that BSD or minix wouldn’t for you?
Again though it is simply the reality of how things are in the audiovisual field, you will never get Dolby or Fraunhofer or Motion Picture Experts Group, etc to open up any of their proprietary IP so you will simply have to accept a feature deficit OR use a license other than GPL that tolerates linking with proprietary code. Like even Microsoft doesn't want to interact with MPEG/Dolby/Fraunhofer more than necessary (see: HEVC codec in the windows store rather than built in)
It is a testament to how thoroughly and utterly open-source (and specifically copyleft) has won that people are completely unable to contemplate the possibility that some code simply cannot and should not be released under viral copyleft licensing. And people can’t even consider the possibility of using kernels with other open licenses like BSD etc that are compatible with these types of proprietary encumbrances, just using another damn kernel is unthinkable today. Well, this is the price, this is what GPL was meant to do from the start - wall out proprietary code and build an ecosystem of forcibly permissive code! Maybe that's not entirely free of downsides.
Sucks that it came down on something the AMD fans care about this time, but the rest of us have been living with this world for a while now, and they've kinda been gleefully rubbing it in for years. Just rewrite your own display standard bro, but GPL, with hookers and blackjack. Not Linus's problem, maybe he's got a pithy thought-terminating-cliche for this one too? he's great with those - "fuck you nvidia", "zfs is just a meme anyway", etc. What a great guy!
The good news is AMD is supposedly working on getting HDMI to license the symbols at least, and that's supposed to drop pretty soon, but lmao at AMD fans crying over being on the other side of the GPL rugburn for even a short while, after constantly rubbing it in on ZFS and NVIDIA and everyone else. Like he’s not even relicensing symbols out from underneath you, this is nothing lol
Nvidia did open source their drivers (or some form thereof) and now provides redistributable firmware blobs. Plus firmware authentication has been broken on some older cards. So hopefully the proprietary drivers will lose importance over time.
As far as I know the ZFS vs GPL issues still haven't been resolved yet. Random incompatibility with the kernel is kind of a thing you need to take for granted if you choose to use ZFS on Linux, because the two code bases just aren't compatible with each other. Linus Torvalds himself has recommended people not to use it in combination with Linux.
Oracle and other ZFS copyright holders could fix this situation by dual licensing ZFS, but they don't care, so you should expect ZFS to break with every major Linux update as not much special care is taken to keep it (and other out-of-tree drivers) compatible.
If you can't replace ZFS for your use case, consider replacing Linux instead. There are a few BSDs out there that will run ZFS without the common Linux problem, for instance.
My use case it "Retaining my data long-term", and the options in that realm are more or less tape (hugely expensive), ZFS, or less-reliable systems like unraid.
Unfortunately I do also need to run Linux, to a degree, so I'm using a distribution that removes the DRM.
Is tape really that expensive nowadays? You can find LTO-7 tape drives on ebay for under 1k USD and actual LTO-7 tapes new from the manufacturer for less than 50usd a piece.
If you are storing enough data that you are even considering tape, the cost of your tapes is going to be just as much as a second hand drive fairly quickly and the break even point against HDDs is like 5-6 HDDs or tapes.
I'm storing ~13 TB. Just enough that online backup (Backblaze etc.) is too expensive to be reasonable, not enough that tape is really sensible. ZFS fits the bill, and let me build a reliable off-site backup system to HDDs.
LTO-7 has 6TB of capacity per tape, so I suppose I could get away with... well, ten or so? But it'd be a lot more manual work, and the tape drives are far more expensive than four 8TB HDDs.
With tape, there's also the issue that if you only have one tape drive, you don't know if your tapes are readable in anything else.
One option could be to run illumos-based system if you need linux compatibility. Lx-zones work pretty well unless very specific capabilities are needed. Of course there's also bhyve for such scenarios.
At runtime there's no problem in practice, but the disconnect between the two projects causes the occasional friction that can blow up your FS if you run rolling release distros.
For a minute, I thought the title was about Linux helping Nvidia block users from illicit usage of their hardware (like using consumer GPUs on data centers).
And was like: "WTF? No way, that must have been a Court order".
There's also the users who bought the hardware. The "their" in "helping Nvidia block users from illicit usage of their hardware" could easily refer to either "Nvidia" or "users".
There is this weird opinion that once you buy an object, it becomes yours, and is no longer the property of whoever made it.
How much machine learning/neural networks happens on Linux compared to Windows? Assuming that's the majority, it should put Linux is a much better negotiating position compared to the time when the driver only benefited the small number of Linux gamers. So it's probably the right time to push Nvidia into a better architecture where the kernel driver is GPL and the closed source stuff is in a userspace component.
I'm typing this using the proprietary Nvidia drivers on FreeBSD right now.. They are SO much easier to deal with than the "native" AMD and Intel drivers that require tens of thousands of lines of linux shim code.
I don't think you get what this change is. You can disable nonfree drivers on the kernel level, and it will make sure they aren't loaded. You can also allow them, as many distros do. Nvidia took their driver and had it lie to the Linux kernel and pretend it was a free driver when it isn't. Linux is making sure they can't do that again, because if you don't want nonfree drivers, you don't want nonfree drivers. Nvidia is working against their users, not Linux.
Unfortunately this is a troll who only meant to stir the pot. They were recently known as veave and veavo. They are constantly churning through accounts and have been for a long time.
Seems easily avoidable by having the modules rendezvous in one of the myriad ways that are possible given that both run in kernel mode with full privileges.
For example, you can walk the kernel-only page tables, find all executable pages, and scan them for a magic string that the other module puts in their text section.
I was thinking the same thing, then I realized they don't even need this. They could simply grab the addresses via /proc/kallsysms and poke them into the driver using a custom helper to load the kernel module.
For the uninitiated, if NVidia refuse to make their modules GPL, and also cannot find a workaround, does this mean you cannot use their cards on (at least unmodified) future versions of Linux?
Maybe NVidia could persuade end users to patch their kernel to get around this?
If Nvidia are breaking the GPL, or DMCA copy-protection-circumvention law, the Linux Foundation (or the FSF or someone) should sue them and get them to stop. If they are not breaking it, they should be allowed to use the symbols.
They already ship their own repackaged Ubuntu, called DGX OS. It's basically Ubuntu with extra software, drivers, and configuration. Switching the kernel around wouldn't be hard for them (they may already be rolling their own kernel).
That said, part of the reason nvidia is so popular is that it's easy to buy their cards, spin up a system, and let a researcher play with it. If people had to buy the dgx workstations for this it would limit them to only the high level cards. There are a lot of benefits to giving every researcher in a company their own hardware for experimenting and debugging before they send their models off to the big clusters for training.
Forcing them to maintain their own kernel fork will incur additional financial expenses - not least in the form of a developer's salary - so it is, in essence a fine.
Will it be enough to force them to stop fucking around? Probably not, but it's one more paper cut, and perhaps in the process of their fork they violate the GPL in a more openly and legally actionable way
Exactly. Nvidia's position is so incredibly strong in AI and these customers clearly do not care whatsoever about spats like this and/or whether or not the driver is closed source/binary/whatever. If they did AMD/ROCm would have more than low single digit market share in AI.
Nvidia obviously has the resources and ability to make a Debian/Ubuntu derivative (or whatever) that can offer increased usability, performance, etc with their hardware. Nvidia may even save effort and cost internally by primarily focusing AI/CUDA driver development on their own distro as opposed to what I'm sure is currently a significant amount of patchwork, workarounds, etc for the bewildering array of variability currently present in the Linux ecosystem.
These users/customers aren't using a given Linux distro out of idealistic passion/preference for the distro like many users here - they just want to do AI. They're going to use the best tools available to achieve that goal.
Needless to say these massive thousands of Nvidia GPU deployments are highly orchestrated and if an Nvidia distro can offer even 1% improvement on the usability, performance, etc with their hardware these customers are going to deploy an Nvidia distro immediately. These customers are also likely effectively supporting a distro variant already and they would absolutely rather let Nvidia take on as much of this effort as possible. I'd venture to guess many Nvidia customers have actually been asking Nvidia for it - Nvidia may already effectively be doing it for them.
Lambda Labs (for example) already does this - shipping and supporting an Ubuntu derivative that does whatever you want with AI within seconds of booting their hardware. Even Oracle already does this and the recent issues with RHEL/Cent are yet another reason this makes sense to Nvidia. Nvidia also already does this with their Jetson line of hardware.
You're absolutely correct that it is the desktop users who will get shafted by this.
I've been a Linux desktop user since 1997. I love Linux. However, for something like this not even the might and influence of Linux/Linus/etc will "win" going up against Nvidia on this.
Bundling their driver and a custom kernel to work with it _really_ sounds like a derivative work that would be a very clear GPL violation. That would be a pretty risky move legally speaking.
The intent of the GPL-- and Linux's interpretation thereof-- is that you can't just circumvent it by putting a thin API in for what you need and then shipping a huge closed source and/or restricted blob that integrates deeply with the GPL thing.
Funny because that's exactly how most commercial Linux-based products work, including and especially Android smartphones. In my opinion, tolerating TiVo-ization was a major and possibly fatal misstep for GPL enforcement. What is a firmware blob, if not a derived work?
It stems from a "nerdy" interpretation of "linking" that considers as relevant the fact that the monolithic proprietary blob (encrypted, protected, unmodifiable) has some sort of internal interface that mirrors the way a user might use a hypothetical free version of the product (running proprietary processes on a free kernel/userland). But it ignores the fact that the user cannot in practice disentangle the product in any way. It is the user experience that should legally be the deciding factor.
I realize this may be a controversial stance, but consider - what if I released a proprietary and closed source desktop application that bundled into its binary a copy of the Linux kernel? Are the specifics of how it interacts internally with this code really relevant? Is this really a different situation than code that runs bare metal?
If you wrote the firmware on your own before, and it works on multiple operating systems, and you didn't refer to Linux to use it... I don't understand how one would think it's a "derived work". How does it "derive" from Linux?
I was perhaps unclear. I meant a firmware blob in the sense of an OS image that includes Linux, such as might be downloaded as an update to your smartphone.
Can you delete the proprietary software, and if so does the Linux still run?
Can you modify the Linux part, and if so does the proprietary software still run?
If those two criteria are satisfied I think you could probably successfully argue that they are cleanly separable components within a "mere aggregate". If not, they pretty clearly are bound together into a larger combined work.
> Can you delete the proprietary software, and if so does the Linux still run?
Generally, yes. Of course, some people have a custom init, and I don't think this really breaks things.
> Can you modify the Linux part, and if so does the proprietary software still run?
Yup, generally. Of course, the device itself may prohibit you from loading arbitrary software on it without rooting it or modifying the bootloader. You may not have a license to run the proprietary software with modified Linux, though.
You mention android smartphones above. The existence of LineageOS, etc, is evidence enough that you can do these things.
Generally, if you modify either the Linux part OR the proprietary part on a smartphone, the machine will fail to boot (i.e. the software will not run). This is a deliberate design goal, cryptographically enforced, and it is not implemented in physical hardware, but in the very software in question - the boot process includes some sort of "integrity check". This is the clearest possible statement of intent to integrate the two into a single combined work.
It boils down to the distinction between "derived work" and "mere aggregate", which is currently legally vague. This vagueness has allowed all sorts of shenanigans that violate the spirit of the GPL.
TiVo-ization is, releasing your code as FOSS, but enforcing in your hardware that you can only run vendor signed builds on the device, preventing users from running their own modifications to the software.
Most enterprise linux derivatives do not bundle proprietary linux modules with a modified linux kernel.
TiVo, like all such products, ran proprietary software "on top" of the Linux kernel (and "underneath", typically, in the form of a closed source bootloader). As far as I know, no company bothers to apply such DRM unless they do this. So this is kind of a distinction without a difference.
The user space interface is explicitly supported to run proprietary software. It's an operating system. The kernel's license taints things that are tightly coupled with it. Even most modules are not this tightly coupled and can deal with the exported symbols.
Similarly, the loader, BIOS, etc, are not encumbered by the kernel license.
We are specifically addressing what happens when you take a Linux kernel (or any other GPL code), modify it, and bundle it with proprietary software, in such a way that neither the free nor proprietary software function without the other. I am arguing that, regardless of the technical details, this constitutes a derived work (and not, as is commonly argued, an "aggregate").
The FSF gently disagrees with me. Tellingly, they won't commit to a clear distinction between "derived" and "mere aggregate", calling it a "legal question", but suggest that "a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)." I say this is a classic nerd mistake of reaching for technical solutions to social problems - the true criterion should be something more like "can the user run these components independently?".
IANAL but I don't think so. You are free to modify a GPL thing and redistribute it as long as you provide the sources. Strip the kernel of the GPL check, ship it with DGX, and provide a tarball of the patched sources.
Fortunately, Linux Desktop users are no longer forced to bend over and take it from NVIDIA: they can get an AMD GPU instead and enjoy a proper kernel driver.
Not sharing their source code with the Linux kernel project, like AMD does. Instead, NVIDIA keeps it close to their chest, providing users only their binary driver. This sometimes causes failure of graphics after kernel upgrades when the kernel changes too much.
In the past they prevented people from running consumer GPUs on Xen systems.
I don't do any AI work, and I just got an Intel GPU. It just worked. I have not installed anything extra, nor have I had to configure anything. It has worked flawlessly.
Some of NVIDIA's big customers would not trust NVIDIA's distro for practical reasons, like not having to do a security audit of yet another distro vendor, or having their own internal distro.
they could be forced to publish their drivers code, since there would be no clear boundaries between their kernel code and their driver code (from a legal point of view)
I have a dumb question - after so many years of bad reputation and so on, why doesn't NVidia just open source their drivers? What is the value of them staying proprietary?
I wouldn't be surprised if there are more as of yet undiscovered limitations that they've added in that are just pure money grabs with no technical merit.
Maybe but given that this is implemented in the driver tells me that there might be some kind of issue with it being implemented on the GPU. I doubt they chose this less than optimal way of implementing such a limitation because they were simply being silly.
Not all kernel modules need to be GPL; that's why there's a license field for modules at all (if everything needs to be GPL, then the license would be implied).
The issue here is that nVidia wants at least part of their module to not be open source, but _also_ wants access to functionality that's been marked as only allowed to be access by GPL modules (the typical assumption is that, in order to use those, your code already needs to be tied deeply enough that you're a derived work).
Note: based off things I've gleaned from LWN and places.
At what point does it make sense to just maintain a fork of the kernel that is pragmatically interested in making things that work rather than sabotage.
If Nvidia doesn't break the kernel license terms, this shouldn't be a problem. Their open source drivers should also work just fine as far as I'm aware.
This whole issue is the result of Nvidia shoveling closed source code into a copyleft ecosystem. Of course they're going to be met with resistance. They could open-source their drivers and use the GPL symbols, of course, but unlike AMD or Intel I doubt they're going to do that.
As for why Linux users would give a shit: if you don't, Nvidia hardware works a lot better on Windows and WSL2 will let you do anything Linux distros will let you do. You're also free to stick to Linux 6.5.
Exactly, and those drivers should work perfectly fine without interruption. The open source driver is MIT+GPLv2, it's only the closed source driver that's still causing problems.
Knowing Nvidia and how shit a company they are, they'll probably just drop Linux support for their older cards at some point and blame Linux.
I also don't give a shit about copyright, but that doesn't allow me to freely copy movies, music and images as the licenses doesn't exist.
It's absolutely normal that the authors of GPL code defend their licensed work against violations, regardless what the users of said code want. Imagine Microsoft openly using GPL code in their closed programs, but as the average user doesn't give a shit should they get a free pass?
This doesn't sound like good faith, but in case it is, it would by pennywise and pound foolish to let them have an exception. In the immediate term better linux drivers would be good, but the precedent that companies don't have to respect GPL would open the doors to linux getting torn apart by big players that want to use it exclusively for their own gain. It would be horrible for the FOSS movement, and we would have traded it for some better drivers.
Thanks for the link, as always LWN is top notch. The comments on there are also amazing.
Somewhat a side comment, but for people interested in this topic but new to LWN, an LWN subscription is unfortunately pretty pricey, but the quality does justify it if you've got the room in your budget.
Just curious, why would you swap out a live link unless it is malicious or disingenuously reposting content from another source? Isn’t there value in a diversity of information sources and/or narrative dialog etc., even if sometimes some other source has a more detailed or better written article? Wouldn’t the better response be to post the other article and let that one win on merit?
Article quality makes a big difference to discussion quality.
Eventually we'll let a submission have more than one URL associated with it so there will be sets of links rather than just a single link - but even then there should be one singled out as somehow canonical.
Answering those questions first requires a standard of value to evaluate the options. HN is a rare site that sets an explicit standard for posts: they should “[gratify] one's intellectual curiosity”.
It’s not a great standard, partly because “gratify” implies a whole set of metaphysical value judgements. But it is better than none at all and can be reasonably inferred to place value on attributes like objectivity, expertise, comprehensiveness, and conciseness.
Should links be swapped even if there isn’t anything technically wrong with the original? Yes, if the replacement is better at gratifying intellectual curiosity.
Is there value if diversity of sources? Yes, but not sources that exhibit obvious bias, are poorly written, or woefully incomplete.
Wouldn’t it be better to post another article instead? Maybe, if both articles are good.
> Wouldn’t the better response be to post the other article and let that one win on merit?
Whether things bubble up to the front page has a little to do with merit and a lot to do with luck or timing. It is not uncommon to replace a poor source that has nevertheless made it to the front page with a higher quality article.
I find it disgusting that most people here are defending NVIDIA. This is literally victim blaming; Linux devs are victims of license/contract violation. NVIDIA has no right to be doing this and are acting above the law.
The kernel devs wouldn't have to put these defenses if NVIDIA played fair and just open-sourced their driver like every other major GPU vendor.
There's a lot of people depending on a functional NVIDIA driver to do a lot of computation. It's understandable that they'd be defensive if the thing that powers their products suddenly taken from them, regardless of who's at fault.
The fear could be that NVIDIAs "hacks" helps with performance and playing by the rules of the kernel developers will cost... say 10% in performance, that would be a pretty big hit for many.
I don't think there's a fear that NVIDIA will stop developing Linux drivers, that doesn't seem realistic, but I also doubt that they are going to open any more than they absolutely have to. NVIDIA isn't a open source friendly company and no Linux kernel hacks are going to change that. They'll change when it's financially beneficial to do so.
So... in what way does opening the source of the driver makes the authorship go away?
You made a bunch of claims based on having no information about the subject that have nothing to do with the post you replied to...
Like... what am I supposed to do with what you wrote?
---
As an aside, from my personal experience, NVidia is a very bureaucratic company with very few people having much of an authority over software it writes. It also has a culture of restricting many freedoms to their employees (as in, mandating OS for their laptops, taking away root privileges on work laptops, requiring a lot of unnecessary reporting when dealing with programming issues etc.)
I would expect that the decision to not open-source the driver was based on some policy established ages ago. Nobody can remember who and for what reason made the decision, but nobody is bold enough to challenge it. Mostly because the organization grew too big and the decision must've been probably made by some title which no longer exists and whoever is in "position of power" now doesn't have any real power.
As for performance... well, I wouldn't expect it to tank. Here's one anecdote that I know about since I'm personally affected by it. On laptops with two graphic adapters (typically Intel and NVidia) where one is used for power-saving mode and another one for better 3D rendering, when such a laptop is connected via HDMI to a big monitor, NVidia's adapter starts overheating and using a lot of unnecessary resources. Turns out someone left out some kernel logging in the very hot loop of the piece of the driver related to HDMI probing.
In other words, I wouldn't be surprised if NVidia's driver would overall benefit from few extra pairs of eyes looking at it. It's hard to imagine that they somehow found a way to utilize system resources so much better than a legitimate driver would. And even if they did, there's a good chance they'd be able to convince Linux kernel developers to let them have it.
I don't disagree that the drivers could benefit from a few extra people looking at them... though I doubt that many outside AMD is looking at the Radeon drivers. There's no harm in NVIDIA opening their drivers, but they won't do it, nor do they like that the kernel developers are saying that users are on their own if they do load their proprietary drivers.
Now what I originally tried to address was people defending NVIDIA, because their work depends heavily on things working as they currently do and what they are looking at now is an ever so slightly more uncertain future.
Edit: Oh I see, you're confused about "if the thing that powers their products suddenly taken from them", is that what you're thinking in terms of authorship? I'm referring to having the drivers taken away, feature, performance, whatever the negative outcome could be in the mind of those defending NVIDIA.
For GPL, open source supporters, and people who don't like or care about Nvidia support, Linux devs are doing the right thing.
For people who depend on their Nvidia hardware to work under Linux, I understand they are pissed off, since it break their support for a non-technical reason.
It is not unlike DRM when you think about it. In the "Digital Rights Management", it is a technical measure to protect the Linux kernel copyright ("copyleft" in this case). In the "Digital Restrictions Management" sense, it is a feature that is design to break something that works. And it is also about the "Direct Rendering Manager", but at least, no one complains about that DRM.
I just with that Nvidia had more competition. For not, they can do whatever they want because they have the best GPUs, both with regard to open source and price. AMD GPUs are meh right now. Maybe Intel will be competitive one day, from my experience, their Linux / open source support is rather good, but maybe because when it comes to GPUs, they are the underdog.
> or people who depend on their Nvidia hardware to work under Linux, I understand they are pissed off, since it break their support for a non-technical reason.
They need to redirect their anger at the correct culprit -- Nvidia. The non-technical breakage is a result of Nvidia continuing to try to sneak around restrictions that they should have been abiding by. Nvidia could have spent the resources to get their drivers to compliance, but instead they chose to use them to try to circumvent the restrictions.
Also it's not the same codebase as their proprietary driver, it is inferior in performance for desktop/gaming users. So it is not really a complete alternative yet.
tbh if the open-nvidia driver works for compute (which runtimes, opencl too/etc?) that pretty much neuters NVIDIA's driver licensing "this isn't allowed on gaming cards in datacenters (except mining)" shenanigans doesn't it? it's MIT/GPL2 licensed, do what the fuck you want with it?
also gives them a way to relieve pressure on the AI market. "install the open drivers bro", assuming it works.
Most crimes don't end up in courts. Doubly so when one side is a corporation with an ungodly amount of money, and the other side is a group of difficult to organize nerds who would struggle to show real damages.
Things not showing up in courts proves basically nothing, and if you think it does, well, I'd be happy to sell you a lawyer who will charge you $200k to win a case over the course of 3 years netting you a judgement of $25k at the end.
Regardless of the legal aspect though, nvidia's clearly in the moral wrong. The kernel ships with a license that tries to protect user's freedom to modify its source code, and the source code for derived works. nvidia is acting counter to that license, and counter to its user's freedom.
Given that at least some other OSs see drivers as 3rd party programs and not derived works of the kernel, I don't see why we should consider Nvidia morally in the wrong. I find it much more likely that they are legally in the wrong, though.
Linux being a monolithic kernel and drivers being a derivative work is an important design choice, which arguably is an important reason Linux became so popular now, as it forces everyone to contribute to the common pool, if they wish to use others' work. One group deciding that they are an exception is morally wrong in my eyes, because it undermines that idea.
> if this is a violation you'd see it in courts but it's not because there's no case
Not every violation needs to be pursued in civil court. It's not even possible -- the courts would melt down and stop operating, or they'd raise their fees to the point of reducing caseload. "No lawsuit" does not imply "no case".
> if this is a violation you'd see it in courts but it's not because there's no case
Not everyone can sue; only people who have standing. Traditionally this would be people who own the copyright -- but on the whole, the core Linux developers have been very resistant to the idea of ever suing. I know Greg KH has come out firmly against it, and a quote above has Linus saying something similar. (I think their attitude is as foolish as saying that you should never ever ever use violence to prevent crime or defend your country.)
Nvidia will not be open sourcing their driver, so a result of this type of open source witch hunt is make the proprietary drivers worse.
You'll have to forgive me for not wanted the only functional driver of hardware in I very much rely on in a daily basis for both work and personal use, to lose functionality.
NVIDIA already ostensibly open-sourced their driver for GeForce RTX 20-series and newer.
Yes, they shoved all the important bits in the firmware, but this still could make for a much more stable Linux module, if NVIDIA actually respects license/code boundaries.
It is worth mentioning that their open-sourced driver is not the same codebase as their proprietary driver, it is inferior in performance for desktop/gaming users. So it is not really a complete alternative yet.
Either way as you mention, the fact it's only GeForce RTX 20-series and newer is a dealbreaker for people with older cards as well.
I do not see on what grounds you can classify in this case Linux as a victim and NVIDIA as an attacker.
There are many people who want to use on their computers both the Linux kernel and NVIDIA GPUs. NVIDIA maintains their Linux drivers only for the benefit of the NVIDIA GPU owners who desire this, they do not get any direct revenue from this activity.
So at most you might say that Linux is a victim of the GPU owners that want to use Linux, despite the fact that some kernel developers hate the owners of NVIDIA GPUs and try to discourage them to use Linux.
The problem is that Linux does not have a clear license that would enumerate what Linux users are allowed to do, and even if it would have such a list, that would be somewhat ridiculous, because one of the main claimed objectives of the Linux development has always been that its purpose is to remove the restrictions imposed by the commercial operating systems.
If Linux would have a license forbidding the Linux users to use it in weapons of mass destruction, that could be justifiable on moral grounds. On the other hand, a license that would forbid the Linux users to buy NVIDIA GPUs or any other piece of hardware cannot have any justification. While some kernel developers did not attempt to do something so pathetic, they still do not find anything better to do than to find new ways to make the life harder for those Linux users that have good reasons for using something like NVIDIA GPUs or the ZFS file system.
It is normal for the kernel developers to not do anything to contribute to proprietary device drivers, but it is ugly and mean to try to sabotage them by actively preventing them to link to the symbols that must necessarily be used by a device driver in order to accomplish its function.
> I do not see on what grounds you can classify in this case Linux as a victim and NVIDIA as an attacker.
The linux kernel is respecting it's user's rights to know what code they run, and to be able to modify it.
nvidia is not extending that courtesy to their users, even though the linux kernel's possibly-legally-enforceable copyright insists that nvidia has to extend such a right. nvidia can release their source code as GPL if they want to use the GPL parts of the kernel.
Are you just as mad at nvidia for having a proprietary driver but not letting users apply patches to the driver? I assure you, the license nvidia distributes its drivers under is much more restrictive than linux's GPL license.
Like, if you're mad that the linux developers are making it harder for nvidia to violate linux's license and make a derivative work of the linux kernel, surely you're even madder that nvidia's developers have made it even harder for anyone to make a derivative work of nvidia's proprietary driver blobs, right?
I do not agree with the theory that linking one program to another makes the former a derivative of the latter, therefore I do not agree that a kernel module is a derivative of the kernel, when it just uses the interfaces that must be used to accomplish its function.
If this theory, which is the only point of disagreement between me and Richard M. Stallman, would be accepted to be true, then what would stop Microsoft to claim that every program that has ever been written to run on Windows is the property of Microsoft?
When there are two hardware vendors, one who offers open-source device drivers and one that offers proprietary drivers, I would always choose the one with open-source device drivers.
Unfortunately, in the case of NVIDIA there are applications for which no other vendor attempts to provide competitive products, so there is no alternative choice. Therefore it does not matter if I would be "mad" at NVIDIA, as that could change nothing.
On the other hand, I am "mad" at this kind of kernel developers, because I do not accept that they have any right to dictate to the Linux users what kind of hardware they should buy. Obviously, they should not support NVIDIA, but inventing methods to sabotage the Linux users that have NVIDIA GPUs is not a justifiable activity.
If a Windows program is not a derivative of the Win32 libraries owned by Microsoft, what use does it serve once separated from the Microsoft libraries?
If an Android application is not a derivative of the Android OS owned by Google, what use does it then serve once separated from the Android base system?
If any C program that has ever been written (except those written for freestanding environments) is not a derivative of the C Standard Library, what use does it serve once separated from libc?
If your argument were right, with the exception of the very small number of programmers who write programs for bare-metal embedded systems, all the other programmers have written all their lives only derivative programs, so none of them (or of their employers) has any right to claim copyright ownership on what they have written.
> They are completely unlike user space applications.
Why?
I cannot see any difference from the POV of copyright. There is no difference between the loading of a kernel module that must discover the addresses of the kernel symbols that it must use and the loading of a user-mode executable that must discover the addresses of the symbols that it needs from the libc shared library.
Also the GPL does not allow the bundling of non-GPL kernel modules with the Linux kernel but it cannot restrict in any way the right of any Linux users to use the kernel by loading any kernel modules they want.
These attempts made periodically by some kernel developers to cripple the performance of the non-GPL kernel modules by hiding the useful kernel symbols when such modules are loaded by the end users have nothing to do with the GPL.
They also do not hurt NVDIA or other hardware vendors, but only the Linux end users, whose systems become broken after kernel updates.
1. the copyright holder used a license that specifically exempts system provided libraries such as libc. User space applications therefore have zero licensing requirements imposed on them by using, for example, libc.
2. Yes, a kernel module will have to discover the address of kernel symbols in the kernel. And a user space application will have to discover the address of symbols in the libraries it dynamically links against. But neither the kernel module nor the application cross the OS/user-space boundary. The kernel module is derived from the kernel, and the user space application is derived from the libraries that it uses. But the user space application is not derived from the kernel.
3. Yes, users can do whatever they want. So sure, an enterprising coder could write their own NVidia driver module, have it use GPL symbols from the kernel, and nobody could stop them. What they cannot do is distribute that, and that is what NVidia does.
These claims are based on a non-careful reading of the GPL.
First, the "System Libraries" exemption also names explicitly the kernel.
More importantly, this exemption has nothing to do with determining whether some work is covered by GPL or not.
The "System Libraries" exemption allows a GPL program to be distributed together with "System Libraries", without providing the source code for those "System Libraries".
The GPL only claims to cover a work that is distributed to others ("conveyed") and which includes a GPL program that is "combined with it such as to form a larger program".
The GPL is not applicable to programs that use interfaces provided by a GPL program, but which are distributed independently of it to the end users, for instance kernel modules or shared libraries.
I've been in the libre software movement for about 30 years, and what you're not really coherently talking about has been thrashed to death for a bit longer than that.
You're going to get nowhere trying to claim that a user space application and a kernel module have the same relationship to the kernel. Actually, less than nowhere.
Isn’t the complaint all along that nvidia is just wrapping their windows code in a shim layer?
So the answer is it’s still a library of functions that provides a substantial portion of a display-driver, even separated from the kernel. a windows driver module/library backend for such is at least as useful as any other code!
As one who has used only Linux on all desktops and laptops for more than two decades, I am pretty sure that Linux does not have a written license that enumerates what a Linux user can do with the computer on which Linux is installed, e.g. whether they may use NVIDIA GPUs.
The GPL is not that kind of license.
While GPL includes some use restrictions, they are logically contradictory.
GPL says:
"This License explicitly affirms your unlimited permission to run the unmodified Program."
So anyone can run the Linux kernel without any restrictions imposed by GPL.
The GPL then has a convoluted specification of how it should forbid a GPL program to be combined with other programs, so that copies of the combination would be transferred to others.
However those restrictions do not apply to kernel modules like those distributed by NVIDIA, which are not "combined" with the GPL Linux kernel until the end user loads the NVIDIA kernel module.
Because the GPL cannot be applied to such kernel modules, the anti-NVIDIA kernel developers take advantage of the fact that when a kernel module is loaded dynamically, in order to work, it must discover the entry addresses for the kernel symbols, exactly like a user-mode executable must discover the entry addresses for the libc shared library.
So they attempt to make difficult for the NVIDIA module to obtain the addresses for the kernel symbols that it needs. This is exactly like if in user space the libc shared library would attempt to not provide e.g. the entry address of "printf", if it would not like the name of the executable file from which "printf" is invoked.
If anyone breaks the GPL, these kernel developers break it, because instead of providing "unlimited permission to run", which means "unlimited permission to" invoke any of the interfaces provided by the kernel, they attempt to hide many of the interfaces when they discover that the Linux users own NVIDIA GPUs, with the purpose of crippling the performance of such GPUs.
If a driver with intrusive telemetry included with a product made in Russia or China was a widely used binary blob in Linux installations, the banhammer would come down pretty hard on that and kernel devs would be heroes for protecting the public, including security-sensitive users. Sauce, gander, goose.
I'm going to get raked across the coals for this but I think it's time for the Linux developers to finally put a stop to NVIDIA's antics. Force them to release an open source driver - they will comply, otherwise their AI conquest dreams will be over.
Start playing hardball with these vendors and either put an end to proprietary blobs or make it a living hell to achieve it with no compatibility guarantees. You're playing in the GPL sandbox so do things their way or get lost. NVIDIA should stick to Windows or another Unix if they don't want to play nice.
I'm betting people would rather not take on the operational burden of a different OS in their stack long term and would prefer a vendor that works with Linux well.
There is still no replacement for CUDA. ROCm is a compatibility joke, Vulkan is too insanely low-level, OpenCL runs way too slow. Compute shaders are technically fine but bring flashbacks to 2006. Metal is a good alternative but only offered on systems without discrete GPUs! so we’re running CUDA for the next five years. In a conflict between Linux and Nvidia, in the HPC or AI spaces, Nvidia wins.
>In a conflict between Linux and Nvidia, in the HPC or AI spaces, Nvidia wins.
I HIGHLY doubt this. Nvidia has decades of investment in Linux internally. They aren't going to convert their DGX to Windows, or their dozens of internally utilized supercomputers. Sure, in a small window end-users are going to make a LOT of noise about Linux "breaking" - but unless Nvidia is planning on forking the kernel and fully maintaining their own version of Linux, they'll cave.
Their customers are not going to run an Nvidia fork, because the vast majority of applications only compile on very specific Linux configurations to begin with. This would effectively cede the market to CPUs or AMD.
That isn't a permanent fork away from the Linux kernel. It's basically them repackaging Ubuntu LTS, customized with some of the binaries packaged in.
Permanently forking the Linux kernel us a VERY different beast then taking Ubuntu, pre-installing Nvidia drivers, and then re-baselining everytime Ubuntu releases a new LTS.
Entirely depends on how extensive the patches are. FAANGS will all have their own kernels with custom patches, some of which will find their way back into the distros, and some which are kept in-house for custom reasons. It isn't necessarily that burdensome.
And I was involved in doing this at Amazon (although a long time ago now).
NVidia also doesn't really need to fundamentally fork the linux kernel to do this since drivers are already a pretty hard API boundary layer. They won't need to touch the TCP/IP stack, scheduler, etc. Their version of a "fork" would be "add back the API which is being removed here".
Lol, no they won't. The cost of developing their software stack is massive. They'd either resort to more technical hacks like running more of the driver in userspace, or if push comes to shove just develop a Linux compatible kernel with a cleanroom codebase. Kernels aren't that hard to develop for a company like NVIDIA especially if you only care about supporting a limited set of hardware (like DGX servers).
Nvidia would win this fight. Linus and co taking a hard stance would result in the industry bifurcating on Linux. AI just has so much momentum and money being poured into it.
Isn't that exactly what has already happened? Nvidia has released a fully open-source kernel side driver for their current hardware, probably because of pressure from the hyperscalers that don't want to run closed-source code in their kernels. The new driver still needs to be integrated into the upstream kernel so this news is still about the current legally dubious one.
Unfortunately there's not really any competition in the GPU space for AI use. AMD hasn't stepped up, and Intel is barely getting its footing for basic gaming functionality. Nvidia has an established monopoly on the GPGPU space, and forcing their hand, and them withdrawing from Linux compatibility, would result in everyone that needs Nvidia to ditch Linux. At least until an alternative becomes available, and then those customers would ditch Nvidia for screwing them over once already.
This is where WSL pulls its mask off. Windows will become (even more so) the platform of choice by being a "more compatible" version of Linux than Linux. And AI developers don't seem to have much affinity for open-source. Why would they care about being stuck on Microsoft and Nvidia's proprietary platforms when they're building their own proprietary models?
Great point. WSL has always been a wolf in sheeps clothing, in my eyes.
I'm not saying it's not useful. It certainly fills a role people clearly wanted filled. But you'd be naive to think Microsoft isn't taking on an "embrace, extend, extinguish" mentality. Again.
Also, I'm sure AI devs would be all for making it more difficult to run models on the desktop so you'd be forced to use a cloud service. They could even keep using a non-GPL patched Linux on their servers because it's not like they're distributing anything.
With Apple's significant work from hardware on up with AI there's a very near future where many AI applications will train models on a Mac[0] directly in XCode[1], bundle it with the iOS/Mac OS application (and browsers), and run inference directly on the device. Apple will also be deploying more and more of their own foundational models shipped in the hardware/OS. Most user AI applications will be as simple as "call this coreml API". With the links provided it could be said we're already there and they've been laying the groundwork for years.
This hits Nvidia and big GPU cloud providers two fold:
1) Training. We already see with the unified memory architecture of Apple Silicon that Apple can provide accelerated training with RAM capable of training/finetuning very large models[2]. 800GB/s bandwidth memory (192 GB!!!) is very close to the RTX 4090 (1TB/s). Also note how many PCIe X16 slots the Mac Pro has... You can be certain that follow up Apple Silicon will eat closer and closer to Nvidia datacenter GPU performance/capability and with Apple's resources potentially even surpass it for all but things like training massive LLM models from scratch a la Google, Meta, OpenAI, etc.
2) Inference. Why pay AWS or whoever to run your inference when users have already spent their money on hardware that does it faster (because network latency) and more privately on the devices they already have? iOS 17 already does some AI tuning (FINALLY) on device with auto-correct - expect to see this show up everywhere in iOS and iOS applications.
I don't make many predictions but this one is obvious. I'm convinced the next generations of Apple Silicon and the Apple software ecosystem, developer experience, etc will be the first very real threat to Nvidia. When this really gets going Intel and AMD will be permanently left at the starting line (where they are now) for all but very bespoke use cases and deployments like Frontier[3].
For people who take issue with MacOS look at the progress of Asahi...
Then, once Google/Android catches up things will get REALLY interesting. This is the future and the current grab for Nvidia GPUs and clouds will eventually look like crypto mining - a few great years to be capitalized on when the getting was good.
> 800GB/s bandwidth memory (192 GB!!!) is very close to the RTX 4090
40xx is not the competition. DGX H100 has 2TB of memory, H100 NVL has 2x4TB bandwidth and are selling as fast as they can be made at any price they ask.
I quoted the 4090 because this is the Mac Pro on the second gen of Apple Silicon in a desktop/workstation. In a few years Apple has nearly caught up to the flagship desktop GPU from Nvidia - who has been at this former niche for 15 years. 192GB is already enough RAM to finetune very large LLMs and we will be seeing more memory from Apple down the road.
192GB is 4 RTX A6000s or 2 A100/H110s ($20k just in GPUs)... A completely maxed out Mac Pro (with wheels and fancy mouse) is under $13k. Oh yeah and you can actually buy them.
The M3, M4, and beyond will have TFLOPS and RAM jumping by leaps and bounds. CoreML will start chipping at CUDA developer mindshare from academia on up - you can already run LLMs at more than reasonable speed on a $2000 Mac Book you already have laying around. Expect to see Mac Pros showing up in AI labs at universities and course work where every student just buys a Mac. Of course at this level it's mostly higher level frameworks anyway so transferrable knowledge to CUDA powered whatever.
As I noted, the big stuff from Nvidia will own the very high end (especially for training) for the foreseeable future and there's plenty of money to be made there as you noted.
But Apple is going to take big chunks out of Nvidia on the hardware side and a host of startups from the software/SaaS side. For hardware less demand on the low-mid side and less demand on the inference hosting side even for the big players.
For software leveraging foundational Apple models, dev tools, etc will make it so that any app developer can drop data in Xcode to tune/build a model for their app. Apps will be able to further finetune with user data on device.
See the links I provided - this is here (in beta) today.
Have you seen Nvidia's valuation lately? They are printing money because everyone wants it. I hear you but that is a utopian pipe dream that will never see the light of day. This is the gold rush.
That's exactly why it's time to strike. They don't want to cause any waves that would stop that momentum. This is the perfect time to intimidate them into falling into line just to avoid a public stink.
There is no way that the Linux people are going to intimidate NVidia. This is just not going to happen, sorry. There won't be a public stink. All that will happen is that Linux will lose market share and that people will stop seeing Linux as a viable alternative because they are documented as picking fights with industry giants they can't possibly hope to win.
Intimidate them? My brother, they are valued in the trillions of dollars. Also how will you orchestrate this coup and get everyone onboard? Impossible.
This is quite honestly the Richard Stallman take. How has that gone? As admirable as it might seem - it has no legs.
Doesn't change the fact that everyone and their brother is ordering H100's as fast as humanely possible and going all-in on CUDA. I agree there is a bubble, but the hype train is going to keep riding for some time.
I personally convinced Microsoft to rename GVFS a few years ago (because same name as a GNU project) using similar tactics, just because I thought it would be funny. All it took was front page of HN, a few reddit re-posts, and Slashdot, all driving traffic to a github issue. They went from outright refusing to ever doing anything about it to completely bending over in a matter of days.
Major corporations with their toes in the open source space are _terrified_ of dev communities turning on them.
Microsoft politely changed the name of an Azure thingy that no one in the world cares about because its name conflicted with the name of a GNOME thingy that no one in the world cares about. The analogy with Nvidia's product line is imperfect.
The valuation means nothing since Linux is the more important technology by a landslide. One is the foundation of literally everything - and the other is faster at graphics and leading an emerging LLM market. Computers still work without AI - anything else in the short term is pure hype.
My MacBook Pro crushes Llama - NVIDIA hardly has an exclusive advantage.
There's no time like the present - the Linux maintainers should have told them to fuck off ages ago and they are being punished for Linus' stance now. Linus is right about a lot of things but letting this charade go on for this long was a mistake.
"NVIDIA hates everything Linux stands for" would be a hell of a slogan they would have to adopt.
And honestly to some people - who gives a shit if they're the market leader in AI chips? There will be someone else that emerges as a competitor that does play nice. What do we lose by telling NVIDIA to piss off? 2, maybe 3 years tops?
This is effectively the last chance I see for the two to divorce and be happier in the future. Otherwise they will be locked in a shitty relationship forever.
>Force them to release an open source driver - they will comply, otherwise their AI conquest dreams will be over.
Hahahaha. Absolutely nobody in the AI space gives a single shit about the GPL. Half of the big players and half of the research institutes have tried one way or another to bastardize what "open source" means.
If they have to install Nvidia-linux which is a fork of Ubuntu with very minor patches in the kernel, they will.
I'm pretty happy that things are the way they are. Linux distros (and the kernel maintainers) can't afford to pick fights with one of their major engines behind Linux adoption in academia and industry.
NVidia comes first, then the OS decision in many contexts. You pick your fights with care, whatever your personal belief in the outcome of your bets, I would not be so sure about that one myself.
This is one of the reasons people want an open source driver: so Nvidia can be called out for that undeniably (even a source-available licence would achieve that) or so OSS devs could release a forked version without if Nvidia can't be shamed into doing so.
They have open sourced part of their driver. They stuffed all of the proprietary crap into a firmware image and open sourced a loader for it so GPL isn't a problem on their recent cards.
Their proprietary drivers will keep working on Windows for years to come, so it's not like Nvidia customers don't have any alternatives.
People would no longer buy their product if it wouldn't work on Linux. The Bazillions that Nvidia earns buying shovels in the AI gold rush? All dependent on working Linux drivers because most to all of the big AI shops run Linux clusters.
Don't you think that AI shops would sooner drop Linux than drop Nvidia? One is printing money with no viable replacement, the other is a general-purpose operating system.
I don't think that's right. switching a gpu is as easy as opening the case, replacing the gpu and installing drivers. if you switch OS you will have to find replacements and alternatives for all the software you're using to manage and run those machines, probably retrain people with that new software, migrate stuff, redo all the config in your new software etc.
On top of that I don't think there's a lot of overhead associated with using different gpus models simultaneously, allowing you to incrementally migrate your servers to a new gpu.
The problem is that even if most of the GPL is very good and rational, the theory that linking another program to a program covered by some license means that the license of the latter becomes applicable to the former is logically inconsistent (because all the methods by which a program can be used are logically equivalent to linking, including the execution of a CLI program from a shell) and in any case even if such a theory could find some legal base, it is certainly abusive and there is no ethical reason that can justify it. By the same theory, if I would write a program to run on MS Windows, my program should become the property of Microsoft.
In my opinion, the only variants of GPL that are correct and the only ones that I would use for my own work, are the former Library GPL and Lesser GPL, which are exactly like the standard GPL, except that they abandon this theory that program linking can unilaterally extend the coverage of one of the licenses of the two programs that are linked.
There is no chance of Linux winning this over Nvidia. The thing is there is no alternative to Nvidia, while there are many to Linux. The demand is seemingly infinite. Every big corp is rushing to secure as many as they can. For people talking about it being hard to keep their own forked or patched kernel, Nvidia is so big at this point that it can buy RedHat(from IBM), Suse, and almost every Linux vendor on the market and the cost would be mostly not relevant to them. There is zero chance of anyone avoiding Nvidia now due to Linux issues. Sure, 5 years ago this might have worked, but that ship has sailed.
Eh that's a pretty wild statement. Some big AI and compute custers don't outweigh the vast vast majority of servers and cloud instances running Linux that will never see or need a GPU. What are these alternatives to Linux?
For instances that don't need a GPU, this new change will simply not matter. My point is that this new change is unlikely to make Nvidia do anything differently compared to what they are already doing.
> The thing is there is no alternative to Nvidia, while there are many to Linux.
Huh? I am a backebd dev and a gamer who would never give up Linux for a proprietary OS, but has no NVidia hardware.
That being said, I know you're talking about industry. My question is, so are we supposed to just take it? NVidia has to be pushed to do the right thing here, as AMD and Intel have done or are we just slaves to 'too big to fail' and somehow this is a triumph of capitalism?
I am talking about industry solely, and the time for pushing was 5 years ago and before. I am not saying what would be the ideal outcome, but that at this point anyone running AI workloads will abandon Linux over Nvidia if there is a need to do so.
I suspect we're going to see more and more specialized hardware in this area before that happens, but what benefit exactly is there to having them on Linux anyway?
Most of that industry is highly opposed to being open in any sensible definition of that word, so what do they bring exactly?
NVDAs foothold here is not about gaming, but machine learning. Few people play on Linux anyway, but machine learning is basically not happening without Nvidia. Not that this is favorable, but it is true. And yes, I am taking it, I simply do not care that much.
And I am guessing ML workloads use up a single computer to do just that (and nothing else), meaning that NVidia could start their own fork of Linux, and people need to just eat it (or switch to AMD, Intel, etc.!)
