New position statement on firmware
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: 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: a. Request relicensing of blobs in category 2 b. Patch drivers in categories 2 and 3 to load separate firmware c. Prune the blobs from the upstream tarball d. Disable affected drivers in category 1, and in category 2 where relicensing is impossible Ben. signature.asc Description: This is a digitally signed message part
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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe.
Re: New position statement on firmware
On Mon, 2009-04-13 at 11:31 -0600, dann frazier wrote: [...] 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. That's true, but the original had this too. Let's change the title to Kernel team plan for handling sourceless firmware. [...] 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. I don't think our views differ significantly. 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. I agree there's no reason to reject patches. In cases where a driver depends on non-free firmware and cannot load it from a separate file at run-time then we disable it. It makes sense to prioritise any work we do based largely on popularity of the hardware and availability of the firmware to our users. I compressed that into the sloppy wording in (d) above. I agree with all your other proposed clarifications. Ben. signature.asc Description: This is a digitally signed message part
Re: New position statement on firmware
On Mon, Apr 13, 2009 at 07:21:02PM +0100, Ben Hutchings wrote: On Mon, 2009-04-13 at 11:31 -0600, dann frazier wrote: [...] 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. That's true, but the original had this too. Let's change the title to Kernel team plan for handling sourceless firmware. [...] 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. I don't think our views differ significantly. 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. I agree there's no reason to reject patches. In cases where a driver depends on non-free firmware and cannot load it from a separate file at run-time then we disable it. It makes sense to prioritise any work we do based largely on popularity of the hardware and availability of the firmware to our users. I compressed that into the sloppy wording in (d) above. I agree with all your other proposed clarifications. Ben. yep, me too. thanks for decrufting that old statement. -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
