| |||||||||||||
Merge into Linux? Useful as test suite before buying hardware!Merge into Linux? Useful as test suite before buying hardware!Posted Mar 5, 2010 15:47 UTC (Fri) by alex (subscriber, #1355)In reply to: Merge into Linux? Useful as test suite before buying hardware! by lxoliva Parent article: Linux-2.6.33-libre released Sure, perhaps it would have been better if I had said point the firmware loader to a directory that only has bona-fida free firmware in it. I have a linux-firmware git tree on my systems but I'm unaware if there is a free firmware only equivalent. I'd certainly try it out if there was. "Anyhow, as long as Linux still includes or requests non-Free firmware, disabling the firmware loader doesn't get even close to solving the real problem: the source code that, per the GPL, needs to be offered or distributed along with the binaries" The GPL is very specific about what boundaries exist (and the Linux version of the GPL even more so). I agree having the firmware in the Linux source tree is undesirable and I think most kernel hackers are on-board with that point of view. However the kernel copying a set of bits from the disk to the hardware isn't a violation of the GPL any more than it would be copying the non-copyleft mp3 on my disk to my music player. You are free after all to use GPL software to do anything :-) ...and the requests for non-Free firmware Does the request_firmware() call actually need specific firmware or just leave it up to the user-space tool to determine the correct firmware? While I certainly don't object to the libre project (after all it's your time not mine :-) it's going diverge more and more as the kernel grows. You may want to consider submitting patches that remove identified firmware from the kernel (although if it breaks functionality by not using request_firmware I doubt there will be any point).
(Log in to post comments)
Merge into Linux? Useful as test suite before buying hardware! Posted Mar 5, 2010 17:00 UTC (Fri) by lxoliva (subscriber, #40702) [Link]
Sorry, my allusion to the requirements for distributing source code was totally unclear. I wasn't talking about any potential legal problem here, but rather about the fact that the source code that invites users into the trap would have to be distributed along with the binaries. This invitation, as well as the firmware that's also there, but that could be stripped off without GPL infringement, if it's in separate files, are the social problem, and they will be there regardless of whether the binaries have the firmware loader disabled.
Divergence is expected, if unfortunate, and not a major concern. Submitting patches to help fix the social problem we're concerned with is pointless, it was tried before and Linux developers don't appear to be interested in helping fix it.
That said, I'm probably going to give it another shot, with at least part of the plan proposed in the announcement. It might help reduce divergence, and it might be that Linux developers are not sufficiently opposed to the idea of telling Free from non-Free firmware that it might go in. Who knows? Maybe they'll surprise me and buy into it all, as an option ;-)
Advice Posted Mar 5, 2010 17:35 UTC (Fri) by alex (subscriber, #1355) [Link]
While I respect the position of the FSF and other individuals on the
political position of software freedom I'd advise you to concentrate on the engineering aspect with any submission to lkml/Linus. There are certainly hackers sympathetic to reducing proprietary taint in the kernel, however the kernel in itself is very much not a political vehicle.
The best you can hope for is reducing the diff between the Linus tree and
|
|||||||||||||