linux-2.6: includes nondistributable and non-free binary firmware

[ldoolitt@recycle.lbl.gov]

Maks -

On Thu, Aug 17, 2006 at 06:05:30PM +0200, maximilian attems wrote:
> > Something about [bug #242866] seems broken, however,
> > because RC-buggy linux-2.6 packages keep making it into
> > testing.  Is it obvious how to keep this from happening,
> > without starting a new bug attached to linux-2.6?
> 
> if you feel like it reassign it,
> anyway linux-2.6 is frozen and propagation to testing
> is coordinated with the release and the d-i team.

Sorry, I don't understand this statement.

> on the other side a good example to remove people access to
> their discs.

That's the argument that sent sarge out the door with
DFSG violations.

> anyway if you want to improve the legal situtation use:
> http://wiki.debian.org/KernelFirmwareLicensing
> dilinger succeeded in various firmware relicensing
> thanks to his quest to the vendors. feel free to pick up.

For each offending file, there are three possible solutions:
1. Get the author to release source code under a DFSG-free license
2. Move the firmware to non-free, patching the driver to use
   request_firmware()
3. Delete the driver and firmware entirely.

AFAIK, the best outcome yet from the relicensing discussions
on http://wiki.debian.org/KernelFirmwareLicensing is to properly
permit the redistribution of the binary, without source code.
That's fine for debian non-free, and a necessary step for making
option (2) above work properly.  Until and unless the entire
Linux kernel is moved to non-free, such relicensing doesn't
solve the fundamental bug.

I agree that option (3) is bad, but I still recommend it for
the short term.  It's the quickest path to a legal and
SC-conforming Linux release, and it will bring people out
of the closet to volunteer to work on (2).  I think (2)
is the actual goal, but maybe not one that can be finished
before the proposed etch freeze -- especially since most
of the blobs need to be relicensed before they can be made
part of firmware-nonfree.

I would be amazed and impressed if option (1) could be made
to work for any of these files.  I don't volunteer to try.

If the kernel team decides on (2) or (3), I'd be happy to
help with the coding.  (Note that, due to the unfortunate
state of upstream, most of the patching/deletion has to
happen in the creation of the .orig.tar.gz file, not the
.diff.gz file)  Unfortunately, due to a lack of hardware,
I can't help with any testing (other than "does it compile").

    - Larry