With the conclusion of GR 2006-007[1], we now have a clear statement from the
Debian developers that it is acceptable to release etch with firmware that
does not meet our usual requirements for inclusion in main, subject to three
principal conditions:
1. the freedom of the kernel for etch will not be a regression relative to
sarge
2. the firmware needs to be in main to support installation of Debian on
certain hardware
3. the license of the firmware complies with the DFSG's requirements for
licenses, even though there may be no source code available for the work
and therefore the work does not meet the DFSG as a whole.
At the time the GR was proposed and seconded, it was generally believed that
this was sufficient to cover all firmware that needed to be shipped in main
for the installer's benefit, because all firmware that was relevant under 2.
was also allowed under 3. Unfortunately, discussion revealed that this was
not the case.
This email is therefore intended to clarify the release team's current
position on the consequences of the GR for kernel firmware in etch, for each
case currently under consideration.
Sourceless firmware under a BSD-style license
---------------------------------------------
Because the BSD license is a DFSG-free license, firmware in this group is
clearly permitted in main for etch. According to [2], this includes mga,
r128, radeon, and advansys firmware.
Sourceless firmware distributed under the GPL
---------------------------------------------
The GPL is also obviously a DFSG-compliant license, but much ado has been
made over the idea that sourceless, GPLed firmware is not covered by this GR
because it's not legal to distribute.
The release managers consider this a non-issue. There are only two
possibilities here: either it is legal to distribute this firmware, in which
case it is permitted in main by the GR; or it is not legal to distribute this
firmware, in which case no GR is sufficient to make such distribution
acceptable to the release team. There is no third option here that an
additional GR would help establish, because there's no point in the first
place of speculating about what voters *believe* is legal to distribute: it's
up to the maintainers and the ftp team to determine if a work is legal to
distribute, not the developers at large.
Neither the release managers nor the ftp masters believe that the sourceless
GPL firmware shipped with the kernel poses a legal problem for Debian. It is
true that such works appear to be inconsistently licensed, but we have a
reasonable belief that this constitutes a licensing bug on the part of the
copyright holder and not an indication of intent to prohibit redistribution.
It is in our long-term interest to get clarification regarding such licensing
bugs, but as with other licensing bugs where we have reason to believe the
*intent* was to provide us with a valid and useful license, such
clarification should not be a blocker for the release.
tg3, typhoon, and acenic firmware
---------------------------------
As mentioned above, it was discovered late in the process that three firmware
images included in the upstream kernel that are relevant to the installer are
not distributed under clearly DFSG-compliant licenses: tg3, typhoon, and
acenic. Of these, only typhoon was in sarge; tg3 and acenic had been removed
from the kernel and have since been readded.
The license on acenic is unclear. The upstream website does grant permission
to modify and distribute the firmware, and we have a separate statement that
permission was granted to distribute it "as part of the GPL driver." At the
same time, the upstream website also appears to place restrictions on use.
We do not believe that use restrictions are compatible with the spirit of the
GR that was passed, and we understand that an upstream license fix is
unlikely; and re-adding this firmware is a regression relative to sarge. We
recommend that the kernel team remove this firmware again for etch, but we
choose not to consider this RC.
The tg3 firmware was previously made available as a sourceless blob under the
GPL, which would be covered by the previous section above. More recently, it
has been distributed in the kernel under a license permitting redistribution
without permitting modification. While this is not explicitly permitted in
main by the GR that was passed, the release managers are confident that
including this firmware in main *would* be permitted by the developers if
asked, and therefore believe this firmware should be included in the kernel
for etch without any need for an additional, time-consuming GR. It is also
possible that the previous GPL grant is still in effect in addition to the
new clarified license, and we do not believe this question is of sufficient
importance to require further investigation prior to etch.
The typhoon firmware is the last installer-relevant driver that we are
allowed to distribute which is not made available under a license that
permits modification. This firmware was included in sarge, so including it
in etch is not a regression; and we again believe that the developers would
have voted to allow this in main for etch if we had known soon enough that
this is what we needed to ask for. We encourage the kernel team to accept
this firmware in the kernel package for etch without further deliberation on
debian-vote, so that our efforts can be focused on a successful etch release
and a quick resolution of the firmware licensing issues for etch+1.
Other sourceless firmware
-------------------------
Finally, there are a handful of firmware blobs in the kernel that are not
needed by the installer, and do not include source code except for a hex
dump. These are (cut-and-pasted from a previous list): dabusb, dgrs, emi62,
keyspan, smctr, cops, emi26, and 3c359. Some of these have licenses
permitting redistribution, in which case they can be included in non-free for
etch at the kernel team's discretion; some of them do *not* have licenses
which permit redistribution, which of course means we should not distribute
them. All of these must be removed from main for the etch release.
Conclusion
----------
In conclusion, we believe that GR 2006-007 has provided adequate guidance on
the firmware question such that no further GRs are needed for etch. The
biggest concern is a set of three firmware blobs for ethernet devices that
are not explicitly allowed by the passed GR... because we didn't know to ask
for it. We think that these edge cases are minor enough that shipping those
blobs in main is not RC, and we would ask the kernel team to join us now in
focusing on bugfixes for etch and planning support for non-free firmware in
etch+1, instead of losing more time in project-wide debates that produce no
code.
On behalf of the release team,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
[1] http://www.debian.org/vote/2006/vote_007
[2] http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html
Attachment:
signature.asc
Description: Digital signature