status of some loadable firmware (was Re: Proposal: The DFSG do not require source code for data, including firmware

[Nathanael Nerode <neroden@fastmail.fm>]

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
>> of
>> data.  I don't think the DFSG *requires* this, and therefore I don't
>> think
>> *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
> contrib.
> 
> 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
>        mod_firmware_load()
>      * 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
http://plutohome.com/wiki/index.php?title=Installation :
"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.
http://langerland.de/linux/bcm43xx/firmware.html

Example #6: bcm203x.  Firmware in the bluez-firmware package in
non-free.  :-)

This is a random selection, but I seem to have already run across the full
gamut of possibilities.

> Kurt

-- 
Nathanael Nerode  <neroden@fastmail.fm>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...