[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The bigger issue is badly licensed blobs (was Re: Firmware poll




"Sven Luther" <sven.luther@wanadoo.fr> 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 <neroden@fastmail.fm> wrote:

> Debian must decide whether it wants to ship BLOBs with licensing which
> technically does not permit redistribution. At least 53 blobs have > this > problem. Many of them are licensed under the GPL, but without source > code
> provided.  Since the GPL only grants permission to distribute if you
> provide source code, the GPL grants no permission to distribute in > these
> cases.
Many people disagree with this interpretation.

A few very vocal people do. I guess they can be counted on the fingers of both
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 type 2.
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 release.

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 the 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 licences.

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 during installation.

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.





Reply to: