[ 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 [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
pgpdUrs2kTjzA.pgp
Description: PGP signature
