Re: Dealing with drivers that need firmware on the filesystem
Craig Sanders dijo [Sun, Jan 09, 2005 at 05:28:23PM +1100]:
> it's worse than just putting them in contrib. there's a whole bunch of
> drivers with firmware blobs that have just been deleted from the kernel
> sources. they're not in contrib, they're not in non-free, they're just gone.
>
> this affects even DFSG-free drivers with DFSG-free patches. you often can't
> apply the patches to the debianised kernel sources because the context that
> the patch needs is missing.
>
> e.g. try downloading the patch[1] for DVICO Fusion DVB-T card's DFSG-free
> driver and applying it to the kernel source from any kernel-source-x.x.x
> package. it won't apply to the debian kernel, yet it applies without a
> problem to pristine sources downloaded from kernel.org.
> (...)
If you are patching a kernel, you should patch a pristine kernel.org
one - I am sure this will also fail to work with any distribution's
kernels. You know, not only we have a butcher knife on our hand. Most
distributions ship with a modified kernel.
Now, if the patch is DFSG-free as you say, it should not be impossible
for you (and I do mean _you_, a DD that cares about this particular
driver) to patch the patch so it applies on Debian's tree as well,
even probably include it in Debian... Or if introduces no ill side
effects, propose it to be included either in the upstream Linux kernel
or in Debian's kernel packaging.
But even then, people who patch their kernels are expected to be able
to download a kernel.org one.
> debian has forked the kernel (and not for any sensible or useful reason - just
> to satisfy some extremist ideologues), and it is already causing problems for
> us and our users. it is also making debian an object of scorn and ridicule by
> kernel hackers (and deservedly so).
...Extremist ideologues that happen to share their point of view with
most of the DDs. I know this makes you terribly unhappy, but this
thread has shown that a majority of DDs agree with the extremist idea
of defending software freedom.
> > We /could/ put non-free firmware in main, on the grounds that while it
> > is in many cases executable code, it does not execute on any processor
> > that is under the direct control of the operating system. This would
> > possibly require a small alteration to the social contract. A result
> > of this would be that not everything in main would be DFSG free.
>
> IMO, this is the correct approach at least for stuff in the standard kernel
> source tree. from the kernel's POV, it is not code, it is just data that gets
> uploaded to a peripheral device[1]. the firmware blob is included in
> GPL-licensed code and is also GPL. it's no more "non-free" than
> pre-calculated lookup tables in programs like gzip and bzip, or the CSS data
> in decss and related programs.
Yes, but we do hold some promises regarding _all_ of main: We can fix
bugs. If we ship this firmware as part of main, we would be expected
to be able to fix it. I am not among those who require the original
sound samples or vector files for every audio or graphic file we ship,
as they can still be altered in the format we have them in... But we
would not be able to keep our quality standards if we allowed non-free
firmware in main.
Greetings,
--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Reply to: