Forgot your password?
typodupeerror
Linux

Alan Cox to NVIDIA: You Can't Use DMA-BUF 946

Posted by Unknown Lamer
from the gauntlet-has-been-thrown dept.
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.
This discussion has been archived. No new comments can be posted.

Alan Cox to NVIDIA: You Can't Use DMA-BUF

Comments Filter:
  • by Anonymous Coward on Thursday October 11, 2012 @03:37PM (#41622309)

    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)

    by Anonymous Coward on Thursday October 11, 2012 @03:41PM (#41622341)

    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)

    by Anonymous Coward on Thursday October 11, 2012 @04:03PM (#41622671)

    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)

    by Unknown Lamer (78415) Works for Slashdot <clinton@NOSPAM.unknownlamer.org> on Thursday October 11, 2012 @04:07PM (#41622733) Homepage Journal

    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.

  • by Anonymous Coward on Thursday October 11, 2012 @04:24PM (#41622973)

    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)

    by peppepz (1311345) on Thursday October 11, 2012 @04:35PM (#41623145)
    NVIDIA only shares the stuff they're forced to share by virtue of the GPL. The lines they added to the ARM kernel are there only because they were forced to release the core changes needed to support their ARM SOCs.

    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.).

  • by Anonymous Coward on Thursday October 11, 2012 @04:42PM (#41623255)

    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)

    by mar.kolya (2448710) on Thursday October 11, 2012 @04:45PM (#41623303)
    Nvidia can go and reimplement (in a 'clean room') Linux kernel and it's APIs - nobody would have problems with that. But it seems like to much work for Nvidia. Instead it takes existing Linux environment, stuffs it with their blob and starts making money on selling chips for smartphones/tablets/etc. And it doesn't give anything back to the community. And that sounds like a violation of spirit of the GPL. And nobody asks Nvidia billions of dollars, nobody even asks Nvidia to give their chips for free. People just think it would be nice of Nvidia to open source its drivers. Drivers for products customers already payed for! It doesn't seems like to much to ask, does it?
  • Re:And this is why (Score:5, Informative)

    by PeterBrett (780946) on Thursday October 11, 2012 @04:58PM (#41623493) Homepage

    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)

    by Guy Harris (3803) <guy@alum.mit.edu> on Thursday October 11, 2012 @05:19PM (#41623807)

    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.

  • by newcastlejon (1483695) on Thursday October 11, 2012 @05:29PM (#41623949)
    For future reference, the word you were looking for is "enjoined". It means being prohibited from doing something by means of an injunction.
  • Re:Honest Question (Score:4, Informative)

    by Svartalf (2997) on Thursday October 11, 2012 @05:30PM (#41623963) Homepage

    Heh... If that were the case, AMD would've stood to lose a lot by what they did.

    Sorry, not buying it.

  • by Omnifarious (11933) * <eric-slashNO@SPAMomnifarious.org> on Thursday October 11, 2012 @05:35PM (#41624029) Homepage Journal

    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)

    by amorsen (7485) <benny+slashdot@amorsen.dk> on Thursday October 11, 2012 @05:41PM (#41624109)

    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.

  • by Chirs (87576) on Thursday October 11, 2012 @06:36PM (#41624721)

    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)

    by PlusFiveTroll (754249) on Thursday October 11, 2012 @06:51PM (#41624895) Homepage

    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.

  • by anomaly256 (1243020) on Friday October 12, 2012 @12:11AM (#41627057)
    OS X's kernel is Mach, not BSD. It's had BSD api and userland tacked on to it but it's actually Mach. It's so altered though that it doesn't really count as either but instead something new and on it's own. Android at it's core is still a linux kernel and not some mutant derivative but actual linux with linux API driving the OS services that drive the jvm that drive the apps you know.
  • Re:And this is why (Score:3, Informative)

    by Anonymous Coward on Friday October 12, 2012 @09:13AM (#41629857)

    >>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.

Help stamp out Mickey-Mouse computer interfaces -- Menus are for Restaurants!

Working...