Re: firmware blobs
On Wed, Aug 16, 2006 at 11:32:57AM -0700, ldoolitt@recycle.lbl.gov wrote:
> 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.
Ah, it has been argued, that since the driver depends on the firmware to work,
it should then go to contrib, but not stay in main, so moving the whole stuff
to non-free is lightyears easier to handle, and you don't need to do the
source-code modification work to remove the firmware.
> > 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.
So ? As said, people where saying that we were fools to ask such from
broadcom, given their non-free-software attitude and all, and they were rather
helpful and after some lengthy discussion and consulting of their legal
department, they agreed to change the licencing, so it is no more defacto
GPL2 (altough it remains non-free, but at least it is distributable).
The main problems are those drivers where the copyright author is lost.
> > 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.
Hehe, but this public list is probably the best place to handle such stuff,
since we are a maintainer team.
Friendly,
Sven Luther
Reply to: