Re: New position statement on firmware
On Mon, Apr 13, 2009 at 05:53:22PM +0100, Ben Hutchings wrote:
> The current text at <http://wiki.debian.org/KernelFirmwareLicensing> is:
>
> > Debian kernel team identifies the following three types of firmware, currently
> > found in the Linux kernel:
> > 1. Sourceless binary blobs with no license, no explicit permission to redistribute, or
> > an explicit prohibition to redistribute.
> > This category currently includes the emi62, keyspan, smctr,
> > cops, emi26, and 3c359 drivers. Removal of these drivers will have minimal
> > impact on the users, as they are believed to be unpopular and not likely to
> > be required during the installation.
> > 2. Sourceless binary blobs distributed under GPL.
> > This situation has been interpreted as a violation of the terms of GPL, which
> > requires the distribution to be accompanied by the source code. Removal of
> > firmware in this category will cause effective removal of a large number of
> > important drivers, resulting in a severe negative impact on our users.
> > 3. Binary blobs violating DFSG for other reasons.
> > This category includes firmware which contains obfuscated source, or is not
> > allowed to be modified. While less numerous than category 2, removal of
> > drivers in this category will also have a significant negative
> > impact on our users.
> > It has been agreed within Debian kernel team, that the firmware in category 1
> > is not acceptable in Debian. It is the intention of the kernel team to prune the
> > affected drivers from the upstream tarball.
> > While we continuosly strive to improve the situation with DFSG-compliance of kernel
> > packages, and there has been progress on it since Sarge release, we recognize that
> > fixing all the problems with drivers falling into categories 2 and 3 is not feasible
> > in the etch release time frame. Alternative solutions, like removal of the affected
> > drivers would have a severe negative impact on our users, and would be detrimentary
> > to the Debian's goal of advancement of free software. Therefore, we propose to accept
> > the drivers from categories 2 and 3 in the kernel packages for etch, given that an
> > agreement can be achieved with release and ftp-master teams, or the issue is
> > resolved by way of General Resolution.
>
> This is clearly outdated in its reference to etch and lack of reference
> to the current approach using firmware loader and firmware-nonfree. I
> propose a new statement along these lines:
>
> The Debian kernel team identifies the following three types of firmware,
> currently found in the Linux kernel:
Thanks for working on this.
> 1. Sourceless binary blobs with no license, no explicit permission to
> redistribute, or an explicit prohibition to redistribute.
> This category currently includes the emi62, keyspan, smctr, cops,
> emi26, and 3c359 drivers. Removal of these drivers will have minimal
> impact on users, as they are believed to be unpopular and not likely
> to be required during installation.
> 2. Sourceless binary blobs distributed under GPL.
> This situation has been interpreted as a violation of the terms of
> GPL, which requires the distribution to be accompanied by the source
> code. This affects several important drivers.
> 3. Binary blobs violating DFSG for other reasons.
> This category includes firmware which contains obfuscated source, or
> is not allowed to be modified.
> It is the intention of the kernel team to:
This sounds more like a "plan" instead of a position statement. imo, a
position statement should be more along the lines of what we will
permit and what we won't, as opposed to what we are currently planning
to work on.
> a. Request relicensing of blobs in category 2
As a position, I would say something like:
Debian should work with the copyright holders of the blobs in category 2
categories 1 and 2,
> b. Patch drivers in categories 2 and 3 to load separate firmware
This might be more clear:
"Add driver support for loading the firmware from userspace and
provide packages for the firmware files in the non-free section of
the archive."
> c. Prune the blobs from the upstream tarball
Might be too jargon for non-dds, maybe:
"Remove the blobs from the source we redistribute"?
> d. Disable affected drivers in category 1, and in category 2 where
> relicensing is impossible
This is the one part where I have a different view - I don't see any
problem with enabling these drivers and adding request_firmware
support. We can't redistribute them, but users are free to way their
own legal risks and install these files from other sources. And to me,
that's no reason to force them to compile their own kernel.
Of course, I'm not saying that we should consider that work a
priority but, if provided with a patch (or one is inherited from
upstream), I don't see why we should reject it.
--
dann frazier
Reply to: