| |||||||||||||
Merge into Linux? Useful as test suite before buying hardware!Merge into Linux? Useful as test suite before buying hardware!Posted Mar 4, 2010 15:40 UTC (Thu) by dwheeler (guest, #1216)Parent article: Linux-2.6.33-libre released
I have two thoughts on this. First, has anyone discussed merging this in the future into the Linux kernel itself? I can imagine a configuration option that said "only include material meeting $LICENSE_CRITERIA". With that, it'd be easy for kernel developers to realize when something has been added that doesn't meet that criteria, identify what doesn't meet it, accept patches that replace it (and see why), etc. Obviously that's up to Linus et al., but as long as it wasn't REQUIRED, they might think that's a good thing. Second, I can see this as being really useful as part of a test suite before buying hardware. Buying hardware is tricky today. If I could run a "libre" test suite, then I could see which one was supported by purely OSS drivers... and buy that one instead.
(Log in to post comments)
Merge into Linux? Useful as test suite before buying hardware! Posted Mar 5, 2010 9:33 UTC (Fri) by alex (subscriber, #1355) [Link]
In theory you should be able to get that by disabling the firmware loader.
There has been a push to remove the binary blobs in the linux source tree and make them available via the firmware loader interface. While not everything has been expunged I'm sure patches doing so would be useful.
Merge into Linux? Useful as test suite before buying hardware! Posted Mar 5, 2010 15:23 UTC (Fri) by lxoliva (subscriber, #40702) [Link]
Disabling the firmware loader would disable support for Free firmware too.
Something that AFAIK hasn't been taken to the Linux developers yet is some means to distinguish Free from non-Free firmware (say, different request_firmware calls), so that you could choose freedom.
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, still contain the non-Free firmware and the requests for non-Free firmware, which is likely to be mistaken as indication that the firmware might be a solution for a technical problem, rather than being a symptom of a social problem.
Merge into Linux? Useful as test suite before buying hardware! Posted Mar 5, 2010 15:47 UTC (Fri) by alex (subscriber, #1355) [Link] 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).
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
|
|||||||||||||