Re: LCC and blobs
Matthew Garrett <mgarrett@chiark.greenend.org.uk> writes:
> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
>
>> 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.
>
> This argument suggests that we can shift drivers from contrib to main
> simply by turning them into kernel patches and getting them included in
> the stock kernel. This seems, uh, odd.
Think about it like plugin support. A program to create gif images
using the non-free gif lib would have to be in contrib. Gimps plugin
support to optionaly use the non-free gif plugin to enhance its
features can still remain in main.
The difference between a standalone driver and a driver included in
the kernel is the usability. A standalone driver is not useable
without its firmware and needs a depends, the kernel works very well
without the firmware (for most people) so only a loose suggests is
appropriate.
The placement of main or contrib follows from that.
>> 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.
>
> But...
>
>> 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.
>
> No. Debian is not about distribution. It is about free software. We
That was aimed more at the free/non-free split. The firmware the user
aquires somewhere else does not concern Debian, only the firmware
blobs debian distributes matter.
For drivers firmware that will always be present in hardware does not
matter, only firmware that needs to be installed at runtime.
> don't make the distinction between main and contrib because of
> distribution requirements - we make it because we think that free code
> that requires non-free code is "tainted" by this. We put it in contrib
> so that people know that by using this software, they will also have to
> use non-free code. This is less obvious for drivers that use firmware in
> flash, but it's still true.
Nicely put.
> For what it's worth, we don't distribute the ipw2100 firmware. The user
> has to obtain that themself. For various other bits of hardware, the
> firmware is already on a CD that the user owns.
>
>> 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.
>
> Yes. That's an entirely separate issue. The definition of a DFSG blob is
> difficult, though.
Perosnaly I think a "char data[] = { ... }" can still qualify. But
thats for debian-legal and some maintainers do debate I guess.
> --
> Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org
MfG
Goswin
Reply to: