Alan Cox to NVIDIA: You Can't Use DMA-BUF 946
DMA-BUF is a recent kernel feature that allows multiple GPUs to quickly copy data into each others' framebuffers. A use case would be the NVIDIA Optimus that pairs a fast GPU with an Intel integrated GPU, where the NVIDIA GPU writes into the Intel framebuffer when it is active. But, NVIDIA won't be able to use this infrastructure because it's GPL. Alan Cox replied on LKML to a request from one of their engineers to mark the API non-GPL: "NAK. This needs at the very least the approval of all rights holders for
the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining
it with proprietary code then you are still in my view as a (and the view
of many other) rights holder to the kernel likely to be in breach
of the GPL requirements for a derivative work. You may consider that
formal notification of my viewpoint. Your corporate legal team can
explain to you why the fact you are now aware of my view is important to
them."
The rest of the thread is worth a read (a guy from RedHat agrees that this code is GPL and cannot become non-GPL without relicensing from a major subset of graphics system contributors). This has a ripple effect: it means that all of the ARM SoC GPU drivers can't use it either, and it may prevent any proprietary drivers for the proposed DRI version 3.
It would still become a derived work of the kernel (Score:3, Informative)
And, as such, forbidden under copyright laws in, for example, the USA or EU.
The only way to avoid that would be to write your own kernel to ACT like (at an ABI level) the Linux Kernel.
If you do not like this, then please get in touch with your legislative branch and ask them to change the copyright laws.
Re:And this is why (Score:4, Informative)
Its not an external API like google maps or what not, its an internal kernel interface that video drivers that are running inside the kernel would use.
Re:Hmmm... (Score:5, Informative)
You are getting muddled. The googVorc case was if oracle could copy right the API (that is, the list of function name, their hierarchy, intput/outputs) and prevent google from doing a clean room implementation that complies with their API. In this case, they are saying NVIDIA can't make an API call _into their code_ and ship proprietary bundles linked against their GPL library. NVIDIA could do a clean-room re-implementation of the kernel if they wanted to, but that is not what is going on here.
If you don't have the constraint that linking is derivative then the whole notion of copy-left is dead, as you can fully use any library in any application. The authors are giving you a license to use their code for free, they can put what ever restrictions on that license they want.
Re:And this is why (Score:5, Informative)
The Intel drivers are a better example: they are rock solid, Intel has contributed tons toward advancing the graphics stack, etc. AMD has maintained a split development effort: hiring external companies and providing some docs for the Free drivers, all the while putting their main development effort into their proprietary FGLRX driver. I suspect that's the real reason their drivers are kind of crap.
Re:What Cox is saying... (Score:5, Informative)
They probably don't want to because they likely infringe on either software patents in the drivers themselves or hardware patents that opening their drivers would expose. Once they opened their drivers they probably would get jumped on by 40 million patent trolls and sued into the ground, as well as being injunction'd from releasing any driver for any operating system (read: not make any money, have increased legal costs, and go out of business).
Re:So? (Score:5, Informative)
A couple years ago, back when they had the upper hand, NVIDIA did not even open up the drivers for their ethernet chips, $DEITY knows what trade secrets could have been hidden in a ethernet driver.
Also, don't say that they're not opening the code because it's licensed by third parties: they don't even release documentation for their chips. The truth is that they don't care about open source, and will behave only when forced to.
Full disclosure: Linus Torvalds develops the linux kernel, he's very vamiliar with the licensing, patent and copyright issues and relationships with NVIDIA, and sent them to "fuck themselves" (sic.).
Debugging is the reason (Score:5, Informative)
The preceeding mail from Jan-2012 mentions the reason why they need to have the drivers that interact with the interface gpl-ed:
'A bug on a driver using such low-level interface could cause side effects
at the wrong places. In order to handle such bugs, the developers and the
maintainers of both subsystems need to see the source code of the entire
pipeline, with is not possible if is there any non-GPL'd driver.
NAK
Mauro.'
Re:GPL API (Score:3, Informative)
Re:And this is why (Score:5, Informative)
I thought Oracle v. Google said APIs weren't copyrightable. As such, GPL-only APIs make no sense because the API can't be copyrighted to begin with.
You're wrong.
It is fine for someone to go and make a new, compatible implementation of the DMA-BUF API, with the same calling conventions etc., and license it however they wish. That is what the Oracle vs Google judgement said.
It is not okay to link your code into the GPL version of the DMA-BUF API unless your code is also GPL'd. That is something different.
Re:And this is why (Score:4, Informative)
Because everyone was arguing that APIs are not copyrightable in the Oracle vs. Google case but somehow you think that they should be GPL?
If Nvidia were able to produce a non-GPL kernel module that implemented that API, they could use it. It's the in-kernel implementation that's GPLed and that only GPLed code can use.
GPL is built on copyright law which means that you are saying that Oracle was right and that an API can be copyright protected.
In this case, it's an implementation, not an API.
Re:What Cox is saying... (Score:4, Informative)
Re:Honest Question (Score:4, Informative)
Heh... If that were the case, AMD would've stood to lose a lot by what they did.
Sorry, not buying it.
Re:This is why I suggest BSD (Score:4, Informative)
My freedoms all come with a 'but'. I can swing my fists all I want, but not if I hit someone. I can own anything I want, but not other people. I consider the BSD license less free because it allows others to infringe on people's freedom. I avoid BSD licensed code as much as is feasible for this reason. In the long run it is poisonous to my freedom even if it provides no obstacles in the short-term.
Re:Face Reality: (Score:3, Informative)
Linux has had proprietary video drivers for more than 15 years. That has obviously not brought world domination. Yes, in the short term it will force a few more users to boot into Windows to play 3D games, but almost all Linux users who play 3D games do that anyway.
15 years of proprietary video drivers has not brought 3ds Max to Linux, even though it would have been an extremely straightforward port of the SGI version, way back when. Exactly the same applies to AutoCAD.
not quite that simple (Score:5, Informative)
The current Nvidia binary blob resides in a bit of a grey area. They have a binary blob that was originally written without looking at the linux specs, and is not a derivative work of the kernel.
They then have an open-source "shim" that is clearly a derivative work of the kernel that allows the binary blob (which has its own API) to interface with the kernel (which has a different API).
The GPL says that any derivative work must be released under the GPL. Normally (as a logic shortcut) this means anything linked against the kernel, however in this case there is a real argument that the binary blob is NOT in fact a derivative work.
However, now we have a new funky feature being added to the kernel. If the binary blob is updated to make use of it, then there is a reasonable argument that it now actually IS a derivative work of the kernel and thus should be released under the GPL.
Re:And this is why (Score:5, Informative)
The GPL doesn't prevent your competitor from using it. It prevents your competitor from taking it, improving it, and using it directly against you. In the GPL he has to release the improvements back to the community. The entire 'community' benefits in the end because of the code you released.
With the BSD license, the competitor takes your code, makes it better then charges you to use the improved features. Granted there are a lot of cases where BSD code is good, but long term open computing platforms are not one of them.
In every case a freedom has a set of associated costs. If you use 'free' software to reduce business costs, there is going to be a cost when it comes to selling the software. It seems an odd position that you want the code to be 'free' as in no rules so you can sell it and be protected by IP, copyright, and trademark rules.
Re:How to (not) get people to use your OS... (Score:5, Informative)
Re:And this is why (Score:3, Informative)
>>hiring external companies and providing some docs for the Free drivers, all the while putting their main development effort into their proprietary FGLRX driver
That's not actually correct. We hired two full time devs to work on the open source drivers over five years ago, added two more last year, and another (total 5) this year.