Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
"Sven Luther" <email@example.com> wrote in message
[🔎] 20060830073254.GA30412@powerlinux.fr">news:[🔎] 20060830073254.GA30412@powerlinux.fr...
On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote:
On Aug 30, Nathanael Nerode <firstname.lastname@example.org> wrote:
> Debian must decide whether it wants to ship BLOBs with licensing which
> technically does not permit redistribution. At least 53 blobs have
> problem. Many of them are licensed under the GPL, but without source
> provided. Since the GPL only grants permission to distribute if you
> provide source code, the GPL grants no permission to distribute in
Many people disagree with this interpretation.
A few very vocal people do. I guess they can be counted on the fingers of
hands or so.
I think everybody can agree that it would be clearer if the blobs used a
licence that clearly allows distribution without requiring source.
In the case of the GPL that is definately not clear.
About the main issue:
As I see it, there are three possible catagories for drivers using firmware
that all drivers should ideally fall into assuming the driver part is free
1. Module and firmware in free. (The firmware can be compiled into the
module, or can be loaded from a file.)
2. Module in free, firmware in nonfree, loaded from file by driver. [One
could argue that the modules belong ion contrib, unless the firmware is
optional (perhaps allowing access to non-essential features)].
3. Module in non-free. [Firmware compiled into module, has not yet be
seperated into seperate file. This is acceptable, but many of these could be
converted to type 2 if somebody puts in the work].
I know we have some modules of type 1. I'm pretty sure we have some modules
of type 3. It has not been clear to me if we currently have any modules of
Obviously if the infrastucture is not there, that should be fixed.
Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3
modules. This can definately be fixed, but doing it for etch could delay
Besides all of that we have quite a few modules with problematic licences.
Generally the licence problem is on the firmware, although some might affect
rest of the driver. Some are type-3 style (firmware hard-coded into module,
firmware lacking source.)Many of those could be shipped as type-3 modules if
licence clarification can be obtained (or preferable: relicencing). A few
are type-2 style, they could be shipped as type-2 if proper clarification
can be obtained.
The above is a rough summer of the problems as I understand it. Please
correct be if I am wrong.
So the question I have is how long would etch need to be delayed to add
support for non-free firmware to D-I?
We could also push back the freeze on the kernel by the same amount and have
some people work on obtaining clarification on some of the problematic
With the combination of those two we could end up with having very few
drivers not ship, and all shipped drivers both free and non-free be usable
While pushing Etch back is a big deal, it almost seems to me that some of
the proposed GRs are an even bigger deal, and, as has been pointed out, the
GRs would probably only make a difference for a small number of modules,
unless we ignore the problematic licencing of most of the remaining drivers.