Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Joe Smith wrote:
> "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.
Probably less. The people who disagree with this interpretation are
contradicting the plain text of the GPL, ignoring copyright law, ignoring
the stated intent of the drafters of the GPL and the FSF, etc.
As I said, the distributors of this unlicensed material probably *intended*
to give it a proper distribution license. Should Debian rely on the
assumption of good intentions? Debian doesn't do that for copyright issues
in *general*.
> 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.
Yes, we do. bluez-firmware and atmel-firmware.
> Obviously if the infrastucture is not there, that should be fixed.
It's there except for d-i.
> 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.
Right.
> 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.
That's all correct.
> So the question I have is how long would etch need to be delayed to add
> support for non-free firmware to D-I?
Joey Hess estimated 6 months work, but that was to implement a whole bunch
of uncommon special cases. I think it is totally unnecessary to implement
all, or even any, of those.
http://lists.debian.org/debian-vote/2006/08/msg00122.html
For (2) from that post, which is the key sticking point for d-i, it needs to
be done anyway, and honestly should not take more than a month if someone
bothers.
So -- point me to the correct parts of the installer. I don't know where to
find this "anna". libdebian-installer I'm looking at -- it would be a great
help if someone could direct me to the part of the code which loads udebs
from disk/network, because I can't find it. Is that all in 'anna', which I
can't find? :-/ If I can't find the source code for 'anna', I can't fix
it.
(3) is trivial and simply requires the will to fix RC bugs.
(4) is frankly not nearly as important as Joey makes it out to be. It is
very unlikely that someone will have a machine where *both* the CD *and*
the NIC *and* the floppy drive if present *and* the USB driver (USB key)
need non-free firmware.
As long as there is one piece of hardware with fully free drivers which can
be used to load the additional non-free material on the machine, it is
perfectly tolerable that an alternate piece of hardware is not so
supported. (I've seen systems where the NIC needed non-free firmware
downloaded and ones where the CD did, but never ones where both did.) I
know it's theoretically possible that someone will buy a "hell machine"
where every single peripheral requires a non-free firmware download -- but
it's unlikely. And if that happens, they can still use the hard drive
method or master their own CD.
> 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.
--
Nathanael Nerode <neroden@fastmail.fm>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
Reply to: