Created attachment 341050 [details, diff] nvidia-drivers-gpl-compliance.patch Attached is a patch from the licenses team that brings nvidia-drivers into license-compliance, specifically ensuring that nvidia-{settings,installer} has source distributed on the mirrors. If you want to rewrite src_unpack to only unpack the needed files, feel free to do so.
Where did you get the idea that nvidia-{installer,settings} are GPL-2? I see that zerochaos thinks that, because html/nvidiasettings.html says: "The source code to nvidia-settings is released as GPL and is available here: ftp://download.nvidia.com/XFree86/nvidia-settings/" However, Nvidia is entirely free to distribute the nvidia-settings binary under a different license, say, the NVIDIA license that covers what the package installs. Did I miss something?
Comment on attachment 341050 [details, diff] nvidia-drivers-gpl-compliance.patch Even if it were GPL code, we're not bound by the GPL-2 or by the NVIDIA license to distribute this code. What could happen is that we need to add GPL-2 to the LICENSE, but you'll still need to argue why NVIDIA needs to ship binaries under the same license it separately ships its source code under...
From README.txt, in the nvidia-drivers package: ==== Q. Where can I find the source code for the 'nvidia-installer' utility? A. The 'nvidia-installer' utility is released under the GPL. The source code for the version of nvidia-installer built with driver 313.26 is in 'nvidia-installer-313.26.tar.bz2' available here: ftp://download.nvidia.com/XFree86/nvidia-installer/ ... The source code to nvidia-settings is released as GPL and is available here: ftp://download.nvidia.com/XFree86/nvidia-settings/ ==== It does not say "the source is under one license, the binary is under another", it explicitly says "The 'nvidia-installer' utility is released under the GPL.". Yes, I agree this does not explain which license the nvidia-settings binaries are covered under, but in the absence of specific evidence to the contrary, the safest option is to include the source tarball.
I doubt Nvidia would sue us for not including the source code. In fact, why don't you ask Nvidia to clarify their LICENSE file, especially with regard to the term "SOFTWARE" (also "Software"). If that doesn't cover everything the source includes, then the LICENSE should specifically mention that. In fact, the LICENSE file's terms are an obvious breach of the GPL. Maybe the FSF can take Nvidia up on this? :)
A similar argument can be made from the other side: it's trivial for us to cover our asses by including those two distfiles - adds only 1.6MB to the download. ulm & I both agree that this patch improves the license state of the package.
(In reply to comment #2) > Even if it were GPL code, we're not bound by the GPL-2 or by the NVIDIA > license to distribute this code. To the best of our knowledge, it is GPLed code. Therefore, nothing else but the GPL gives us the right to distribute it, under the terms of the GPL. (In reply to comment #4) > I doubt Nvidia would sue us for not including the source code. "They won't sue us" isn't a premise we (or any other distro) can act under. > In fact, why don't you ask Nvidia to clarify their LICENSE file, especially > with regard to the term "SOFTWARE" (also "Software"). If that doesn't cover > everything the source includes, then the LICENSE should specifically mention > that. > > In fact, the LICENSE file's terms are an obvious breach of the GPL. Maybe > the FSF can take Nvidia up on this? :) That's not our problem, but Nvidia's. And it is irrelevant for the issue at hand.
(In reply to comment #5) > A similar argument can be made from the other side: it's trivial for us to > cover our asses by including those two distfiles - adds only 1.6MB to the > download. Without playing lawyers, why don't we ship the kernel sources on our boot media, again? > ulm & I both agree that this patch improves the license state of the package. Just adding GPL-2 to LICENSE would fix that. We could even add a RESTRICT=mirror, if you like.
(In reply to comment #7) > Without playing lawyers, why don't we ship the kernel sources on our boot > media, again? That question is not so far-fetched as you may think. For example, the FreeBSD folks don't mirror our install media on their servers for that reason. > Just adding GPL-2 to LICENSE would fix that. We could even add a > RESTRICT=mirror, if you like. Sure, that would also fix it. But make it RESTRICT="mirror bindist" please.
(In reply to comment #8) > > Just adding GPL-2 to LICENSE would fix that. We could even add a > > RESTRICT=mirror, if you like. > > Sure, that would also fix it. But make it RESTRICT="mirror bindist" please. That one's easy. (I'll also consider actually incorporating the nvidia-settings sources and compiling them the way the separate nvidia-settings package does.)
Rick: As was previously discussed on IRC, I assume you understand now that Pentoo violates the GPL by shipping a compiled nvidia.ko, and that our ebuilds have safeguarded us from enabling you to do that. RESTRICT=bindist means you cannot distribute the compiled code.
(In reply to comment #10) > Rick: As was previously discussed on IRC, I assume you understand now that > Pentoo violates the GPL by shipping a compiled nvidia.ko, and that our > ebuilds have safeguarded us from enabling you to do that. RESTRICT=bindist > means you cannot distribute the compiled code. 1.) As per our discussion on irc weeks ago the latest release of Pentoo doesn't ship a compiles nvidia.ko AS A PRECAUTION because I'm unable to prove wether or not nvidia.ko contains gpl code in the compiled binary. I do not honestly have the skill to prove that it does or does not, so I now have users build it on boot. 2.) sadly catalyst doesn't actually seem to care about RESTRICT=bindist. I have patched catalyst a few months ago to force (or not force) setting of USE=bindist, but RESTRICT seems to do exactly nothing.
(In reply to comment #11) > (In reply to comment #10) > > Rick: As was previously discussed on IRC, I assume you understand now that > > Pentoo violates the GPL by shipping a compiled nvidia.ko, and that our > > ebuilds have safeguarded us from enabling you to do that. RESTRICT=bindist > > means you cannot distribute the compiled code. > > 1.) As per our discussion on irc weeks ago the latest release of Pentoo > doesn't ship a compiles nvidia.ko AS A PRECAUTION because I'm unable to > prove wether or not nvidia.ko contains gpl code in the compiled binary. I > do not honestly have the skill to prove that it does or does not, so I now > have users build it on boot. I realise we are outside the scope of the Gentoo Project now, and maybe this discussion shouldn't take place here at all. So, maybe any further correspondence should go private. I just happened to notice /lib/modules/{KVER}/video/nvidia.ko (in the squashfs image) in an ISO image downloaded from [1], which was apparently released on March 8 2012. Fixing the situation means you should probably take off-line all ISO images (old and new) that include the compiled driver. And yes, the compiled driver (nvidia.ko) that you ship does contain both a closed source "blob" of code linked to a kernel driver that glues the proprietary code to the Linux kernel, which is a clear violation of the kernel's license. > 2.) sadly catalyst doesn't actually seem to care about RESTRICT=bindist. I > have patched catalyst a few months ago to force (or not force) setting of > USE=bindist, but RESTRICT seems to do exactly nothing. I don't feel inclined to advise you on how to fix Pentoo's technical problems, as my interest lies with the Gentoo Project and not Pentoo. [1] http://www.pentoo.ch/isos/pentoo-i686-2013.0_RC1.1.iso
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > Rick: As was previously discussed on IRC, I assume you understand now that > > > Pentoo violates the GPL by shipping a compiled nvidia.ko, and that our > > > ebuilds have safeguarded us from enabling you to do that. RESTRICT=bindist > > > means you cannot distribute the compiled code. > > > > 1.) As per our discussion on irc weeks ago the latest release of Pentoo > > doesn't ship a compiles nvidia.ko AS A PRECAUTION because I'm unable to > > prove wether or not nvidia.ko contains gpl code in the compiled binary. I > > do not honestly have the skill to prove that it does or does not, so I now > > have users build it on boot. > > I realise we are outside the scope of the Gentoo Project now, and maybe this > discussion shouldn't take place here at all. So, maybe any further > correspondence should go private. > > I just happened to notice /lib/modules/{KVER}/video/nvidia.ko (in the > squashfs image) in an ISO image downloaded from [1], which was apparently > released on March 8 2012. Fixing the situation means you should probably > take off-line all ISO images (old and new) that include the compiled driver. > > And yes, the compiled driver (nvidia.ko) that you ship does contain both a > closed source "blob" of code linked to a kernel driver that glues the > proprietary code to the Linux kernel, which is a clear violation of the > kernel's license. If you have any time or inclination now, or in the future, I'd love to know how to conclusively prove that nvidia.ko contains gpl code in a more certain method than "strings nvidia.ko | grep GPL". You know my email I'm sure. > > > 2.) sadly catalyst doesn't actually seem to care about RESTRICT=bindist. I > > have patched catalyst a few months ago to force (or not force) setting of > > USE=bindist, but RESTRICT seems to do exactly nothing. > > I don't feel inclined to advise you on how to fix Pentoo's technical > problems, as my interest lies with the Gentoo Project and not Pentoo. > Perhaps you are unaware, catalyst is the tool we in Release Engineering use to generate stages and livecds for gentoo. This is a gentoo problem not a pentoo problem. > > [1] http://www.pentoo.ch/isos/pentoo-i686-2013.0_RC1.1.iso
