Bug 1389253

(In reply to mejiko from comment #0)
> Hello.
> 
> linux-firmware included non-free firmware.
> Please see WHENCE file.
> 
> 
> non-free firmware list :

It is confusing to use the term "free" here.  Very very little of the binary firmware distributed in Fedora falls under any sort of free definition.

> <LIST START>
> 
> 
> Unknown:
> 
> snd-maestro3
> snd-ymfpci
> snd-korg1212
> dvb-ttusb-budget
> emi62
> ti_usb_3410_5052
> ip2
> vicam
> cassini
> acenic
> qlogicpti
> myri_sbus
> lgs8gxx

Most of these that were derived from the kernel-source are fine.

> non-distributable (non-free):
> 
> smctr
> io_ti
> yam
> 3c359

These are fine.  They have no explicit disallowment of redistribution, only that they are licensed for use with the various hardware components.  

> Questionable:
> 
> ambassador
> 
> Reason: This license is GPLv2. but no source code. (If binary distribute
> with or without modify, GPLv2 require publish source code)
> and more restriction apply. This is GPL incompatible.

This one is odd.  It's putting the _data_ under the kernels of the GPL, not the source.  The GPL isn't really a data/content license, but there is nothing specifically wrong with the license usage as it is specified.

> keyspan, slicoss, sxg
> 
> Reason: This license is "OS specific", I think. (Is this restriction is OK ?)

These are fine.

> ti_usb_3410_5052, whiteheat, cpia2, io_edgeport, snd-sb16-csp, starfire,
> smc91c92_cs, snd-wavefront
> 
> Reason: This license status is unclear. (Is there really licensed under
> GPLv2 ?) 
> and no source code. (If there firmware license is GPLv2, and If binary
> distribute with or without modify, GPLv2 require publish source code, I
> think)

These all are found originally in kernel-source.  They're fine.  The comments about "Alledgedly GPLv2" do not mean they are GPLv2 licensed.

> serial_cs
> 
> Reason: Where is source code ? (This license is GPLv3)

It's in the linux-firmware git repo (the .cis files) and the tool to compile it is at http://git.kernel.org/cgit/utils/cis-tools/cis-tools.git

> <LIST END>
> 
> 
> I suggest that resolve license problem.
> Thanks.

I don't really see any problems.  I'll leave the bug open for a bit for FE-Legal to weigh in.

This is all fine. As your reference link points out, the one compromise Fedora makes is for Binary Firmware. We wish we didn't have to make it, but at this point in time, we do.

(In reply to Josh Boyer from comment #1)
> > ambassador
> > 
> > Reason: This license is GPLv2. but no source code. (If binary distribute
> > with or without modify, GPLv2 require publish source code)
> > and more restriction apply. This is GPL incompatible.
> 
> This one is odd.  It's putting the _data_ under the kernels of the GPL, not
> the source.  The GPL isn't really a data/content license, but there is
> nothing specifically wrong with the license usage as it is specified.

Er... the GPL doesn't distinguish between code and data, really.

The only difference between the two is the practical answer to the question  "what is the preferred form for modification?".

For stuff that's *genuinely* data, like a sequence of register values to load, you could argue that a simple array of numbers is indeed the preferred form for modification. (Although try submitting those without suitable #defines and comments in a driver, and tell me that it's really "preferred".)

For something that is actual code that runs on a CPU, it's even harder to argue that pretending it's "data" and having an array of numbers is really the preferred form for modification. That's just sophistry.

Although having said that, the GPL doesn't explicitly state for *whom* it must be the preferred form, and what drugs they may be on at the time. :)