| |||||||||||||
FSFLA: Linux kernel is "open core"FSFLA: Linux kernel is "open core"Posted Nov 8, 2010 23:00 UTC (Mon) by jebba (✭ supporter ✭, #4439)Parent article: FSFLA: Linux kernel is "open core"
Interesting timing for this. Alexandre has been updating the linux-libre kernel regularily for a couple years or so, matching every upstream (& -stable, -rc) release.
On the LKML side, David Woodhouse has been plugging away moving firmware out of "random" locations in the kernel into a firmware/ subdirectory and using a common method for the firmware to be loaded (instead of each driver making up its own way). As I understand it, this whole firmware/ directory is likely moving out around 2.6.38, so all the non-free binary blobs that are currently in the kernel will be gone. Well, gone to a file outside of linux-2.6.xx.tar. RSN, the Linus tree will be free of non-free software. :)
(Log in to post comments)
Yup - this will finally clear any doubt... Posted Nov 8, 2010 23:38 UTC (Mon) by khim (subscriber, #9252) [Link] As I understand it, this whole firmware/ directory is likely moving out around 2.6.38, so all the non-free binary blobs that are currently in the kernel will be gone. What? Will they remove it? Well, gone to a file outside of linux-2.6.xx.tar. RSN, the Linus tree will be free of non-free software. :) Ah. So this will finally clear any and all doubts. As was pointed out by authors of the article Free Bait, or Open Core as first coined by Andrew Lampitt, is a licensing strategy that combines Free and non-Free Software: the distributor offers, under non-Free terms, premium features that are not available in the Free, typically copyleft, core. And after this big cleanup we'll have two packages: Linus's tree (which contains only free software) and tarball with "premium features" (and the first tarball will conveniently include hooks for the second one which are useless without it). Classic, textbook execution of open core strategy! If anything the article is a little early: today Linux kernel mixes free software and proprietary software so it's not obvious that it's open core, after this cleanup it'll be quite easy to see.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 0:11 UTC (Tue) by bojan (subscriber, #14302) [Link]
> Classic, textbook execution of open core strategy!
Feel free to not download or strip the non-free bits. Which, of course, will turn a whole lot of your hardware into bricks.
Does anyone seriously believe that Linus and other kernel developers wouldn't prefer NOT to ship binary blobs, if they could? Most of them spent their life releasing their source to general public. What possible motivation would they have for "bait-and-switch" here? Money? Fame? Power? Please.
I think members of FSFLA should do themselves and all of us a favour by rewriting all those binary blobs as free software. Yeah, I know - not as easy as writing a trashy press release, bashing folks that work hard on REAL problems every day.
Well, this is better... Posted Nov 9, 2010 0:34 UTC (Tue) by khim (subscriber, #9252) [Link] Does anyone seriously believe that Linus and other kernel developers wouldn't prefer NOT to ship binary blobs, if they could? Most of them spent their life releasing their source to general public. What possible motivation would they have for "bait-and-switch" here? Money? Fame? Power? Please. Well, the offenders here are usually hardware vendors and I'm not sure what drives them, but I suspect all three factors play a role. But the linux developers condone this situation so even if they are not actual felons they certainly can be counted as participators. I think members of FSFLA should do themselves and all of us a favour by rewriting all those binary blobs as free software. Yeah, I know - not as easy as writing a trashy press release, bashing folks that work hard on REAL problems every day. That it's not as easy is not a problem - harder things were done. That it's not as effective is a problem: if there are thousands of people who are contributing to the problem and only few who are fixing it then it'll never be fixed. Non free components are increasing faster than they're being replaced as was corectly pointed out...
Well, this is better... Posted Nov 9, 2010 1:00 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
many of the core linux developers are very clear that they are not worried aobut firmware blobs.
I would be very surprised if Linus made a change that caused the tarballs that he ships to be unusuable without some other tarball. He is willing to have the firmware reorganized so that a distro can easily remove it if they want to do so.
Well, this is better... Posted Nov 9, 2010 1:17 UTC (Tue) by bojan (subscriber, #14302) [Link]
> Well, the offenders here are usually hardware vendors and I'm not sure what drives them, but I suspect all three factors play a role. But the linux developers condone this situation so even if they are not actual felons they certainly can be counted as participators.
Felons? Offenders? Please. What crime has been committed?
Really nice that FSFLA is dragging Linus' name through the mud for a problem he and other developers cannot fix all by themselves (not even close). All the while Linus and Co are contributing ALL of their work to free software. Talking about hypocrisy...
> That it's not as easy is not a problem - harder things were done.
Yeah, and that's why I run Hurd.
If FSFLA want do something for REAL, they should then talk to the hardware manufacturers to free those firmwares. Or reverse engineer it. Or whatever else that WORKS.
Whinging about Linus being the bad guy just makes them look like spoilt kids that didn't like the latest toy they received.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 0:48 UTC (Tue) by gus3 (guest, #61103) [Link]
As soon as they get corporate permission, or the legal right, to reverse-engineer the devices, the firmware can be disassembled and then modified. And then we can also reverse-engineer nVidia's 3D acceleration.
Wait a minute. Didn't Linus rail against nVidia's using GPL'd API's a few years ago? Rather than outright banning the "nvidia" module, the kernel team added the "tainted" kernel flag, so that kernel crashes could be flagged as "unsupported stuff here".
How is the Intel microcode any different?
Yup - this will finally clear any doubt... Posted Nov 9, 2010 1:28 UTC (Tue) by bojan (subscriber, #14302) [Link]
> How is the Intel microcode any different?
Kernel doesn't link to it?
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:21 UTC (Tue) by gus3 (guest, #61103) [Link]
In the sense of the kernel object code in core, yes, that's true.
In the sense of affecting the behavior of the CPU, the only difference I see is that object code is external, where microcode is internal to the CPU. You can verify that the object code under the GPL doesn't run counter to your intentions, and you can also improve it or tailor it to your purposes. Why can't you do the same with microcode? It is also executable, just on a different level.
I'm not necessarily arguing for opening up Intel's microcode format (although dang, that would be sweet for my curious mind). I'm simply saying Linus is a bit two-faced for arguing against nVidia's proprietary module, but including Intel's microcode.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:48 UTC (Tue) by bojan (subscriber, #14302) [Link]
> I'm simply saying Linus is a bit two-faced for arguing against nVidia's proprietary module, but including Intel's microcode.
That is one interpretation.
Mine is that because Linus writes Linux (and not Intel microcode) and nVidia drivers are linked into the kernel, the traces of such crashed kernel become next to useless, because nobody can see the source of such linked-in modules (and they could be causing the crash). Ergo, nVidia and others were put on the "tainted" list, so that users don't expect help if they come to Linus with a "tainted" trace.
Sure, if Intel provides dodgy microcode, your machine will be just as screwed. But at least this is not something Linus is supposed to support in any way, shape or form, because it really is outside the kernel.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 6:43 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
you may not be aware that when the kernel loads, it includes microcode that it loads into the CPU. the is just the same as loading firmware into an external device.
however, in the nvidia driver situation, the code is being loaded into kernel space and can mess with other, seemingly unrelated things (if by no other way thatn by not following all the locking needed to make access to something safe)
Yup - this will finally clear any doubt... Posted Nov 9, 2010 13:47 UTC (Tue) by lxoliva (subscriber, #40702) [Link]
The microcode is actually not part of the kernel. The kernel supports loading it, but the actual microcode is separate.
As for tainting, I really don't understand why a driver that has access to DMA, system memory, buses and all on the primary CPU taints the kernel, but a blob that runs on a separate CPU and has access to DMA, system memory, buses and all doesn't taint it.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 14:11 UTC (Tue) by hmh (subscriber, #3838) [Link]
You'd need to taint anything that is SMM-capable.
You'd also need to taint anything that lacks an IOMMU configured in such a way that NO device can access non-exclusive memory, and where a device cannot attack other devices in the same bus.
I.e. it would be useless.
Yup - this will finally clear any doubt... Posted Nov 10, 2010 7:28 UTC (Wed) by Los__D (guest, #15263) [Link]
Then I guess you'd taint any device that we don't have complete HDLs for?
Yup - this will finally clear any doubt... Posted Nov 10, 2010 7:34 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
don't forget the requirement for the installation tools for the software, so that would mean that they would not only have to provide you with the HDL for the chips, they would also have to provide you with the ability to produce a modified chip and put it on the board.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:06 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
> Feel free to not download or strip the non-free bits.
Which is exactly what the announcement is--a version you can download with non-free bits removed.
> Which, of course, will turn a whole lot of your hardware into bricks.
That is incorrect, actually. Most devices don't draw from non-free software in the kernel. The linux-libre kernel will run 100% fine on many systems. Wifi is the big exception--often (but not always) that requires uploading non-free firmware.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:11 UTC (Tue) by bojan (subscriber, #14302) [Link]
> Wifi is the big exception--often (but not always) that requires uploading non-free firmware.
Who needs it anyway, eh? It's not like there are networks and apps out there you can connect to... :-)
Yup - this will finally clear any doubt... Posted Nov 9, 2010 5:09 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
> Who needs it anyway, eh? It's not like there are networks and apps out there you can connect to... :-)
...
> But at least this is not something Linus is supposed to support in any way, shape or form, because it really is outside the kernel.
Except that these things are *in* the kernel (tarball) at the moment, in some cases. It seems most Intel wifi firmware is outside (in fedora, for example, it's a separate RPM), but some wifi blobs are in the kernel tarball proper. Do you think the Intel firmware should be moved *in*? If not, why not have the other non-free blobs moved *out*? At least, for starters....
Yup - this will finally clear any doubt... Posted Nov 9, 2010 7:00 UTC (Tue) by bojan (subscriber, #14302) [Link]
Outside the kernel in the sense that it doesn't really run as part of it. Same as other firmware. Kernel just treats it as data that needs to be pushed somewhere.
I'm guessing the distribution together with the rest of the kernel source is just a convenience thing.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 15:11 UTC (Tue) by dmk (subscriber, #50141) [Link]
I think you are right. So, I now think open core is good. Thx for enlighten me.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 21:07 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] Yes, we agreed at the Kernel Summit last week that we're going to remove the legacy firmware/ directory from the kernel. It's just confusing now, since most distributions have already stopped shipping its contents and are instead shipping the separate linux-firmware.git repository which contains a lot more firmware for different devices.I was tempted to send a patch the same day we agreed it, but then decided to wait for 2.8.38 I want to make the transition slightly easier for those who were using CONFIG_FIRMWARE_IN_KERNEL, by doing something that'll look for MODULE_FIRMWARE tags in the drivers which are built into the kernel, and try to pull those firmware images in automatically.
Yup - this will finally clear any doubt... Posted Nov 10, 2010 1:42 UTC (Wed) by dmarti (subscriber, #11625) [Link] Is anyone doing any security audits on that firmware, or are all hardware vendors trusted with DMA access to everywhere? Just wondering.
Yup - this will finally clear any doubt... Posted Nov 10, 2010 1:47 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]
This is what we have an IOMMU for.
FSFLA: Linux kernel is "open core" Posted Nov 8, 2010 23:43 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]
Nope, there are still a few blobs outside of firmware.
But this whole argument by the linux-libre folks is nonsense. Devices are no more free if they load their proprietary code from flash rather than relying on the driver to copy it from the host. Further, if the driver loads the code that is likely to make it easier to reverse-engineer and replace.
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 2:43 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
I didn't see him arguing that.
Do you think it's good that the Linus tarball is full of things like:
"Licence: Unknown
There's a pile of that, for starters... What about all the other odd ball licenses that are floating around in there? Should they remain?
Ignoring the "open core" bit Posted Nov 9, 2010 11:15 UTC (Tue) by pboddie (subscriber, #50784) [Link]
Agreed, the "open core" rhetoric is misplaced, but the actual point of the message remains. If anyone were to submit stuff for inclusion in Debian or Fedora with "licence unknown", they'd be told to go and fix it.
Ignoring the "open core" bit Posted Nov 9, 2010 16:01 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]
Yes, that's exactly why Debian doesn't include those.
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 9:35 UTC (Tue) by job (guest, #670) [Link]
They may well be. Please read my comment above.
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 10:26 UTC (Tue) by ballombe (subscriber, #9523) [Link]
That is not clear. The laws governing hardware and software are very different, but in general laws about software are more restrictive that laws about hardware. It is much easier to sell a firmware with a very restrictive license (that e.g. prevent it being resold) than a piece of hardware. You can also more easily disclaim warranty on firmware than on hardware.
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 16:02 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]
A somewhat outdated summary of those blobs can be found at http://wiki.debian.org/KernelFirmwareLicensing
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 17:57 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
This is probably the most recent:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...
FSFLA: Linux kernel is "open core" Posted Nov 11, 2010 19:29 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] That's for the blobs in the firmware directory; I was pointing out the blobs outside it.
FSFLA: Linux kernel is "open core" Posted Nov 11, 2010 21:16 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link] Ah, interesting. I wonder why things like this didn't get moved to thefirmware/ directory. From:linux-2.6/drivers/net/appletalk/cops_ffdrv.h
/* * The firmware this driver downloads into the Localtalk card is a * separate program and is not GPL'd source code, even though the Linux * side driver and the routine that loads this data into the card are. * * It is taken from the COPS SDK and is under the following license * * This material is licensed to you strictly for use in conjunction with * the use of COPS LocalTalk adapters.
FSFLA: Linux kernel is "open core" Posted Nov 13, 2010 1:30 UTC (Sat) by dwmw2 (subscriber, #2063) [Link]
That particular example didn't get moved just because we didn't notice it.
AFAICT the only person doing regular sweeps of the kernel to check for such things is Alexandre, and he's completely jumped the shark so most people who are actually doing useful work on this stuff have started ignoring him.
S'probably worth going through the current deblob script and working out if there are more examples like the one you provided above; thanks for that.
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 19:29 UTC (Mon) by wookey (subscriber, #5501) [Link]
What does 'jumped the shark' mean?
FSFLA: Linux kernel is "open core" Posted Nov 18, 2010 10:33 UTC (Thu) by mpr22 (subscriber, #60784) [Link] From Wikipedia: Jumping the shark is an idiom used to denote the point in a television program's history where the plot spins off into absurd storylines or unlikely characterizations. These changes were often the result of efforts to revive interest in a show whose audience had begun to decline. (The above text is available under the Creative Commons Attribution Share-Alike licence.) While I do find some of the FSFLA's publicity material surrounding Linux-libre to be of dubious quality and appropriateness, I am less than convinced that "jumping the shark" is applicable here.
|
|||||||||||||