| |||||||||||
Debian Weekly News 2004/15Debian Weekly News 2004/15Posted Apr 14, 2004 5:03 UTC (Wed) by jwb (subscriber, #15467)Parent article: Debian Weekly News 2004/15 I find it pretty unbelievable that Debian would stop distributing the drivers which load firmware into their peripherals. Actually, I believe it fully. But it still amazes me. The code in question does not even execute on the host CPU, so clearly it is not a derived work of the kernel, and therefore it is not covered by the GPL. Many peripherals need firmware loaded before they can run, namely scads of cheap USB devices. Consider this exercise. To start peripheral XYZ it is necessary to write 0xf5, 0x02, 0x26, 0xff to its registers. So a driver might have source like char boot[] = {0xf5,0x02,0x26,0xff}; This information would have come from reading the datasheets. It's embedded binary code with no source. Now, what is the difference between that and char firmware[] = { 4 kilobytes }? The answer: there is no difference. They are both binary code with no source. But nobody would think of suggesting that the former example should be removed from the kernel, and for that reason neither should the latter example.
(Log in to post comments)
Debian Weekly News 2004/15 Posted Apr 14, 2004 5:32 UTC (Wed) by Ross (subscriber, #4065) [Link] If there is a source format for the former then it would be exactly thesame -- except much easier to fix. I thought the kernel developers had decided on an interface to load binary-only firmware from userspace (and before you say that is impossible it could include initial RAM images or the new cpio stuff). That way there is a clear separation of the works. No worries about derivatives (in either direction) and cleaner kernel code to boot.
Debian Weekly News 2004/15 Posted Apr 14, 2004 5:32 UTC (Wed) by piman (subscriber, #8957) [Link] Easy -- those 4 bytes can (and are) written easily by hand, i.e. they are the preferred form of modification. For the purposes of the GPL and the DFSG, that makes them the source.People (most people, especially those working on commercial hardware) don't write 4k binary blobs by hand anyone, everyone uses an assembler. The assembly code is the source. The issue is much less about GPL-compatibility (in most cases), than about compliance with the Debian Free Software Guidelines. Debian doesn't want to distribute non-free software, regardless of where that software is executed.
Debian Weekly News 2004/15 Posted Apr 14, 2004 15:03 UTC (Wed) by jwb (subscriber, #15467) [Link] Okay, I can see your point. But what about other cases of objects that are not distributed with source? Take an image for example. If the artist creates the image using the Gimp, but Debian distributes the PNG, does that mean that either 1) Debian must also distribute the XCF file, because that's the preferred form for modification, or 2) Debian must move all artwork to non-free?Don't get me wrong, I'd love to have the commented source for all these firmware blobs. Some firmware source for the aic7xxx/79xx SCSI HBA for example is included in the kernel by Adaptec themselves. And short of that I think loading the firmware from userspace is the best idea. But either way I think the project is blowing this issue out of proportion and it will hurt the users eventually.
Debian Weekly News 2004/15 Posted Apr 14, 2004 19:44 UTC (Wed) by piman (subscriber, #8957) [Link] The answer is, Debian must distribute the XCF, if such a form existed. Sometimes the author of the work doesn't even save an intermediate form (for example, you don't distribute your source code with undo information in it), in which case, that's probably the preferred form for modification. If the author has an XCF that she modifies and then only gives users the PNG, then that image is proprietary, because you don't have source access. But if the author uses a PNG herself as the main form of modification, then it's the source.In most cases, Debian does distribute the source to non-code, like XCF for image files, if such things exist. If you run across a situation where Debian doesn't, please file a bug against the package.
Non-free firmware in the kernel tree. Posted Apr 14, 2004 8:59 UTC (Wed) by ballombe (subscriber, #9523) [Link] Firmware are copyrighted code. Even forgetting the source issue, some firmware were found to carry a license incompatible with the GPL and/or DFSG. Some licenses did not allow for redistribution at all. See http://bugs.debian.org/242895 for an example.
Debian Weekly News 2004/15 Posted Apr 14, 2004 13:43 UTC (Wed) by sholden (guest, #7881) [Link] The firmware in question clearly doesn't meet the requirements outlined in Debian Free Software Guidelines, so either they go or it goes.And the difference in your example is that when a firmware change is made chances are the programmer does not edit a 4 kilobyte char array assignment statement by hand, and hence that isn't the "source". If the 4 kilobytes was derived from datasheets and that is how it is managed then it would be fine, but that clearly isn't the case in some of these cases.
Debian Weekly News 2004/15 Posted Apr 14, 2004 13:57 UTC (Wed) by pizza (subscriber, #46) [Link] Consider this -- the "firmware" that these drivers include used to be embedded directly into the hardware, usually in the form of an EEPROM or somesuch. Instead now, to save hardware costs, they forego the onboard ROM to save the $1.09 per device and have the host upload the firmware. This is the case with the current crop of prism3 wireless cards, for example.So while it can be argued that this makes the device "non-free", the device was NEVER "free" to begin with. The hardware is still a magic black box, datasheets or no, because we don't have the, say, VHDL sources of the chips . This does not make the driver "non-free"; instead it ends up in a similar situation as, say, using Ethereal on Windows -- Free Software that depends on Non-Free components. But when you think about it, does anyone actually run Linux on "Free" hardware? Let's look at that shiny CPU, mmmm? The only difference now is that parts of that former black box have been transferred to the host. As far as the driver is concerned, it's still just a Non-Free component that's being interfaced to. All that said, this is purely a matter of redistribution. If there is a binary blob associated with a driver, we need permission from the copyright holder to distribute it, be it with the kernel or from some other source. Otherwise we're breaking copyright law.
deb http://http.debian.org/debian firmware Posted Apr 14, 2004 15:37 UTC (Wed) by chant (guest, #20286) [Link] I agree completely. Perhaps debian could use a 'firmware' section, in addition to non-free/contrib/main. Firmware could be put in this section (to be loaded in from userspace via hotplug, like my Atmel 802.11b card) so long as debian has the right to redistribute it. I suppose the key issue is ensuring that every driver that needs firmware load it from user space - not a huge issue as long as you use initrd.Sure, it's not free , but as pizza points out, hardware has never been free in the first place.
Debian Weekly News 2004/15 Posted Apr 14, 2004 18:20 UTC (Wed) by Peter (guest, #1127) [Link] So while it can be argued that this makes the device "non-free", the device was NEVER "free" to begin with. That's not the issue. The issue is not whether your PC is a completely "open" or "free" platform. We all know it is not, for quite a few reasons. However, there's a great deal of difference between "Debian can run on hardware which itself doesn't meet the Debian Free Software Guidelines" ... and "Debian claims to be distributing 100% free software, but in reality is also distributing software which is not free." The latter is a convenient little lie, and because it's a lie, it bothers a lot of Debian developers. Maybe you see no problem loading some binary blob into your RAID controller, but then again, maybe you also see no problem running the non-free NVidia XFree86 driver. You're free to do those things, even under Debian, but you'll have to get them somewhere else. Debian claims that their distribution contains only free works, not "only free works, plus whatever non-free components happen to be necessary to use any given hardware".
Debian Weekly News 2004/15 Posted Apr 14, 2004 22:02 UTC (Wed) by mlei (guest, #17766) [Link] Extremely well-thought out post. If there were moderation on this site I'd mod it up informative.
Debian Weekly News 2004/15 Posted Apr 14, 2004 22:17 UTC (Wed) by Peter (guest, #1127) [Link] Thanks. The content wasn't original - I already read the flamewar on debian-devel. (:
Debian Weekly News 2004/15 Posted Apr 15, 2004 16:42 UTC (Thu) by pizza (subscriber, #46) [Link] You ignored the last paragraph of my original post. I agree that the "little lie" runs counter to the DFSG.But I'm taking that "little lie" one step further -- I see no difference, morally, between a binary blob that has to be copied over to the hardware, versus a binary blob already embedded in the device itself (even if it's just mask ROM!). I consider that blob and the rest of the hardware inserparable, because without it, the hardware is just a paperweight. But as you said, distributing this binary blob runs counter to the DFSG. I just hope that, once all of these redistributable (yet non-DFSG-compliant) binary blobs are removed, the Debian kernels are still bootable.
Debian Weekly News 2004/15 Posted Apr 15, 2004 23:36 UTC (Thu) by Peter (guest, #1127) [Link] I just hope that, once all of these redistributable (yet non-DFSG-compliant) binary blobs are removed, the Debian kernels are still bootable. Long term, I think it's good for someone to stand up and send a message to these vendors that not everyone thinks they should keep back part of their source code just because it's not executed on the host CPU. Remember, a few years ago, binary-only drivers were quite common, even for things like network cards. But you can't get your driver into a Linus published kernel without giving out your source under the GPL. And these days, nobody in server space wants to be caught without a driver in the standard Linux kernel. So the vendors swallowed hard and did the right thing, contributing docs and in many cases actual drivers to Linux kernel development. Not that I expect this next round to be won so easily, mind. Mostly because Linus doesn't really care about this part of the issue, so you can't threaten vendors with not having a driver in the official kernel. Debian is considerably less influential. But still, Adaptec proved many years ago that it's entirely possible - even reasonable - to ship full source code for your firmware. (They even went a step further and shipped the source for an assembler capable of assembling it.) And I dunno, maybe it's just me, but this decision doesn't seem to have hurt them in the least. Since Adaptec proved it can be done, I don't see much reason for other vendors to insist on sending us their binary blobs. Except for the obvious reason: that they really don't care. That is the attitude it would be nice to change.
|
|||||||||||