seconds searched for override of resolution 007 needed. (Was: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.)
Hello,
Ok, since the proposal in its amended by Manoj form passed, we need to add an
amendment to this proposal, accordying to Manoj, so that we don't have two
proposals in effect at the same time, leaving it a full mess.
So, i propose this amendment, as discussed with Manoj, and need your seconds
on this one too.
=== START OF PROPOSAL ===
Definition: For the purpose of this resolution, the "firmware" mentioned below
designates binary data included in some of the linux kernel drivers, usually as
hex-encoded variables and whose purpose is to be loaded into a given piece of
hardware, and be run outside the main memory space of the main processor(s).
0. This resolution overrides the resolution just voted
(http://www.debian.org/vote/2006/vote_007).
1. We affirm that our Priorities are our users and the free software
community (Social Contract #4);
2. We acknowledge that there is a lot of progress in the kernel firmware
issue, both upstream and in the debian packaging; however, it is not
yet finally sorted out.
3. We give priority to the timely release of Etch over sorting every bit out;
for this reason, we will treat removal of problematic firmware as a
best-effort process, and in no case add additional problematic material
to the upstream released kernel tarball.
4. We allow inclusion of such firmware into Debian Etch, even if their license
does not normally allow modification, as long as we are legally allowed to
distribute them.
5. We further note that some of these firmware do not have individual license,
and thus implicitly fall under the generic linux kernel GPL license.
We will include these firmware in Debian Etch and review them after the
release. Vendors of such firmware may wish to investigate the licensing
terms, and make sure the GPL distribution conditions are respected,
especially with regards to source availability.
6. We will include those firmware into the debian linux kernel package as well
as the installer components (.udebs) used by the debian-installer.
==== END OF PROPOSAL ====
Only change, is the addition of clause 0. which states the override. I am not
totally satisfied by this text, so if someone has a better idea, it would be
nice.
Friendly,
Sven Luther
On Sat, Oct 07, 2006 at 06:49:17AM +0200, Sven Luther wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello, ...
>
> Since there seems nobody objected to the proposal, and the few returns i had
> were mostly positive, i am now making the following proposal.
>
> I will add below the original rationale of Frederik's proposal, on whom
> this one is based, as well as the position statement of the kernel team, which
> emerged from the irc meeting from last saturday about this issue, and which is
> reflected in the below proposal.
>
> For the secretary : The proposal is only the part between the two below
> START/END OF PROPOSAL markers :)
>
> === START OF PROPOSAL ===
> Definition: For the purpose of this resolution, the "firmware" mentioned below
> designates binary data included in some of the linux kernel drivers, usually as
> hex-encoded variables and whose purpose is to be loaded into a given piece of
> hardware, and be run outside the main memory space of the main processor(s).
>
> 1. We affirm that our Priorities are our users and the free software
> community (Social Contract #4);
>
> 2. We acknowledge that there is a lot of progress in the kernel firmware
> issue, both upstream and in the debian packaging; however, it is not
> yet finally sorted out.
>
> 3. We give priority to the timely release of Etch over sorting every bit out;
> for this reason, we will treat removal of problematic firmware as a
> best-effort process, and in no case add additional problematic material
> to the upstream released kernel tarball.
>
> 4. We allow inclusion of such firmware into Debian Etch, even if their license
> does not normally allow modification, as long as we are legally allowed to
> distribute them.
>
> 5. We further note that some of these firmware do not have individual license,
> and thus implicitly fall under the generic linux kernel GPL license.
> We will include these firmware in Debian Etch and review them after the
> release. Vendors of such firmware may wish to investigate the licensing
> terms, and make sure the GPL distribution conditions are respected,
> especially with regards to source availability.
>
> 6. We will include those firmware into the debian linux kernel package as well
> as the installer components (.udebs) used by the debian-installer.
> ==== END OF PROPOSAL ====
>
> Rationale:
> ==========
>
> Overview:
>
> The Linux kernel source contains device drivers that ship with firmware
> files provided by the hardware manufacturer. They are uploaded during
> the driver initialization to the corresponding hardware device.
>
> Some of these binary image files are provided as a hexdump of register
> bank settings, others consist in fact of compiled binary code which is
> executed on the hardware device.
>
> Any device driver in the Linux kernel is freely available in source=
> format and licensed under the GPL2. For many device drivers with
> attached firmware, the firmware image is freely distributable along
> with the corresponding driver. The most common source format for
> firmwares is the hexdump char array. It is almost impossible to
> distinguish between register dumps and binary code without asking the
> device manufacturer who provided the firmware.
>
> Removing every firmware which is distributed as hexdump only will
> cripple the kernel to an extent where it becomes unusable for most of
> our users, because popular network and scsi devices are among the
> drivers in question. Without these drivers, the user's system might not
> be installable at all.
>
>
> The current situation:
>
> We achieved a lot of progress compared with the situation in 2.6.8 (the
> kernel that shipped with sarge). We were able to convince upstream that
> a firmware loader is a good thing, and that firmware and kernel code
> should be separated. This firmware loader was added in 2.6.13, and
> meanwhile, more than 40 drivers have been converted to the new
> infrastructure. However, this is not yet finished, and some important
> drivers still use the old method. There will be a day where we can drop
> the remaining legacy, but we are not there yet.
>
> Also, though the firmware loader allows us to put the firmware where it
> belongs to (main or non-free, depending on the case), the installer can
> as of now only take udebs from main. Fixing this is not too hard, but
> it is doubtful whether we can fix this in time for etch, and we do not
> want to depend on that (and even then, we still would have non-free
> firmware, see above). But since there is lots of hardware which needs
> firmware for correct operation, the installer would not work for
> mainstream hardware otherwise.
>
> There are two ways how to deal with it:
> 1. Accept these issues as transitional issues for now; or
> 2. Delay etch for some serious time.
>
>
> In our social contract, we promised that the users and the free software
> community are our priorities. We firmly believe that our users profit
> very much from releasing etch in time, and that this is important enough
> that we can accept the transitional status with having a few firmware
> images left in main that should belong somewhere else. Of course,
> everyone who wants to make the number of such firmware images as small
> as possible is welcome to help converting old firmware loaders to the
> new standard, and working on the Debian installer. We are happy if this
> issues become smaller or even vanishes, but we do not want this to be a
> release blocker.
>
> Kernel Team statement of position :
> ===================================
>
> 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 dabusb, dgrs, 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.
>
> Thanks :
> ========
>
> Thanks go to Frederik Schueler for helping draft this proposal, as well as for
> MJ Ray and Manoj Srivastav, who helped with the english spelling, to Jurij Smakov,
> for drafting the kernel team position statement, to Anthony Towns, Frans Pop and
> Andreas Barth who read the proposal and publicly stated it was fine with them,
> to all those participating in the original drafting of Frederik's proposal,
> to all the proposer of other proposals as well as all those having
> participated in the discussion, and thus helped mature this proposal, and
> finally to all those having read all those numerous posts on -vote, even
> though they didn't actively participate in the discussion.
>
> Friendly,
>
> Sven Luther
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFFJzFH2WTeT3CRQaQRAu8mAKCZl6c+OL3QxHnPCf5xccrUBUjInwCePuct
> srZa72HVJrcuaVlyEPB3c0E=
> =i8Tx
> -----END PGP SIGNATURE-----
>
>
> --
> To UNSUBSCRIBE, email to debian-vote-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
> ---------------------------------------------------------------------------------------
> Orange vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
Reply to: