Bug#390994: linux-2.6: e100 microcode: distributable with BSD license, but license not in Linux source

[Sven Luther <sven.luther@wanadoo.fr>]

On Wed, Oct 04, 2006 at 04:08:02AM -0400, Nathanael Nerode wrote:
> Package: linux-2.6
> Severity: serious
> Justification: copyright
> 
> OK.  So the e100 microcode situation isn't as bad as we expected -- thanks entirely
> to OpenBSD.

Can you check that those binary blobs are indeed bit-to-bit identic ? 

> I'm opening this bug to track this issue because I expect it will be resolved relatively
> quickly, and because the 'big bug' is getting to be way too much.
> 
> There are three different bundles of microcode:
> /*  Micro code for 8086:1229 Rev 8                      */
> ...
> #define D101M_B_RCVBUNDLE_UCODE \
> 
> This is present in OpenBSD, in 
> http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2&content-type=text/plain
> under a 3-clause BSD license.  Under the same name.
> 
> /*  Micro code for 8086:1229 Rev 9                      */
> ...
> #define D101S_RCVBUNDLE_UCODE \
> 
> This is present in OpenBSD, in 
> http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2&content-type=text/plain
> under a 3-clause BSD license.  Under the same name.
> 
> /*  Micro code for the 8086:1229 Rev F/10               */
> ...
> #define     D102_E_RCVBUNDLE_UCODE \
> 
> This is present in OpenBSD, in 
> http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2&content-type=text/plain
> under a 3-clause BSD license.  Under the same name.
> 
> It's worth noting that OpenBSD has substantial additional downloadable microcode in that
> file.
> 
> The copyright problem will be fixed as soon as the proper copyright notice and license
> from OpenBSD's copy is added to Debian's copy.  Simple and excellent.  :-)  Thanks
> OpenBSD!
> 
> However, the microcode is still non-free (lack of source).  Conversion to userland
> firmware loading should be done (and I might even get around to it myself).  If
> this is done, I strongly advise that the *same format* and *same filenames* be used
> as in OpenBSD, so that the firmware files are interchangable; no point in deliberate
> incompatibility.

Indeed. Do you agree that we can do this post-etch, as the current GRs propose ? 

Fact is d-i will not have support for non-free firmware in etch, which means
qlogic will be unsupported, and any such firmware we move out is in the same
case. Frans's "No way" and corresponding statement from Joey Hess make this
rather a definitive situation.

Friendly,

Sven Luther