Re: Call for vote (Re: call for seconds: on firmware)
Manoj Srivastava sriva...@debian.org wrote: To cast a vote, it is necessary to send this ballot, with the text form (which is embedded later in this ballot) filled out, to a dedicated e-mail address, in a signed message, as described below. Suggest restructuring to simplify:- To cast a vote, complete the text form (embedded later in this ballot) and send the completed ballot in a signed message to a dedicated e-mail address as described below. [ ] Choice 4: Empower the release team to decide about allowing DFSG violations [3:1] Other posts defined in the foundation documents seem to use appoint more than empower - suggested reword:- [ ] Choice 4: Appoint the release team to decide DFSG violations policy [3:1] Would be good to have message-ids or links for the proposals if they're handy. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Call for vote (Re: call for seconds: on firmware)
Does 5 refer only to firmware that is not currently identified as being non-free? If that is the case, is 5 a viable choice? If it doesn't resolve the problem completely and allow us to release then it needs to be accompanied by a plan for the other problem firm/software. - Manoj Srivastava sriva...@debian.org wrote: Here is the *DRAFT DRAFT DRAFT* ballot for the GR. Please note the dates on the ballot; voting is not open yet. Please send comments to the debian-vote@lists.debian.org list. -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Call for vote (Re: call for seconds: on firmware)
On Thu, Dec 04, 2008 at 07:45:05PM +0100, Robert Millan wrote: On Tue, Dec 02, 2008 at 09:18:03AM +0100, Peter Palfrader wrote: Feel free to propose an amendment. I might accept it. I propose the following ammendment: [...] Since there was no further reply on this proposed ammendment, and no followup discussion for a reasonable period of time, I conclude that after discussion, the ballot in: http://www.debian.org/vote/2008/vote_003 titled General Resolution: Lenny and resolving DFSG violations, represents each of the opinions in a reasonably accurate manner, and that it is unlikely that it will be improved. Therefore I'm hereby calling for vote. -- 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
Re: Call for vote (Re: call for seconds: on firmware)
Hi, Here is the *DRAFT DRAFT DRAFT* ballot for the GR. Please note the dates on the ballot; voting is not open yet. Please send comments to the debian-vote@lists.debian.org list. manoj General Resolution: Lenny and resolving DFSG violations; FIRST CALL FOR VOTES FOR THE Lenny Release General Resolution = === = === === = === === == Voting period starts 00:00:01 UTC on Sunday, December 14th, 2008 Votes must be received by 23:59:59 UTC on Saturday, December 21st, 2008 This ballot is for a vote being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions contact [EMAIL PROTECTED] Also, note that you can get a fresh ballot any time before the end of the vote by sending a mail to [EMAIL PROTECTED] with the subject gr_lenny. HOW TO VOTE First, read the full text of the various proposals. To cast a vote, it is necessary to send this ballot, with the text form (which is embedded later in this ballot) filled out, to a dedicated e-mail address, in a signed message, as described below. The dedicated email address this ballot should be sent to is: [EMAIL PROTECTED] The form you need to fill out is contained at the bottom of this message, marked with two lines containing the characters '-=-=-=-=-=-'. Do not erase anything between those lines, and do not change the choice names. There are 7 choices in the form, which you may rank with numbers between 1 and 7. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue until you reach your last choice. Do not enter a number smaller than 1 or larger than 7. You may skip numbers, leave some choices unranked, and rank options equally. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. Make sure you have read the proposals in detail. To vote no, no matter what, rank Further Discussion as more desirable than the unacceptable choices, or you may rank the Further Discussion choice and leave choices you consider unacceptable blank. (Note: if the Further Discussion choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the Further Discussion choice by the voting software). Finally, mail the filled out ballot to: [EMAIL PROTECTED] Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. The voting software (Devotee) accepts mail that either contains only an unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail (RFC 3156 compliant). You may, if you wish, choose to send a signed, encrypted ballot: use the vote key appended below for encryption. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 41b0a520-c6c1-4e7b-8c49-74ee85faf242 [ ] Choice 1: Reaffirm the Social Contract [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1] [ ] Choice 4: Empower the release team to decide about allowing DFSG violations [3:1] [ ] Choice 5: Assume blobs comply with GPL unless proven otherwise [ ] Choice 6: Exclude source requirements for firmware (defined) [3:1] [ ] Choice 7: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- The actual text of the various options are as follows. Please note that this does not include preludes, prologues, any preambles to the resolution, post-ambles to the resolutions, abstracts, fore-words, after-words, rationales, supporting documents, opinion polls, arguments for and against, and any of the other important material you will find on the mailing list archives. Please read the debian-vote mailing list archives for details. -- Choice 1: Reaffirm the Social Contract = === == 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that we promised to deliver a 100% free operating system (Social Contract #1); 3. Given that we have known for two previous releases that we have non-free bits in various parts of Debian, 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 (to the best of our knowledge as of 1 November 2008). -- Choice 2: Allow Lenny to release with proprietary firmware [3:1] == == = = == ===
Re: call for seconds: on firmware
On Tue, Dec 02, 2008 at 09:18:03AM +0100, Peter Palfrader wrote: I would ask that the proposer withdraw this resolution (which in effect is a non-binding position statement, contradicting the text of the DFSG as many of us understand it) and draft a resolution in its place that disambiguates the DFSG. Peter, I too would prefer if you did, for the sake of clarity. But if you will, then please do it soon. Minimal time for discussion period has passed, and due to the urgency of the situation I don't want to wait much longer before calling for vote. Feel free to propose an amendment. I might accept it. I propose the following ammendment: --- firmware2008-12-04 19:40:22.0 +0100 +++ firmware.new2008-12-04 19:40:44.0 +0100 @@ -16,3 +16,20 @@ b) we however do require all other freedoms that the DFSG mandate from components of our operating system, and c) such firmware can and should be part of our official installation media. + d) the Debian Free Software Guidelines shall be ammended as follows: + +--- social_contract.wml22 Nov 2007 03:15:39 - 1.23 social_contract.wml4 Dec 2008 18:36:32 - +@@ -95,7 +95,11 @@ the free software community as the basis +lipstrongSource Code/strong/p + pThe program must include source code, and must allow + distribution in source code as well as compiled +- form./p/li ++ form. As a special exception, the requirement to include ++ source code does not apply to firmware (Firmware is data such ++ as microcode or lookup tables that is loaded into hardware ++ components in order to make the component function properly. It ++ is not code that is run on the host CPU)./p/li +lipstrongDerived Works/strong/p + pThe license must allow modifications and derived works, and + must allow them to be distributed under the same terms as -- 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
Re: call for seconds: on firmware
On Tue, 02 Dec 2008, Robert Millan wrote: In light of the Secretary's claims that the above GR would give him the power to amend the text of the DFSG even though it says nothing of the sort, I am sure if he actually did that we could override him. I hope that would not be necessary however. I would ask that the proposer withdraw this resolution (which in effect is a non-binding position statement, contradicting the text of the DFSG as many of us understand it) and draft a resolution in its place that disambiguates the DFSG. Peter, I too would prefer if you did, for the sake of clarity. But if you will, then please do it soon. Minimal time for discussion period has passed, and due to the urgency of the situation I don't want to wait much longer before calling for vote. Feel free to propose an amendment. I might accept it. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 30, 2008 at 05:11:23PM -0800, Steve Langasek wrote: On Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary wrote: ,[ Proposal 6: Exclude source requirements from firmware (defined) ] | Firmware is data such as microcode or lookup tables that is loaded into | hardware components in order to make the component function properly. | It is not code that is run on the host CPU. | | Unfortunately such firmware often is distributed as so-called blobs, | with no source or further documentation that lets us learn how it works | or interacts with the hardware in question. By excluding such firmware | from Debian we exclude users that require such devices from installing | our operating system, or make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` This will need wording to change the SC, since this is not a temporary override, but adds a definition of firmware, and an exclusion from the 100% free promises of the SC. i Do we require source for firmware in main: No ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Release iV Do we modify foundation documents: Yes v Do we override foundation documentsNo In light of the Secretary's claims that the above GR would give him the power to amend the text of the DFSG even though it says nothing of the sort, I would ask that the proposer withdraw this resolution (which in effect is a non-binding position statement, contradicting the text of the DFSG as many of us understand it) and draft a resolution in its place that disambiguates the DFSG. Peter, I too would prefer if you did, for the sake of clarity. But if you will, then please do it soon. Minimal time for discussion period has passed, and due to the urgency of the situation I don't want to wait much longer before calling for vote. -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary wrote: ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and free software. We don't trade | them against each other. However during getting an release out of the | door, decisions need to be done how to get a rock stable release of the | high quality Debian is known for, release more or less on time, and to | minimize the usage of problematic software. We acknowledge that there | is more than just one minefield our core developers and the release | team are working at. | | We as Developers at large continue to trust our release team to follow | all these goals, and therefor encourage them to continue making | case-by-case-decisions as they consider fit, and if necessary | authorize these decisions. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` This (and the vote web page) is missing one of the spelling corrections from [EMAIL PROTECTED]: therefor - therefore. I would also suggest the following changes; Andi, I'd appreciate if you would acknowledge these under A.1.6 of the SRP: s/ during/, while/ s/an release/a release/ s/need to be done/need to be made about/ s/rock stable/rock-stable/ s/working at/working in/ s/case-by-case-decisions/case-by-case decisions/ s/authorize these decisions/we authorize these decisions/ None of these changes are intended to change the meaning of the resolution; if I've misunderstood the intended meaning of the resolution, let me know and I'll propose different wording to clarify those points. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 30, 2008 at 04:20:38PM -0800, Steve Langasek wrote: On Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary wrote: ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and free software. We don't trade | them against each other. However during getting an release out of the | door, decisions need to be done how to get a rock stable release of the | high quality Debian is known for, release more or less on time, and to | minimize the usage of problematic software. We acknowledge that there | is more than just one minefield our core developers and the release | team are working at. | | We as Developers at large continue to trust our release team to follow | all these goals, and therefor encourage them to continue making | case-by-case-decisions as they consider fit, and if necessary | authorize these decisions. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` This (and the vote web page) is missing one of the spelling corrections from [EMAIL PROTECTED]: therefor - therefore. I would also suggest the following changes; Andi, I'd appreciate if you would acknowledge these under A.1.6 of the SRP: s/ during/, while/ s/an release/a release/ s/need to be done/need to be made about/ s/rock stable/rock-stable/ s/the release team are/the release team is/ s/working at/working in/ s/case-by-case-decisions/case-by-case decisions/ s/authorize these decisions/we authorize these decisions/ None of these changes are intended to change the meaning of the resolution; if I've misunderstood the intended meaning of the resolution, let me know and I'll propose different wording to clarify those points. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: call for seconds: on firmware
On Mon, Dec 01, 2008 at 11:45:57AM +1100, Anibal Monsalve Salazar wrote: s/the release team are/the release team is/ Sorry, that was wrong. signature.asc Description: Digital signature
Re: call for seconds: on firmware
On Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary wrote: ,[ Proposal 5: allow Lenny to release with firmware blobs ] | 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; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 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 (to the best of our knowledge | as of 1 November 2008); | 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 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. ` * This proposal gives the binary blobs distributed in the kernel the benefit of doubt, and assumes they do not violate the GPL and are the preferred form of modification, however unlikely that is. Nothing in the text of your proposal says anything about assum[ing] they do not violate the GPL. This summary, and the title given on http://www.debian.org/vote/2008/vote_003, are incorrect. - The text of this option (and of the GR passed on this subject for etch) stipulates that we will only deliver the firmware if we are legally allowed to do so. If the governing license is the GPL, it's not legal to redistribute firmware that we don't have the source for. Therefore this proposal does not have the effect you claim. - The firmware that's actually at issue - both for etch and now - is firmware distributed with the Linux kernel whose stated license is *not* the GPL. The release team is not seeking to play dumb regarding the GPL's license requirements; the only aim here is to include, in main, certain recently-noticed firmware blobs whose license meets the requirements of the DFSG but for which we don't have source code. - Regardless of any titles or summaries tacked onto this proposal, the text of it authorizes the release team to include firmware in main for lenny that does not comply with DFSG#2 - the same as the 2nd, 3rd, and 4th proposals. The same majority requirements must be applied to each. The majority requirement for the ballot option in http://www.debian.org/vote/2006/vote_007 with the exact same wording as in 4. above was 1:1. The majority requirement for all of these four proposals on the present vote should be the same. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary wrote: ,[ Proposal 6: Exclude source requirements from firmware (defined) ] | Firmware is data such as microcode or lookup tables that is loaded into | hardware components in order to make the component function properly. | It is not code that is run on the host CPU. | | Unfortunately such firmware often is distributed as so-called blobs, | with no source or further documentation that lets us learn how it works | or interacts with the hardware in question. By excluding such firmware | from Debian we exclude users that require such devices from installing | our operating system, or make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` This will need wording to change the SC, since this is not a temporary override, but adds a definition of firmware, and an exclusion from the 100% free promises of the SC. i Do we require source for firmware in main: No ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Release iV Do we modify foundation documents: Yes v Do we override foundation documentsNo In light of the Secretary's claims that the above GR would give him the power to amend the text of the DFSG even though it says nothing of the sort, I would ask that the proposer withdraw this resolution (which in effect is a non-binding position statement, contradicting the text of the DFSG as many of us understand it) and draft a resolution in its place that disambiguates the DFSG. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
* Steve Langasek ([EMAIL PROTECTED]) [081201 01:15]: On Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary wrote: ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and free software. We don't trade | them against each other. However during getting an release out of the | door, decisions need to be done how to get a rock stable release of the | high quality Debian is known for, release more or less on time, and to | minimize the usage of problematic software. We acknowledge that there | is more than just one minefield our core developers and the release | team are working at. | | We as Developers at large continue to trust our release team to follow | all these goals, and therefor encourage them to continue making | case-by-case-decisions as they consider fit, and if necessary | authorize these decisions. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` This (and the vote web page) is missing one of the spelling corrections from [EMAIL PROTECTED]: therefor - therefore. I would also suggest the following changes; Andi, I'd appreciate if you would acknowledge these under A.1.6 of the SRP: s/ during/, while/ s/an release/a release/ s/need to be done/need to be made about/ s/rock stable/rock-stable/ s/working at/working in/ s/case-by-case-decisions/case-by-case decisions/ s/authorize these decisions/we authorize these decisions/ As always, I trust your language skills more than mine. IOW, these changes are approved / acknowledged. Cheers, Andi signature.asc Description: Digital signature
Re: call for seconds: on firmware
On Sat, 15 Nov 2008 09:45:56 -0600, Debian Project Secretary wrote:
Since some people have had trouble reading the proposals, I am
including a short impact of the proposal list below the proposal.
Thanks for listing the consequences of the different choices.
In order to make it easier for me and maybe others I'm trying to
compact them into a single table below (the FD column is from Russ'
followup mail to -vote).
v Consequence / Proposal | 1 | 2 | 3 | 4 | 5 | 6 | FD
---|---|---|---|---|---|---|---
i require source for firmware in main| Y | N | N | N | Y | N | Y
ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N
iii What do we do for Lenny| W | R | R | R | R | R | W
iv modify foundation documents| N | N | N | Y | N | Y | N
v override foundation documents | N | Y | Y | N | N | N | N
---|---|---|---|---|---|---|---
Y(es) N(o) R(elease) W(ait)
As a side note:
I guess what makes this vote confusing (at least for me) is that we
try to answer several questions (roughly equivalent to the
consuequences) in one vote ...
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Andrew Lloyd Webber Tim Rice
signature.asc
Description: Digital signature
Re: call for seconds: on firmware
On Sun, Nov 23, 2008 at 06:29:26PM +, gregor herrmann wrote: On Sat, 15 Nov 2008 09:45:56 -0600, Debian Project Secretary wrote: Since some people have had trouble reading the proposals, I am including a short impact of the proposal list below the proposal. Thanks for listing the consequences of the different choices. In order to make it easier for me and maybe others I'm trying to compact them into a single table below (the FD column is from Russ' followup mail to -vote). v Consequence / Proposal | 1 | 2 | 3 | 4 | 5 | 6 | FD ---|---|---|---|---|---|---|--- i require source for firmware in main| Y | N | N | N | Y | N | Y ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N I have a problem with that. Only (4) is _really_ actively taking sides on that. All the other votes are completely unrelated to the Release Team decision. I feel there are two votes, the one about Should we release with or without the firmware issues, which de facto endorse or rescind the Release Team decision, and the rest. Mixing the two issues suck badly, because I believe that the project at large would want to allow the release team to ignore the firmware bugs for the release (hence endorsing our choice), while there is no consensus on the firmware source issues. At least I _believe_ it's where the project stands, and it did, twice, in the past. So tying the allow firmware without / with source or whatever change related to that, _with_ the question about what we do for lenny are definitely a bad mix that sounds rather unfair and blocking people from at the same time not wanting to slow the release for this issue, but still confirming sourceless firmwares in main are against their interpretation of the DFSG. iii What do we do for Lenny| W | R | R | R | R | R | W iv modify foundation documents| N | N | N | Y | N | Y | N v override foundation documents | N | Y | Y | N | N | N | N ---|---|---|---|---|---|---|--- Y(es) N(o) R(elease) W(ait) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLqBfISGfcq.pgp Description: PGP signature
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Pierre Habouzit wrote: On Sun, Nov 23, 2008 at 06:29:26PM +, gregor herrmann wrote: On Sat, 15 Nov 2008 09:45:56 -0600, Debian Project Secretary wrote: Since some people have had trouble reading the proposals, I am including a short impact of the proposal list below the proposal. Thanks for listing the consequences of the different choices. In order to make it easier for me and maybe others I'm trying to compact them into a single table below (the FD column is from Russ' followup mail to -vote). v Consequence / Proposal | 1 | 2 | 3 | 4 | 5 | 6 | FD ---|---|---|---|---|---|---|--- i require source for firmware in main| Y | N | N | N | Y | N | Y ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N As a side note: I guess what makes this vote confusing (at least for me) is that we try to answer several questions (roughly equivalent to the consuequences) in one vote ... I think the primary question that started this line of proposals was how to resolve the presence of allegedly sourceless firmware in the kernel image. Some of the solutions to that issue have longer term impact, and could be considered on their own merit. However, since they also solve the Lenny issue, I think they belong on this ballot; since we can resolve about one way to solve Lenny, and then we get a second chance to come to a different (and conflicting) resolution about Lenny by the second or third votes. I have a problem with that. Only (4) is _really_ actively taking sides on that. All the other votes are completely unrelated to the Release Team decision. I think we need to resolve what to do with lenny first: and if it is to let the release team have to power to decide whether possible DFSG/GPL violations can be present in the Debian system is one way of resolving this. I feel there are two votes, the one about Should we release with or without the firmware issues, which de facto endorse or rescind the Release Team decision, and the rest. What is the rest? At this point, I see no options on the ballot which will _not_ resolve the Lenny release issue. Mixing the two issues suck badly, because I believe that the project at large would want to allow the release team to ignore the firmware bugs for the release (hence endorsing our choice), while there is no consensus on the firmware source issues. At least I _believe_ it's where the project stands, and it did, twice, in the past. The project can say so again. Option 5 is defined for that; which essentially says that the project allows people to say release Lenny as long as there are no proven DFSG violations. So tying the allow firmware without / with source or whatever change related to that, _with_ the question about what we do for lenny are definitely a bad mix that sounds rather unfair and blocking people from at the same time not wanting to slow the release for this issue, but still confirming sourceless firmwares in main are against their interpretation of the DFSG. I take it you do not think option 2 meets this goal, which says that for Lenny we shall ignore possible DFSG violations in the kernel? Or Option 5, which says we'll not hold up the release for things we just suspect are DFSG violations? Even option 3 allows us to just ignore the DFSG violations for the release. Would you just want to add something that just says We like to say that we do not like sourceless firmwares in main, except when it come to releases, and then that is fine to the proposals 2 and 3? I am unable to see the distinction between what you seek and options 2/3. manoj -- The shortest distance between two points is under construction. Noelie Alito Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Russ Allbery wrote: gregor herrmann [EMAIL PROTECTED] writes: In order to make it easier for me and maybe others I'm trying to compact them into a single table below (the FD column is from Russ' followup mail to -vote). v Consequence / Proposal | 1 | 2 | 3 | 4 | 5 | 6 | FD ---|---|---|---|---|---|---|--- i require source for firmware in main| Y | N | N | N | Y | N | Y ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N iii What do we do for Lenny| W | R | R | R | R | R | W iv modify foundation documents| N | N | N | Y | N | Y | N v override foundation documents | N | Y | Y | N | N | N | N ---|---|---|---|---|---|---|--- Y(es) N(o) R(elease) W(ait) I'm pretty sure from the further analysis, and I think Manoj confirmed, I did not. that FD is N-N-R-N-N. I think it is Y-N-?-N-N. (personally, I think my interpretation of the SC is ? == W, but I can't say that as secretary). The ? is to be resolved depending on whether the firmware blobs violate the DFSG or not (are they the preferred form of modification?). The constitution does not give release teams the powers to override the foundation documents, so the release team can not ignore SC violations. I can make a formal interpretation of the constitution, if you wish. Even if some people think that set of choices is nonsensical, my understanding of the current situation is that the release team has ruled, as DPL delegates, that the current situation does not violate the SC sufficiently to warrant removing the relevant packages from I do not think that the constitution allows for sufficiently. You can't supersede a foundation document in a minor way without a super majority vote. main or delaying the release (this is not the same thing as ignoring SC violation bugs under the project governance process). In the absence of an override of that delegate decision, it stands. I do not think that statement is in compliance with the constitution. The release team is free to interpret the SC and decide there is no violation there (as long as they have a rationale, defensible position, etc). That would not violate the constitution. They can't just decide, yeah, it violates the SC, but not very much, so let us go ahead. manoj -- Stupidity, like virtue, is its own reward. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Manoj Srivastava [EMAIL PROTECTED] writes: The release team is free to interpret the SC and decide there is no violation there (as long as they have a rationale, defensible position, etc). That would not violate the constitution. My understanding is that that's exactly what they did, and that's what my post was trying to say. That would make FD mean N-N-R-N-N, yes? (This is probably confused by the fact that the release team has several members who seem to have reached the same conclusion for different reasons.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23, 2008 at 02:21:47PM -0600, Manoj Srivastava wrote: The constitution does not give release teams the powers to override the foundation documents, so the release team can not ignore SC violations. I can make a formal interpretation of the constitution, if you wish. 3. Individual Developers 3.1. Powers An individual Developer may 1. make any technical or nontechnical decision with regard to their own work; The Secretary is not the Release Team's keeper. And the DFSG is not a decision properly made under [the rules of the constitution] because the DFSG predates the constitution and has never been amended or re-confirmed by General Resolution. (2004/vote_003 only amended the text of the Social Contract, not the DFSG.) So there's no way that the constitution gives you special authority in disputes over interpretation of the DFSG, either. (Even if it had been ratified by GR, I find the claim that the Secretary's powers include deciding whether a developer is working against a constitutional decision to be dubious at best.) Even if some people think that set of choices is nonsensical, my understanding of the current situation is that the release team has ruled, as DPL delegates, that the current situation does not violate the SC sufficiently to warrant removing the relevant packages from I do not think that the constitution allows for sufficiently. You can't supersede a foundation document in a minor way without a super majority vote. supersede means replace with a newer revision. The Release Team hasn't proposed doing anything of the sort. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23, 2008 at 07:43:05PM +, Manoj Srivastava wrote: On Sun, Nov 23 2008, Pierre Habouzit wrote: On Sun, Nov 23, 2008 at 06:29:26PM +, gregor herrmann wrote: On Sat, 15 Nov 2008 09:45:56 -0600, Debian Project Secretary wrote: Since some people have had trouble reading the proposals, I am including a short impact of the proposal list below the proposal. Thanks for listing the consequences of the different choices. In order to make it easier for me and maybe others I'm trying to compact them into a single table below (the FD column is from Russ' followup mail to -vote). v Consequence / Proposal | 1 | 2 | 3 | 4 | 5 | 6 | FD ---|---|---|---|---|---|---|--- i require source for firmware in main| Y | N | N | N | Y | N | Y ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N As a side note: I guess what makes this vote confusing (at least for me) is that we try to answer several questions (roughly equivalent to the consuequences) in one vote ... I think the primary question that started this line of proposals was how to resolve the presence of allegedly sourceless firmware in the kernel image. Some of the solutions to that issue have longer term No it's not, the original question was do the release team has powers to decide that it's okay to ignore DFSG violations for a release. The firmware discussion came _then_. I have a problem with that. Only (4) is _really_ actively taking sides on that. All the other votes are completely unrelated to the Release Team decision. I think we need to resolve what to do with lenny first: and if it is to let the release team have to power to decide whether possible DFSG/GPL violations can be present in the Debian system is one way of resolving this. No, we need what to do with the process of releasing first. To me, the questions of endorsing the RT or not, and delaying the release or not are one and the same, and are completely distinct from the sourceless firmwares issues in Debian, even if loosely correlated. And again, the releasing issues _HAVE COME FIRST_, and are the very source of all the rest. It's just that I feel that _you_ don't care about that, just about the firmware issues. I'm annoyed you don't see other people see two different problems here. I feel there are two votes, the one about Should we release with or without the firmware issues, which de facto endorse or rescind the Release Team decision, and the rest. What is the rest? At this point, I see no options on the ballot which will _not_ resolve the Lenny release issue. For *'s sake Manoj, have you read what I wrote ? There is no sane way to decide that the release team was right to lenny-ignore those bugs but _still_ reaffirm that the sourceless firmwares are still not OK as a general rule. This is a valid opinion, and I believe it concerns a fair amount of people in Debian, at least it's what past votes show unambiguously. I feel those people are betrayed. And FWIW I'm not one of them, I'm objectively opposing your choice here, not preaching for my church. Mixing the two issues suck badly, because I believe that the project at large would want to allow the release team to ignore the firmware bugs for the release (hence endorsing our choice), while there is no consensus on the firmware source issues. At least I _believe_ it's where the project stands, and it did, twice, in the past. The project can say so again. Option 5 is defined for that; which essentially says that the project allows people to say release Lenny as long as there are no proven DFSG violations. huh, no that option rescind the RT decision. We didn't decide having sourceless firmwares was not a DFSG violation, we decided it was not critical enough to delay the release for that since the project stated that twice already. So tying the allow firmware without / with source or whatever change related to that, _with_ the question about what we do for lenny are definitely a bad mix that sounds rather unfair and blocking people from at the same time not wanting to slow the release for this issue, but still confirming sourceless firmwares in main are against their interpretation of the DFSG. I take it you do not think option 2 meets this goal, which says that for Lenny we shall ignore possible DFSG violations in the kernel? Or Option 5, which says we'll not hold up the release for things we just suspect are DFSG violations? Even option 3 allows us to just ignore the DFSG violations for the release. That's not the same, it doesn't decide if the release team was right or not, and is tied to _other_ decisions which prevent people from voting in conscience. They have to weight every option to vote for the one the _closest_ to what they think. To be frank, if
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Steve Langasek wrote: On Sun, Nov 23, 2008 at 02:21:47PM -0600, Manoj Srivastava wrote: The constitution does not give release teams the powers to override the foundation documents, so the release team can not ignore SC violations. I can make a formal interpretation of the constitution, if you wish. 3. Individual Developers 3.1. Powers An individual Developer may 1. make any technical or nontechnical decision with regard to their own work; Does that mean I can just ignore the DFSG in my packages, and no one can override that? I don't think so. The constitution and ther foundation documents limit the powers we have; and allowing non-free crap does not seem like a technical decision to me. Sounds more like a non-technical social decision. The Secretary is not the Release Team's keeper. No. The secretary just decides on their own things under their purview. I am not, if you notice, hacking dak. And the DFSG is not a decision properly made under [the rules of the constitution] because the DFSG predates the constitution and has never been amended or re-confirmed by General Resolution. (2004/vote_003 only amended the text of the Social Contract, not the DFSG.) So there's no way that the constitution gives you special authority in disputes over interpretation of the DFSG, either. The constitution has wording on what the foundation documents are, and how they can be overridden. I am interpreting the constitution when it comes to my role, to the best of my ability to do so. (Even if it had been ratified by GR, I find the claim that the Secretary's powers include deciding whether a developer is working against a constitutional decision to be dubious at best.) I can only say what the constitution does or does not allow, and what powers the constitution confers on people. I have no idea of people are working against the constitution or not. Even if some people think that set of choices is nonsensical, my understanding of the current situation is that the release team has ruled, as DPL delegates, that the current situation does not violate the SC sufficiently to warrant removing the relevant packages from I do not think that the constitution allows for sufficiently. You can't supersede a foundation document in a minor way without a super majority vote. supersede means replace with a newer revision. The Release Team hasn't proposed doing anything of the sort. Overriding parts of the foundation documents as you please is tantamound to, and generally indistinguishable from, replacing the document (perhaps temporarily) with a new version. When I wrote that proposal, this is what I did have in mind. manoj -- Where love is there is no labor; and if there be labor, that labor is loved. Austin Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Pierre Habouzit wrote: On Sun, Nov 23, 2008 at 07:43:05PM +, Manoj Srivastava wrote: On Sun, Nov 23 2008, Pierre Habouzit wrote: I think the primary question that started this line of proposals was how to resolve the presence of allegedly sourceless firmware in the kernel image. Some of the solutions to that issue have longer term No it's not, the original question was do the release team has powers to decide that it's okay to ignore DFSG violations for a release. The firmware discussion came _then_. The answer is simple: the constitution gives them no powers to override the foundation documents on their own. Since all powers to the delegates flow from the constitution, that is that, no? I have a problem with that. Only (4) is _really_ actively taking sides on that. All the other votes are completely unrelated to the Release Team decision. I think we need to resolve what to do with lenny first: and if it is to let the release team have to power to decide whether possible DFSG/GPL violations can be present in the Debian system is one way of resolving this. No, we need what to do with the process of releasing first. To me, the questions of endorsing the RT or not, and delaying the release or not are one and the same, and are completely distinct from the sourceless firmwares issues in Debian, even if loosely correlated. And again, the releasing issues _HAVE COME FIRST_, and are the very source of all the rest. It's just that I feel that _you_ don't care about that, just about the firmware issues. I'm annoyed you don't see other people see two different problems here. I think there is little non-technical blocking the release apart from the firmware issue. There is no reason to delay the release (apart from the RC bugs) than firmware in Debian (which is not being counted as RC, since it has been downgraded) I feel there are two votes, the one about Should we release with or without the firmware issues, which de facto endorse or rescind the Release Team decision, and the rest. What is the rest? At this point, I see no options on the ballot which will _not_ resolve the Lenny release issue. For *'s sake Manoj, have you read what I wrote ? There is no sane way to decide that the release team was right to lenny-ignore those bugs but _still_ reaffirm that the sourceless firmwares are still not OK as a general rule. This is a valid opinion, and I believe it concerns a fair amount of people in Debian, at least it's what past votes show unambiguously. I feel those people are betrayed. And FWIW I'm not one of them, I'm objectively opposing your choice here, not preaching for my church. I guess I am obtuse, since I am still not seeing it. a) No delegate can just ignore the foundation documents constitutionallyy. b) If the release team is correct, then there is no DFSG violation, and the sourceless firmware in testing are rightly there. c) If the sourceless firmware is not OK, then how can the release team have been right? huh, no that option rescind the RT decision. We didn't decide having sourceless firmwares was not a DFSG violation, we decided it was not critical enough to delay the release for that since the project stated that twice already. No. The first time, we decided to bring back the old social contract for sarge, that did not say Debian was 100 % free. After releasing Sarge, we made the change. *THE RELEASE DID NOT VIOLATE THE SOCIAL CONTRACT AS IT STOOD* The second time, we said the firmware must comply with the DFSG. That meant, in practice, that the formware was considered to be in compliance with the GPL, and thus the preferred form of modification -- and no one could _prove_ otherwise. *THE RELEASE DID NOT VIOLATE THE SOCIAL CONTRACT AS IT STOOD* So tying the allow firmware without / with source or whatever change related to that, _with_ the question about what we do for lenny are definitely a bad mix that sounds rather unfair and blocking people from at the same time not wanting to slow the release for this issue, but still confirming sourceless firmwares in main are against their interpretation of the DFSG. I take it you do not think option 2 meets this goal, which says that for Lenny we shall ignore possible DFSG violations in the kernel? Or Option 5, which says we'll not hold up the release for things we just suspect are DFSG violations? Even option 3 allows us to just ignore the DFSG violations for the release. That's not the same, it doesn't decide if the release team was right or not, and is tied to _other_ decisions which prevent people from voting in conscience. They have to weight every option to vote for the one the _closest_ to what they think. To be frank, if I were in the position to
Re: call for seconds: on firmware
On Sun, Nov 23, 2008 at 03:13:38PM -0600, Manoj Srivastava wrote: On Sun, Nov 23 2008, Steve Langasek wrote: On Sun, Nov 23, 2008 at 02:21:47PM -0600, Manoj Srivastava wrote: The constitution does not give release teams the powers to override the foundation documents, so the release team can not ignore SC violations. I can make a formal interpretation of the constitution, if you wish. 3. Individual Developers 3.1. Powers An individual Developer may 1. make any technical or nontechnical decision with regard to their own work; Does that mean I can just ignore the DFSG in my packages, and no one can override that? I don't think so. No, it means that the *secretary* doesn't have special powers to decide the DFSG has been violated and a remedy is in order. We have lots of other structures in place to override developers when we think they've made a decision that's wrong: the ftp team can remove packages from the archive; the release team can refuse to release the package; the TC and the developers can override the decision via the documented processes in the constitution. The secretary is not, and should not be, one of the parties with power to directly override decisions made by developers, no matter how improper you might think they are. And the DFSG is not a decision properly made under [the rules of the constitution] because the DFSG predates the constitution and has never been amended or re-confirmed by General Resolution. (2004/vote_003 only amended the text of the Social Contract, not the DFSG.) So there's no way that the constitution gives you special authority in disputes over interpretation of the DFSG, either. The constitution has wording on what the foundation documents are, and how they can be overridden. I am interpreting the constitution when it comes to my role, to the best of my ability to do so. It has language about how the foundation documents can be *superseded*. If you had meant to say overridden, you should have written that when proposing the GR for 2003/vote_0003, instead of claiming after the fact that supersede implies override. The Debian Project did not ratify any statement about the circumstances under which the foundation documents can be overridden or ignored. That doesn't mean overriding the DFSG is *ok*, but it does mean that if you assert /in your role as secretary/ that a particular action taken by a developer is a violation of the DFSG or SC and therefore not permitted, you're legislating from the bench, which harms the integrity of the office of Project Secretary overall. (Even if it had been ratified by GR, I find the claim that the Secretary's powers include deciding whether a developer is working against a constitutional decision to be dubious at best.) I can only say what the constitution does or does not allow, and what powers the constitution confers on people. I have no idea of people are working against the constitution or not. Then on what grounds does the secretary, as interpreter of the constitution, have any authority to say that the constitution does not give release teams the powers to override the foundation documents? By my reading, the constitution gives any developer the power to make any decision regarding their own work, as long as it a) doesn't work against decisions made under the constitution, and b) isn't overridden by one of the documented processes. Overriding parts of the foundation documents as you please is tantamound to, and generally indistinguishable from, replacing the document (perhaps temporarily) with a new version. When I wrote that proposal, this is what I did have in mind. When I seconded it and voted for it, it was not. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 23 2008, Steve Langasek wrote: On Sun, Nov 23, 2008 at 03:13:38PM -0600, Manoj Srivastava wrote: On Sun, Nov 23 2008, Steve Langasek wrote: On Sun, Nov 23, 2008 at 02:21:47PM -0600, Manoj Srivastava wrote: The constitution does not give release teams the powers to override the foundation documents, so the release team can not ignore SC violations. I can make a formal interpretation of the constitution, if you wish. 3. Individual Developers 3.1. Powers An individual Developer may 1. make any technical or nontechnical decision with regard to their own work; Does that mean I can just ignore the DFSG in my packages, and no one can override that? I don't think so. No, it means that the *secretary* doesn't have special powers to decide the DFSG has been violated and a remedy is in order. I do not. All I have the power to decide is how the vote is conducted. We have lots of other structures in place to override developers when we think they've made a decision that's wrong: the ftp team can remove packages from the archive; the release team can refuse to release the package; the TC and the developers can override the decision via the documented processes in the constitution. The secretary is not, and should not be, one of the parties with power to directly override decisions made by developers, no matter how improper you might think they are. I am not overriding any decision. I am just creating a ballot in the best means I can see, based on my understanding of the foundation documents. I am not going to do something I consider unethical just because other office bearers can correct things, or take up the slack. The release team can release whatever they please. I am not modifying dak. Their decision can still be overridden. But the proper form of the ballot is my responsibility, and I am not going to shirk it. You think I am wrong in the decision, ok. I think the release team and the kernel team were wrong too. I am not interfering with the kernel image packages (though I do have a certain affinity to them -- the very first auto generated kernel image package was created by me; they were hand made prior to that). Bur as a secretary, I have obligations, to the constitution, the project, and end users, whose rights ought not to be trampled by non-free crap. And the DFSG is not a decision properly made under [the rules of the constitution] because the DFSG predates the constitution and has never been amended or re-confirmed by General Resolution. (2004/vote_003 only amended the text of the Social Contract, not the DFSG.) So there's no way that the constitution gives you special authority in disputes over interpretation of the DFSG, either. The constitution has wording on what the foundation documents are, and how they can be overridden. I am interpreting the constitution when it comes to my role, to the best of my ability to do so. It has language about how the foundation documents can be *superseded*. If you had meant to say overridden, you should have written that when proposing the GR for 2003/vote_0003, instead of claiming after the fact that supersede implies override. I maintain that supsersede and override have no distinction, as far as I interpret the constitution here. If you think that there should be a distinction, and the constitution needs to be clarified, you know where to start the process. The Debian Project did not ratify any statement about the circumstances under which the foundation documents can be overridden or ignored. That doesn't mean overriding the DFSG is *ok*, but it does mean that if you assert /in your role as secretary/ that a particular action taken by a developer is a violation of the DFSG or SC and therefore not permitted, you're legislating from the bench, which harms the integrity of the office of Project Secretary overall. (Even if it had been ratified by GR, I find the claim that the Secretary's powers include deciding whether a developer is working against a constitutional decision to be dubious at best.) I can only say what the constitution does or does not allow, and what powers the constitution confers on people. I have no idea of people are working against the constitution or not. Then on what grounds does the secretary, as interpreter of the constitution, have any authority to say that the constitution does not give release teams the powers to override the foundation documents? Huh? Did I not say, and I quote I can only say what the constitution does or does not allow, firstly, while doiung my job, and secondly, since my role is also that of interpreting the constitution? I am trying to interpret the constitution based on what is written, and my memory of the various resolutions ratifying it or amending it; as
Re: call for seconds: on firmware
Steve Langasek [EMAIL PROTECTED] writes: […] we will […] 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 Etch, as long as we are legally allowed to do so, and the firmware is distributed upstream under a license that complies with the DFSG. (http://www.debian.org/vote/2006/vote_007) This says that the *license* must comply with the DFSG. It specifically does *not* say that the *firmware* complies with the DFSG, allowing us to ship firmware in main for which source code was unavailable if it otherwise complied with the DFSG. If I understand you correctly, you're arguing that availability of the source form of a work is not a necessary criterion to describe a work as “distributed upstream under a license that complies with the DFSG”. Is that a fair phrasing of the assertion? -- \“It is seldom that liberty of any kind is lost all at once.” | `\ —David Hume | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
- Steve Langasek [EMAIL PROTECTED] wrote: This says that the *license* must comply with the DFSG. It specifically does *not* say that the *firmware* complies with the DFSG, allowing us to ship firmware in main for which source code was unavailable if it otherwise complied with the DFSG. So yes, the etch release did violate the Social Contract (including the DFSG by reference) as it stood. To have any standing you must show that the firmware in question is not an executable. For data lookup tables, or something like that... sure, maybe. If the firmware runs is executed by a Turing complete CPU attached to the system then it is a binary like any other and should be subject to the same rules anything else is! Modern 3Ware cards have a PowerPC CPU. Claiming that their firmware is not an executable is a distortion. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
- Steve Langasek [EMAIL PROTECTED] wrote: It appears what you don't understand is what the DFSG actually says, since you're playing word substitution games with the text. Maybe /you've/ promised not to distribute any works without source code in Debian. The Debian project has done no such thing. The Debian project can only act through its members (until we build an AI) so your point seems syntactically meaningless. -- Ean Schuessler, CTO Brainfood.com [EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Thu, Nov 20, 2008 at 03:50:07PM +1100, Ben Finney wrote: Steve Langasek [EMAIL PROTECTED] writes: On Wed, Nov 19, 2008 at 09:00:02AM +1100, Ben Finney wrote: Whether loaded by the kernel or present on the chip, we have promised that works without source code will not be distributed in Debian. We? That's what I wrote, yes. I, like every other Debian Developer and Debian Maintainer (unless I misunderstand the process of gaining those responsibilities?), have explicitly declared my understanding of, adherence to, and support of that promise. It appears what you don't understand is what the DFSG actually says, since you're playing word substitution games with the text. Maybe /you've/ promised not to distribute any works without source code in Debian. The Debian project has done no such thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Steve Langasek [EMAIL PROTECTED] writes: It appears what you don't understand is what the DFSG actually says, since you're playing word substitution games with the text. An accusation that could easily be made from many contradictory positions. The DFSG is not unambiguous in its wording, which of course leads to these conflicting interpretations, and leads us to call General Resolutions in some cases. Fortunately, in the case of programmatic works and DFSG §2, the Debian project has *already* voted on the interperatation and decided URL:http://www.debian.org/vote/2006/vote_004 that the requirement for source code applies to all programmatic works in Debian: … the Debian Project: Reaffirms that programmatic works distributed in the Debian system (IE, in main) must be 100% Free Software, regardless of whether the work is designed to run on the CPU, a subsidiary processing unit, or by some other form of execution. That is, works must include the form that the copyright holder or upstream developer would actually use for modification. There are doubtless many other hairs to split in the DFSG, but that one, at least, has been resolved. Maybe /you've/ promised not to distribute any works without source code in Debian. The Debian project has done no such thing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
[apologies for the poorly edited previous post, it was sent accidentally.] Steve Langasek [EMAIL PROTECTED] writes: It appears what you don't understand is what the DFSG actually says, since you're playing word substitution games with the text. An accusation that could easily be made from many contradictory positions. The DFSG is not unambiguous in its wording, which of course leads to these conflicting interpretations, and leads us to call General Resolutions in some cases. Fortunately, in the case of programmatic works and DFSG §2, the Debian project has *already* voted on the interperatation and decided URL:http://www.debian.org/vote/2006/vote_004 that the requirement for source code applies to all programmatic works in Debian: … the Debian Project: Reaffirms that programmatic works distributed in the Debian system (IE, in main) must be 100% Free Software, regardless of whether the work is designed to run on the CPU, a subsidiary processing unit, or by some other form of execution. That is, works must include the form that the copyright holder or upstream developer would actually use for modification. There are doubtless many other hairs to split in the DFSG, but that one, at least, has been resolved. Maybe /you've/ promised not to distribute any works without source code in Debian. The Debian project has done no such thing. Insofar as we're talking about programmatic works, and insofar as the Debian project has resolved the above interpretation of source code requirement, then yes, the Debian project *has* promised to do that. -- \ “If I had known what it would be like to have it all... I might | `\ have been willing to settle for less.” —Jane Wagner, via Lily | _o__) Tomlin | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Ben Finney [EMAIL PROTECTED] writes: Fortunately, in the case of programmatic works and DFSG §2, the Debian project has *already* voted on the interperatation and decided URL:http://www.debian.org/vote/2006/vote_004 that the requirement for source code applies to all programmatic works in Debian: Wrong, actually. Thanks to Charles Plessy for pointing out that I'd misread that page; the resolution was in fact for “Further Discussion”. -- \ “What I have to do is see, at any rate, that I do not lend | `\ myself to the wrong which I condemn.” —Henry Thoreau, _Civil | _o__)Disobedience_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Wed, Nov 19, 2008 at 09:00:02AM +1100, Ben Finney wrote: Johannes Wiedersich [EMAIL PROTECTED] writes: Ben Finney wrote: The Debian system we provide is usable. There may be devices which are not yet operable with Debian, Which wireless card is supported by debian without any sourceless firmware, either loaded by the kernel or present on the chip? Whether loaded by the kernel or present on the chip, we have promised that works without source code will not be distributed in Debian. We? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Steve Langasek [EMAIL PROTECTED] writes: On Wed, Nov 19, 2008 at 09:00:02AM +1100, Ben Finney wrote: Whether loaded by the kernel or present on the chip, we have promised that works without source code will not be distributed in Debian. We? That's what I wrote, yes. I, like every other Debian Developer and Debian Maintainer (unless I misunderstand the process of gaining those responsibilities?), have explicitly declared my understanding of, adherence to, and support of that promise. -- \ “In general my children refuse to eat anything that hasn't | `\ danced on television.” —Erma Bombeck | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
* Lars Wirzenius [EMAIL PROTECTED] [2008-11-17 19:31]: (Quote attribution elided on purpose.) Stop your FUD. The Release Team isn't violating the Social Contract. It is my opinion that releasing lenny with known DFSG violations is a violation of the Social Contract, on the part of the project as a whole, regardless of which individuals are making the decisions. Did you ever read SC #4? It's a violation of the SC to not provide our users with a usable system. yours Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Martin Wuertele [EMAIL PROTECTED] writes: * Lars Wirzenius [EMAIL PROTECTED] [2008-11-17 19:31]: It is my opinion that releasing lenny with known DFSG violations is a violation of the Social Contract, on the part of the project as a whole, regardless of which individuals are making the decisions. Did you ever read SC #4? It's a violation of the SC to not provide our users with a usable system. The Debian system we provide is usable. There may be devices which are not yet operable with Debian, but that doesn't mean Debian stops being usable on the myriad other devices already supported. Are you advocating an interpretation that SC §4 is only satisfied by providing an operating system that is usable with every single device that exists at a given point in time? -- \“Madness is rare in individuals, but in groups, parties, | `\nations and ages it is the rule.” —Friedrich Nietzsche | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Martin Wuertele wrote: * Lars Wirzenius [EMAIL PROTECTED] [2008-11-17 19:31]: (Quote attribution elided on purpose.) Stop your FUD. The Release Team isn't violating the Social Contract. It is my opinion that releasing lenny with known DFSG violations is a violation of the Social Contract, on the part of the project as a whole, regardless of which individuals are making the decisions. Did you ever read SC #4? It's a violation of the SC to not provide our users with a usable system. I do not think you have read 4 and 5 together. 4. Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. 5. Works that do not meet our free software standards We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created `contrib' and `non-free' areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian. We encourage CD manufacturers to read the licenses of the packages in these areas and determine if they can distribute the packages on their CDs. Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists). So, SC says we know our users might need non-free crap, and we shall give it to them, in `contrib' and `non-free' areas in our archive. Frankly, the fact you totally ignore §5 weakens your argument. manoj -- Unibus timeout fatal trap program lost sorry An error message printed by DEC's RSTS operating system for the PDP-11 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Marc 'HE' Brockschmidt wrote: Robert Millan [EMAIL PROTECTED] writes: On Mon, Nov 17, 2008 at 08:08:36AM +0100, Andreas Barth wrote: Though I agree that the release team cannot put any foundation document aside, I don't think the release team is overriding the social contract, but chooses a certain interpretation (that I think is the correct one btw). Other people obviously prefer a different interpretation, and so the relevant question is: Whose interpretation is the binding one? Currently, it seems to me that unless decided otherwise by a GR, the release team has the final say (as explained by Russ). When you say chooses a certain interpretation, are you referring to the one in which SC #4 is interpreted in a way that cannot be complied with no matter what, only to use this impossibility as proof that SC #4 and SC #1 contradict each other, and in turn resolving that because the SC is inconsistent, SC #1 is meant to be read figuratively? I discussed this with Andi in the past, so let me answer: From our point of view, SC#4 is relatively clear: Our users need to be able to use a stable release of Debian and the free software community (not free software!) needs us to spread the use of _free_ software. Driving off people to another distribution because we have found yet another sequence of magic numbers that might, or might not, have source code somewhere is a clear violation of SC#4 in our eyes. It is your Myopia about §5 that is distressing; you seem to selectively read the SC as it benefits your views. , | 5. Works that do not meet our free software standards | | We acknowledge that some of our users require the use of works that | do not conform to the Debian Free Software Guidelines. We have | created `contrib' and `non-free' areas in our archive for these | works. The packages in these areas are not part of the Debian | system, although they have been configured for use with Debian. We | encourage CD manufacturers to read the licenses of the packages in | these areas and determine if they can distribute the packages on | their CDs. Thus, although non-free works are not a part of Debian, | we support their use and provide infrastructure for non-free | packages (such as our bug tracking system and mailing lists). ` The SC never said that we include things that violate DFSG #2 , | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. ` to be in main; it even states that `contrib' and `non-free' areas in our archive have been designed for that. This selective reading of the SC is one reason I believe the release team is in violation of the social contract. manoj -- University: A modern school where football is taught. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Finney wrote: The Debian system we provide is usable. There may be devices which are not yet operable with Debian, Which wireless card is supported by debian without any sourceless firmware, either loaded by the kernel or present on the chip? Would you imply that wireless networking should never be usable by debian users, if it turns out that publication of sourcecode is illegal in countries like the US or the EU? (Modifications of the firmware are probably illegal, because they can modify the electromagnetic emission of the devices, potentially killing people around it.) Consider these questions rhetorical, since they have already been answered here and/or on debian-devel. Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkiyVUACgkQC1NzPRl9qEWOEgCcDd6ddrrhDdObht+ooKFpG+ou 84sAnjGoAD2peo+FVdkgyn0AVn0wpALf =v8eR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Johannes Wiedersich wrote: Ben Finney wrote: The Debian system we provide is usable. There may be devices which are not yet operable with Debian, Which wireless card is supported by debian without any sourceless firmware, either loaded by the kernel or present on the chip? The latter is not a concern. See, the SC says that non-free junk should not be in main; it can be elsewhere. So, the user is free to use non-free firmware -- so if the user acquires it along with the hardware, we don't care. The SC only talks about what is part of the Debian system. We also say people might need non-free stuff, and we put that in a special area on our archive. Would you imply that wireless networking should never be usable by debian users, if it turns out that publication of sourcecode is illegal in countries like the US or the EU? (Modifications of the firmware are probably illegal, because they can modify the electromagnetic emission of the devices, potentially killing people around it.) Strawman. Debian users like me do use nvidia, and iwlwifi, even though my iwlwifi driver uses firmware not in Debian (it is in non-free). So, I could not install this laptop over wifi. Now a big deal -- I installed it over a wired LAN, and I suppose I could have done sneakernet itself. I do not think that the hassle was worth sacrificing Debian's principles for. manoj -- A kiss is a course of procedure, cunningly devised, for the mutual stoppage of speech at a moment when words are superfluous. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manoj Srivastava wrote: On Tue, Nov 18 2008, Johannes Wiedersich wrote: Ben Finney wrote: The Debian system we provide is usable. There may be devices which are not yet operable with Debian, Which wireless card is supported by debian without any sourceless firmware, either loaded by the kernel or present on the chip? The latter is not a concern. See, the SC says that non-free junk should not be in main; it can be elsewhere. So, the user is free to use non-free firmware -- so if the user acquires it along with the hardware, we don't care. According to the SC yes. But I can't see the reasoning behind the argument that firmware loaded on boot is 'evil' and the corresponding hardware should not be supported while the same firmware is 'good' when it is already present on boot and not re-loaded. Arguably hardware, that loads firmware on boot, has the advantage, that programming errors or security holes can be patched, while those with code on flash can't be patched. It seems ridiculous, if Debian supports the latter and leaves users of the former out in the cold. The SC only talks about what is part of the Debian system. We also say people might need non-free stuff, and we put that in a special area on our archive. There should be a distinction between 'non-free' software that is part of the OS or part of user applications and firmware that is just loaded for peripherials. These are completely different cups of tea. Would you imply that wireless networking should never be usable by debian users, if it turns out that publication of sourcecode is illegal in countries like the US or the EU? (Modifications of the firmware are probably illegal, because they can modify the electromagnetic emission of the devices, potentially killing people around it.) Strawman. Debian users like me do use nvidia, and iwlwifi, even though my iwlwifi driver uses firmware not in Debian (it is in non-free). I have no doubt that savvy developers like all on this list will know how to deal with this. Let me be the advocatus of a 'normal user' who does not _want_ to be bothered by googling his way out of all the little obstacles to her/his debian installation... (googling the network card won't work, unless it works already, by the way... There are users with just on PC and no other network connection for a 'sneaker net'. They have the recommended net-install of d-i, but their card requires firmware. What now? As you stand, debian just won't support them. You are basically telling them: buy and use a non-free OS in order to download the firmware necessary to install a free OS. ) So, I could not install this laptop over wifi. Now a big deal -- I installed it over a wired LAN, and I suppose I could have done sneakernet itself. I do not think that the hassle was worth sacrificing Debian's principles for. Yes, big deal: the wired LAN of my laptop is e100, and requires firmware IIRC. One of the principles as I understand it is 'priorities for users'. Too much of this discussion smells like 'SC #1 is more important than SC $4, as long as we DDs know a way to install and configure our machines'. SC #4: We will be guided by the needs of our users... We will place their interests first in our priorities. The primary interest of the user is to be able to *install* a functional debian (without the requirement of downloading unoffical patches to the installation media). Why should we give someone a d-i cd, if it is rather likely that it won't work? Cheers, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkki7JEACgkQC1NzPRl9qEVr1wCfX7kbhzGmNUqm3aq1STKtw7RG ZXsAniZNwWhFB+DcJWptFk5DbBRalJQ2 =4I2r -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
* Manoj Srivastava [EMAIL PROTECTED] [2008-11-18 14:47]: On Tue, Nov 18 2008, Martin Wuertele wrote: * Lars Wirzenius [EMAIL PROTECTED] [2008-11-17 19:31]: (Quote attribution elided on purpose.) Stop your FUD. The Release Team isn't violating the Social Contract. It is my opinion that releasing lenny with known DFSG violations is a violation of the Social Contract, on the part of the project as a whole, regardless of which individuals are making the decisions. Did you ever read SC #4? It's a violation of the SC to not provide our users with a usable system. I do not think you have read 4 and 5 together. 4. Our priorities are our users and free software [..] 5. Works that do not meet our free software standards [..] So, SC says we know our users might need non-free crap, and we shall give it to them, in `contrib' and `non-free' areas in our archive. That still doesn't conclude that releasing Lenny with propable issues violates the SC. As already pointed out why should hardware that loads firmware blobs from flash be treated different than hardware loading the blob from a filesystem. One could conclude that even Intel CPUs are non-free while UltraSparcs are DFSG-free placing amd64 and i386 outside main. yours Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Martin Wuertele wrote: * Manoj Srivastava [EMAIL PROTECTED] [2008-11-18 14:47]: On Tue, Nov 18 2008, Martin Wuertele wrote: * Lars Wirzenius [EMAIL PROTECTED] [2008-11-17 19:31]: (Quote attribution elided on purpose.) Stop your FUD. The Release Team isn't violating the Social Contract. It is my opinion that releasing lenny with known DFSG violations is a violation of the Social Contract, on the part of the project as a whole, regardless of which individuals are making the decisions. Did you ever read SC #4? It's a violation of the SC to not provide our users with a usable system. I do not think you have read 4 and 5 together. 4. Our priorities are our users and free software [..] 5. Works that do not meet our free software standards [..] So, SC says we know our users might need non-free crap, and we shall give it to them, in `contrib' and `non-free' areas in our archive. That still doesn't conclude that releasing Lenny with propable issues violates the SC. As already pointed out why should hardware that loads firmware blobs from flash be treated different than hardware loading the blob from a filesystem. One could conclude that even Intel CPUs are non-free while UltraSparcs are DFSG-free placing amd64 and i386 outside main. It is no different. Debian should be distributing neither. We should not get in the way of the user getting their non-free crap from elsewhere (even embedded in their hardware, or on a usb stick from non-free), but neither should be in Debian main. If you find hardware with embedded software in Debian main, please let me know. I know people who relish downloadable hardware, it feeds their SCI-FI fetishes. manoj -- He who takes nothing in the world that has not been given him, long or short, big or small, attractive or that is what I call a brahmin. 409 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Johannes Wiedersich wrote: Manoj Srivastava wrote: On Tue, Nov 18 2008, Johannes Wiedersich wrote: Ben Finney wrote: The Debian system we provide is usable. There may be devices which are not yet operable with Debian, Which wireless card is supported by debian without any sourceless firmware, either loaded by the kernel or present on the chip? The latter is not a concern. See, the SC says that non-free junk should not be in main; it can be elsewhere. So, the user is free to use non-free firmware -- so if the user acquires it along with the hardware, we don't care. According to the SC yes. But I can't see the reasoning behind the argument that firmware loaded on boot is 'evil' and the corresponding hardware should not be supported while the same firmware is 'good' when it is already present on boot and not re-loaded. It is not good. It is still non-free. Debian should distribute neither. Since Debian does not currently distribute hardware, we do not have to worry about the latter. The fact that users might use non-free junk is their business. Debian should not be an enabler in taking away users freedoms -- if they do so on their own it is their business. So the SC says Debian shall not have non-free junk. If the users obtain the non-free crap (say, embedded in hardware or from the non-free repo), we shall support their decision. Arguably hardware, that loads firmware on boot, has the advantage, that programming errors or security holes can be patched, while those with code on flash can't be patched. It seems ridiculous, if Debian supports the latter and leaves users of the former out in the cold. So some means of getting non-free junk are more secure than other means of getting non-free junk. However, since there is no source, the users can't do any learning or fixing themselves -- that freedom is not given to them. So, we should not stand in the way of users getting non-free junk however they want. We just do not distribute it in Debian. The SC only talks about what is part of the Debian system. We also say people might need non-free stuff, and we put that in a special area on our archive. There should be a distinction between 'non-free' software that is part of the OS or part of user applications and firmware that is just loaded for peripherials. These are completely different cups of tea. Why? I see no rationale why only some freedoms are important. I think that being able to change stuff in how my iwlwifi works would be nice, as long as I continue to conform to the laws of the land. Would you imply that wireless networking should never be usable by debian users, if it turns out that publication of sourcecode is illegal in countries like the US or the EU? (Modifications of the firmware are probably illegal, because they can modify the electromagnetic emission of the devices, potentially killing people around it.) Strawman. Debian users like me do use nvidia, and iwlwifi, even though my iwlwifi driver uses firmware not in Debian (it is in non-free). I have no doubt that savvy developers like all on this list will know how to deal with this. Let me be the advocatus of a 'normal user' who does not _want_ to be bothered by googling his way out of all the little obstacles to her/his debian installation... Sorry. The free distribution does mean that you need to either w buy hardware supported by free software, or learn how to feed your non-free habit by yourself. We might make it easy for you to feed your non-free habit, which is why we have the non-free area of the archive. d-i already allows you to feed it your non-free junk. I think that is plenty support. (googling the network card won't work, unless it works already, by the way... There are users with just on PC and no other network connection for a 'sneaker net'. They have the recommended net-install of d-i, but their card requires firmware. What now? As you stand, debian just won't support them. You are basically telling them: buy and use a non-free OS in order to download the firmware necessary to install a free OS. ) So, I could not install this laptop over wifi. Now a big deal -- I installed it over a wired LAN, and I suppose I could have done sneakernet itself. I do not think that the hassle was worth sacrificing Debian's principles for. Yes, big deal: the wired LAN of my laptop is e100, and requires firmware IIRC. Senakernet the non-free crap in. One of the principles as I understand it is 'priorities for users'. Too much of this discussion smells like 'SC #1 is more important than SC $4, as long as we DDs know a way to install and configure our machines'. You conveneintly fail to read SC#5. That ius how we fulfil SC#4: we add it in non-free. We already have an installer that supports adding non-free
Re: call for seconds: on firmware
Manoj Srivastava wrote: On Tue, Nov 18 2008, Marc 'HE' Brockschmidt wrote: Robert Millan [EMAIL PROTECTED] writes: On Mon, Nov 17, 2008 at 08:08:36AM +0100, Andreas Barth wrote: Though I agree that the release team cannot put any foundation document aside, I don't think the release team is overriding the social contract, but chooses a certain interpretation (that I think is the correct one btw). Other people obviously prefer a different interpretation, and so the relevant question is: Whose interpretation is the binding one? Currently, it seems to me that unless decided otherwise by a GR, the release team has the final say (as explained by Russ). When you say chooses a certain interpretation, are you referring to the one in which SC #4 is interpreted in a way that cannot be complied with no matter what, only to use this impossibility as proof that SC #4 and SC #1 contradict each other, and in turn resolving that because the SC is inconsistent, SC #1 is meant to be read figuratively? I discussed this with Andi in the past, so let me answer: From our point of view, SC#4 is relatively clear: Our users need to be able to use a stable release of Debian and the free software community (not free software!) needs us to spread the use of _free_ software. Driving off people to another distribution because we have found yet another sequence of magic numbers that might, or might not, have source code somewhere is a clear violation of SC#4 in our eyes. It is your Myopia about §5 that is distressing; you seem to selectively read the SC as it benefits your views. , | 5. Works that do not meet our free software standards | | We acknowledge that some of our users require the use of works that | do not conform to the Debian Free Software Guidelines. We have | created `contrib' and `non-free' areas in our archive for these | works. The packages in these areas are not part of the Debian | system, although they have been configured for use with Debian. We | encourage CD manufacturers to read the licenses of the packages in | these areas and determine if they can distribute the packages on | their CDs. Thus, although non-free works are not a part of Debian, | we support their use and provide infrastructure for non-free | packages (such as our bug tracking system and mailing lists). ` The SC never said that we include things that violate DFSG #2 , | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. ` Note that firmware is no program AFAICS... to be in main; it even states that `contrib' and `non-free' areas in our archive have been designed for that. This selective reading of the SC is one reason I believe the release team is in violation of the social contract. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18 2008, Luk Claes wrote: Note that firmware is no program AFAICS... I do not think I agree. I think it is indeed a software program, and I am not alone: ,[ http://en.wikipedia.org/wiki/Computer_software ] | Firmware which is software programmed(sic) resident to electrically | programmable memory devices on board mainboards or other types of | integrated hardware carriers ` Frankly, a software program may be loaded into parts of the computer heavily dependent on the processor that will run the program instructions; the processor can be designed to read instructions from core memory, magnetic tape, field programmable gate arrays, hardware registers . Putting in hardware design details into foundation documents seems weird; and as the number of processors and cores explode, with new GPU's (which used to be video cards) now being able to perform computations for the so called central processor, the boundary between computations performed on the multiplying number and kinds of processors in a computer is going to get rapidly blurred. The DFSG has lasted us oer a decade. In another decade, I think the distinction of central and periphery and Cell processors is likely to erode; and our DFSG definition should be forward looking. manoj -- It is better to be bow-legged than no-legged. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Tue, Nov 18, 2008 at 12:12:18PM -0600, Manoj Srivastava wrote: On Tue, Nov 18 2008, Luk Claes wrote: Note that firmware is no program AFAICS... I do not think I agree. I think it is indeed a software program, and I am not alone: ,[ http://en.wikipedia.org/wiki/Computer_software ] | Firmware which is software programmed(sic) resident to electrically | programmable memory devices on board mainboards or other types of | integrated hardware carriers It's software, which is programmed [...] (in)to [flash], as I read it. I.e. the programmed up there pertains to the way the firmware is put onto the device, not what the firmware is in itself. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Johannes Wiedersich [EMAIL PROTECTED] writes: Ben Finney wrote: The Debian system we provide is usable. There may be devices which are not yet operable with Debian, Which wireless card is supported by debian without any sourceless firmware, either loaded by the kernel or present on the chip? Whether loaded by the kernel or present on the chip, we have promised that works without source code will not be distributed in Debian. Would you imply that wireless networking should never be usable by debian users, if it turns out that publication of sourcecode is illegal in countries like the US or the EU? Debian users can get whatever non-free stuff they feel motivated to get from the same type of places they've always been available: direct from the vendor, or from some other party that is not breaking a promise by distributing it to them. Even, according to our social contract, from the ‘non-free’ collection. -- \ “Homer, where are your clothes?” “Uh... dunno.” “You mean Mom | `\dresses you every day?!” “I guess; or one of her friends.” | _o__)—Lisa Homer, _The Simpsons_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le Tue, Nov 18, 2008 at 12:12:18PM -0600, Manoj Srivastava a écrit : The DFSG has lasted us oer a decade. In another decade, I think the distinction of central and periphery and Cell processors is likely to erode; and our DFSG definition should be forward looking. Hi Manoj, I completerly agree. How about allowing the Project to release Lenny without changing the DFSG? Despite forward-looking as strong as I can, I do not see people using the microcontroller of their wireless cards for anything else than controlling their wireless cards. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
ke, 2008-11-19 kello 07:58 +0900, Charles Plessy kirjoitti: Manoj, I completerly agree. How about allowing the Project to release Lenny without changing the DFSG? That is what Manoj proposed on 2008-11-10 in http://lists.debian.org/debian-vote/2008/11/msg00060.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le Wed, Nov 19, 2008 at 06:36:12AM +0200, Lars Wirzenius a écrit : ke, 2008-11-19 kello 07:58 +0900, Charles Plessy kirjoitti: Manoj, I completerly agree. How about allowing the Project to release Lenny without changing the DFSG? That is what Manoj proposed on 2008-11-10 in http://lists.debian.org/debian-vote/2008/11/msg00060.html Hi Lars, Manoj and everybody. I apologise for the noise I caused by overlooking the proposal. It completely fits what I would like to vote for (after Further discussion). Have a nice day -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Mon, Nov 17, 2008 at 08:08:36AM +0100, Andreas Barth wrote: I believe that one of the arguments used is that by doing so, the RT would be overriding a foundation document, and developers cannot do so without $higher_power. Though I agree that the release team cannot put any foundation document aside, I don't think the release team is overriding the social contract, but chooses a certain interpretation (that I think is the correct one btw). Other people obviously prefer a different interpretation, and so the relevant question is: Whose interpretation is the binding one? Currently, it seems to me that unless decided otherwise by a GR, the release team has the final say (as explained by Russ). When you say chooses a certain interpretation, are you referring to the one in which SC #4 is interpreted in a way that cannot be complied with no matter what, only to use this impossibility as proof that SC #4 and SC #1 contradict each other, and in turn resolving that because the SC is inconsistent, SC #1 is meant to be read figuratively? I think we discussed this before [1]. In any case, if you think the SC is so badly broken, you should be ammending the text to disambiguigate it, like we did in GR 2004 / 003, or even in GR 2003 / 003. [1] http://lists.debian.org/debian-vote/2008/11/msg00039.html -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16, 2008 at 06:02:00PM +0100, Josselin Mouette wrote: What they are not empowered to do is to decide to release with DFSG violations in main. Sorry? The release team is empowered to release, and that includes releasing with some known RC bugs. That’s what they’ve been doing – including with DFSG-freeness RC bugs – since I have known this project. The Social Contract doesn’t say anything about stable releases, nor about the release team. The interpretation that the release team is somehow special is your own. Why would it have to? Knowingly violating the Social Contract is not allowed anywhere in the project, not just in stable releases. The fact that other participants did (either intentionally or unintentionally) is by no means an excuse for the Release Team to do the same. -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
* Robert Millan ([EMAIL PROTECTED]) [081117 16:26]: On Sun, Nov 16, 2008 at 06:02:00PM +0100, Josselin Mouette wrote: What they are not empowered to do is to decide to release with DFSG violations in main. Sorry? The release team is empowered to release, and that includes releasing with some known RC bugs. That’s what they’ve been doing – including with DFSG-freeness RC bugs – since I have known this project. The Social Contract doesn’t say anything about stable releases, nor about the release team. The interpretation that the release team is somehow special is your own. Why would it have to? Knowingly violating the Social Contract is not allowed anywhere in the project, not just in stable releases. The fact that other participants did (either intentionally or unintentionally) is by no means an excuse for the Release Team to do the same. Stop your FUD. The Release Team isn't violating the Social Contract. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
(Quote attribution elided on purpose.) Stop your FUD. The Release Team isn't violating the Social Contract. It is my opinion that releasing lenny with known DFSG violations is a violation of the Social Contract, on the part of the project as a whole, regardless of which individuals are making the decisions. I further think that including sourceless firmware in main is a DFSG violation. It is my firm belief that the decision to violate the SC with a release should be taken by the project as a whole, via a GR, and that individual members, whether delegated or not, cannot make that decision. Based on recent discussions it seems to me that the release team is attempting to release lenny speedily and taking on itself to decide that the SC violation is acceptable. Thus, I think Robert is correct: the release team is violating the Social Contract. Further, I find it unacceptable to attack him for attempting to discuss this (mostly in a constructive manner, no less) and attempting to have the project decide on this via a GR. I would find it unacceptable even if it turned out that Robert was wrong. We should refute his arguments by counter-arguments based on fact, not by harrassing him. So far, most people disagreeing with Robert seem to be counter-arguing him, not his arguments. I understand that the people most involved in release management find it very frustrating that the freeze is taking a long time, but taking that frustration out on Robert is not the way to solve this. I also understand that the firmware issue is quite controversial in Debian. That's a reason to think carefully, not to blast out personal attacks. Or, indeed, to blast out lots of e-mails on this topic at all. On the whole, this discussion has had little sanity, and even less thoughtfulness, courtesy, and civility. Shame on us. For the record, I'm all for releasing lenny with the current known sourceless firmware included, like we did for sarge and etch. Every release gets better than the previous in this regard, so there's progress. However, I do not see that the previous votes are justification for automatically taking the same decision for lenny, without voting. I might even vote for a decision to have a permanent release exception, although I wouldn't vote for including sourceless firmware in main. I admit that given how little I've helped with lenny during its entire development cycle I have little ground to stand on, but I am not going to let that get in my way to the soap box. Thank you for listening. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Manoj Srivastava wrote: The proposers and sponsors of option 5 didn't propose this as an amendment to the current GR. Why should they have to *withdraw* the proposal in order to get it considered separately at a later time? They only need to do so to prevent it from being on the current ballot. I think it would be a pity of any of the 6 options is withdrawn, since any of them could lend us relief from the current mess wrt Lenny release. Why? The option was proposed as GR on it's own and it was seconded this way. Even if I can see where you're coming from in merging it into the current GR, that's not what was asked for. Do we now need a GR to tell the secretary that a proposed and seconded GR should not be merged into other GRs? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Robert Millan [EMAIL PROTECTED] writes: On Mon, Nov 17, 2008 at 08:08:36AM +0100, Andreas Barth wrote: Though I agree that the release team cannot put any foundation document aside, I don't think the release team is overriding the social contract, but chooses a certain interpretation (that I think is the correct one btw). Other people obviously prefer a different interpretation, and so the relevant question is: Whose interpretation is the binding one? Currently, it seems to me that unless decided otherwise by a GR, the release team has the final say (as explained by Russ). When you say chooses a certain interpretation, are you referring to the one in which SC #4 is interpreted in a way that cannot be complied with no matter what, only to use this impossibility as proof that SC #4 and SC #1 contradict each other, and in turn resolving that because the SC is inconsistent, SC #1 is meant to be read figuratively? I discussed this with Andi in the past, so let me answer: From our point of view, SC#4 is relatively clear: Our users need to be able to use a stable release of Debian and the free software community (not free software!) needs us to spread the use of _free_ software. Driving off people to another distribution because we have found yet another sequence of magic numbers that might, or might not, have source code somewhere is a clear violation of SC#4 in our eyes. This is also the reason why I am unhappy about the 3:1/1:1 discussion: From my point of view, releasing with possibly sourceless firmware blobs is what the SC asks us to do, so these options should be 1:1. Not doing that would violate it, so those options should require a 3:1 majority. Now, other people, including our secretary, have quite a different opinion. The problem here is that the secretary's opinion is actually more important than mine, because Manoj can decide the majority requirements. And that sucks - not because Manoj doesn't share my opinion, but because his opinion has a bigger influence on the outcome of this than mine. I think we discussed this before [1]. In any case, if you think the SC is so badly broken, you should be ammending the text to disambiguigate it, like we did in GR 2004 / 003, or even in GR 2003 / 003. What, more editorial changes? This is going to be a lot of fun. Marc -- BOFH #333: A plumber is needed, the network drain is clogged pgp11AqMYJkIz.pgp Description: PGP signature
Re: call for seconds: on firmware
* Manoj Srivastava [Sat, 15 Nov 2008 17:38:56 -0600]: That does not seem to make sense. Either you have 'none of this non-free crap in the archive ever' or you have 'the release team downgrades these bugs and includes non-free crap' Not both. Which is why they are on the same ballot. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want to allow firmware in main independently of what the Release Team thinks? How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want Lenny not to be blocked by firmware issues even if the Release teams changes their mind and remove the lenny-ignore tags? Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The pure and simple truth is rarely pure and never simple. -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
This one time, at band camp, Adeodato Simó said: * Manoj Srivastava [Sat, 15 Nov 2008 17:38:56 -0600]: That does not seem to make sense. Either you have 'none of this non-free crap in the archive ever' or you have 'the release team downgrades these bugs and includes non-free crap' Not both. Which is why they are on the same ballot. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want to allow firmware in main independently of what the Release Team thinks? How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want Lenny not to be blocked by firmware issues even if the Release teams changes their mind and remove the lenny-ignore tags? Or the vote that I suspect would be a reasonably common one if the vote allowed it: I don't want firmware in main, but I want the Release Team to have the freedom to allow it for Lenny. Which was really the starting point of this whole round of proposals. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: call for seconds: on firmware
On Sun, Nov 16, 2008 at 12:13:25PM +, Robert Millan wrote: On Sun, Nov 16, 2008 at 08:54:17AM +0100, Stefano Zacchiroli wrote: Let me observe that the fact that several people here think is not authoritative. That said, I disagree with point (ii) of your interpretation: i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iV Do we modify foundation documents: No v Do we override foundation documentsNo it should rather be Yes: Instead of having a long, useless discussion on what Further discussion means, would it be possible to remove that option? Correct me if I am wrong, but I think for any interpretation of what Further Discussion would mean in this vote, there's an explicit option in the ballot. Further discussion means none of the ballot options seems right to me, I prefer we discuss this again. IOW it's the statu quo, it solves nothing, it means please draft a new ballot. I see no problem with such a meaning, it's always what it has meant. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpHMHlZedbOU.pgp Description: PGP signature
Re: call for seconds: on firmware (was: on firmware (possible proposal))
Hi, On Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader wrote: On Wed, 12 Nov 2008, Peter Palfrader wrote: I so didn't want to get into this discussion, but here goes anyway. I'm considering formally proposing this GR (option): I'm hereby proposing the following general resolution: | Firmware is data such as microcode or lookup tables that is loaded into | hardware components in order to make the component function properly. | It is not code that is run on the host CPU. | | Unfortunately such firmware often is distributed as so-called blobs, | with no source or further documentation that lets us learn how it works | or interacts with the hardware in question. By excluding such firmware | from Debian we exclude users that require such devices from installing | our operating system, or make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. Looking for seconds now. I'm hereby seconding this proposal. Regards, Patrick signature.asc Description: Digital signature
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Stefano Zacchiroli wrote: On Sat, Nov 15, 2008 at 04:24:18PM -0800, Russ Allbery wrote: Hm, no, the impression that I got from this discussion that at least several people here think the result of Further discussion is: Let me observe that the fact that several people here think is not authoritative. That said, I disagree with point (ii) of your interpretation: i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iV Do we modify foundation documents: No v Do we override foundation documentsNo it should rather be Yes: ii Do we allow the Release Team to ignore SC violation bugs: Yes Rationale: with further discussion nothing changes. Today RMs are empowered, by delegation, to decide upon transitions and lenny-ignore tags. It will be the same tomorrow if further discussion wins. What they are not empowered to do is to decide to release with DFSG violations in main. If you think there is such a powere delegated to them, you need to show that these powers are there with the DPL in the first place, or that they belong to the RM. So, sure, they can ad whatever tags they wish to the BTS. But the release Lenny woth stuff the SC says we will not have in the Debian system, sorry, no. If people disagree with that, they can overrule delegates' decision as supported by our constitution. Err, it should not come to that, since they would be exceeding their authority in the first place (releasing something that the SC says Debian shall not). BTW, this is yet another hint that separate ballots would have been better, because we are implicitly calling for another GR in some special case, but unfortunately Dato's proposal to split ballots doesn't seem to have gained enough momentum. We can have a spearate vote on what to do post lenny, if people still want that. But currently, with the issue on how to go about releasing lenny, all these proposals are related. manoj -- 'Tis true, 'tis pity, and pity 'tis 'tis true. Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_ Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Stephen Gran wrote: Or the vote that I suspect would be a reasonably common one if the vote allowed it: I don't want firmware in main, but I want the Release Team to have the freedom to allow it for Lenny. As far as the lenny release is concerned, how is this different from letting the RM's decide option? Either the GR decides, or the RM's decide, perhaps basing on how far above the furhter discussion the no firmware in main option is? Seems like either the GR says something definitive about firmware in main, or it delegates the decision to the RMs. Which the ballot allows. manoj somewhat confused -- We don't have to protect the environment -- the Second Coming is at hand. James Watt Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Adeodato Simó wrote: * Manoj Srivastava [Sat, 15 Nov 2008 17:38:56 -0600]: That does not seem to make sense. Either you have 'none of this non-free crap in the archive ever' or you have 'the release team downgrades these bugs and includes non-free crap' Not both. Which is why they are on the same ballot. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want to allow firmware in main independently of what the Release Team thinks? At this point, I think we should decide about Lenny. So the vote should be to allow firmware in main. We can then have another vote just about changing the SC to allow the rlease team to make Debian non-free when they so decide, separately. If you think such an option should be on the current ballot, please propose one, and call for seconds. So I suppose this is me saying there could be multiple votes, if sponsors so desire, but the release lenny vote has all the options on the ballot, since releasing Lenny can happen via any of these mechanisms. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want Lenny not to be blocked by firmware issues even if the Release teams changes their mind and remove the lenny-ignore tags? So currently vote for what you want to happen for Lenny. We can have a different vote about changing the SC and the constitution later. I think we can be reasonably sure that the current spate of discussions is about releasing Lenny. For this action, any of the ballot options will have a distinct decision; and the ballot should have _all_ the possible courses of action for that decision. If, later, people want to try out changes to the SC/constitution, they can have their separate vote. Since we are in a hurry to release Lenny, the what to do with Lenny vote comes first. I'll be happy to run independent votes on any issue after that decision has been taken. I also think that the Lenny release hanging over our heads is tainting the discussion of the other options, but that is just my personal opinion. manoj -- It is easier to fight for principles than to live up to them. Alfred Adler Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le samedi 15 novembre 2008 à 19:39 -0600, Manoj Srivastava a écrit : Hm, no, the impression that I got from this discussion that at least several people here think the result of Further discussion is: i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iV Do we modify foundation documents: No v Do we override foundation documentsNo and that seems to be consistent with what Manoj is ruling about overrides of the SC. This is my reading, yes. As far as I see, the SC is pretty clear, and leaves us no other option. It seems very convenient to decide at the same time that further discussion equals proposition #1 and that other propositions require 3:1 majority. This means that, if proposition #1 fails to gather 1:1 majority and other propositions fail to gather 3:1 (a very likely outcome), you get to decide that proposition #1 applies anyway. It makes me feel uneasy. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: call for seconds: on firmware
On Sunday 16 November 2008, Manoj Srivastava wrote: I think we can be reasonably sure that the current spate of discussions is about releasing Lenny. For this action, any of the ballot options will have a distinct decision; and the ballot should have _all_ the possible courses of action for that decision. If the current vote is going to be interpreted that way then any option that _modifies_ foundation documents is not relevant and does not add to the GR. The same goes for options that _structurally_ allow the RT to allow violations. Those are clearly long-term decisions, which apparently you feel should be decided separately. I therefore propose to remove Proposals 5 and 6 on your list [1] from this vote and to hold a separate vote on them later. IMO the then remaining proposals still cover all relevant scenarios for the release of Lenny (as proposal 3 basically covers 5 with a restriction to Lenny). The current ballot really is highly inconsistent and confusing with your interpretation of it. This does leave the problem whether a delay of a vote on GR proposals that have received sufficient seconds is allowed, but possibly if the proposers of 5 and 6 agree we should just do that. Cheers, FJP [1] http://lists.debian.org/debian-vote/2008/11/msg00186.html signature.asc Description: This is a digitally signed message part.
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Josselin Mouette wrote: Le dimanche 16 novembre 2008 à 10:04 -0600, Manoj Srivastava a écrit : ii Do we allow the Release Team to ignore SC violation bugs: Yes Rationale: with further discussion nothing changes. Today RMs are empowered, by delegation, to decide upon transitions and lenny-ignore tags. It will be the same tomorrow if further discussion wins. What they are not empowered to do is to decide to release with DFSG violations in main. Sorry? The release team is empowered to release, and that includes releasing with some known RC bugs. That’s what they’ve been doing – including with DFSG-freeness RC bugs – since I have known this project. The Social Contract doesn’t say anything about stable releases, nor about the release team. The interpretation that the release team is somehow special is your own. The social contract says that the debian system and all its components will be 100% free, free as determined by the dfsg. DFSG says that free means source code. The constitution says that superseding a foundation document needs a 3:1 majority vote, not a handful of people. Downgrading reports of SC violation to ignore and releasing that seems like a weaselly end run around promises we made just for convenience, I am sure that the RMs are not going to stoop to that. manoj -- genlock, n.: Why he stays in the bottle. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Le dimanche 16 novembre 2008 à 11:24 -0600, Manoj Srivastava a écrit : The social contract says that the debian system and all its components will be 100% free, free as determined by the dfsg. All its components include the unstable suite as well. Why are you focusing on the release team when hundreds of other developers (yes, that includes you) ignored the DFSG violations as well by not fixing them? Downgrading reports of SC violation to ignore and releasing that seems like a weaselly end run around promises we made just for convenience, I am sure that the RMs are not going to stoop to that. I can’t wait to see you pull on your black leather uniform and whip the release managers while they stoop. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Frans Pop wrote: On Sunday 16 November 2008, Manoj Srivastava wrote: I think we can be reasonably sure that the current spate of discussions is about releasing Lenny. For this action, any of the ballot options will have a distinct decision; and the ballot should have _all_ the possible courses of action for that decision. If the current vote is going to be interpreted that way then any option that _modifies_ foundation documents is not relevant and does not add to the GR. The same goes for options that _structurally_ allow the RT to allow violations. Those are clearly long-term decisions, which apparently you feel should be decided separately. No, I don't really feel quite that way. Yes, some of the options on this ballot have long term impact, but they are also equally capable of solving our What to do about Lenny problems. Since they all solve the Lenny issue, they are relevant, and related, solutions for the issue. I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. manoj -- Tcl tends to get ported to weird places like routers. Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
First of all, please stop the obnoxious cross-posting. It makes the threads unreadable anyway. (If you could stop the condescending and pedantic tone, that would help as well, but I guess that would be asking too much of you.) Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? It’s not that your interpretation of the Social Contract is flawed; but it is only your interpretation. The secretary is not a superhuman – unless he is leading a double life chasing evil aliens at night, but that would be irrelevant to Debian – and as such it would be inappropriate to consider only his interpretation as valid. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: call for seconds: on firmware
Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? The secretary isn't a delegate. The secretary has special powers explicitly listed in the Constitution that are not available to the DPL or to a delegate and a selection process mandated by the Constitution that isn't the same as delegation. It’s not that your interpretation of the Social Contract is flawed; but it is only your interpretation. The secretary is not a superhuman – unless he is leading a double life chasing evil aliens at night, but that would be irrelevant to Debian – and as such it would be inappropriate to consider only his interpretation as valid. However, the Constitution does that, so far as I can tell. A 3:1 majority can, of course, change the Constitution, which would effectively overturn the decision of the secretary. Alternately, you could try to convince the secretary that the project membership has reached an opposite consensus under 7.3. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Pierre Habouzit wrote: On Sun, Nov 16, 2008 at 06:04:32PM +, Josselin Mouette wrote: First of all, please stop the obnoxious cross-posting. It makes the threads unreadable anyway. (If you could stop the condescending and pedantic tone, that would help as well, but I guess that would be asking too much of you.) Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? I believe the sense of the vote is to clarify the DFSG and that there is no consensus on the matter. We could decide a 3:1 majority to say that firmwares are subject to the DFSG _as well_ as for saying that the firmwares are _not_ subject to the DFSG. The SC is pretty clear about everything in the Debian system (which includes image .debs) should be 100% free. Not just things in the Debian system that run on a host CPU (what is that, anyway) are free. How we define free is the DFSG. So, since everything in the Debian system is free, everything must pass the DFSG. There is no ambiguity here. manoj -- By golly, I'm beginning to think Linux really *is* the best thing since sliced bread. -- Vance Petree, Virginia Power Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 16 novembre 2008 à 12:43 -0800, Russ Allbery a écrit : It’s not that your interpretation of the Social Contract is flawed; but it is only your interpretation. The secretary is not a superhuman – unless he is leading a double life chasing evil aliens at night, but that would be irrelevant to Debian – and as such it would be inappropriate to consider only his interpretation as valid. However, the Constitution does that, so far as I can tell. No. The Secretary has the power to interpret the Constitution (§7.1.3) but not the Social Contract. Hm, good point. In fact, looking at it from that angle, it looks like interpretation of the foundation documents when it comes to work in Debian follows the normal decision-making process in Debian, since it's not an issue of the Constitution. That means that the primary decision rests with individual developers doing their own work (section 3), overridable by the DPL or a delegate of the DPL (section 5 and 8), which in turn is overridable by a General Resolution (section 4). Given that no GR has been passed to specifically override the release team decision, I think it's fairly clear that a vote of further discussion would leave the decision with the previous decision-making body, in this case the release team as DPL delegates. There doesn't appear to be anything in the Constitution that would allow anyone else to override the release team's interpretation of the foundation documents. I think that for a GR to be relevant, it would need to specifically fall under point 3 of section 4.1 (although I suppose one could read an action on the foundation documents under point 5 to implicitly fall under point 3 as well). The GR we passed for etch says nothing about what we do for lenny and hence couldn't override a release team decision for lenny. Manoj, am I misinterpreting something here? The question isn't what the SC says, but rather who gets to decide what it means and how it applies to their work. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16, 2008 at 09:01:38PM +, Manoj Srivastava wrote: On Sun, Nov 16 2008, Pierre Habouzit wrote: On Sun, Nov 16, 2008 at 06:04:32PM +, Josselin Mouette wrote: First of all, please stop the obnoxious cross-posting. It makes the threads unreadable anyway. (If you could stop the condescending and pedantic tone, that would help as well, but I guess that would be asking too much of you.) Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? I believe the sense of the vote is to clarify the DFSG and that there is no consensus on the matter. We could decide a 3:1 majority to say that firmwares are subject to the DFSG _as well_ as for saying that the firmwares are _not_ subject to the DFSG. The SC is pretty clear about everything in the Debian system (which includes image .debs) should be 100% free. Not just things in the Debian system that run on a host CPU (what is that, anyway) are free. The SC speaks about software, and doesn't define it. I believe software is what is interpreted or run on the host CPU, firmware is in a gray area. All is a matter of interpretation and I believe we have to settle that, once and for all. Firmwares are not going to disappear anytime soon, and playing that game for each release is destroying us from the inside. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp1VdzGVVoZV.pgp Description: PGP signature
Differing standards of freedom for different bitstreams (was: call for seconds: on firmware)
Ben Finney [EMAIL PROTECTED] writes: This gives no argument for why such bitstreams should be held to different standards of freedom for its recipients. The properties “not code that is run on the host CPU” is mentioned, but seems to be irrelevant to the argument. Can you re-write this so it's clear why this particular class of bitstream should not be held to the same freedom standards as everything else in Debian? I've seen quite a number of seconds for Peter Palfrader's proposal, yet have not seen an answer to my question above. If this proposal passes, it seems to me that the result is the establishment of a contradiction between: | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, […] versus SC §1: 1. Debian will remain 100% free […] We promise that the Debian system and all its components will be free according to [the DFSG] […] We will never make the system require the use of a non-free component. Those two cannot, by my reading, be simultaneously true. Surely some significant number of those who second the proposal must have a rational way to reconcile “Debian will remain 100% free” with the differing standards of freedom proposed by Peter? -- \ “Oh, I realize it's a penny here and a penny there, but look at | `\ me: I've worked myself up from nothing to a state of extreme | _o__) poverty.” —Groucho Marx | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16, 2008 at 10:20:05PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 09:01:38PM +, Manoj Srivastava wrote: The SC is pretty clear about everything in the Debian system (which includes image .debs) should be 100% free. Not just things in the Debian system that run on a host CPU (what is that, anyway) are free. The SC speaks about software, and doesn't define it. The statement that Manoj refers to, above, does *not* speak about software. 1. 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. There is no need to define “software” for this promise to be understood. It explicitly promises that “the Debian system and all its components will be free”. This bit doesn't require the so called source of the work to exist within Debian explicitly. It asks for any component in Debian to meet the DFSG. In turn however, the DFSG requires that in their §2. The DFSG use a mix of component, software, program words, which makes them a mess in that regard. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpbw00qNQvtU.pgp Description: PGP signature
Defining free, and the DFSG's terminological shortcomings (was: call for seconds: on firmware)
Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 10:20:05PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: The SC speaks about software, and doesn't define it. The statement that Manoj refers to, [SC §1], does *not* speak about software. […] There is no need to define “software” for this promise to be understood. It explicitly promises that “the Debian system and all its components will be free”. This bit doesn't require the so called source of the work to exist within Debian explicitly. It asks for any component in Debian to meet the DFSG. Okay. So, at least, we agree that the promise that Debian will remain 100% free does not depend on the term “software”. In turn however, the DFSG requires that in their §2. The DFSG use a mix of component, software, program words, which makes them a mess in that regard. That seems to be an argument for proposing a re-wording of the DFSG, so that freedoms are defined without referring to that mess of terms. I would agree that could be a good motivation in principle. -- \“Human reason is snatching everything to itself, leaving | `\ nothing for faith.” —Saint Bernard, 1090–1153 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Defining free, and the DFSG's terminological shortcomings (was: call for seconds: on firmware)
On Sun, Nov 16, 2008 at 11:15:10PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 10:20:05PM +, Ben Finney wrote: Pierre Habouzit [EMAIL PROTECTED] writes: The SC speaks about software, and doesn't define it. The statement that Manoj refers to, [SC §1], does *not* speak about software. […] There is no need to define “software” for this promise to be understood. It explicitly promises that “the Debian system and all its components will be free”. This bit doesn't require the so called source of the work to exist within Debian explicitly. It asks for any component in Debian to meet the DFSG. Okay. So, at least, we agree that the promise that Debian will remain 100% free does not depend on the term “software”. It depends on the DFSG which depends on term software. So yes, it doesn't depend _directly_ on the term software. In turn however, the DFSG requires that in their §2. The DFSG use a mix of component, software, program words, which makes them a mess in that regard. That seems to be an argument for proposing a re-wording of the DFSG, so that freedoms are defined without referring to that mess of terms. I would agree that could be a good motivation in principle. Yes, I believe the DFSG are clumsy when it comes to its terms. Component is clear. Firmwares are part of Debian components for sure, there is absolutely no doubt about that. But I'm honnestly not sure what programs or software mean, and in §2 that's the terms in use, and that's the sole § causing issues with them. We have had quite a few rounds of GRs to say that documentations, images, documentation, fonts... are softwares, we could continue such rounds, or make the DFSG clearer. I would be more on the latter side. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQMCq5QBjdT.pgp Description: PGP signature
Re: call for seconds: on firmware
On Sun, Nov 16, 2008 at 01:17:08PM -0800, Russ Allbery wrote: Given that no GR has been passed to specifically override the release team decision, I think it's fairly clear that a vote of further discussion would leave the decision with the previous decision-making body, in this case the release team as DPL delegates. I believe that one of the arguments used is that by doing so, the RT would be overriding a foundation document, and developers cannot do so without $higher_power. Note: I'm not giving any opinion either way as to what a FD vote means. Personally, I think it's a 'send it back to the drawing board' item, and I'd need to further think about that that entails regarding the current position. Neil -- * Maulkin cries Maulkin NB: rm -rf /chroots/sarge while /home is mounted at /chroots/sarge/home is NOT-A-GOOD-THING(tm) signature.asc Description: Digital signature
Re: call for seconds: on firmware
Neil McGovern [EMAIL PROTECTED] writes: On Sun, Nov 16, 2008 at 01:17:08PM -0800, Russ Allbery wrote: Given that no GR has been passed to specifically override the release team decision, I think it's fairly clear that a vote of further discussion would leave the decision with the previous decision-making body, in this case the release team as DPL delegates. I believe that one of the arguments used is that by doing so, the RT would be overriding a foundation document, and developers cannot do so without $higher_power. Sure, and this is something that I always thought too, but I don't see this anywhere in the Constitution. But even more fundamentally, I think the question of whether this decision actually overrides the SC is part of the dispute. People have in this thread put forward reasons why they don't think firmware may violate the current SC (including Manoj, for that matter), so it's not like it's completely inconceivable to reconcile the RT position with the SC. Given that, someone has to decide which reading of the SC applies, and as near as I can tell from the Contitution, in the absence of a GR overriding their decision, the RT is empowered as delegates to make such decisions with regard to the release. Or if the DPL doesn't think the delegation includes making such a judgement, the individual developers uploading the packages are empowered to make that decision unless overruled by the DPL or a delegate. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16, 2008 at 11:42:19AM -0600, Manoj Srivastava wrote: I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. The proposers and sponsors of option 5 didn't propose this as an amendment to the current GR. Why should they have to *withdraw* the proposal in order to get it considered separately at a later time? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Pierre Habouzit [EMAIL PROTECTED] wrote: [...] [SC 1] doesn't require the so called source of the work to exist within Debian explicitly. It asks for any component in Debian to meet the DFSG. In turn however, the DFSG requires that in their §2. The DFSG use a mix of component, software, program words, which makes them a mess in that regard. Quite right! We need some editorial changes to fix this(!) Except we already tried that, with the social contract, not long before madcoder joined. Surely no-one joining in 2005 could be ignorant of what SC 1 applies to, given all the noise in 2004? Actually, the DFSG don't use component, software or program but some of the explanations/illustrations do. I think the DFSG could be written exactly, maybe using some system of formal symbols, and there would *still* be disagreements about the meaning. The price of freedom is eternal vigilance, sadly. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Russ Allbery wrote: Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 16 novembre 2008 à 12:43 -0800, Russ Allbery a écrit : It’s not that your interpretation of the Social Contract is flawed; but it is only your interpretation. The secretary is not a superhuman – unless he is leading a double life chasing evil aliens at night, but that would be irrelevant to Debian – and as such it would be inappropriate to consider only his interpretation as valid. However, the Constitution does that, so far as I can tell. No. The Secretary has the power to interpret the Constitution (§7.1.3) but not the Social Contract. Hm, good point. In fact, looking at it from that angle, it looks like interpretation of the foundation documents when it comes to work in Debian follows the normal decision-making process in Debian, since it's not an issue of the Constitution. That means that the primary decision rests with individual developers doing their own work (section 3), overridable by the DPL or a delegate of the DPL (section 5 and 8), which in turn is overridable by a General Resolution (section 4). Manoj, am I misinterpreting something here? The question isn't what the SC says, but rather who gets to decide what it means and how it applies to their work. Sure. I, as secretary (as opposed to with other developers in a GR) can not, and ahve never said I can, decide for the release team how to interpret the SC. I have said that my personal read on this is that the firmware blobs are not source code, so unless we decide to override the DFSG, we can't release. As secretary, I can say that the foundation documents can't be superseded or overridden by the DPL or delegates. So, if the release team states that they are not violating the SC, and can defend that stance, they are within their rights -- and the people who do not like that can, via GR, override their decision. But the release team can't say they decided to bend the rules and disregard the SC, since the power to do so is not granted by the constitution. manoj -- Meekness is uncommon patience in planning a worthwhile revenge. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Pierre Habouzit wrote: On Sun, Nov 16, 2008 at 09:01:38PM +, Manoj Srivastava wrote: On Sun, Nov 16 2008, Pierre Habouzit wrote: On Sun, Nov 16, 2008 at 06:04:32PM +, Josselin Mouette wrote: First of all, please stop the obnoxious cross-posting. It makes the threads unreadable anyway. (If you could stop the condescending and pedantic tone, that would help as well, but I guess that would be asking too much of you.) Le dimanche 16 novembre 2008 à 11:34 -0600, Manoj Srivastava a écrit : So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. So another delegate (the secretary) should make the decision instead? I believe the sense of the vote is to clarify the DFSG and that there is no consensus on the matter. We could decide a 3:1 majority to say that firmwares are subject to the DFSG _as well_ as for saying that the firmwares are _not_ subject to the DFSG. The SC is pretty clear about everything in the Debian system (which includes image .debs) should be 100% free. Not just things in the Debian system that run on a host CPU (what is that, anyway) are free. The SC speaks about software, and doesn't define it. I believe software is what is interpreted or run on the host CPU, firmware is in a gray area. All is a matter of interpretation and I believe we have to settle that, once and for all. Firmwares are not going to disappear anytime soon, and playing that game for each release is destroying us from the inside. I tend to agree with: http://en.wikipedia.org/wiki/Computer_software Back when I voted on the social contract, and now, I believe that everything computer related that is not hardware (or wetware), is software/. The article also states: Firmware which is software programmed resident to electrically programmable memory devices on board mainboards or other types of integrated hardware carriers So, there seem to be a wide spread view that firmware are indeed software. I think that an entity, like a program, can have multiple representations: * It starts life as wetware, when I think through the steps needed * It may have a stint as hardware (something tanngible), when I print it out, or write it out using pen and paper * When encoded as 0/1 and 1. it is in a software representation. I believe now, as I did then, that everything we distribute on a CD, being encoded in 0s and 1s, is software. manoj -- Every man is as God made him, ay, and often worse. Miguel de Cervantes Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sun, Nov 16 2008, Steve Langasek wrote: On Sun, Nov 16, 2008 at 11:42:19AM -0600, Manoj Srivastava wrote: I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. The proposers and sponsors of option 5 didn't propose this as an amendment to the current GR. Why should they have to *withdraw* the proposal in order to get it considered separately at a later time? They only need to do so to prevent it from being on the current ballot. I think it would be a pity of any of the 6 options is withdrawn, since any of them could lend us relief from the current mess wrt Lenny release. As to future votes, anyone may propose a failed option on any vote for a fresh look anytime they so desire. manoj -- Our business is run on trust. We trust you will pay in advance. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Mon, Nov 17, 2008 at 01:27:26AM +, MJ Ray wrote: Quite right! We need some editorial changes to fix this(!) Except we already tried that, with the social contract, not long before madcoder joined. Surely no-one joining in 2005 could be ignorant of what SC 1 applies to, given all the noise in 2004? Actually, the DFSG don't use component, software or program but some of the explanations/illustrations do. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. You seem to be saying that everything after the title is merely explanation/illustration and not a binding part of the DFSG. That doesn't make any sense. Just reading the titles of each of the DFSG doesn't tell you what the guidelines are. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
* Neil McGovern ([EMAIL PROTECTED]) [081117 00:27]: On Sun, Nov 16, 2008 at 01:17:08PM -0800, Russ Allbery wrote: Given that no GR has been passed to specifically override the release team decision, I think it's fairly clear that a vote of further discussion would leave the decision with the previous decision-making body, in this case the release team as DPL delegates. I believe that one of the arguments used is that by doing so, the RT would be overriding a foundation document, and developers cannot do so without $higher_power. Though I agree that the release team cannot put any foundation document aside, I don't think the release team is overriding the social contract, but chooses a certain interpretation (that I think is the correct one btw). Other people obviously prefer a different interpretation, and so the relevant question is: Whose interpretation is the binding one? Currently, it seems to me that unless decided otherwise by a GR, the release team has the final say (as explained by Russ). Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware (was: on firmware (possible proposal))
On Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader wrote: | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and So do the licenses for all those blobs we have now comply with the DFSG other than that we don't have the source for it? Does this mean that even if the blob is GPL'd, we don't need sources for it? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware (was: on firmware (possible proposal))
On Sat, Nov 15, 2008 at 8:24 PM, Kurt Roeckx [EMAIL PROTECTED] wrote: Does this mean that even if the blob is GPL'd, we don't need sources for it? That sounds like it would be a GPL violation. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Paul Wise wrote: On Sat, Nov 15, 2008 at 8:24 PM, Kurt Roeckx [EMAIL PROTECTED] wrote: Does this mean that even if the blob is GPL'd, we don't need sources for it? That sounds like it would be a GPL violation. Only if the blob is not the actual source, no? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sat, Nov 15, 2008 at 10:49 PM, Luk Claes [EMAIL PROTECTED] wrote: Paul Wise wrote: On Sat, Nov 15, 2008 at 8:24 PM, Kurt Roeckx [EMAIL PROTECTED] wrote: Does this mean that even if the blob is GPL'd, we don't need sources for it? That sounds like it would be a GPL violation. Only if the blob is not the actual source, no? Presumably. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Hi, This is how things stand: The Situation: We are close to releasing Lenny The Problem: The kernels we are shipping have blobs that might not meet the DFSG, and some might be in violation of the kernel's GPL license. This would put them in conflict with the SC. The proposed solutions below all try to address the basic issue of releasing while meeting the promises made in the SC. A new proposal has been seconded, which extends the minimum discussion period by a week (I think the relevant second came in at 14 Nov 2008 22:53:07). If the proposers do not submit the wml that should go up as the vote page, I'll make up the wording for the vote web page. Here is the handy seconds registry. I hope I have recorded all seconds, and recorded their sponsorship correctly, please let me know if I have missed anything. (I have also simplified the summation formula below) |+---+---+---+---++| || 1 | 2 | 3 | 4 | 5 | 6 | |+---+---+---+---++| | Robert Millan [EMAIL PROTECTED]| 1 | 1 | 1 | | 1 | | | Bas Wijnen [EMAIL PROTECTED] | 1 | | | ||| | Manoj Srivastava [EMAIL PROTECTED] | 1 | 1 | | | 1 || | Holger Levsen [EMAIL PROTECTED] | 1 | 1 | 1 | 1 || 1 | | Peter Samuelson [EMAIL PROTECTED] | 1 | 1 | 1 | || | | Hubert Chathi [EMAIL PROTECTED] | 1 | 1 | 1 | ||| | Andreas Barth [EMAIL PROTECTED]| | | | 1 ||| | Alexander Reichle-Schmehl [EMAIL PROTECTED] | | | | 1 || 1 | | Reinhard Tartler [EMAIL PROTECTED] | | | | 1 ||| | Bernd Zeimetz [EMAIL PROTECTED] | | | | 1 | 1 | 1 | | Neil McGovern [EMAIL PROTECTED] | | | | 1 | 1 | | | Frans Pop [EMAIL PROTECTED] | | 1 | 1 | || 1 | | [EMAIL PROTECTED] (Rémi Vanicat) | 1 | 1 | 1 | 1 ||| | John H. Robinson, IV [EMAIL PROTECTED] | | | | | 1 || | Lars Wirzenius [EMAIL PROTECTED]| | | | | 1 || | Damyan Ivanov [EMAIL PROTECTED] | | | | | 1 | | | Colin Tuckley [EMAIL PROTECTED] | | | | | 1 | 1 | | Pierre Habouzit [EMAIL PROTECTED] | | | | | 1 || | Gunnar Wolf [EMAIL PROTECTED] | | | | | 1 | | | Peter Palfrader [EMAIL PROTECTED]| | | | || 1 | | Russ Allbery [EMAIL PROTECTED] | | | | || 1 | | Martin Michlmayr [EMAIL PROTECTED] | | | | || 1 | | Steve McIntyre [EMAIL PROTECTED] | | | | || 1 | | Mark Hymers [EMAIL PROTECTED] | | | | || 1 | | Moritz Muehlenhoff [EMAIL PROTECTED]| | | | || 1 | | Ben Pfaff [EMAIL PROTECTED]| | | | || 1 | | Cyril Brulebois [EMAIL PROTECTED] | | | | || 1 | |+---+---+---+---++| || 7 | 7 | 6 | 7 | 10 | 13 | |+---+---+---+---++| #+TBLFM: @29$2=vsum(@2..-I)::@29$3=vsum(@2..-I)::@29$4=vsum(@2..-I)::@29$5=vsum(@2..-I)::@29$6=vsum(@2..-I)::@29$7=vsum(@2..-I) Since some people have had trouble reading the proposals, I am including a short impact of the proposal list below the proposal. ,[ Proposal 1: reaffirm the Social Contract ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that we promised to deliver a 100% free operating system | (Social Contract #1); | | 3. Given that we have known for two previous releases that we have | non-free bits in various parts of Debian, 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 (to the best of our knowledge as of 1 November 2008). ` i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iv Do we modify foundation documents: No v Do we override foundation documentsNo ,[ Proposal 2: allow Lenny to release with proprietary firmware ] | 1.
Re: call for seconds: on firmware
Peter Palfrader's proposal [1] explicitly said, and I quote: | I'm hereby proposing the following general resolution. I don't think it's acceptable to bundle it up with the ongoing GR, since it was not proposed as an amendment to it. [1]: http://lists.debian.org/debian-vote/2008/11/msg00164.html -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The problem I have with making an intelligent statement is that some people then think that it's not an isolated occurrance. -- Simon Travaglia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware (was: on firmware (possible proposal))
On Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader wrote: I'm hereby proposing the following general resolution: | Firmware is data such as microcode or lookup tables that is loaded into | hardware components in order to make the component function properly. | It is not code that is run on the host CPU. | | Unfortunately such firmware often is distributed as so-called blobs, | with no source or further documentation that lets us learn how it works | or interacts with the hardware in question. By excluding such firmware | from Debian we exclude users that require such devices from installing | our operating system, or make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. Seconded. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Release Assistant `. `' xmpp:[EMAIL PROTECTED] Stable Release Manager `-finger pkern/[EMAIL PROTECTED] signature.asc Description: Digital signature
Re: call for seconds: on firmware (was: on firmware (possible proposal))
This one time, at band camp, Peter Palfrader said: | Firmware is data such as microcode or lookup tables that is loaded into | hardware components in order to make the component function properly. | It is not code that is run on the host CPU. | | Unfortunately such firmware often is distributed as so-called blobs, | with no source or further documentation that lets us learn how it works | or interacts with the hardware in question. By excluding such firmware | from Debian we exclude users that require such devices from installing | our operating system, or make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. I assume we have enough seconds by now, but since I said I would, I second this proposal. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: call for seconds: on firmware
,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and free software. We don't trade | them against each other. However during getting an release out of the | door, decisions need to be done how to get a rock stable release of the | high quality Debian is known for, release more or less on time, and to | minimize the usage of problematic software. We acknowledge that there | is more than just one minefield our core developers and the release | team are working at. | We as Developers at large continue to trust our release team to follow | all these goals, and therefor encourage them to continue making | case-by-case-decisions as they consider fit, and if necessary | authorize these decisions. | (Since this option overrides the SC, I believe it would require 3:1 | majority) Also, this one should not be voted together with the rest, since it's an orthogonal issue. This not /exclusively/ a solution for the problem for Lenny. We can ask the proposer of this option what he thinks, if you don't agree it should be split out. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Dar Williams - You Rise And Meet The Day -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware (was: on firmware (possible proposal))
* Peter Palfrader ([EMAIL PROTECTED]) [081114 21:01]: On Wed, 12 Nov 2008, Peter Palfrader wrote: I so didn't want to get into this discussion, but here goes anyway. I'm considering formally proposing this GR (option): I'm hereby proposing the following general resolution: | Firmware is data such as microcode or lookup tables that is loaded into | hardware components in order to make the component function properly. | It is not code that is run on the host CPU. | | Unfortunately such firmware often is distributed as so-called blobs, | with no source or further documentation that lets us learn how it works | or interacts with the hardware in question. By excluding such firmware | from Debian we exclude users that require such devices from installing | our operating system, or make it unnecessarily hard for them. | | Therefore the Debian project resolves that | a) firmware in Debian does not have to come with source. While we do | prefer firmware that comes with source and documentation we will not | require it, | b) we however do require all other freedoms that the DFSG mandate from | components of our operating system, and | c) such firmware can and should be part of our official installation media. Looking for seconds now. seconded. Cheers, Andi signature.asc Description: Digital signature
Re: call for seconds: on firmware
On Sat, Nov 15 2008, Adeodato Simó wrote: Peter Palfrader's proposal [1] explicitly said, and I quote: | I'm hereby proposing the following general resolution. I don't think it's acceptable to bundle it up with the ongoing GR, since it was not proposed as an amendment to it. I have explained why I think all these proposals are related (they all affect releasing lenny while kernels contain firmware blobs, and some of the solutions have effects that are more far reaching than others). Since they are related, they belong on the same ballot -- even if they were not all formally declared to be amendments of the original proposal. Our voting methods do not deal well with related options being on separate ballots. manoj -- Imitation is the sincerest form of television. The New Mighty Mouse Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sat, Nov 15 2008, Adeodato Simó wrote: ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and free software. We don't trade | them against each other. However during getting an release out of the | door, decisions need to be done how to get a rock stable release of the | high quality Debian is known for, release more or less on time, and to | minimize the usage of problematic software. We acknowledge that there | is more than just one minefield our core developers and the release | team are working at. | We as Developers at large continue to trust our release team to follow | all these goals, and therefor encourage them to continue making | case-by-case-decisions as they consider fit, and if necessary | authorize these decisions. | (Since this option overrides the SC, I believe it would require 3:1 | majority) Also, this one should not be voted together with the rest, since it's an orthogonal issue. This not /exclusively/ a solution for the problem for Lenny. We can ask the proposer of this option what he thinks, if you don't agree it should be split out. While some of the proposals have longer lasting effects than just the current release, they are still related: for example, the proposal singled out above, if passed, would make proposal 5 moot, and invalidate proposal 1. Given that these proposals are strongly related, they should be on the ballot together. Post Lenny, if we do want to change our foundation documents, we can try and do so; but splitting out options on how to handle the release of lenny in view of firmware blobs, and the apparent conflict with the SC, would result in a botched decision. Serial votes with subsets of options really lend themselves to tactical voting our voting method is not designed to deal with. manoj -- Screw up your courage! You've screwed up everything else. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
Josselin Mouette [EMAIL PROTECTED] writes: Le samedi 15 novembre 2008 à 09:45 -0600, Debian Project Secretary a écrit : | (Since this option overrides the SC, I believe it would require 3:1 | majority) So you get to decide which options need 3:1 majority? Well, yes. Constitution section 7.1, point 3. I don’t understand why you decide that we need a 3:1 majority to allow release managers to release lenny, while we do not require such a fuss to allow kernel or glibc developers to knowingly violate the social contract at each upload. Why should we consider the stable release process differently from our other processes? I don't think it's that unreasonable to consider our releases to be the primary output of our development process. If nothing else, it's rather hard to keep from never violating the SC temporarily by simple mistake during unstable development, and treating the release as the point at which we have to clear all that up provides a firm boundary for what temporary will be in temporary violations. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: call for seconds: on firmware
On Sat, Nov 15 2008, Josselin Mouette wrote: Le samedi 15 novembre 2008 à 09:45 -0600, Debian Project Secretary a écrit : | (Since this option overrides the SC, I believe it would require 3:1 | majority) So you get to decide which options need 3:1 majority? I thought it was clear that the constitution spelled out that amending a foundation document requires the majority. If you want to supersede a (part of a) foundation document, the majority comes into play. §4.1.5, etc. I don’t understand why you decide that we need a 3:1 majority to allow release managers to release lenny, while we do not require such a fuss to allow kernel or glibc developers to knowingly violate the social contract at each upload. Why should we consider the stable release process differently from our other processes? We should not. Ideally, having agreed to the social contract and the DFSG, Debian developers should be working hard to remove non-DFSG compliant stuff out of main. However, we are human, and there can be bugs in our packages during the work-in-progress stage. Most reasonable people can agree that it takes time to fix bugs, so Sid has bugs, and some of these are DFSG violation bugs. However, our release of the Debian system is what we produce, and we have promised that the Debian system shall be 100% free. I do think upholding the SC should be a goal for all DD's at any time, but YMMV. manoj -- Oh Dad! We're ALL Devo! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
