Linked by Thom Holwerda on Tue 9th Nov 2010 22:24 UTC, submitted by koki
GNU, GPL, Open Source Now this is interesting. We see what is at its core a very valid concern, in practice not a problem to anyone, and, thanks to the tone of the press release, close to trolling. The Free Software Foundation Latin America is complaining about something that has been known for a while - there is some non-Free code stuck in the Linux kernel (mostly firmware). A valid issue of concern from an idealogical viewpoint, but sadly, the tone of the press release turns this valid concern into something close to trolling.
Thread beginning with comment 449331
To read all comments associated with this story, please click here.
This is a solved problem.
by boldingd on Tue 9th Nov 2010 23:33 UTC
boldingd
Member since:
2009-02-19

This is an old problem, that's already been mostly solved. I believe it's possible to disable binary blobs when you (or your distributor) build the kernel, and there already exist distributions that do this. This is a problem that already has a compromise solution in place.

I'm curious what the FSF-LA's goal is, here, as they're bringing up some fairly old news.

Reply Score: 3

RE: This is a solved problem.
by WereCatf on Tue 9th Nov 2010 23:42 in reply to "This is a solved problem."
WereCatf Member since:
2006-02-15

This is an old problem, that's already been mostly solved. I believe it's possible to disable binary blobs when you (or your distributor) build the kernel, and there already exist distributions that do this. This is a problem that already has a compromise solution in place.

As far as I know, most distros do offer several versions of kernels and there likely exists also one which doesn't ship with the binary blobs. And as you said, there exist whole distros dedicated to shipping only F/OSS software, no proprietary anything. And you know, you don't even need to disable the blobs anywhere: just delete them.

Reply Parent Score: 2

boldingd Member since:
2009-02-19

It's more than just "some distributors pull them out." I do believe that, when you check out the kernel's source and run the configure script, it has a high-level option to not include any binary firmware blobs. An effective solution to this problem is built right into the kernel's make system.

Solutions to this problem don't just exist, they are well-supported and incredibly easy to use.

Reply Parent Score: 3

RE: This is a solved problem.
by umccullough on Tue 9th Nov 2010 23:43 in reply to "This is a solved problem."
umccullough Member since:
2006-01-26

I'm curious what the FSF-LA's goal is, here, as they're bringing up some fairly old news.


It would seem, based on the reading of comments on that article, that the guy who wrote this was one of the people who helped clean up the mess in the first place (although I can't confirm that). I found this blurb for example:

"When lxoliva started working on linux-libre, it *wasn't* marked as such. It was scattered all about the kernel tree sometimes in separate files, sometimes mixed in with the main driver, etc."

Reply Parent Score: 5

Lennie Member since:
2007-09-22

I do know it was now all moved to a seperate directory.

But this is a good thing about Linux, people can do with it what they want. Even if they do not agree with Linus.

Reply Parent Score: 4

RE: This is a solved problem.
by raboof on Wed 10th Nov 2010 01:17 in reply to "This is a solved problem."
raboof Member since:
2005-07-24

This is an old problem, that's already been mostly solved. I believe it's possible to disable binary blobs when you (or your distributor) build the kernel, and there already exist distributions that do this.


Yes. AFAIK Debian distributes its kernels without binary blobs, but has the blobs available in separate, easily-installable packages in the 'non-free' section.

Seems like a fine solution if you ask me. Perhaps it'd be nice if kernel.org also started distributing the firmware as a separate package, wouldn't that end this discussion once and for all?

Reply Parent Score: 5

RE[2]: This is a solved problem.
by asdf on Wed 10th Nov 2010 14:01 in reply to "RE: This is a solved problem."
asdf Member since:
2009-09-23

Some firwmares have version dependency against specific drivers. There are cases where firmware for newish devices evolve quickly changing programming interface along the way. The drivers and firmwares need to be updated in lockstep in those cases. Distributing them together is just much less painful for everyone involved.

Reply Parent Score: 1