[HN Gopher] Making life (even) harder for proprietary modules
___________________________________________________________________
Making life (even) harder for proprietary modules
Author : segfaultbuserr
Score : 333 points
Date : 2023-08-30 09:41 UTC (13 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| netsharc wrote:
| What colour are your bits[1], but on the kernel level... Yay?
|
| [1] https://ansuz.sooke.bc.ca/entry/23
| btdmaster wrote:
| Except in this case NVIDIA can decide to colour those bits GPL
| by licensing their drivers.
| gentleman11 wrote:
| I assumed this was related to the official drivers spying on you,
| but was mistaken. This is only about integrating with gpl code
| nly wrote:
| Not sure what's to gain here really. NVIDIA are free to remove
| this check and just ship their own Linux distro to their
| profitable customers.
|
| It's desktop users with NVIDIA GPUs who will end up shafted.
| Zigurd wrote:
| 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.
| COGlory wrote:
| Are they going to port all my GPU accelerated software over to
| that distro?
| kkielhofner wrote:
| 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.
| mrighele wrote:
| My guess is that Nvidia will get into a partnership with some
| distro to use a patched kernel that removes the relevant parts.
|
| 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
| xav0989 wrote:
| They already do: https://docs.nvidia.com/dgx/dgx-os-6-user-
| guide/index.html
| AdmiralAsshat wrote:
| 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.
| bjoli wrote:
| 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.
| josefx wrote:
| Can you list what abuses by nvidia you are talking about that
| made life for users worse?
| effie wrote:
| 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.
| tedivm wrote:
| 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.
|
| https://docs.nvidia.com/dgx/dgx-os-6-user-guide/index.html
| NikkiA wrote:
| 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
| kkielhofner wrote:
| Thank you for providing this! When I wrote my comment below I
| suspected such a thing existed but I wasn't sure.
| slim wrote:
| 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)
| admax88qqq wrote:
| 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.
| junon wrote:
| Not unless they open source the derivation of otherwise make
| the source available.
| jacooper wrote:
| Which they won't do because they don't want to open source
| their drivers, that's the whole issue.
| mlyle wrote:
| 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.
| dTal wrote:
| 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?
| mlyle wrote:
| > What is a firmware blob, if not a derived work?
|
| 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
| dTal wrote:
| 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.
| junon wrote:
| I am not 100%, but inclusion of GPL software is not
| prohibited in non-GPL works as long as the GPL work is
| made available, at least upon request.
| dTal wrote:
| 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.
| admax88qqq wrote:
| This is different thatn TiVo-ization.
|
| 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.
| dTal wrote:
| 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.
| mlyle wrote:
| 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.
| dTal wrote:
| 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?".
| exabrial wrote:
| Are we saying that _ALL_ Linux kernel modules by their very
| nature _HAVE TO_ be GPL?
|
| Couldn't NVidia just compile against a compatible, but ASL
| header?
|
| Just trying to understand whats happening!
| userbinator wrote:
| 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.
|
| "Get along, kids."
| tigrezno wrote:
| Just when I bought my first Amd Radeon card :)
| orangetuba wrote:
| I just switched to AMD Radeon as well to get away from the
| nVidia hellscape that is nVidia and Linux.
| rany_ wrote:
| 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.
| nialv7 wrote:
| I thought the nvidia kernel driver is open sourced?
| https://github.com/NVIDIA/open-gpu-kernel-modules
|
| It says it's dual licensed MIT/GPL2
| rany_ wrote:
| That's only for a small subset of their more recent GPUs, as
| you can see here: https://github.com/NVIDIA/open-gpu-kernel-
| modules#compatible...
|
| 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.
| COGlory wrote:
| It is absolutely an alternative. We are running it on an
| HPC cluster with dozens of A40s and A100s and getting
| comparable benchmarks.
| rany_ wrote:
| I'll add "for desktop users" as that's my only experience
| with it. I haven't used it for compute.
| beanjuiceII wrote:
| what are you talking about, if this is a violation you'd see it
| in courts but it's not because there's no case
| [deleted]
| TheDong wrote:
| 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.
| justin66 wrote:
| > Most crimes don't end up in courts.
|
| It would lend credibility to your arguments if you
| understood the difference between criminal and civil
| actions.
| tsimionescu wrote:
| 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.
| vilunov wrote:
| 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.
| cryptonector wrote:
| > 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".
| adrian_b wrote:
| 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.
| Zigurd wrote:
| 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.
| TheDong wrote:
| > 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?
| adrian_b wrote:
| 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.
| TimeBearingDown wrote:
| If a kernel module is not derivative of the kernel, what
| use does it then serve once separated from any Linux GPL
| code?
| adrian_b wrote:
| This argument is lame.
|
| 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.
| PaulDavisThe1st wrote:
| The OS/user-space boundary has always been defined by
| Linux (and by Linus) as a license boundary.
|
| And the GPL has always noted exceptions for system-
| provided libraries.
|
| Kernel modules run inside kernel-space. They are
| completely unlike user space applications.
| adrian_b wrote:
| > 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.
| PaulDavisThe1st wrote:
| 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.
| adrian_b wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| paulmd wrote:
| 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!
| matkoniecz wrote:
| > I do not see on what grounds you can classify in this case
| Linux as a victim and NVIDIA as an attacker.
|
| NVIDIA deliberately violates GPL license.
|
| > The problem is that Linux does not have a clear license
|
| are you sure about that?
| adrian_b wrote:
| 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.
| mrweasel wrote:
| 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.
| bogwog wrote:
| Those are exactly the type of people who have the power to
| pressure Nvidia to do the right thing.
| crabbone wrote:
| Open-sourcing code doesn't take it away from the author...
| what are you talking about?
| mrweasel wrote:
| What are you talking about?
|
| 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.
| crabbone wrote:
| 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.
| mrweasel wrote:
| Still not sure what you're getting at.
|
| 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.
| deeviant wrote:
| 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.
| TimeBearingDown wrote:
| 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.
| rany_ wrote:
| 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.
| matkoniecz wrote:
| > open source witch hunt
|
| Enforcing licences and neutering illegal violation of license
| is not a witch hunt.
| GuB-42 wrote:
| 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.
| genocidicbunny wrote:
| > 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.
| [deleted]
| TechBro8615 wrote:
| 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.
| rmbyrro wrote:
| 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".
|
| And then relief...
| Karellen wrote:
| Who is the "they" in "their hardware"?
|
| And what does illicit use of things you yourself own even look
| like?
| rmbyrro wrote:
| Come'on, there's only one hardware maker there, no need to
| specify.
|
| I did provide an example of illicit usage, could you please
| just read it again?
| Karellen wrote:
| 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.
| phendrenad2 wrote:
| 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.
| Longlius wrote:
| >However you could argue that ALL loadable kernel modules are
| violating the GPL equally
|
| Except most loadable kernel modules are in the kernel source
| tree and available under the GPL.
| hlandau wrote:
| There is a comment here by the author of this patch which is
| absolutely extraordinary:
|
| 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.
| baq wrote:
| Being open source with GPL2 is a digital right, is it not? DRM
| is a logical step against GPL piracy.
| tremon wrote:
| 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.
| ye-olde-sysrq wrote:
| RMS even describes the GPL's weaponizing of copyright against
| itself as a "judo throw" in his writings. The intent there is
| very explicit.
| kmeisthax wrote:
| RMS also changed GPLv3 to specifically forbid exactly the
| kind of lawsuit being threatened in the commit message.
| thrtythreeforty wrote:
| I am less familiar with the lawsuit sections of GPLv3;
| would you mind pointing to the relevant sections?
| kmeisthax wrote:
| GPLv3 has the following clause:
|
| >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.
| ye-olde-sysrq wrote:
| 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.
| gnull wrote:
| > 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.
| trustmebro wrote:
| The values of the FOSS community are pro Good. If you do
| something shady, and they help you save face with a gentle
| touch like this, you're lucky.
| Dylan16807 wrote:
| It's a shady workaround to the kernel itself being shady with
| which symbols get marked GPL.
| mort96 wrote:
| Marking symbols as GPL is not shady.
| Dylan16807 wrote:
| For the symbols where use of them does not imply that the
| code is derivative of the kernel, it is shady.
|
| See also kernel_fpu_begin
| mort96 wrote:
| Code which links against the kernel is derivative as far
| as the GPL is concerned.
| [deleted]
| Dylan16807 wrote:
| That's obviously not true when you consider code that was
| ported from other architectures.
|
| 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?
| Bjartr wrote:
| 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.
| nvm0n2 wrote:
| Presumably they actually can't, because the forked kernel
| would still be GPL.
| Bjartr wrote:
| How would the GPL stop them from removing the check? They'd
| have to share their changed kernel source, but nobody would
| want it.
| nvm0n2 wrote:
| 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.
| Bjartr wrote:
| 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.
| EMIRELADERO wrote:
| Don't they realize the DMCA has interoperability exceptions for
| this sort of thing?
| sterlind wrote:
| 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.
| Dylan16807 wrote:
| > 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.
|
| Which they blatantly aren't.
| Traubenfuchs wrote:
| What is the consequence of this?
|
| Will the drivers work worse or outright break?
|
| Why would the average Linux user who doesn't give a shit about
| licensing want this?
| otherme123 wrote:
| 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?
| pantalaimon wrote:
| This is not about what the users what, it's about the intention
| of the developers as expressed in the license.
| H8crilA wrote:
| Precisely. As a user who didn't write the code you don't get
| to say how people, including you, can use it.
| jeroenhd wrote:
| 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.
| kaladin-jasnah wrote:
| > 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.
|
| They already have, but their open modules only work on newer
| cards. https://github.com/nvidia/open-gpu-kernel-modules.
| fsflover wrote:
| Discussion: https://news.ycombinator.com/item?id=31344981
| jeroenhd wrote:
| 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.
| [deleted]
| [deleted]
| mnd999 wrote:
| Yeah, users suffer because the kernel devs are having a dick
| swinging contest with nVidia. Pretty pathetic all round.
| r1ch wrote:
| I hope this doesn't break ZFS again.
| jeroenhd wrote:
| 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.
| loeg wrote:
| It's somewhat controversial but there's no real conflict
| between the licenses at runtime.
| jeroenhd wrote:
| 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.
| johnny22 wrote:
| blow it up? or just cause it to not work and force you to
| temporarily go back to an earlier kernel?
| Filligree wrote:
| There aren't any viable alternatives to ZFS, however. It
| would be easier to swap out the rest of the OS.
| jeroenhd wrote:
| 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.
| Filligree wrote:
| 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.
| mnd999 wrote:
| If you're building a ZFS based storage server, FreeBSD is a
| great choice for this reason.
| rascul wrote:
| Are there other companies that distribute closed source kernel
| modules that this could have implications for? Or is it just
| Nvidia?
| londons_explore wrote:
| Im worried that one day kernel developers might try to force all
| of userspace to be GPL or otherwise oper source.
|
| Just because your project is open source is no reason to try to
| force everyone else to be open source.
| mort96 wrote:
| Why would you be worried about that? What has the kernel
| community ever said to even indicate that they'd want to move
| in that direction?
| CodesInChaos wrote:
| 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.
| andromeduck wrote:
| BSD exists and Nvidia maintains some support for it.
| drewg123 wrote:
| 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.
| gavinray wrote:
| Why do this? Impeding Nvidia's productivity on Linux only harms
| the Linux community.
|
| 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.
| version_five wrote:
| Yeah, yeah
|
| 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.
| juancn wrote:
| Next step, we make an open source loadable module with a small
| virtual machine that loads blobs from user mode.
|
| 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.
| yjftsjthsd-h wrote:
| > 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.
| Aardwolf wrote:
| 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.
| jmclnx wrote:
| I think Linux should mirror what OpenBSD does, remove all
| support for nVidia until it is opened up.
|
| But these days, commercial companies have more say over what
| and how hardware is used in Linux than we do.
| zb10948 wrote:
| And OpenBSD has how much share in workstation/graphics
| market?
| freilanzer wrote:
| > less games
|
| AMD cards work very well in linux.
| red-iron-pine wrote:
| yeah the open source driver is pretty solid
|
| the propritary driver for nvidia was generally decent, but i
| got an AMD card for my last build because the FOSS driver was
| good
| justapassenger wrote:
| NVIDIA needs Linux in 2023 much more than Linux needs them.
|
| 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.
| Nextgrid wrote:
| Nvidia already _has_ Linux (up to this change).
|
| 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.
| wongarsu wrote:
| 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.
| justapassenger wrote:
| 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.
| grotorea wrote:
| But can NVIDIA maintain a patchset that just removes
| these new protections from the kernel instead of a
| complete fork?
| [deleted]
| justapassenger wrote:
| 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.
|
| INAL.
| ylyn wrote:
| No, I don't think they can really fork it. How are they
| going to get support for new hardware in their fork?
| Nextgrid wrote:
| 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.
| toyg wrote:
| Lol, what do you think runs those hypervisors, macOS and
| Windows...?
|
| There are already VM/container-focused distributions
| (Alpine etc). There is no real ecosystem fork and likely
| never will be.
| sassy_quat wrote:
| [dead]
| pxc wrote:
| > making the situation worse for desktop Linux users and
| consumers
|
| 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.
| josefx wrote:
| 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.
| Clamchop wrote:
| If and when everyone is running AI workloads, then all of
| the competition will need to have proper support for it.
|
| 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.
| itsboring wrote:
| 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.
| [deleted]
| umanwizard wrote:
| Losing their dominant position in Linux would be catastrophic
| for Nvidia; they'll do anything to avoid that happening.
| wang_li wrote:
| 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.
| colinsane wrote:
| 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)?
| trasz4 wrote:
| [dead]
| gnu8 wrote:
| 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.
| yrro wrote:
| 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?
| jujube3 wrote:
| Don't clutter up this thread with actual facts and
| information.
| jesprenj wrote:
| Why shouldn't a proprietary driver be able to interact with a
| free kernel?
|
| 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.
| Karellen wrote:
| > 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:
|
| 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.
| adrian_b wrote:
| > 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.
| pdonis wrote:
| _> 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.
| Karellen wrote:
| It's not a restriction on use.
|
| 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.
| adrian_b wrote:
| 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.
| Karellen wrote:
| > Writing a program "based on" an API, i.e. which invokes
| the provided functions, is not a derivative work.
|
| If that were the case, the LGPL would never have been
| needed.
| im3w1l wrote:
| 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.
| adrian_b wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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?
| Dylan16807 wrote:
| > 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?
|
| The marking on symbols _cannot be trusted_.
| pdonis wrote:
| _> 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.
| em-bee wrote:
| 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?
| chaorace wrote:
| > 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.
| PaulDavisThe1st wrote:
| 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.
| klempner wrote:
| 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.
| em-bee wrote:
| 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.
| adrian_b wrote:
| 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.
| em-bee wrote:
| 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.
| Karellen wrote:
| > 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.
| redeeman wrote:
| > Because Linus is more pragmatic than RMS.
|
| 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
| pjc50 wrote:
| 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.
| tsimionescu wrote:
| 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.
| jesprenj wrote:
| 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).
| tremon wrote:
| 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.
| dragonwriter wrote:
| > 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.
| jeroenhd wrote:
| > 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.
| linuxftw wrote:
| 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.
| jeroenhd wrote:
| 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.
| grotorea wrote:
| 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.
| linuxftw wrote:
| 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.
|
| 1: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_Ame
| rica,_....
| cmeacham98 wrote:
| > 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.
| linuxftw wrote:
| My mistake, thanks for the clarification.
|
| 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.
| [deleted]
| Matl wrote:
| > 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?
| kmeisthax wrote:
| 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.
| floxy wrote:
| 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.
| tzs wrote:
| > 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.
| phendrenad2 wrote:
| 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.
| nextaccountic wrote:
| > 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.
|
| When one checks the wording of the "exception", https://githu
| b.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.
| samus wrote:
| 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.
| mkl wrote:
| The exception has been there since v1.0 I think:
| https://mirrors.edge.kernel.org/pub/linux/kernel/v1.0/
|
| It's not there in 0.99.9.
| juancn wrote:
| All this lawyer-ese detracts from making Linux useful. It's a
| pity that so much effort is spent on some fundamentalist view of
| open source.
| barryrandall wrote:
| Agreed. NVIDIA is wasting kernel developers' time and humanity
| would be better off if they just open sourced their driver.
| jeroenhd wrote:
| 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.
| [deleted]
| lucasyvas wrote:
| 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.
| seanw444 wrote:
| 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.
| whoopdedo wrote:
| 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?
| seanw444 wrote:
| 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.
| whoopdedo wrote:
| 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.
| kkielhofner wrote:
| One word: Apple.
|
| 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
|
| [2] - https://www.apple.com/mac-pro/
|
| [3] - https://www.amd.com/en/products/frontier
| blackoil wrote:
| > 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.
| kkielhofner wrote:
| 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.
| jacquesm wrote:
| 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.
| freeone3000 wrote:
| 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.
| sam0x17 wrote:
| webgpu will eventually fill this role right?
| elromulous wrote:
| +1
|
| 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.
| tw04 wrote:
| >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.
| nvm0n2 wrote:
| 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).
| lamontcg wrote:
| > but unless Nvidia is planning on forking the kernel and
| fully maintaining their own version of Linux
|
| https://docs.nvidia.com/dgx/dgx-os-6-user-
| guide/introduction...
| tw04 wrote:
| 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.
| lamontcg wrote:
| 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".
| MichaelZuo wrote:
| > ... 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.
| seanw444 wrote:
| Yeah, they totally would.
| COGlory wrote:
| 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.
| MichaelZuo wrote:
| No, it would be a lot easier to modify their applications
| then wait for AMD to create CUDA 2.0.
| lucasyvas wrote:
| Linux wins hands down, it always has.
| intelVISA wrote:
| There's quite a lot of questionable telemetry in the driver, I
| am not sure how it would work if exposed to GDPR scrutiny like
| that.
| dspillett wrote:
| 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.
| PaulHoule wrote:
| Whatever. From a pragmatic perspective it's a reason to stick
| with Windows.
| whalesalad wrote:
| 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.
| sam0x17 wrote:
| > Have you seen Nvidia's valuation lately
|
| 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.
| jacquesm wrote:
| 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.
| lucasyvas wrote:
| 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.
| whalesalad wrote:
| 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.
| mrguyorama wrote:
| nVidia's entire valuation right now is riding the AI
| bubble. All you have to do is convince the market that
| this disagreement might hurt that.
| whalesalad wrote:
| 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.
| sam0x17 wrote:
| One article saying "AMD playing nice with open source,
| nVidia not, will nVidia continue to be a leader in AI?"
| and they'll fold
| blackoil wrote:
| That's a daydream. NVidia never played nice with OSS.
| People still use it and are doubling down on CUDA.
| sam0x17 wrote:
| 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.
| justin66 wrote:
| 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.
| lucasyvas wrote:
| 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.
| ohgodplsno wrote:
| >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.
| [deleted]
| pedrocr wrote:
| 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.
| kmeisthax wrote:
| 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.
| aseipp wrote:
| 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.
| cryptonector wrote:
| Or perhaps Linux et. al. suing Nvidia and others might cause
| pressure to relax the DMCA. We can only speculate.
| kmeisthax wrote:
| 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.
|
| [0] TiVo clause be damned
| [deleted]
| [deleted]
| cogman10 wrote:
| Lawsuits are like nuclear war in this instance.
|
| 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.
| gwd wrote:
| > Lawsuits are like nuclear war in this instance.
|
| 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.
| cogman10 wrote:
| > 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...
| llm_thr wrote:
| The difference is that the suit in that case was for
| billions of dollars.
|
| The suit in this case would be for compliance with the GPL.
| MichaelZuo wrote:
| Every additional interest involved in the case would
| multiply legal complexity, and legal costs, probably
| exponentially.
| beanjuiceII wrote:
| 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
| Zigurd wrote:
| 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.
| cogman10 wrote:
| 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.
| teddyh wrote:
| 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.
| [deleted]
| CoastalCoder wrote:
| Could you elaborate on this?
|
| It's the first I've heard of it, but maybe I'm just too out
| of the loop.
| teddyh wrote:
| <https://news.ycombinator.com/item?id=32924033>
| Scoring6931 wrote:
| Is your source a random person on the Internet?
|
| I work daily with LLVM and haven't noticed any slowdown
| in contributions by employees from Google or Apple.
| teddyh wrote:
| 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.
| dagmx wrote:
| 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.
| teddyh wrote:
| It could be that I am conflating Clang with LLVM.
| gameoverhumans wrote:
| 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 :)
|
| [1]: https://www.youtube.com/watch?v=tQIdxbWhHSM
| garaetjjte wrote:
| Linus opinion on GPL enforcement is clear:
| https://lists.linuxfoundation.org/pipermail/ksummit-
| discuss/...
|
| >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.
| zb3 wrote:
| Why would it be awful? I agree that DMCA 1201 is awful, but if
| Nvidia can use that, we should be able to do it as well.
| throwaway09223 wrote:
| Any of the thousands of contributors to the Linux kernel can
| make this claim. Linus doesn't have any special authority here.
| jauntywundrkind wrote:
| From the article, Hellwig's write-up:
|
| > 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.
| jeroenhd wrote:
| 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.
| mnd999 wrote:
| If you break everyone's computers you're going to get then blame,
| whether it's your fault or not.
| vuavu wrote:
| Linux kernel working against their users? Why?
| Moomoomoo309 wrote:
| 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.
| Aissen wrote:
| LWN covered this in a now-freely available article:
| https://lwn.net/Articles/939842/ ; it has a bit more details and
| context.
| trimethylpurine wrote:
| Thank you. This is a much better article.
| dang wrote:
| Ok, we've changed to that from
| https://www.phoronix.com/news/Linux-6.6-Illicit-NVIDIA-
| Chang.... Thanks!
| Erlangen wrote:
| @dang, could you use this link instead?
| dcow wrote:
| 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?
| dang wrote:
| 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.
| abtinf wrote:
| 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.
| loeg wrote:
| > reposting content from another source
|
| 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.
| sp332 wrote:
| Typing "@dang" doesn't actually do anything. To message the
| mods, use the Contact email at the bottom of the page.
| freedomben wrote:
| 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.
| lacoolj wrote:
| Guess I'll have to prevent upgrading to this kernel until NV gets
| their end straightened out
| the8472 wrote:
| 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.
| duped wrote:
| 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?
| xxs wrote:
| CUDA, and pretty much all optimization(hacks) done to run games
| better
| rany_ wrote:
| > CUDA, and pretty much all optimization(hacks) done to run
| games better
|
| 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.
| duped wrote:
| They could bake this into the firmware as an opaque blob, no?
| rany_ wrote:
| 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.
| HeckFeck wrote:
| "Fuck you Nvidia" - L. Torvalds.
|
| 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.
| vladvasiliu wrote:
| What good would that do if people keep buying their product as-
| is?
| c4mpute wrote:
| 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.
| dns_snek wrote:
| 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.
| legacynl wrote:
| 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.
| blackoil wrote:
| Have you read about latest NVidia results? There are no
| other GPUs. Else they wouldn't have 800% profit growth.
| grotorea wrote:
| Aren't you forgetting the "buy a GPU" step? And aren't
| most OSes either free or significantly cheaper than the
| sort of GPU AI uses?
| bigbillheck wrote:
| If you switch your GPU away from Nvidia, you're also
| switching away from CUDA which is an extremely big deal.
| mkl wrote:
| No, people would just patch their kernel to undo this
| restriction. Some distributions would just do it for
| everyone.
| [deleted]
| devit wrote:
| 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.
| drewg123 wrote:
| 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.
| ribit wrote:
| Oh the irony... and these are people preaching "software freedom"
| two_handfuls wrote:
| [flagged]
| adrian_b wrote:
| 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.
| crop_rotation wrote:
| 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.
| Matl wrote:
| > 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?
| incrudible wrote:
| 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.
| crop_rotation wrote:
| 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.
| Matl wrote:
| 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?
| kcb wrote:
| 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?
| crop_rotation wrote:
| 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.
| datenwolf wrote:
| They should add this ASCII art to every commit that rekts
| Nvidia's shenanigans: /*------
| +--------------------------------------+ //--\\\\
| | _ _ _ _ _ | // _ _\\
| | | \| |_ _(_)__| (_)__ _ | \|(0)(0)\
| | | .` \ V / / _` | / _` |_ | d n " b
| | |_|\_|\_/|_\__,_|_\__,_( ) | \_U_^ /
| | |/ | /
| \_/|_____ | Nvidia, |
| ___\ |__/\ \_ | Fuck you! |
| / | / |:| \ | ___ _ _ |
| / / /\ |:| | \ | | __| _ __| |__ _ _ ___ _ _| | |
| | /\__/ \|:\ | \ | | _| || / _| / / | || / _ \ || |_| |
| \ /\ / ||: \ \ | | |_| \_,_\__|_\_\ \_, \___/\_,_(_) |
| \/ \_/ ||: | | \| |__/ |
| / / //; \ | |+--------------------------------------+
| \ / /|; \ | */
| dang wrote:
| Please don't do this here.
| pxeger1 wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-30 23:01 UTC)