Re: LCC and blobs
Brian Nelson <pyro@debian.org> writes:
> On Sat, Dec 11, 2004 at 08:11:31PM +0100, Josselin Mouette wrote:
>> Le samedi 11 d?cembre 2004 ? 11:00 -0800, Brian Nelson a ?crit :
>> > You are the only person I've seen express views similar to mine on
>> > debian-legal. All other participants argue for non-free-firmware-using
>> > drivers going in contrib.
>>
>> Do they?
>
> Judge for yourself:
>
> http://lists.debian.org/debian-legal/2004/10/msg00089.html
>
> (and others...)
>
>> > Also, the current practice already is moving in this direction. For
>> > example, the ipw2100 driver is in contrib.
>>
>> For a single package that won't work without the binary blob, that's a
>> good policy.
>
> It's a completely inconsistent and arbitrary policy.
The split between main and contrib can be made pretty simple and
consistent:
Does the package in question depend on something outside of main?
The linux kernel certainly does not depend on any specific firmware
and in fact most users can use it perfectly without any. Some users do
have special hardware wich needs extra firmware blobs but that hardly
constitutes as depends.
| Debian Policy
| 3.5 Dependencies
|
| Every package must specify the dependency information about other
| packages that are required for the first to work correctly.
I think firmware blobs fall nicely under suggests and there is nothing
wrong for a package in main (e.g. kernel-image-*) to suggest a package
in non-free (e.g. broadcom-tg3-firmware-update).
| 7.2 Binary Dependencies - Depends, Recommends, Suggests, Enhances,
| Pre-Depends
|
| Suggests
| This is used to declare that one package may be more useful with
| one or more others. Using this field tells the packaging system
| and the user that the listed packages are related to this one and
| can perhaps enhance its usefulness, but that installing this one
| without them is perfectly reasonable.
With drivers that load external firmware files this split is possible
leaving the driver in main inside the kernel and the non DFSG free
firmware in non-free.
For modules that are not part of the kernel the same argument doesn't
work. A driver that is only for hardware X which only works with
firmware is not functional without it. It would depend on the firmware
-> contrib (at a minimum).
> Virtually *all* device drivers in existance require a binary blob to
> work. It's up to the manufacturer to provide the binary blob to the
No. I have no binary blob (from Debian) at all on any of my debian
systems spaning several archs. There is a huge difference between the
hardware having firmware and the driver including or loading
one. Don't confuse that.
For Debian it is all about distribution. The rest does not matter at
all. Debian is not distributing the firmware that is in hardwares
eproms. Everything the user has is a big black box that somehow
works. What's inside it does not matter, only what Debian distributes.
> user when they purchase the device. Some devices have the blob on the
> hardware itself; for others, the manufactures ship it on CD or make it
> downloadable from a website. Some manufactures allow us to distribute
> it; others don't. We should not care what they do. That's up to the
> manufacturer's and the users of their hardware to work out.
We don't care what blobs do as long as they are not linked into GPL
software (like the kernel). Only then they have to follow the GPL.
Standalone blobs just have to follow DFSG if they want to be in main
and some of the BSD licensed blobs can be once they stop linking into
the kernel. Blame it on the viral nature of the GPL.
Actually having DFSG blobs is preferable since they can be included in
the initrd or on the first CD (since that is a glomeration of works
and not a single object) and can be used in the Debian-Installer.
>> But for a driver that's built within the kernel, this is fucking
>> stupid. We already have several packages with some features that only
>> work when some non-free stuff is installed (see e.g. xine). What's
>> wrong with the kernel having *some* modules needing non-free blobs?
>> They won't work out of the box, but that's not a reason to exclude
>> them from the kernel. This is more work for the kernel maintainers,
>> more work for the users, and no gain.
>>
>> In fact, all these drivers (including ipw2x00) should be built with our
>> kernel, and the binary firmwares that we can ship should be included in
>> the non-free section.
>
> That would be an acceptable though not ideal solution to me.
That is what people are trying to do in cases where the firmware blob
can't be in main. Some can and should be.
> --
> For every sprinkle I find, I shall kill you!
MfG
Goswin
Reply to: