Making life (even) harder for proprietary modules
lwn.net
lwn.net
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.
The suit in this case would be for compliance with the GPL.
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.
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.
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.
https://www.justia.com/trials-litigation/lawsuits-and-the-co...
It's the first I've heard of it, but maybe I'm just too out of the loop.
I work daily with LLVM and haven't noticed any slowdown in contributions by employees from Google or Apple.
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.
[0] TiVo clause be damned
>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.
It's also worth noting that, in 2016 when Linus shared this view, NVIDIA's market cap was 60B. It's now 1200B: https://www.macrotrends.net/stocks/charts/NVDA/nvidia/market...
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.
> 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.
[0] https://www.linuxfoundation.org/about/members (I had to grep the HTML to find it)
https://lore.kernel.org/lkml/20230731083806.453036-6-hch@lst...
"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.
See also kernel_fpu_begin
Unless you mean specifically how the GPL is written, but the GPL doesn't get to decide what's derivative, copyright does.
And if that was solidly true, why isn't every symbol marked GPL?
Also FSF tends to overstate the importance of linking.
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.
Changing some entry points won't make it a derived work.
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.
Which they blatantly aren't.
Especially since the GPL license does explicitly allow you to modify the source.
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.
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.
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 is literally implementing kernel level DRM, the thing free software swore to destroy.
Or at least the requirement that proprietary drivers do not interact with GPL-only code would in my opinion be considered an EULA.
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.
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.
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.
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.
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.
1: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
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.
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.
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.
When one checks the wording of the "exception", https://github.com/torvalds/linux/blob/master/LICENSES/excep... it says
> 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.
It's not there in 0.99.9.
> 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.
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.
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:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
> 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.
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?
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.
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.
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.
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
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.
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.
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.
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.
If that were the case, the LGPL would never have been needed.
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 dynamic linking you never distribute someone else's code so you don't need a license to distribute it.
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.
> 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?
The marking on symbols cannot be trusted.
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.
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?
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.
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.
> 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.
But I may have misunderstood/misremembered the details. It's been years since I cared enough to do a deep dive on this.
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.
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.
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.
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?
This stupid DRM crap helps no one and only fuels more cat-and-mouse games that waste everyone's time.
"Get along, kids."
Except most loadable kernel modules are in the kernel source tree and available under the GPL.
It will only run blobs signed by a private key owned by NVIDIA, the public key is part of the open source module.
Or we create a hypervisor that virtualizes linux, and bypasses most of the kernel or...
There's always a way... this is just annoying and makes it more expensive to get decent drivers for Linux, so less effort will be spent there.
No, it makes it more expensive to get proprietary drivers for Linux; it is not clear that this is a great loss.
First of all they care if it works well enough.
The biggest draw of open source is the "free as in beer" part (gratis), relatively few people care about the "free as in freedom" (libre).
how is AI stuff tied to nvidia? what would make it difficult to port (or to be portable)?
It doesn't help that AMD's equivalent open toolchain, ROCm, is barely even supported by their own GPU lineup.
But these days, commercial companies have more say over what and how hardware is used in Linux than we do.
10 years ago, it was different. Mostly Linux geeks who wanted to play games, who were minority of their sales, cared about it.
Now, basically all of NVIDIA valuation is built on AI, and almost all major players who buy their HW, and a lot of it, use it on Linux.
Cutting Linux off is not an option for NVIDIA.
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.
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 are already VM/container-focused distributions (Alpine etc). There is no real ecosystem fork and likely never will be.
Most desktop Linux users don't need NVIDIA even a little, because AMD's GPUs will serve them just fine. They're not doing AI.
Or at least we hope Nvidia wouldn't be left as the only vendor of modern GPUs in that case. That would be very unfortunate.
And willingness of others to follow. NVIDIA needs Linux to sell their HW. For Linux NVIDIA isn’t even 1% of their market.
INAL.
AMD cards work very well in linux.
the propritary driver for nvidia was generally decent, but i got an AMD card for my last build because the FOSS driver was good
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
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 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.
It’s literally not, it’s what AMD’s maintainers have said themselves?
> HDMI 2.1 is not available on Linux due to the HDMI Forum. See: https://www.phoronix.com/scan.php?page=news_item&px=HDMI-Clo...
https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_83...
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
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.
Unfortunately I do also need to run Linux, to a degree, so I'm using a distribution that removes the DRM.
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.
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.
A single 16TB Helium sealed HDD is 350USD (https://www.westerndigital.com/products/internal-drives/wd-g...).
When you mentioned tape, I was assuming you had a lot more data than just 13TB. Normally I hear people mention it with like 100+TB.
And was like: "WTF? No way, that must have been a Court order".
And then relief...
And what does illicit use of things you yourself own even look like?
I did provide an example of illicit usage, could you please just read it again?
There is this weird opinion that once you buy an object, it becomes yours, and is no longer the property of whoever made it.
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.
Maybe NVidia could persuade end users to patch their kernel to get around this?
So at worst it will force more complicated workaround solutions for Nvidia driver devs which could in turn cause more bugs for users.
It's desktop users with NVIDIA GPUs who will end up shafted.
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.
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.
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
In fact I will expect that one (cough Ubuntu cough) may do it on their own just to get a bigger slice of people working with Cuda
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?
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.
Similarly, the loader, BIOS, etc, are not encumbered by the kernel license.
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?".
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?
2. to trace from a source or origin
I don't really see the difference-- as long as you have tools to pull apart the disk image.
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.
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.
LineageOS proves nothing. It's a separate work.
In the past they prevented people from running consumer GPUs on Xen systems.
And arbitrary limitations implemented at the driver level to force you to purchase their enterprise GPUs, see https://github.com/keylase/nvidia-patch#nvenc-and-nvfbc-patc...
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.
Couldn't NVidia just compile against a compatible, but ASL header?
Just trying to understand whats happening!
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.
Will the drivers work worse or outright break?
Why would the average Linux user who doesn't give a shit about licensing want this?
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.
They already have, but their open modules only work on newer cards. https://github.com/nvidia/open-gpu-kernel-modules.
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.
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?
Yeah yeah, there's some moral argument over licensing and FOSS, but in the spirit of pragmatism sometimes you ought to look the other way.
Yeah, yeah
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.
Are you familiar with Phoronix?
> 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.
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.
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.
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.
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.
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.
There would be literally zero reduction in performance by relicensing currently-proprietary code under the GPL.
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.
It would lend credibility to your arguments if you understood the difference between criminal and civil actions.
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".
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.)
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.
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?
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.
And the GPL has always noted exceptions for system-provided libraries.
Kernel modules run inside kernel-space. 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.
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.
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.
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.
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!
NVIDIA deliberately violates GPL license.
> The problem is that Linux does not have a clear license
are you sure about that?
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.
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.
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.
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.
Enforcing licences and neutering illegal violation of license is not a witch hunt.
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.
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.
It says it's dual licensed MIT/GPL2
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.
also gives them a way to relieve pressure on the AI market. "install the open drivers bro", assuming it works.
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.
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.
Why wouldn't they? It would only be a few million dollars a year to do so, at most.
https://docs.nvidia.com/dgx/dgx-os-6-user-guide/introduction...
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.
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".
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.
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.
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.
[0] - https://coremltools.readme.io/docs
[1] - https://coremltools.readme.io/docs/xcode-model-preview-types
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.
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.
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.
This is quite honestly the Richard Stallman take. How has that gone? As admirable as it might seem - it has no legs.
Major corporations with their toes in the open source space are _terrified_ of dev communities turning on them.
My MacBook Pro crushes Llama - NVIDIA hardly has an exclusive advantage.
"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.
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.
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.
Their proprietary drivers will keep working on Windows for years to come, so it's not like Nvidia customers don't have any alternatives.
We should take this mantra to the Nvidia offices and chant it until we go hoarse, may the proprietary blob crumble like the walls of Jericho.
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.
Just because your project is open source is no reason to try to force everyone else to be open source.
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?
Most of that industry is highly opposed to being open in any sensible definition of that word, so what do they bring exactly?