Slashdot Mirror


Kororaa Accused of Violating GPL

AlanS2002 writes "The Kororaa Project, a pre-configured binary install method for Gentoo Linux which bundles nVidia's and ATI binary drivers in its Kororaa Xgl Live CD , has put its Live CD on hold after being accused of violating the GPL. The issue appears to be the distribution of the Linux Kernel and nVidia's/ATI binary drivers together. When the binary drivers are built the GPL'ed code is included in the binary result, which is a violation."

5 of 843 comments (clear)

  1. Re:tainted kernel by tomstdenis · · Score: 4, Informative

    It only taints the kernel if you load the module. The kernel itself [the bzImage] is entirely based on GPL code.

    So don't autoload the drivers and the kernel will not load with a tainted status. /me shakes head...

    Tom

    --
    Someday, I'll have a real sig.
  2. Re:Aggregation is not linking! by ebooher · · Score: 4, Informative
    Perhaps, but the binary module is compiled by linking against the kernel headers, and it includes shim code which may (or may not) be derived from the kernel. This would mean that the compiled binary module (which he is distributing) could therefore be derived from the kernel, and thus would need to be distributed under the terms of the GPL.

    According to information that the originator of Kororaa received from NVidia while investigating this matter, this is not true.

    The NVIDIA kernel module consists of two pieces: a binary-only portion and a kernel interface layer (aka the "shim"). The binary-only portion is not Linux-specific (the same code is used on Windows, Solaris, etc), and does not include any Linux kernel header files when it is built. The shim is provided in source code form with the driver package, and this is the piece that is compiled for your version and configuration of the Linux kernel. The shim is the only piece that references Linux kernel data structures or macros, and only does so to the extent that is needed to provide the functionality of a modern graphics driver. After the shim is compiled, it is linked with the binary-only portion, to produce the final NVIDIA kernel module.

    NVidia states that the binary is the same binary they use in all Systems. Be they Linux, BSD, Windows, or Bob's Unknown Mini-OS. The "shim" is the glue code they write that is OS specific that makes calls into the binary.

    --
    "Genius may shine aloof and alone, like a star, but goodness is social, and it takes two men and God to make a Brother."
  3. You've got the dependency graph wrong by Morgaine · · Score: 5, Informative

    The nVidia "shim" is licensed under the GPL and is copyright nVidia --- this means that it's perfectly legal to compile the shim against the GPL kernel. At the same time, nVidia is free to do whatever they want with the shim, and its license is immaterial to them at that point because they hold its copyright. The GPL has no say over what else the copyright owner can do with kernel-linked code, the only thing that's mandatory is that it's GPL'd, and it is. For example, it's very common for copyright holders to dual-license their own GPL'd code for commercial and highly proprietary use.

    Well, what nVidia chose to do in this case is to link the shim with their binary driver, and they're perfectly entitled to do that, by their copyright. Furthermore, since the shim and the binary driver are separate components from the kernel, they can certainly be shipped on the same CD as GPL components, as long as the binary code is not linked to the kernel. And it's not.

    So you see, by virtue of being the copyright holders of the shim and GPL'ing it, nVidia easily comply with the requirements of the GPL but aren't constrained in what else they do with it.

    If the binary module were linked against the kernel then you'd be right, but it's not. At no point in time did the binary module even get a sniff of the kernel, and it's shipped without knowing anything about it, nor viceversa.

    Yes, the dependency is contrived, but that's how the GPL forced them to rearrange their code dependency graph in order to stay on the good side of the GPL's guidelines.

    --
    "The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
  4. A counter-argument by xenocide2 · · Score: 4, Informative

    Does anyone besides open source zealots care about open drivers? I think so. Perhaps if Nvidia and ATi had open sourced their drivers, Xgl wouldn't have taken so long to exist (Xgl requires a certain level of driver support, and aiglx even more so). I'm pretty sure you'd have liked this just as much 4 years ago, when I first saw people talking about things like openGL accellerated gtk widgets, and otherwise imagining how to use 3d to its best. But 4 years ago, you were writing off a large group of people by doing that.

    Furthermore, installing drivers for your ethernet, cd drive, etc is very simple on linux, because the drivers are open source and in kernel. Attempting to maintain a glue between the kernel and your driver is painful and prone to failure; unlike in tree drivers, when someone else breaks code you depended on, you have to fix it, not them. Recall that nvidia's nforce2 boards are better supported in the kernel than by nVidia itself! With no documents to support them in their efforts, even. I hear they even now recommend the reverse engineered driver over their own, but don't distribute or improve, oddly. If nvidia's drivers were GPL'd, installing them would be as simple as installing anything else.

    It's pretty naive to think that their IP is so valuable that the source code would disclose it any more than the underlying binary code does. Their IP is already in jeopardy by distributing the software. One of the many reasons I suspect they have no intention of participating in OSS is that there's a number of speed over quality decisions written into it that would be exposed, perhaps even application specific optimizations. While this could be neat to have optimized drivers on a per game basis, this is never disclosed to the public (and when revealed sparks not applause but public humiliation). Furthermore, it means that optimizations are done on their terms, not the public's. Any application specific optimizations are given only to a specific application, with no cross over improvement in other applications, or the ability to make the change. If NVIDIA really wanted to share their drivers with the public and gain all the benefits often touted, they'd stop pointing at other people's IP they own and begin to change it. They haven't, and they won't. What nefarious secrets lie within? Perhaps just a case of "this stuff is really hard, and we don't do it very well?"

    Just a thought -- if you dislike the open source spirit as embodied by the GPL, why not do something productive about it, like make a liveCD based on BSD running Xgl. There's nvidia drivers for BSD too, ya know. And for all the talk about pressuring vendors to open their code, they have no qualms about giving it away reguardless with no expectation of anything in return. Linux needs to focus on being Linux, not beating Redmond.

    The good news is that I suspect the person who wrote to Kororaa doesn't actually have any basis for the claim. While nvidia's legality has been on shady grounds, the message published doesn't provide any insightful evidence in either direction. Anyone seriously familiar with the kernel and binary objects should be familiar with the recurring arguments and whatnot. It's clear to me that if the drivers themselves were in violation, nvidia would have been sued some time ago.

    --
    I Browse at +4 Flamebait

    Open Source Sysadmin

  5. Re:tainted kernel by swillden · · Score: 4, Informative

    So don't autoload the drivers and the kernel will not load with a tainted status.

    That doesn't make any difference.

    Copyright law prohibits the creation of derived works without permission, and the GPL does not grant that permission unless you distribute source. So the question boils down to "Are the binary-only modules derivative works under the law?".

    The answer is: yes and no. The modules come from ATI and NVidia in two parts: a binary-only part that contains all of the interesting code, and some "glue code" that is distributed in source. Both parts have liberal redistribution permissions, which makes the GPL happy, so the big issue is source.

    The argument is that the core, binary-only components of their drivers are not derived works of Linux, since they contain no Linux code (not even any headers) and I think they even claim that the same binaries are used on other platforms and wasn't developed specifically for Linux, at least in the beginning. The glue code that they distribute that wraps the binary-only component is clearly a derived work of Linux, but they distribute the source to that.

    When a user compiles the glue code and links it with the binary-only component to produce a kernel module, the result is a derived work of the GPL'd Linux kernel. Note that I didn't say "and loads it into a running kernel". That's not really relevant. Technically, it's somewhat unclear whether the GPL gives users the right to create otherwise unauthorized derived works, but the general interpretation (including by the FSF) is that people can do whatever they like, and it's only when they start distributing that the question of whether or not the GPL has granted them permission becomes important.

    When someone takes that same compiled glue plus binary module and distributes them, they're distributing a derived work of Linux, without complying with the terms of the GPL, and therefore without permission to distribute under copyright law.

    I think it's quite clear that Kororaa cannot do this without infringing Linux copyrights. The only way they can justify it is if they can argue that the binary kernel modules (glue + core binaries) are not, under the law, derived works of Linux. That seems like a tough one, but IANAL, so maybe it's possible.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.