-----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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
