It's the FSF's version of digital rights management.
Bullshit, DRM exists to prevent end users from doing what they want, GPL exists to make sure end users can do whatever they want and have all that is necessary for them to do so. IIRC you work for Apple so I can see why this is so confusing for you.
I know that and I never denied it (although OSS drivers are improving). But the truth is, that there's no reason to use Linux except for the fact that it's open source.
If all I cared about was functionality delivered, then I'd use Windows: NVIDIA makes good drivers for Windows, too. Instead, I choose Linux because of its unique features, which stem from it being open source.
I couldn't agree more. That's just to the point IMHO.
Many times I read about the "great" Linux support by NVidia.
But actually, NVidia doesn't support Linux at all - they "just" provide more or less well functional drivers.
That's a difference which matters.
If NVidia would really "support" Linux, this would include respecting the open philosophy behind Linux.
Now, my personal opinion about the blobs is that *I* am fine with the "AMD way".
They have their proprietary crap but they also provide documentation of the hardware.
What is EXPORT_SYMBOL_GPL and why is it so important it is GPL only?
Not everything in the kernel is covered under the GPL completely, there are exceptions made. Export_Symbols tells the developers what is and isn't under the GPL. If something isn't under the GPL then closed source programs can link to it and its no problem, if they ARE under the GPL (like DMA-BUF currently is) then closed source cant link to it without becoming a "Derivitive work" under the GPL and being forced to open up the code.
The article does make an interestingg point though... DRI-3 depends on DMA-BUF for a lot of stuff. DMA-BUF really is at the core of DRi-3. So its interesting that the developers would choose to not allow it to be exported NON-GPLed because that means AMD and Nvidia cant officially support DRI-3 without some nasty hacks. (See the video from the Suse convention about DRI-3 to learn why DRI-3 is good)
Its not that you can reverse engineer GPUs by analyzing software drivers. You can can not do that. GPUs are MASSIF pieces of architecture. Its almost like claiming that you can reverse engineer car engine by having all docs about steering car ...
However gpu drivers are also complex, and require time and money and HR to make them good.
So one can learn how to write GOOD DRIVERS by looking at source code of such. And good drivers add huge amount of value to your GPU!
There are also issues of IP that can be property of 3rd party companies.
There is also this little company that is called MicroSoft, who put requirements for GPU drivers, who will not certify any drivers that do not meat those requirements. And which by accident contain clauses of scrambling source code, not compromising DRM by documenting stuff, supporting heavy encryption for TP, etc.
Nvidia just can not ignore that market you know.
AMD is not that bad. They release documentation, code, have folks working on OSS drivers, etc.
Intel is so far best, BUT they also do not release full docs.
But this story is not about FLOSS but about copyright and simple courtesy.
Companies like Nvidia they won't release their drivers as open source, and that's because they don't want competition, only monopoly. They prefer less profit with more trouble in order to maintain monopoly. That's why they co-develop and use D3D, because Microsoft gives them monopoly. And now that monopoly is gone, just now they discover OpenGL, and Nvidia wants OpenGL for their next Voxel-Raytracing engine. Were can we benefit: If we produce a Unified_Graphics_Driver, that is multilevel and uses LLVM to target CPUs and GPUs with back-ends, then we can pursue companies like Nvidia to contribute: 1)To open the previous generation until OpenGL3.3 with all the side-things, and when they go to Raytracing they can release OGL4-4.3 with tessellation and compute shaders. 2)To use the new closed generation OGL4-4.3 as extensions for our Unified_GD and only working with Nvidia GPUs. Tessellation_compiler_extra (for example) and the tessellation_program_extra for the synthesizer (for example), plus the TXAA_fx (for example). They can also use our UGD as they please in any operating system. 3)Use only OpenGL from now on, and stop co-develop the D3D any farther.
Most kernel devs are paid by AMD and Intel. Of course they reject NVidia's request. Nothing personal; just business, stopping NVidia from providing something competitive to AMD and Intel. I can't say I can blame them though. It's NVidia's own fault. If they had rooted the kernel dev team with more of their own developers, they would have been in a position to change policies.
What sickens me is that a piece of open source software is now abused for greedy corporate politics. That's ugly.
I might be wrong, but I have a feeling that this is not so much about licensing, security, and open drivers, but rather about many kernel developers being sick of Nvidia's antics (including changing licenses within kernel on a whim). You have to see it in the context of Linus' "fuck you" comments.
I'm guessing that many people don't want to pander to Nvidia anymore.
in my now 5 years (including 3 years of vocational education) I came to the point that there are only 2 reasons to not publish your code as open-source:
1. your code is ugly. Really ugly. It's bad designed, variables are badly named and your code is covered in comments that don't actually explain anything since they're long outdated
2. you want to make money with your program.
While point 2 is not entirely true since there are companies that make money off of their open-source programs, I still don't understand how that's possible.
and if your program goes out of the production cycle, there is really only reason 1 to not release the source code.
Sorry, you are being *very* naive.
Here's a number of other reasons:
1. Your code includes licensed 3'rd party code that cannot be opened.
2. Your code includes patent-infringing code that will get you sued.
3. Your code is multi-platform (more on that later) and includes platform specific code that prevents it from being opened.
4. Your code is being used by clients and you're prohibited by contract from releasing your code.
(putting my proprietary-out-of-tree-kernel-developer-on)
BTW, its important to note that the nVidia driver code is shared code between Windows, BSD and Linux.
As far as I know (from speaking with relevant lawyers) once your code is being used (unchanged) in both GPL'ed (Linux) as well as non-GPL'ed environments (Windows and/or BSD) your code can no longer be considered derived work - even though it links directly to (or runs under) the Linux kernel.
Of-course, as this particular corner case was never put to trial (pun-intended) this is mere legal speculation for now.
On a personal note (Ignoring for a second that we've yet to hear the code owner's view on the matter), I believe the Linux devs are being right instead of being smart.
nVidia is actually trying to play nice - I believe this behavior should be encouraged instead of being ignored. (E.g. trying to reach a gentleman's agreement that DMA-BUF will be made EXPORT_SYMBOL in-exchange to some documentation or headers)