Linux 5.9 Brings Safeguard Following NVIDIA's Recent "GPL Condom" Incident

[oiaohm]

That's probably the reason why Google did choose NVida for Stadia.

https://techcrunch.com/2019/03/19/google-scores-a-custom-amd-gpu-to-power-its-stadia-cloud-gaming-hardware/

AMD has Stadia and most gaming consoles because AMD will in fact do the custom drivers the vendors want. Nvidia is a jackass.

[oleid]

https://techcrunch.com/2019/03/19/google-scores-a-custom-amd-gpu-to-power-its-stadia-cloud-gaming-hardware/

AMD has Stadia and most gaming consoles because AMD will in fact do the custom drivers the vendors want. Nvidia is a jackass.

Yes, I forgot the irony-tags

[amdtesterman]

% vainfo
libva info: VA-API version 1.8.0
libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.8 (libva 2.8.0)
vainfo: Driver version: Mesa Gallium driver 20.2.0-rc2 for AMD Radeon RX 5700 (NAVI10, DRM 3.38.0, 5.8.0, LLVM 10.0.0)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProcvainfo

In him face..

[L_A_G]

From a kernel development perspective, being able to set a flag that clearly says "this kernel is considered tainted because it runs with non-GPL modules to which we do not have source code access" is a benefit in that the Vendor is clearly responsible for making their code work with Linux, not the other way around -- particularly when troubleshooting an issue.

Way to miss the point... The issue wasn't about marking it as not being entirely GPL compliant, but the needlessly hostile language used to do so.

This has been the philosophy from day one as I understand it.

Yes, a philosophy that not all companies subscribe to and aren't liable to become full converts to overnight. Hence you have to convince them over time and being flat out hostile like this only sets you back in.

Besides, Linux and NVidia have both been around for so long that NVidia really has no excuse for pretending that it doesn't understand how Linux kernel development works. The same goes for Facebook and the developer in question.

The fact that you understand something doesn't mean that you're fully willing to commit to it. Particularly when it's to something as sweeping as a full GPL license which, like most of Stallman's creations, doesn't really try to give people and organizations a possibility to slowly inch themselves towards where you want them to be.

If your goal is to get Nvidia to go "Screw this open source stuff, we're not opening up anything we don't absolutely have to" then you're well on your way to that. I on the other hand would like them to open up and I understand that it's going to have to be a slow process that takes years. You're not convincing them to speed this process up, you're convincing them to abandon it entirely.

[tildearrow]

Also the part where there is a proprietary AMDGPU-PRO driver that is not FOSS but tends to be a bit ahead in terms of compatibility and stability. Not sure why birdie would bother with changing hardware, seems like poor troubleshooting on his part. My Vega56 card is rock solid stable on Ubuntu 20:04 for Steam gaming, and it does all the things you would expect, like video decoding and encoding, etc.

Guess what? The proprietary driver actually is less stable for me than the open one (Mesa 19.0).

[ermo]

Way to miss the point... The issue wasn't about marking it as not being entirely GPL compliant, but the needlessly hostile language used to do so.

Why are you discussing this with me when it's clearly the kernel devs you need to engage with to actually change this?

I would argue that there are plenty of other hardware makers who have -- successfully I might add -- open sourced their drivers without losing market share; quite the opposite in fact.

Point in case: Intel. If Intel can do it successfully, why can't (or won't) NVidia? Intel has not been dissuaded by the Linux kernel licence and the language used to describe a kernel that has non-open-source modules loaded as far as I can tell.

Again, Linux and its development and licencing model is a known quantity and has been for years. Other companies have adapted because they can see that they can still be successful within the context of that model.

From my perspective, Linux is not the hostile actor wrt. kernel development here. And I'm perfectly happy to agree to disagree on this.

[L_A_G]

Why are you discussing this with me when it's clearly the kernel devs you need to engage with to actually change this?

Because you endorsed their needlessly hostile response to Nvidia's attempt to mitigate the downright virulent nature of "full" GPL licenses like the one used by the Linux kernel. Try to remember that basically everything that seriously touches GPL has to be re-licensed under it and it was found to be legally enforceable not too long ago.

I would argue that there are plenty of other hardware makers who have -- successfully I might add -- open sourced their drivers without losing market share; quite the opposite in fact.

It's obviously not about market share, but about having to put basically everything under GPL due to the way the license works. Not that there aren't licenses like LGPL that strip this away, but the kernel uses full GPLv2 and has no plans to re-license under a less virulent license. Nvidia's drivers build on top of a universal code base for a wide variety of platform and many of these platforms are highly proprietary and probably aren't even in the slightest compatible with full GPLv2.

