Re: broadcom proposed firmware licence, please comment ...
Taking off debian-legal, since this is so not legal discussion anymore.
Andres Salomon wrote:
> > I think they said they'd accept a patch which loaded the firmware but fell
> > back to firmware built into the kernel if it wasn't present, as a
> > "transitional" requirement. Ugh squared. But I can do it; I can even do
> > it in such a way that the tg3 patch to the kernel would consist of a
single
> > file deletion.
>
> Are they looking for a transition, or are they just looking for proof that
> the firmware loading will actually work? Transition code doesn't sound
> overly useful to me.
They said they were looking for a transition. (And I agree, it doesn't sound
that useful to me either.)
I believe, however, that the idea was to avoid causing difficulties for people
who didn't know where to find the firmware or how to install it. If the
kernel installation files were changed to properly install firmware files in
the right place per default, that would likely satisfy them. (I can
integrate my generate-binary-firmware-file-from-hex code into the kernel
patch if this sort of solution is desired.) Fixing up the installation files
is just a little bit beyond what I'm personally willing to do at the moment,
though, since I haven't yet figured out the kernel installation file system.
So someone else would have to write that part.
If anyone's volunteering to do so :-), I believe we'd decided that the "right
place" was:
/usr/lib/hotplug/firmware/tg3/5701_a0-0.0.0
/usr/lib/hotplug/firmware/tg3/tso-1.4.0
/usr/lib/hotplug/firmware/tg3/tso_5705-1.1.0
(This forms the beginnings of a namespace and conventions for loadable
firmware files, and is where my existing code puts them.)
> Keep in mind the patch we'd have would have to simply readd the tg3
> driver; the patch can't delete the file.
Oh, what I was thinking was this:
(1) reorganize the upstream kernel driver so that the included firmware was in
a separate file (#included, for instance), as is done in most such drivers
(2) include the firmware loading code upstream
(3) Debian's tar.gz.orig simply omits the firmware-containing file
(4) The patch simply removes the references to it in the driver file
> As such, it would still need to
> be maintained (although shouldn't be too complex, as long as it doesn't
> include firmware loading features and such).
Reply to: