Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther <sven.luther@wanadoo.fr> writes:
> On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote:
>> md@Linux.IT (Marco d'Itri) writes:
>>
>> > On Aug 04, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
>> >
>> >> >>think not? Prove it by proposing a GR. More importantly, the release team
>> >> > I had such a plan, but no time to implement it currently.
>> >> How do you handle the fact that it is a license violation making the
>> >> thing illegal to distribute?
>> > I see that the lawyers of SuSE and Red Hat do not believe this to be
>> > true or at least do not consider it a problem, and this is enough for
>> > me to ignore the opinion of the debian-legal@ armchair lawyers.
>> >
>> > --
>> > ciao,
>> > Marco
>>
>> I hope you do believe this to be true. Otherwise you would need to go
>> back to NM and do the licensing section again. There can be no doubt
>> that binaries without source or even a "DO NOT DISTRIBUTE" notice
>> break the GPL.
>
> No, because those are not linked together with the GPLed code, but are a mere
> aggregation of works inside the same media, i.e. the binary file. Those
> non-free firmware will never run inside the same memory space as the kernel,
> and are offloaded to a peripheral processor, and the communication media
> between the kernel and this peripheral processor running said firmware is
> clearly defined, there is no doubt that those non-free firmware do not break
> the kernel GPL.
They are linked in, they have symbols, the code directly references
their address. Can you name one tool that will easily remove such
"aggregated" code from the kernel image? And we aren't just talking
about firmware here. There are header files and even C source files
with issues in the vanilla kernel.
I agree with you that firmware included in a kernel deb that gets
loaded with the firmware loader just an aggregation. But that is not
the issue here.
And even for an aggregation of works the DFSG holds and you are still
in trouble.
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.
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?
If I put the non-free library into an external plugin and (optionaly)
dlopen it then I have a completly different story.
> The second case is easier, we have simply to remove the non-free firmware, and
> put it in non-free, and/or remove completely the non-free driver and put it in
> non-free. In the case of modules vital to boot the machine we are trully
> screwed here, and by some of ourselves even.
>
> The problem is that the installer people, who where told repeteadly by me and
> others about this issue since over 6 month, and should have worked on enabling
> the installer to load .udebs from multiple apt/anna sources and not just one,
> thus enabling to place those non-free .udebs into a separate non-free .udeb
> archive, and solve this problem neatly.
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.
> But then, the d-i team, has prefered to ignore this issue, shot the messenger,
> and go into kicking out, witch hunts and diffamatory tactics in order to not
> face their own lack of vision and inadequateness, in the same way as their
> reaction to the kernel module .udeb proposal was over-agressive and now leaves
> us in mostly the same situation as we where at the sarge release time, with
> the d-i team incapacity to handle kernel abi bumps and security upgrades in a
> timely fashion.
One problem is that you keep banging on the door, where the watchdog
barks at you and the armed guards won't let you in. Try the window or
the backdoor. Change your approach.
Personaly I think the only way to get D-I to use non-free udebs is to
first have some. Preferably something essential. The harddisk driver
or network driver of Bastians or Joeys system would be perfect. Since
we can't convince the developer to implement this feature for its own
merit lets create some desperate need for it.
> So, i don't believe there is much choice left to the kernel team in this issue
> but to ask for a waiver of the DFSG compliance for the kernel for etch, and
> hope the d-i folk take their responsabilities a bit more seriously for the
> etch+1 release.
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.
> Friendly,
>
> Sven Luther
Reply to: