Re: non-free firmware in the linux kernel
Sven Luther wrote:
> Hi all,
>
> I am cross posting to debian-release and debian-boot, since this will
> affect them too.
<snip>
> 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.
I would like to add that I have volunteered to
(a) assist with converting these to the request_firmware infrastructure
(b) package the blobs for 'non-free'. Udebs provided on request.
I actually *did* this for tg3 (back when the firmware was undistributable,
but before I'd noticed that). However, all my work so far has been
rejected by upstream for reasons which I can only call pure hostility (I
have seen few technical reasons, and have received no response to requests
regarding what would be an acceptable patch). The corresponding patches
have been removed from the Debian kernel because the kernel maintainers at
the time did not want to maintain patches relative to upstream. This does
not exactly encourage me to work on other drivers. I have since misplaced
my tg3 work, and would have to retrieve it from an old Debian kernel
package. Help doing so would be appreciated :-)
> 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.
OK, but (c) is better. However, we can use a combination of (b) and (c).
> c) we move the firmware in non-free, and actively use the
> request_firmware mechanism.
Great idea!
> 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.
If my DD application ever goes through, I would definitely vote against
this, because the argument is completely bogus. For an similar argument,
"An implementation of BASIC is more akin to hardware, because it replaces
IBM BASIC which used to be kept in ROM". This argument might wash if the
"firmware" was not code at all, but in the cases I know of, the "firmware"
is in fact code for MIPS, ARM, and other ordinary CPUs which are on the
expansion card.
> 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.
(d) is unacceptable. I have *volunteered* to work on (b) and (c) and I am
happy to be the effective maintainer for any involved patches and packages.
I see no reason why that would not be acceptable to the kernel team. I'm
even happy to leave any individual non-free lump in 'main' while the work
on making it loadable from non-free is in progress.
> 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.
Committment made. Will it be accepted?
> 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 :
>
> http://people.debian.org/~fs/firmware-irc-log.html
You should have invited me, you know. :-)
--
ksig --random|
--
To UNSUBSCRIBE, email to debian-boot-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: