status of some loadable firmware (was Re: Proposal: The DFSG do not require source code for data, including firmware
- To: email@example.com
- Cc: firstname.lastname@example.org
- Subject: status of some loadable firmware (was Re: Proposal: The DFSG do not require source code for data, including firmware
- From: Nathanael Nerode <email@example.com>
- Date: Mon, 28 Aug 2006 22:28:56 -0400
- Message-id: <[🔎] firstname.lastname@example.org>
- References: <20060822221804.GC28755@mauritius.dodds.net> <20060823183031.GA17560@roeckx.be> <20060824081642.GD18636@mauritius.dodds.net> <20060824182949.GA19432@roeckx.be> <20060825000833.GA24243@mauritius.dodds.net> <20060825180451.GA22032@roeckx.be>
Kurt Roeckx wrote:
> On Thu, Aug 24, 2006 at 05:08:33PM -0700, Steve Langasek wrote:
>> On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote:
>> > On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote:
>> > > > Point 3 then seems to go the other way around and say we don't need
>> > > > sources for of few types of works. My main problem with this is
>> > > > that still a little vague about which types of works don't require
>> > > > source.
>> > > What problems do you consider this vagueness to cause? What changes
>> > > would you suggest to make this less vague?
>> > It lists "images, video, and fonts". And I'm assume it's going to
>> > cover
>> > more than just that. I'm also not sure that this is something we want
>> > for all types of data.
>> I think we *want* the best possible form for modification for all types
>> data. I don't think the DFSG *requires* this, and therefore I don't
>> *we* should require it. Do you disagree?
> I think we should require it. The DFSG says we need the source, and
> I understand that as the best possible form for modification.
> For instance, bison/yacc generates a C file. You could consider that
> C file a source, but it's not. We want the original file that was used
> to generate that C file. There might be several layers of tools that
> are used to generate an object file from it's source, but it's the
> source we want.
>> > For instance when they're raster images or fonts, I'd rather have the
>> > source, if there ever was a vector based format of it. But I don't
>> > care if there never was a vector based format, so nothing that would be
>> > a more prefered way of changing it.
>> "Rather have" != "Insist on for inclusion in main", though?
> No, I would insist on having it.
>> > > Anyway, the answer I had in mind was a hex editor or a decompiler.
>> > > If the firmware in question *is* code, and we know what the chip in
>> > > question is that the code is running on, both options seem within the
>> > > realm of
>> > > plausibility to me. No, of course they're not the *ideal* means of
>> > > editing such a work, but AFAIK most firmware is on the order of what
>> > > programmers used to program directly in assembly, so it's also not
>> > > totally *insane* to try to edit such a binary directly as it would be
>> > > for most modern userspace apps, for instance.)
>> > I don't see a hex editor useful for much, and a decompiler only
>> > slightly
>> > better. If a decompiled version was useful to do derived work, it
>> > would be the same as source, so not requiring source doesn't make sense
>> > to me.
>> > The difference with source is that you actually have names of functions
>> > and variables, you have comments with it. Those things make it easy to
>> > understand what it's trying to do. So it's easier to make changes too.
>> OTOH, the source may require a non-free tool to render it into a binary
>> firmware form. If you don't have that tool, and maybe even no hope of
>> getting access to it, is it any longer evident that the source is more
>> useful than the binary for derived works? Yes, from there we get into
>> discussions about defining "source" as "whatever form people prefer to
>> work from" -- hmm, redefinition? -- and whether we can ship anything in
>> main that we don't have a full toolchain for; but a) is that actually
>> required by the DFSG, and b) is that the right standard to set, either
>> today or in the future?
> The DFSG doesn't say that the toolchain should be available for it to be
> free, and it shouldn't. But I understand the SC as requiring it to be
> included in main. It's also one of the reasons we have such a thing as
> There was a time when alot of java applications were in contrib because
> there wasn't anything in main we could use them with. But those were
> free software. You just needed non-free software for it to be useful.
> And now most, if not all, have moved to main.
>> > It would also be useful to have a list of firmwares we're currently are
>> > talking about, and what license they have. Are there any that only
>> > fail DFSG 2, or will this part of GR have no effect at all?
>> Larry Doolittle has prepared a very helpful table at
>> <http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html>. A number
>> of these are marked as being under a "BSD-ish" license, which would
>> qualify; a number of others are listed as GPL but sourceless, which
>> nominally makes them non-distributable, but it seems unlikely that any
>> copyright holders on these would refuse to relicense under more
>> appropriate terms even if they weren't willing/able to release source.
> So, from that list:
> * 46 source files that already use request_firmware() or
> * 18 already removed from Debian (linux-2.6_2.6.17.orig.tar.gz)
> * 47 apparently nondistributable
> * 12 apparently ok for non-free
> * 14 free
> So, we have a total of 137 drivers that require firmware. We have
> 14 that are free and can stay in main in any case.
> I'm not sure about those 46 that already use request_firmware(),
Almost all of these feature externally packaged firmware, not in the kernel
source. It's a fairly easy project to download and package those whose
licenses allow it.
> but we
> seem to have atleast 12 (BSD-ish) that could go to non-free, but with
> your proposol could stay in main.
> It would be interestig to know if any of those other 46 are currently in
> non-free, or what their license is.
Yes, it would.
Example #1: ipw2200. Firmware downloadable from
http://ipw2200.sourceforge.net/firmware.php. It's a nasty license. I
believe it's clearly safe to make a downloader package with clickwrap,
though. I don't think Debian as a whole wants to agree to the "you may not
reverse engineer" provisions, otherwise it would be distributable.
Example #2: atmel. Firmware in atmel-firmware package in non-free. :-)
Example #3: cx88-blackbird. The firmware appears to lack a public
distribution license. Reference
"You can get this from the card manufacturer."
Some people seem to have made illegal packages of it; I suspect that they
simply lifted the file off the manufacturer's CD.
Example #4: ivtv. There's a program called 'ivtvfwextract' floating around
to extract the firmware from the manufacturer's CD.
(http://www.cugy.net/forums/printthread.php?t=1103&page=2&pp=15) Again it
probably doesn't have a public distribution license.
Example #5: bcm43xx. Similar to ivtv, there's a 'bcm43xx-fwcutter' program.
Example #6: bcm203x. Firmware in the bluez-firmware package in
This is a random selection, but I seem to have already run across the full
gamut of possibilities.
Nathanael Nerode <email@example.com>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...