this post was submitted on 30 Aug 2023
112 points (100.0% liked)

Linux

8119 readers
13 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 1 year ago
MODERATORS
all 25 comments
sorted by: hot top controversial new old
[–] baggins@lemmy.ca 17 points 1 year ago (4 children)

Hmm I don't really understand any of this. Wish this one came with an ELI5

[–] LPThinker@lemmy.world 29 points 1 year ago (1 children)

I can't claim full understanding, but what I took away from it was that NVIDIA somehow ended up using GPL-licensed code in their proprietary drivers, possibly in a way that could incriminate the Linux kernel if not handled properly. My best guess (as someone with no kernel programming experience) is that NVIDIA sometimes contributes code directly to the Linux kernel that exists solely to support their proprietary drivers (the shims mentioned in the article). Apparently, these shims were exporting GPL-licensed code for use inside the proprietary drivers, which would be a violation of the GPL (unless NVIDIA made the source code for their proprietary drivers freely available in compliance with the GPL).

TLDR: (I think?) NVIDIA essentially infected the linux kernel with license violations to support their proprietary drivers, and the linux kernel devs are working to excise the violations and prevent anything like that going forward.

[–] superminerJG@lemmy.world 13 points 1 year ago (1 children)

well, if that's true I should be allowed to email NVIDIA and ask for their driver code

[–] ggppjj@lemmy.world 7 points 1 year ago (1 children)

You're allowed to email anyone you want.

[–] Ajen@sh.itjust.works 4 points 1 year ago (1 children)

That's not what the restraining order says

[–] ggppjj@lemmy.world 2 points 1 year ago

And you're gonna listen to that silly 'ol piece of paper over me, a complete stranger online?

[–] dan_linder@lemmy.world 25 points 1 year ago (1 children)

I'm not an expert but this is what I understand from a podcast l listened to (https://twit.tv/shows/untitled-linux-show):

There's a subset of Linux users who desire or need GPL compliant environments for they purposes (personal or work related).

There's a kernel flag that is set to track if the drivers or gas loaded are also 100% GPL.

NVidia wrote their own video driver which is NOT GPL compliant, so as soon as they are loaded the kennel flag is set to "not GPL". To get around the simple checks for GPL compliant drivers, NVidia wrote a wrapper (a "condom") to lie that it was GPL-compliant when it was violating the GPL flag meaning.

The Linux 6.6 release apparently has more protections to keep NVidia from working around the GPL check. (For now...)

[–] baggins@lemmy.ca 5 points 1 year ago (1 children)

Interesting. I wonder why Nvidia cares.

[–] d3Xt3r@lemmy.world 10 points 1 year ago (1 children)

nVidia doesn't, but lawyers do. License violations are not cool, regardless of who does it.

[–] baggins@lemmy.ca 2 points 1 year ago

They must care otherwise why would they bother to hack the GPL flag. 🤷

[–] IHeartBadCode@kbin.social 22 points 1 year ago (1 children)

Tainted kernels are not supported. Kernel devs aren't spending time to fix bugs that come from a taint (uses blobs of code that are not open sourced) driver. Because the closed drivers can wreck all kinds of havoc and the kernel devs are helpless to fix the actual "source" of the problem.

There's been all kinds of ways for the kernel to detect tainted binaries. nVidia is notorious for trying to circumvent that detection so that engineers can sit there and blame the kernel for failures.

nVidia has been a massively shit company to the open source community. If I had a list of most anti FOSS companies to ever exist, nVidia would be right behind SCO, with like TiVo behind nVidia. I know it's hard but people who enjoy open source projects shouldn't do business with the company. But if you got to have a nVidia card so be it, but I cannot NOT recommend nVidia enough.

[–] JATtho@sopuli.xyz 1 points 1 year ago* (last edited 1 year ago)

I almost posted comment about this but I had to keep it short. The Nvidia has an problem with their driver tainting the customers kernel/system which renders the customer in bad situation. (Of not being able to get support from kernel devs)

The proprietary taint is there for exactly for this reason:

  • You load an proprietary module and all bets are off.
  • For starters, you cannot tell there isn't a backdoor engineered into it.
  • Even if the module behaves well, you now cannot debug the rest of the system any more, because all trust is gone.
  • You cannot (at least easily) audit such system.

Nvidia solution to this is breaking the kernel license terms and acting like illegal smugglers in-order to access those sweet sweet GPL-only kernel APIs as lazily as possible. I would say that this is just arrogant and greedy way of doing software development. On top of this the kernel devs get all the blame for their vigilantly of trying to exercise their own license terms.

I think if nvidia would not be this arrogant and vile to the kernel devs, they would already have an proper kernel module that could co-exist between the GPL and proprietary code. If the proprietary code is implemented only in user-space/firmware they can keep their secrets: The user-space <-> kernel-space is an boundary where kernel GPL ends. Implementing such thing would not be easy, but I don't regard it being impossible: look at android.

In extreme: If the hostility continues, kernel devs just might be forced to go invent an corporate blacklist that goes against all principles of co-operation.

Others slightly more sane hw vendors, probably thought: fuck it. It is more profitable to push some FOSS code into the public than keeping the entire thing an trade secret. (I assume this results in the weirdly large firmware blobs that obfuscate and separate the actual hardware from the FOSS drivers)

EDIT: I read more about this issue. From proprietary code vendors viewpoint the current kernel is kind of "GPL or gtfo" situation. Linux kernel doesn't really have an internal stable ABI for modules/drivers. Implementing such thing would require (partly) dropping the monolithic design of the Linux kernel... Such interface would be then able to added to the GPL exemption of syscall users. This would open such big can of worms that it looks to be impossible.

[–] ono@lemmy.ca 13 points 1 year ago

Disclaimer: I haven't looked at the code.

It looks like Nvidia's proprietary driver was caught circumventing measures that keep proprietary code from mixing with GPL code in the kernel, deliberately violating the kernel's license. The kernel maintainers are responding by adding more restrictions.

[–] aport@programming.dev 11 points 1 year ago

Glad I stopped buying Nvidia years ago

[–] Molecular0079@lemmy.world 1 points 1 year ago (1 children)

Hopefully this all gets ironed out before kernel 6.6 lands in Arch.