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

Re: LCC and blobs



Michael Poole <mdpoole@troilus.org> writes:

> Goswin von Brederlow writes:
>
>> Brian Nelson <pyro@debian.org> writes:
>> 
>> > You aren't reading what I've written.  Virtually 100% of firmware
>> > out there (included on the device or loaded externally) is non-free.  By
>> > your reasoning, the entire kernel should be moved to contrib since no
>> > free hardware exists on which it can run.
>> 
>> Sure it runs on free hardware. On 100% free hardware. Take a pen, a
>> paper and the boch source code and run your own linux on the pen+paper
>> system. :)
>> 
>> Ok, it's a bit insane, but possible.
>> 
>> But let me say it again: "What matters is if the firmware itself is
>> distributable at all and if it is DFSG-compliant."
>
> You contradict yourself.  You can execute the firmware-loading driver
> on pen and paper also; it operates just as well as the rest of the

You still need the non-free firmware and the emulation of the hardware
(or emualtion of hardware+firmware). :)

> kernel does.  Less trivially, imagine a device that speaks the same
> protocol as the "problematic" device+firmware combination -- with the
> distinction of not needing firmware.  Since the software can use that
> device instead, the status of the firmware is irrelevant.

For the freeness of the driver: Yes it is. I never said the driver
itself should be non-free. You talk about the driver while I talked
about the firmware. Having a device that emulates the device+firmware
doesn't make the firmware for the old device free.

On the other hand having a device that uses the same driver but
without firmware loading means the driver (on its own) is usefull
and should be in main. The firmware becomes optional, the depends
becomes a suggests. It can influence the main7contrib decision.

> Otherwise, we must move clients and servers for network protocols into
> contrib if the other end is not implemented by software in main: they
> do not function properly without the other end.  Some examples would
> be things that speak AIM, MSN, Yahoo! messenger, etc.  Since some
> suggest that Linux kernel modules should be moved to contrib while the
> rest of the kernel stays in main, it seems reasonable that AIM support
> for gaim, naim, etc. should also be moved to contrib.

I hope nobody thinks that a non-free server somewhere halfway around
the globe makes a free client less free.

The story with kernel modules (and we are talking standalong modules,
not modules that are part of the kernel image) going to contrib is
slightly different. You need to install something non-free on the
system you want to use the module itself (and the module has no other
use unlike the linux kernel). If an AIM client required you to also
install a non-free AIM server package on the same system then the
client should go to contrib.

Installing non-free firmware taints your filesystem, using AIM does
not.

> Michael Poole

MfG
        Goswin



Reply to: