Re: firmware blobs
Sven -
On Wed, Aug 16, 2006 at 08:00:26PM +0200, Sven Luther wrote:
> Thanks for this report, it is nice to see someone actually contributing useful
> information instead of just complaining :)
Quoting from the Beatles: "You say you want a contribution,
well, you know, we're all doing what we can."
> > Unless something changes soon, we're looking at 59 RC bugs
> > in the linux-2.6 source package. The good news (AFAICT) is
> Well, i think a single RC bug with info about all of them would be
> enough.
If the kernel maintainers agree to rip them all out at once,
I agree. If they want to "fix" them one-by-one, we need 59
independent bugs filed.
> > that ripping these non-SC-conforming files out of the kernel,
> Well, i think it would be easier to move the whole drivers to non-free, this
> is the way we have been doing this until now at least.
Whatever. I'm neither a kernel maintainer, nor a firmware-nonfree
maintainer. I see firmware, but no drivers, in firmware nonfree.
I see two advantages to finally having a driver in the kernel
without its firmware: (1) this can improve the legal situation
of upstream. (2) it keeps the architecture-dependent and
toolchain-sensitive stuff in one set of .debs (linux-*.deb),
while the firmware-nonfree .deb is architecture independent.
Otherwise, the firmware-laden modules end up with a pseudo-duplicate
of the kernel's fancy build system.
Finally, moving drivers to non-free only helps for the 12 files
that are BSD-ish. The 44 GPL-ish files _have_ to have their
firmware separated out.
> BTW, if you have some time, and feel like doing it, could you identify the
> copyright holders on the non-distributable parts of it ? It would make asking
> them to clarify the licencing easier that way, as we already did for broadcom
> and the ql-thingies.
This is a big job, and unlikely to have much success. I actually
tried on two of them (drivers/net/myri_code.h and
drivers/media/dvb/ttusb-budget/dvb-ttusb-dspbootcode.h). In both
cases, the manufacturer supplied hardware, documentation, and otherwise
cooperated with the driver development. So the intent is (probably)
there, but there is no known paper trail that would authorize redistribution
of the copyrighted material.
> Nice, but there is lengthy and non-negligible d-i work which needs to be done,
> and as they want to freeze pretty early ...
I already emailed Frederik Schueler, suggesting that the offending
code get ripped out of 2.6.17 before its upcoming migration to testing.
- Larry
Reply to: