[ note: resent due to typo in debian-devel adress. The original went to
-vote and -release. Please reply to the original to not break
threading. ]
[ Please respect the Mail-Followup-To header, and reply to -vote. I will
inform debian-devel and debian-release regularly with updates and new
arguments in a concise and hopefully balanced way ]
Dear developers,
As was seen in another thread[1], the recent change to the Social Contract
also influences the release-policy of Sarge.
I see a lot of discussion about the Social Contract change, people are
calling for revote, there are accusations towards both sides. In any
case, things are quite subtle and not black/white, and some people think
there was insufficient information and inadequate discussion highlighting
all sides of the story.
But, as you might have noticed, the rage on debian-devel did _not_ start
when the result of the vote was announced. Rather, it was started
because of the implications Anthony Towns drew of the result of the
vote. I believe, and my talks with numerous DD's have stengthen me in my
belief, that many developers believed that the policy on ignoring
certain problems in Sarge (the sarge-ignore policy) was a practical
decision for the sake of releasing Sarge in the forseeable future. Those
who thought that the old SC basically said the same as it does now, did
for the most part excuse the RM's decision on this: it was not
practically viable to f.e. move GFDL-docs to non-free before Sarge was
released.
It now turns out that Anthony Towns based his sarge-ignore policy on his
reading of the Social Contract. I think quite some DD's would like to
release Sarge soon, even though it might still have some problems. This
wish is mostly pragmatic:
If Sarge, which is already long overdue, is to be released fully conform
the SC, a lot of extra work would still need to happen, amongst
others the d-i support for non-free. Stalling the release also has a
very negative impact on d-i itself[2][3], and people are going to try to
get in a lot of new upstream stuff, etc etc, while currently, Sarge is
well on its way to be released relatively soon.
Also note the situation of woody, which doesn't conform to the new
(reading of the old, according to some) SC either. Stopping to
distribute it would not be in the interest of our users - it would also
mean stopping security support.
I therefore propose a GR which explicitely excuses Sarge from some
issues, something that previously was already done by the Release
Manager on his own. There are basicaly two approaches to this, one is to
amend the Social Contract to explicitely say so, the other is to merely
pass a GR excusing Sarge from the SC. Please see
http://www.wolffelaar.nl/~jeroen/gr/release_sarge_gr.txt (included
below) for a current draft of this GR. I want to include concisely and
to the point the arguments for each side of the case on the GR itself,
so that voters can make a well-informed decision even if they do not
wish to follow this whole discussion. I would like to get the mentioned
text integral on the ballot for the advantage of all voters, also those
who wish to not fully follow the discussion. I therefore promise to
include any argument in the document if it gets at least 3 DD's
seconding it (unless my promise is abused, to my own descretion), or
when I myself am convinced it is a valid argument.
Note that I also added two options, A and B, which partly or fully revert the
decision made in the last GR. While I didn't intially want to put those
options on the draft ballot, I've still done so because of popular demand, and
they would have been added anyway otherwise.
The ballot is now quite full, once it is time for seconds (not yet, let's
first discuss), maybe some options will fail to get five seconds, so they are
dropped. If all get enough seconds, well, this is what the voting system is
designed to handle: a very broad spectrum of opinions, and still a good method
to determine the best option for everyone.
Procedural note: Since I'm not a Debian Developer, I guess some Debian
Developer would in addition need to officially propose any of the options.
W.r.t. Steve Langasek's proposal, it is quite close, but not the same as
the option C figurating in this mail. It is about either revert the SC
temporarily, also with fixed deadline (Steve's variant), or note in the
SC itself that it will only apply from a later date.
The actual text of the current draft:
===================================================================
This draft lists 6 options, ranging from completely going back to the previous
version, to keeping the current one and applying it to Sarge, with some
gradational-option in between:
A: The recent Social Contract change is reverted
B: The Social Contract is changed to apply to software+documentation only
C: A clause is added to the Social Contract stating it will be effective
starting just after Sarge is released
D: Social Contract is left alone, but a GR is passed stating Sarge can be
released with GFDL docs and binary firmware
E: Social Contract is left alone, but a GR is passed stating Sarge can be
released with binary firmware
F: Social Contract is left alone, and Sarge will fully abide by it
G: Further Discussion
| Sarge | Sarge++ |
----------------------+-------+---------+
DFSG to software only | ABCD* | A |
DFSG to sw + docs | E* | B |
DFSG to all data | F | CDEF |
* D and E for Sarge will be a GR excemption, not backed by the Social Contract
Option A:
| It is decided that the Social Contract is to be replaced with version 1.0 of
| the Social Contract, which was ratified July 5, 1997
|
| Or, this option could read that the Social Contract is changed to reflect
| the view that the DFSG only applies to software, and not to documentation and
| other data.
|
| Firmware is considered data.
Rationale:
- The Social Contract is changed towards the strict view that DFSG only applies
to software, and to nothing else, because that's what the DFSG is intended
to cover. It makes not much sense to have DFSG cover documentation and other
data too
Option B:
| It is decided that the Social Contract is to be replaced with a version
| emphasizing that the DFSG applies to software and documentation, but not
| to other data like fonts, images, and the like. It is also added that the
| requirements for documentation only are effective after the release of Sarge.
|
| Firmware is considered data.
Rationale:
- For practical reasons, the new meaning of the Social Contract (new w.r.t.
the July 5, 1997 edition) only starts to apply after Sarge is released.
- ...
Option C:
| It is decided that the Social Contract is to be amended as follows:
|
| Clause one of the Social Contract, currently reading:
|
| > Debian will remain 100% free
| >
| > We provide the guidelines that we use to determine if a work is "free" in the
| > document entitled "The Debian Free Software Guidelines". We promise that the
| > Debian system and all its components will be free according to these
| > guidelines. We will support people who create or use both free and non-free
| > works on Debian. We will never make the system require the use of a non-free
| > component.
|
| shall have this text appended:
|
| > We apologize that the current state of some of our documentation and
| > kernel drivers does not live up to this part of our Social Contract. While
| > Sarge will not meet this standard in those areas, we promise to rectify
| > this in the following release.
|
| resulting in the new Clause one of the Social contract being as follows:
|
| > Debian will remain 100% free
| >
| > We provide the guidelines that we use to determine if a work is "free" in the
| > document entitled "The Debian Free Software Guidelines". We promise that the
| > Debian system and all its components will be free according to these
| > guidelines. We will support people who create or use both free and non-free
| > works on Debian. We will never make the system require the use of a non-free
| > component.
| >
| > We apologize that the current state of some of our documentation and
| > kernel drivers does not live up to this part of our Social Contract. While
| > Debian 3.1 will not meet this standard in those areas, we promise to rectify
| > this in the following release.
|
| It is still tried to implement the new Social Contract as good as possible,
| but where that is not easily possible, for example where significant changes
| to the Debian Installer are needed to accomodate users who require some
| sorts of firmware during installation even though that is in non-free, are
| not done before Sarge is released.
Rationale:
- Woody is also DFSG-buggy as above, delaying Sarge will also mean that our
current stable system violates the DFSG like we want eventually to prevent.
- Delaying Sarge will cause more users to think about a switch to other
distributions that will not delay a release for a very long time
merely because some problem that exists for many many years was just
recently decided to be release-critical, even though the current stand of
affairs is that there is a long time to go to fix it.
- Having a release which might require non-free for even booting the
installation media, will require additional work to ensure this is working
smoothly, something that cannot be done in a reasonable timeframe.
- It is very unproductive w.r.t. the recent talks with the FSF to get to an
agreement about the GFDL if Debian would mid-conversation drop GFDL from
main. It probably nullifies any chance to have a fruitfull discussion with
the FSF.
- Releasing Sarge without adequate documentation in the default install is not
wise and user-friendly.
Option D:
| It is decided to release Sarge when it's ready, even though it might still
| contain DFSG-related bugs of the classes (and only of the classes):
|
| - It contains GFDL documents
| - It contains binary firmware
|
| But DFSG-related bugs like:
|
| - Package is under a non-free license (excempting GFDL)
| - Package has no license
| - Package cannot be distributed
|
| are still considered release-critical
|
| This resolution has no effect on releases after Sarge
Rationale: as Option C, and in addition:
- The Social Contract will not changed by this option, which would be quite
inconsequent, but rather it is clarified that implementing the new version
of the Social Contract for the upcoming release is not an currently
achievable goal, and that a delay in implementing is only a natural.
- Only the wording of the SC has changed, the meaning has not. It was always
meant to say what it says now, and release management has decided to ignore
particular classes of violations for the sake of releasing Sarge. It was
agreed by consensus that this was ignored before, so it should be ignored
for Sarge also at this moment.
Con:
- Anthony Towns has stated that he wishes to not violate the Social Contract
releasing Sarge, even if a GR like this one is passed allowing him to do so.
Option E:
| It is decided to release Sarge when it's ready, even though it might still
| contain DFSG-related bugs of the class (and only of the class):
|
| - It contains binary firmware
|
| But DFSG-related bugs like:
| - It contains GFDL documents
| - Package is under a non-free license (excempting GFDL)
| - Package has no license
| - Package cannot be distributed are still considered Release Critical.
| are still considered release-critical
|
| This resolution has no effect on releases after Sarge
Rationale:
As option C, but:
- The Social Contract is not changed, which would be quite inconsequent, but
rather it is clarified that implementing the new version of the Social
Contract for the upcoming release is not an currently achievable goal, and
that a delay in implementing is only a natural.
- Considering the recent vote there is no reason to release Sarge with GFDL
documents in main.
- Documentation can easily be moved: no software depends on documentation, a
move of documentation from main to non-free should not be very hard to do,
and thus not delay the release of Sarge too much (unlike the binary firmware
issues). If one puts non-free in one's sources.list, there will be no
difference for the user.
Con:
- Anthony Towns has stated that he wishes to not violate the Social Contract
releasing Sarge, even if a GR like this one is passed allowing him to do so.
Option F:
| It is decided to release Sarge when it's ready, which includes that Sarge
| must not violate the DFSG in any way.
|
| This means that DFSG bugs like:
|
| - It contains binary firmware
| - It contains GFDL documents
|
| are also considered release-critical
This option serves as an explicit option for those who believe Sarge should be
released only after it has fully be cleaned of GFDL documents and sourceless
binary firmware.
Rationale:
- Considering the recent vote there is no reason to release Sarge with GFDL
documents or sourceless binary firmware in main
Option G:
| Further discussion
===================================================================
I'd like to thank the following people who provided valuable feedback to
me in the past 1.5 day while I was preparing this document:
- Colin Watson
- Anthony Towns
- Pascal Hakim
- Scott James Remnant
- Frank Kuester
- Marc Brockschmidt
- Andreas Barth
And the following people who are supporting me in this effort:
- Colin Watson
- Pascal Hakim
- Norbert Tretkowski
- Frank Lichtenheld
- Christian Perrier
- Frank Kuester
- Andreas Barth
- Marc Brockschmidt
Thanks for considering this,
--Jeroen
[1] http://lists.debian.org/debian-devel/2004/debian-devel-200404/msg03857.html
[2] http://lists.debian.org/debian-devel/2004/debian-devel-200404/msg04006.html
[3] http://lists.debian.org/debian-devel/2004/debian-devel-200404/msg04112.html
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Attachment:
pgpOGVNKko9wL.pgp
Description: PGP signature