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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

Sven Luther <sven.luther@wanadoo.fr> writes:

> On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <sven.luther@wanadoo.fr> writes:
>> And even for an aggregation of works the DFSG holds and you are still
>> in trouble.
> Sure, the DFSG says that we need the source code for those, and they are thus
> non-free, but what i am arguing is that they are not violation of the kernel
> GPL, since they are separate aggregate works.

As part of the source files they are seperate works. When you compile
and LINK them all together they become one work. Just like when you
link in non GPL static (or even dynamic) libraries.

>> Let me make another example. I take a GPL program and link in a
>> non-free library plus glue code that forks a child and uses the
>> library. Only the child does use the non-free library and the
>> communication between father and child is clearly defined.
> Let me make another example. You buy a random bunch of hardware, and either
> run linux on it, or run a free linux driver running it. This hardware in
> question happens to have some random bios on it, which is non-free, or some
> fpga config file hidden in a flash.
> This is exactly the same case as the one you are describing, with the sole
> exception of the firmware in question being temporarily transported in the
> kernel binary and uploaded in the device.

No, to get the same case you have to read out the bios/flash and
include that in Debian to be distributed by debian in main. If you do
that the hardware vendor would sue you in a minute for copyright
infringement because you don't even have distribution rights.

> Finally, what you mention is more akin to the unicorn driver, which is a
> driver for a soft-ADSL pci modem, which links to a non-free, binary-only,
> x86-only ADSL library. This is indeed more than just agregation, and after i
> engaged bewan over it, and we consulted with RMS and the FSF, they released
> their drivers with a GPL+exception licence, and the package is now happily
> sitting in non-free, waiting for someone to write a free ADSL library
> replacement.

Indeed. That was one of the bad examples.

>> The non-free library never runs in the same address space as the rest
>> of the program. Does that mean this is just an aggregation of works
>> and GPL compliant?
> I am not familiar enough with how library are run, but there is some very
> different way in which libraries called by programs work, and the way the main
> cpu interacts with a peripheral processor on a pci card, don't you think ? Or
> do you want also to declare that you can run GPLed Linux kernels only on
> hardware whose VHDL of every chip on it as well as schematics and gerbers are
> freely available, not counting that you would also need free PCB design tools
> which can read the format, as well as free tools running the manufacturing
> plant, and so on ...

_IF_ Debian would distribute the CPU in main then zes, I would require
that. But Debian is not a hardware vendor.

Where people buy their hardware or how free their hardware is has
little to do with Debian main. It is a problem for the linux upostream
authors to support the hardware with free source code and sometimes
they fail.

>> I've been bugging Bastian about this issue as well since I need this for
>> multiarch. I have a hacked together cdebootstrap that first
>> concatenates the Packages files from multiple sources and then calls
>> libd-i. It is ugly but it works. This workaround is quite simple to
>> copy into D-I if you really want to work on it.
> Ah, nice, i would really be interested in that. Now, the problem is that it
> needs to be integrated into the main d-i work, and given their
> over-conservativeness and immobilism, it is way too late for etch, or didn't
> you hear that d-i was supposed to be frozen this week ?

Please stop making this into an attack. Better spend that energy into
writing a patch. You've done D-I work before so maybe you even looked
at libd-i source before.

> Nope, i keep pointing out the responsabilities of the current mess to where it
> belongs. I don't care about the d-i guys, the DPL clearly said i should expect
> nothing of them (well, of a few of them), and fork d-i, so ...

But finger pointing will get no work done. Just annoy people.

>> If the kernel is split up then D-I not handling non-free will be a
>> release blocker and will be solved. I don't think compromising ideals
>> because D-I doesn't yet handle non-free is the right thing to do. It
>> is not like implementing this will take more than a weekend.
> Maybe, but without me stepping up, and pointing the finger to this problem,
> nobody would have cared, probably they would have been afraid to suffer the
> same treatement i got at their hands for daring mention those problems.

You are not stepping up. So far you are just pointing fingers. And so
far I haven't seen anybody care that didn't care already.

I care and I'm not afraid to suffer your treatment because I always
got the treatment that I deserve from the D-I team and to some extend
so did you before it escalated out of all bounds.

> Friendly,
> Sven Luther


Reply to: