Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote:
> 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.
Please read last years discussion on debian-legal where this was exposed in
detail, and a consensus was found which i reflect in my position here.
Think of the case of a windows compression program which produce binaries with
builtin uncompressor binaries.
What you claim is that using those (winzip and co) to compress the linux
kernel source would break the GPL, because they are physically housed in the
same binary.
> >> 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.
Notice that i am not arguing that the firmware is not non-free and doesn't
break the DSFG, but that the firmware is not a derived work of the linux
kernel, just aggregated on the same distribution media (the linux binary
file), i think you are seriously confusing the two in your above
argumentation. The first makes the firmware unfit to be in main, while the
second is a GPL violation of the kernel source, and forbids all distribution
of it.
> > 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.
Indeed. It is non-free, and the problematicness of the licencing has been
solved. It is an out-of-tree module though, so not something to worry about in
this case.
> >> 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.
Ah, again you are confused. We are not discussing the DFSG-freeness, but the
violation of the GPL of the kernel here. Two totally separate matters, please
read the debian-legal argumentation of last year about this issue in order to
clarify your comprehension of this issue.
> 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.
Indeed. but when you mention GPL violation, it means that you are not allowed
to distribute the whole linux kernel, even in non-free.
> >> 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
Why ? i am only stating facts, and they banned me of the d-i team for daring
toeven mention some of the d-i fallacies like this one.
> writing a patch. You've done D-I work before so maybe you even looked
> at libd-i source before.
I do have, but that is beside the point.
> > 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.
It will not allow anyone to forget the issue and believe that everything is
fine, indeed.
> >> 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 am forbidden to do kernel/d-i related work by Frans who threatened me on irc
about it.
> 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.
Thanks a lot. I think nobody deserves to be threated like i was, but then in
this Frans has showed he is no better than Jonathan or Andrew, and i guess
that the above claim puts you in the same category, unless you are clueless
about what happened. Death and fatal sickness are not something to be taken
advantage of to fight a personal feud and use the oportunity to get ride of
people you dislike, and yet Frans did exactly that.
Friendly,
Sven Luther
Reply to: