[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: non-free firmware in the linux kernel

Hi all, 

I am cross posting to debian-release and debian-boot, since this will affect
them too.

On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote:
> Hi,
> 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
  our users.

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 :



Sven Luther

Reply to: