Re: LCC and blobs
Goswin von Brederlow <firstname.lastname@example.org> 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.
> 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.
No. Debian is not about distribution. It is about free software. We
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.
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
Matthew Garrett | email@example.com