[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



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.

There is a problem, as was the case for some of the firmware we where
distributing, like the tg3 one, where there was no explicit licence for the
firmware hexdump, and as thus, it was defacto placed under the GPL, and this
means it is indeed undistributable.

But this can easily be solvev by approaching those upstream guys and fixing
the licencing issue with them, and before you all laugh about such an idea,
this was done by Andres Salomon and me and a few others for such firmwares as
the tg3 one from Broadcom, and they indeed did clear up the licencing.

> As to being a problem that depends if anyone ever sues, which is
> indeed unlikely.
> 
> But Debian has also made a promise that main will be free. And the
> kernel breaks that.

Indeed, and that is the problem here. We have two cases, first, there is the
firmwares without source placed (by author's ignorance usually) under defacto
GPL and undistributable, this we have to remove from both main or even
non-free, and go the author contacting route (except in some cases, the
copyright holder has been multiple-times bought up, and the new owner doesn't
care, and everyone is screwed).

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.

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.

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.

Friendly,

Sven Luther



Reply to: