Re: Social Contract GR's Affect on sarge
Reading debian-vote, I think it would be helpful if we stated our
opinion formally. There still seems to be some dispute.
I therefore hereby propose the following resolution and call for a
vote. I'm hoping we can get enough of the TC to vote in favour to get
an official resolution well before the close of voting.
Headline advice: we recommend that Developers vote as follows:
either B,D,E,C,A,F,FD (2453167) Grandfather clause for Sarge
or D,B,E,C,A,F,FD (4253167) Rescind Social Contract changes
It seems to us that:
* The Social Contract as amended is unambiguous, and prevents the
release of Sarge as-is.
* We would like to see Sarge's release go in parallel with the
time-consuming fixes to the copyright problems.
Therefore:
* The Developers must decide whether to waive or amend the Social
Contract. If no waiver is forthcoming, then Sarge will not be
released until all of the problematic material has been sorted
out.
* If such a grandfather resolution does not pass with a 3:1
supermajority then the Social Contract is not waived and sarge
should not be released until the non-free stuff is removed somehow.
We are pleased to see this waiver process is happening and will
probably result in a resolution in time. So:
* The Release Manager should plan for such a resolution to either
grandfather the existing situation, or permit the release of Sarge
some other way. To do anything else would be to prejudge the
issue.
* Of the General Resolution currently being voted on, the effects as
we see them on the Sarge release process are as follows:
B,D,E: Sarge will go ahead (software quality permitting).
C: Sarge will be delayed to remove certain non-free items not
covered by the grandfather clause (see below).
A: Sarge will go ahead if it can be done by 2004-09-01.
F: Sarge will be delayed to remove the non-free `non-software'.
We offer the following observations advice to the Developers as they
cast their votes:
* The choice we in Debian are making for our users is not between a
release containing entirely free components and one containing
some non-free components; it is between a new release containing
some non-free components and continued distribution of the
previous release also containing non-free components.
* We would prefer the release of Sarge to go ahead unimpeded by
these Social Contract issues. We therefore advise Developers to
rank proposals A,B,C,D,E above F.
* Hard release deadlines are very problematic for Debian. We
therefore advise Developers to rank B,C,D,E above A.
* The grandfather resolution in Option C applies only to
documentation and kernel drivers. We believe that there are some
other problematic `non-software' components, so that Option C only
does a partial job. We therefore advise Developers to rank
proposals B,D,E above C.
* Any grandfather resolution authorising the release of Sarge should
be as short as possible. It is a bad idea to write a long
document `under the gun'. The project has not had adequate time
and attention for consideration of the new foundation document in
proposal E. We therefore advise Developers to rank B,D above E.
* The choice between B (grandfather clause) and D (permanently
rescind the SC changes) is entirely a matter of conscience.
We feel it would be inappropriate for the TC to offer an opinion.
* It is important that the Developers send a clear decision. We
urge all Developers to vote. We also urge Developers to give a
low preference Further Discussion, as that would not be a
desirable outcome.
* Developers who disagree with our view that the Sarge release
should not be delayed should rank F above the other options.
Our other recommendations apply to those Developers too.
We also note that the Technical Committee has no formal authority in
this area. The questions being disputed are not technical. Any
authority we have derives only from Release Manager (who has
delegated this controversial decision to us) and of course from our
power to state our opinions.
Ian.
Reply to: