Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote:
> 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
i guess objdump would do it, from most of these cases, the only symbol
involved is the position of it in the code, and the incrimated code is just a
binary hexdump contained in a single variable + size.
> "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.
Well, we are speaking about "firmware hexdumps", i don't know about the others
you are referencing, but if there are other suchs, please list them
explicitly. And no, a separate header file containing just this single
variable doesn't count.
> 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.
What is then ?
> 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.
> 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.
If you follow the FSF FAQ about the GPL, you will see that there are a certain
amount of criterias which apply here, among them the separate memory pool/area
one, as well as the well defined communication interface, which is clearly
respected here.
So, altough IANAL, i believe without doubts that we are not seing a GPL
violation here, and that the non-free firmware and the linux kernel are mere
aggregation. After writing this to LKML last year, i also contacted the FSF
legal counsel, and altough they didn't give a supportive analysis of this,
there was no strong outcry either. Not sure what this means.
I believe i got the consensus of debian-legal behind me on this one, as you
would see if you consulted the archives, and the broadcom, and QL-something,
legal team, also found this analysis reasonable and changed their tg3 and
ql-something licencing accordyingly.
Also, if you really want to argue the other way, you will end up in a world of
trouble, and will end not being able to run linux on any box around i know.
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.
> 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 ...
I know we all dream of such a world, but we are far-far-far from it.
> If I put the non-free library into an external plugin and (optionaly)
> dlopen it then I have a completly different story.
Nope, because it is just software, while the firmware in question, can in
those days of fpga's and flash firmware, be considered as part of the
hardware. Its still non-free though, but debian doesn't distribute hardware,
so we don't need to worry for it.
> > 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.
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 ?
> > 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.
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 ...
> 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.
Yeah, well, i was threatened by Frans to not work on any d-i/kernel related
issues, so ...
> > 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.
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.
Friendly,
Sven Luther
Reply to: