On Fri, Oct 24, 2008 at 10:37:52PM -0500, Manoj Srivastava wrote: > > Nevertheless I would merge it in my proposal if you still want me to. > > If we must have a GR, I would feel better with these options on > the ballot.
Okay then. Here's the new ballot including your proposed options.
Option 1 (set an upper limit)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The developers resolve that:
When ever a package in Debian is found to have been violating the DFSG for
60 days or more, and none of the solutions that have been implemented (if
any) is considered suitable by the maintainers, the package must be moved
from Debian ("main" suite) to the Non-free repository ("non-free" suite).
The action of moving it may be performed by any of the developers (however,
moving packages in the "stable" distribution may still require approval by
the Release Team for "stable"). When this happens, any known DFSG violation
in the package must be resolved before the package can be moved back into
Debian.
(Since this option does not contradict SC #1, I believe it would only require
simple majority; please correct me if I'm wrong)
Option 2 (set an upper limit, make this part of the SC)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The developers resolve that the Social Contract shall be ammended as follows:
--- social_contract.wml 22 Nov 2007 03:15:39 -0000 1.23
+++ social_contract.wml 24 Oct 2008 14:54:30 -0000
@@ -31,6 +31,24 @@ the free software community as the basis
free and non-free works on Debian. We will never make the
system require the use of a non-free component.
</p>
+ <p>
+ In order to ensure continued compliance with this promise, the
+ following rule is to be followed:
+ </p>
+ <p>
+ When ever a package in Debian is found to have been violating the
+ Debian Free Software Guidelines</cite></q> for 60 days or more, and
+ none of the solutions that have been implemented (if any) is
considered
+ suitable by the maintainers, the package must be moved from Debian
+ ("main" suite) to the Non-free repository ("non-free" suite).
+ </p>
+ <p>
+ The action of moving it may be performed by any of the developers
(however,
+ moving packages in the "stable" distribution may still require
approval by
+ the Release Team for "stable"). When this happens, any known DFSG
violation
+ in the package must be resolved before the package can be moved back
into
+ Debian.
+ </p>
</li>
<li><strong>We will give back to the free software community</strong>
<p>
(Since this option ammends the SC, I believe it would require 3:1 majority)
Option 3 (set an upper limit, allow lenny to release with propietary firmware)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The developers resolve that the following rule shall take effect inmediately
after Lenny is released:
When ever a package in Debian is found to have been violating the DFSG for
60 days or more, and none of the solutions that have been implemented (if
any) is considered suitable by the maintainers, the package must be moved
from Debian ("main" suite) to the Non-free repository ("non-free" suite).
The action of moving it may be performed by any of the developers (however,
moving packages in the "stable" distribution may still require approval by
the Release Team for "stable"). When this happens, any known DFSG violation
in the package must be resolved before the package can be moved back into
Debian.
In addition:
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; however, it is not yet finally sorted out;
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
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 in udebs as long as it is
necessary for installation (like all udebs), and firmware included in
the kernel itself 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.
(Since this option overrides the SC, I believe it would require 3:1 majority)
Option 4 (set an upper limit, make this part of the SC, allow lenny to release
with propietary firmware)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The developers resolve that, inmediately after Lenny is released, the Social
Contract shall be ammended as follows:
--- social_contract.wml 22 Nov 2007 03:15:39 -0000 1.23
+++ social_contract.wml 24 Oct 2008 14:54:30 -0000
@@ -31,6 +31,24 @@ the free software community as the basis
free and non-free works on Debian. We will never make the
system require the use of a non-free component.
</p>
+ <p>
+ In order to ensure continued compliance with this promise, the
+ following rule is to be followed:
+ </p>
+ <p>
+ When ever a package in Debian is found to have been violating the
+ Debian Free Software Guidelines</cite></q> for 60 days or more, and
+ none of the solutions that have been implemented (if any) is
considered
+ suitable by the maintainers, the package must be moved from Debian
+ ("main" suite) to the Non-free repository ("non-free" suite).
+ </p>
+ <p>
+ The action of moving it may be performed by any of the developers
(however,
+ moving packages in the "stable" distribution may still require
approval by
+ the Release Team for "stable"). When this happens, any known DFSG
violation
+ in the package must be resolved before the package can be moved back
into
+ Debian.
+ </p>
</li>
<li><strong>We will give back to the free software community</strong>
<p>
In addition:
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; however, it is not yet finally sorted out;
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
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 in udebs as long as it is
necessary for installation (like all udebs), and firmware included in
the kernel itself 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.
(Since this option ammends the SC, I believe it would require 3:1 majority)
Option 5 (set an upper limit, allow lenny to release with DFSG violations)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The developers resolve that the following rule shall take effect inmediately
after Lenny is released:
When ever a package in Debian is found to have been violating the DFSG for
60 days or more, and none of the solutions that have been implemented (if
any) is considered suitable by the maintainers, the package must be moved
from Debian ("main" suite) to the Non-free repository ("non-free" suite).
The action of moving it may be performed by any of the developers (however,
moving packages in the "stable" distribution may still require approval by
the Release Team for "stable"). When this happens, any known DFSG violation
in the package must be resolved before the package can be moved back into
Debian.
In addition:
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
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)
Option 6 (set an upper limit, make this part of the SC, allow lenny to release
with DFSG violations)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The developers resolve that, inmediately after Lenny is released, the Social
Contract shall be ammended as follows:
--- social_contract.wml 22 Nov 2007 03:15:39 -0000 1.23
+++ social_contract.wml 24 Oct 2008 14:54:30 -0000
@@ -31,6 +31,24 @@ the free software community as the basis
free and non-free works on Debian. We will never make the
system require the use of a non-free component.
</p>
+ <p>
+ In order to ensure continued compliance with this promise, the
+ following rule is to be followed:
+ </p>
+ <p>
+ When ever a package in Debian is found to have been violating the
+ Debian Free Software Guidelines</cite></q> for 60 days or more, and
+ none of the solutions that have been implemented (if any) is
considered
+ suitable by the maintainers, the package must be moved from Debian
+ ("main" suite) to the Non-free repository ("non-free" suite).
+ </p>
+ <p>
+ The action of moving it may be performed by any of the developers
(however,
+ moving packages in the "stable" distribution may still require
approval by
+ the Release Team for "stable"). When this happens, any known DFSG
violation
+ in the package must be resolved before the package can be moved back
into
+ Debian.
+ </p>
</li>
<li><strong>We will give back to the free software community</strong>
<p>
In addition:
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
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 ammends the SC, I believe it would require 3:1 majority)
Option 7 (exception for lenny, no reform)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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; however, it is not yet finally sorted out;
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
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 in udebs as long as it is
necessary for installation (like all udebs), and firmware included in
the kernel itself 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.
(Since this option overrides the SC, I believe it would require 3:1 majority)
Option 8 (reaffirm the Social Contract)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. We affirm that our Priorities are our users and the free software
community (Social Contract #4);
2. Given that we have known for two previous releases that we have
non-free bits in kernel sources, 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.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
signature.asc
Description: Digital signature
