Hi,
This is how things stand:
The Situation: We are close to releasing Lenny
The Problem: The kernels we are shipping have blobs that might not meet
the DFSG, and some might be in violation of the kernel's
GPL license. This would put them in conflict with the SC.
The proposed solutions below all try to address the basic issue
of releasing while meeting the promises made in the SC. A new proposal
has been seconded, which extends the minimum discussion period by a
week (I think the relevant second came in at 14 Nov 2008 22:53:07).
If the proposers do not submit the wml that should go up as the
vote page, I'll make up the wording for the vote web page.
Here is the handy seconds registry. I hope I have recorded all
seconds, and recorded their sponsorship correctly, please let me know
if I have missed anything. (I have also simplified the summation
formula below)
|----------------------------------------------------+---+---+---+---+----+----|
| | 1 | 2 | 3 | 4 | 5 | 6 |
|----------------------------------------------------+---+---+---+---+----+----|
| Robert Millan <rmh@aybabtu.com> | 1 | 1 | 1 | | 1 | |
| Bas Wijnen <wijnen@debian.org> | 1 | | | | | |
| Manoj Srivastava <srivasta@debian.org> | 1 | 1 | | | 1 | |
| Holger Levsen <holger@layer-acht.org> | 1 | 1 | 1 | 1 | | 1 |
| Peter Samuelson <peter@p12n.org> | 1 | 1 | 1 | | | |
| Hubert Chathi <uhoreg@debian.org | 1 | 1 | 1 | | | |
| Andreas Barth <aba@not.so.argh.org> | | | | 1 | | |
| Alexander Reichle-Schmehl <alexander@schmehl.info> | | | | 1 | | 1 |
| Reinhard Tartler <siretart@debian.org> | | | | 1 | | |
| Bernd Zeimetz <bernd@bzed.de> | | | | 1 | 1 | 1 |
| Neil McGovern <neilm@debian.org> | | | | 1 | 1 | |
| Frans Pop <elendil@planet.nl> | | 1 | 1 | | | 1 |
| vanicat@debian.org (Rémi Vanicat) | 1 | 1 | 1 | 1 | | |
| "John H. Robinson, IV" <jaqque@debian.org> | | | | | 1 | |
| Lars Wirzenius <liw@liw.fi> | | | | | 1 | |
| Damyan Ivanov <dmn@debian.org> | | | | | 1 | |
| Colin Tuckley <colin@tuckley.org> | | | | | 1 | 1 |
| Pierre Habouzit <madcoder@debian.org> | | | | | 1 | |
| Gunnar Wolf <gwolf@gwolf.org> | | | | | 1 | |
| Peter Palfrader <weasel@debian.org> | | | | | | 1 |
| Russ Allbery <rra@debian.org> | | | | | | 1 |
| Martin Michlmayr <tbm@cyrius.com> | | | | | | 1 |
| Steve McIntyre <steve@einval.com> | | | | | | 1 |
| Mark Hymers <mhy@debian.org> | | | | | | 1 |
| Moritz Muehlenhoff <jmm@debian.org> | | | | | | 1 |
| Ben Pfaff <blp@cs.stanford.edu> | | | | | | 1 |
| Cyril Brulebois <kibi@debian.org> | | | | | | 1 |
|----------------------------------------------------+---+---+---+---+----+----|
| | 7 | 7 | 6 | 7 | 10 | 13 |
|----------------------------------------------------+---+---+---+---+----+----|
#+TBLFM: @29$2=vsum(@2..-I)::@29$3=vsum(@2..-I)::@29$4=vsum(@2..-I)::@29$5=vsum(@2..-I)::@29$6=vsum(@2..-I)::@29$7=vsum(@2..-I)
Since some people have had trouble reading the proposals, I am
including a short impact of the proposal list below the proposal.
,----[ Proposal 1: reaffirm the Social Contract ]
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
|
| 2. We acknowledge that we promised to deliver a 100% free operating system
| (Social Contract #1);
|
| 3. Given that we have known for two previous releases that we have
| non-free bits in various parts of Debian, and a lot of progress has
| been made, and we are almost to the point where we can provide a
| free version of the Debian operating system, we will delay the
| release of Lenny until such point that the work to free the operating
| system is complete (to the best of our knowledge as of 1 November 2008).
`----
i Do we require source for firmware in main: Yes
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Wait
iv Do we modify foundation documents: No
v Do we override foundation documents No
,----[ Proposal 2: allow Lenny to release with proprietary firmware ]
| 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; most of the issues that were outstanding at the time of the
| last stable release have been sorted out. However, new issues in the
| kernel sources have cropped up fairly recently, and these new issues
| have not yet been addressed;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the kernel distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);
| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat removal of sourceless
| firmware as a best-effort process, and deliver firmware as part of
| Debian Lenny as long as we are legally allowed to do so.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
This is a temporary override, so the SC need not be changed.
i Do we require source for firmware in main: No
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Release
iV Do we modify foundation documents: No
v Do we override foundation documents Yes
,----[ Proposal 3: (allow Lenny to release with DFSG violations ]
| 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 on DFSG compliance
| issues; however, they are not yet finally sorted out;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the packages distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);
|
| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat fixing of DFSG violations as
| a best-effort process.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
This is a temporary override, so the SC need not be changed.
i Do we require source for firmware in main: No
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Release
iV Do we modify foundation documents: No
v Do we override foundation documents Yes
,----[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ]
| Debian's priorities are our users and free software. We don't trade
| them against each other. However during getting an release out of the
| door, decisions need to be done how to get a rock stable release of the
| high quality Debian is known for, release more or less on time, and to
| minimize the usage of problematic software. We acknowledge that there
| is more than just one minefield our core developers and the release
| team are working at.
|
| We as Developers at large continue to trust our release team to follow
| all these goals, and therefor encourage them to continue making
| case-by-case-decisions as they consider fit, and if necessary
| authorize these decisions.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
This will need wording to change the SC, and the constitution,
since this is not a temporary override, but adds to the powers of the
delegates of the project leader.
i Do we require source for firmware in main: No
ii Do we allow the Release Team to ignore SC violation bugs: Yes
iii What do we do for Lenny: Release
iV Do we modify foundation documents: Yes
v Do we override foundation documents No
,----[ Proposal 5: allow Lenny to release with firmware blobs ]
| 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; most of the issues that were outstanding at the time of the
| last stable release have been sorted out. However, new issues in the
| kernel sources have cropped up fairly recently, and these new issues
| have not yet been addressed;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the kernel distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);
| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat removal of sourceless
| firmware as a best-effort process, and deliver firmware as part of
| Debian Lenny as long as we are legally allowed to do so, and the
| firmware is distributed upstream under a license that complies
| with the DFSG.
`----
i Do we require source for firmware in main: Yes*
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Release
iV Do we modify foundation documents: No
v Do we override foundation documents No
* This proposal gives the binary blobs distributed in the kernel
the benefit of doubt, and assumes they do not violate the GPL and are
the preferred form of modification, however unlikely that is.
,----[ Proposal 6: Exclude source requirements from firmware (defined) ]
| Firmware is data such as microcode or lookup tables that is loaded into
| hardware components in order to make the component function properly.
| It is not code that is run on the host CPU.
|
| Unfortunately such firmware often is distributed as so-called blobs,
| with no source or further documentation that lets us learn how it works
| or interacts with the hardware in question. By excluding such firmware
| from Debian we exclude users that require such devices from installing
| our operating system, or make it unnecessarily hard for them.
|
| Therefore the Debian project resolves that
| a) firmware in Debian does not have to come with source. While we do
| prefer firmware that comes with source and documentation we will not
| require it,
| b) we however do require all other freedoms that the DFSG mandate from
| components of our operating system, and
| c) such firmware can and should be part of our official installation media.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
This will need wording to change the SC, since this is not a
temporary override, but adds a definition of firmware, and an exclusion
from the 100% free promises of the SC.
i Do we require source for firmware in main: No
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Release
iV Do we modify foundation documents: Yes
v Do we override foundation documents No
manoj
--
Excusing bad programming is a shooting offence, no matter _what_ the
circumstances. -- Linus Torvalds, to the linux-kernel list
Debian Project Secretary <secretary@debian.org>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C