I hereby propose the following General Resolution to stablish a procedure
for resolving DFSG violations:
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)
--
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."
Attachment:
signature.asc
Description: Digital signature