Spoke with a developer relations guy at Epic a few years ago and when asking about why it wasn't licensed under GPL he explained that while most of the Unreal Engine had just been made open source, there were plenty of platform-specific bits that couldn't be made open source due to licensing on various (mostly console) platforms. Not that they weren't going to give you that code, but you first have to prove to them that you've legally licensed the code that those bits of the engine tie to. The reason why AMD can't open source their PSP (Platform Security Processor) code is also very similar, it involves proprietary bits of ARM's TrustZone IP not owned by AMD.

This is probably the reason why Nvidia doesn't want to re-license their drivers under Linux kernel GPL; It runs up against bits that that according to GPL, which I again have to point out is legally enforceable, have to be open sourced under it, but which Nvidia can't legally expose to the public due to the third party licenses they're already under.

Again, Linux and its development and licencing model is a known quantity and has been for years. Other companies have adapted because they can see that they can still be successful within the context of that model.

The fact that Linux development is a known quantity doesn't mean that every company out there is going to be comfortable with it. Particularly when the virulent nature of it probably crashes with licenses to parts from or built on third parties.

From my perspective, Linux is not the hostile actor wrt. kernel development here. And I'm perfectly happy to agree to disagree on this.

You still don't get it, do you? Nvidia doesn't want to or can't re-license a huge amount of code under a license known to be virulent and downright cantankerous at times, kernel devs pitch a fit over it either not understanding or refusing to acknowledge and people like you cheer them on.

[oiaohm]

Because you endorsed their needlessly hostile response to Nvidia's attempt to mitigate the downright virulent nature of "full" GPL licenses like the one used by the Linux kernel. Try to remember that basically everything that seriously touches GPL has to be re-licensed under it and it was found to be legally enforceable not too long ago.

Simple question is what Nvidia doing proven legal in court the answer is no.

Spoke with a developer relations guy at Epic a few years ago and when asking about why it wasn't licensed under GPL he explained that while most of the Unreal Engine had just been made open source, there were plenty of platform-specific bits that couldn't be made open source due to licensing on various (mostly console) platforms. Not that they weren't going to give you that code, but you first have to prove to them that you've legally licensed the code that those bits of the engine tie to.

The reality here the issue Epic mentioned with the console code applies equally to when you use GPL works as the China case said.

The reason why AMD can't open source their PSP (Platform Security Processor) code is also very similar, it involves proprietary bits of ARM's TrustZone IP not owned by AMD..

https://www.op-tee.org/

That is a big fat no. ARM allows all TrustZone Implementations to be released open source if the one making it decided to to allow for what ever OS in the trusted zone to be properly peer reviewed. So it cannot be ARM TrustZone IP that causing the issue. That not to say AMD is not using some other parties tech in their that is preventing them.

This is probably the reason why Nvidia doesn't want to re-license their drivers under Linux kernel GPL; It runs up against bits that that according to GPL, which I again have to point out is legally enforceable, have to be open sourced under it, but which Nvidia can't legally expose to the public due to the third party licenses they're already under.

China ruling on this is straight forwards. If you cannot meet the terms of the GPL contract you have no legal right to use the GPL code. So rock hard place. The GPL licenses and end users have to be legally respected in China. Now we may get more ruling like this.

You still don't get it, do you? Nvidia doesn't want to or can't re-license a huge amount of code under a license known to be virulent and downright cantankerous at times, kernel devs pitch a fit over it either not understanding or refusing to acknowledge and people like you cheer them on.

If Nvidia cannot come into the legal requirements with their existing code with GPLv2 requirements they should be making sure they are not hindering the open source Nvidia driver developers.

Really Nvidia shows they don't really care about their end users since they are not providing what the open source driver developers need in firmware for them to-do their job so that if the hell hits that there end users don't end up with their cards being bricks.

L_A_G there is technically way around the Linux kernel GPLv2 license.

https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note

What ever you cannot bring into conformance with GPLv2 must be done as a userspace program using syscalls.

[Guest]

I'm really curious what this means to Canonical (ZFS) and Google (Android).

Hopefully it will force them to stop being blatant violators of GPL.

[fkoehler]

Well, I am of the opinion that the software should be made to run on the hardware. Not that the hardware should be picked to meet the software's arbitrary demands.

LOL, I always pick the hardware that supports the software I want to use. I mean, if the word Design Qualification (DQ) means anything to you, that should be obvious