Re: non-free firmware in the linux kernel
I am cross posting to debian-release and debian-boot, since this will affect
On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote:
> at least I lost track a bit, so this mail is basically a question to
> bring me up to speed.
Ok, we had a long discussion on #debian-kernel, and altough not all
participated (Manoj, maks, fs, dilinger, kyle and me mostly), i think it sums
up well the current situation.
> In 2004, there was a GR that decided to put everything in main under the
> DFSG. We had some discussions, but in the end, the result was that all
> the non-free firmware bits have to be removed from main before we can
> release etch.
> Now, my question is: Is there still work open? If so, what? Or is the
> current removal of firmware enough, and we can relax on this topic?
Basically, the situation is like this :
1) there where drivers under implicit GPL licence with binary only firmware.
Since there was no explicit licence for this firmware, it was GPL, and since
it was sourceless, it was non-distributable. We started work to get
upstreams to relicence their code, which happened with the tg3 and qla2xxx
drivers, but failed for others, like the acenic one, partly because of the
demise of the company producing them and various acquisitions which left the
IP in an unknown state nobody seems to bother with.
2) there are now drivers which contains non-free firmware blobs, with
explicit licence, and these are thus distributable. A quick search for fw_
revealed 159 such files in 2.6.15.
3) an effort seems to be happening inside the upstream kernel to use the
request_firmware infrastructure which allows to load firmware code from
userland through an hotplug mechanism. There seem to be more and more
drivers going this way, since there aare more in current git than in 2.6.15
which was released a week ago, qla2xxx being among them.
Here is a link to the relevant wiki page about the cleaning up of messy
licences : http://wiki.debian.org/KernelFirmwareLicensing
So, basically this means we have the following options :
a) we move the whole kernel to non-free :)
b) we move the affected modules to non-free. Well those that have their
licencing solved, the others will simply no more be distributed, or
distributed form an unofficial source.
c) we move the firmware in non-free, and actively use the request_firmware
d) we go for a new GR, asking for an exception for the linux kernel, in
order to still stay in main, even though the firmware is non-free, arguing
that said firmware is more akin to hardware, since it replaces firmware on a
prom or flash on the expansion card, and you thus lose no freedom if we
distribute it, and the pain the other solutions will cause to ourselves and
I think everyone agrees that a) is not a possibility. Both b) and c) require a
non-negligible amount of work, altough b) is less work than c), but c) is the
better solution, and also to the best of my knowledge the one which upstream
seems to favour, altough both may mean a long-term additional work for the
kernel-team, work which the kernel team is not really prepared to make, which
leaves d). Not sure if d) is politically right right now with regard to the
GFDL situation, but that is another issue, which will then need to be debated.
So, Andreas, you proposed help and bug squasing parties focused on this, i
guess it is now clear what needs done :), and i can only stress that this
needs an additional comitment of help, since any patch which will come up will
probably have to be maintained by the debian kernel team for a long time.
Also, if we go the BSP way, it has to make clear that it had to be a long
standing and coordinated effort, since random patches of dubious quality will
probably only make matters worse for the kernel team..
I also CCed the debian-boot team, since it becomes evident that this will mean
some work on the d-i part, either to move the whole of d-i into nonfree (case
a), or to modify d-i to use non-free .udebs for certain modules or firmware.
Ok, i believe this summarizes the discussion of this evening, a log of the irc
discussion can be found at :