Proposed wording for the SC modification
Le samedi 15 novembre 2008 à 09:45 -0600, Debian Project Secretary a écrit : ,[ 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 Since the proponents have not yet formulated a new version for the changes to the foundation documents, here it is. 8 - - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - - DFSG #2 will be changed to the following: 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. However, as a special exception, firmware is exempted from the source code requirement. 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. 8 - - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - - I guess it still needs to be approved by the proponents. -- .''`. : :' : 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: Proposed wording for the SC modification
On Mon, 17 Nov 2008, Josselin Mouette wrote: This will need wording to change the SC Since the proponents have not yet formulated a new version for the changes to the foundation documents, here it is. This is not part of my GR as proposed and seconded. If anybody wants to change the words of either the DFSG or the SC they will need to propose an amendmend. As proposed this clarifies my and other people's view of what our foundation documents mean. You are welcome to add a note/comment/explanation to the SC, but this doesn't modify it. Thanks. -- | .''`. ** 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: Proposed wording for the SC modification
Le Mon, Nov 17, 2008 at 02:05:40PM +0100, Peter Palfrader a écrit : If anybody wants to change the words of either the DFSG or the SC they will need to propose an amendmend. As proposed this clarifies my and other people's view of what our foundation documents mean. You are welcome to add a note/comment/explanation to the SC, but this doesn't modify it. Hi Peter, the problem is that we were told that voting for your amendment makes it necessary to organise a vote to change the DFSG or the SC… I really understand your position, but apparently it is not me or you who decides. Can the Secretary clarify again what will hapen if Peter's option is voted ? - What if Peter does not think that a second vote is necessary, but the Secretary does ? - What if a second vote is organised, but not option gets a 3:1 majority ? - What if no second vote is organised ? - What if Peter's option is voted with less than a 3:1 majority ? 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: Proposed wording for the SC modification
Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. Therefore I think we should decide on a new wording before the vote instead of letting someone else decide on it. -- .''`. : :' : 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: Proposed wording for the SC modification
* Josselin Mouette [Mon, 17 Nov 2008 14:38:43 +0100]: Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. Therefore I think we should decide on a new wording before the vote instead of letting someone else decide on it. Can the SC be modified without a second vote? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joaquín Sabina - Los cuentos que yo cuento -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
This one time, at band camp, Josselin Mouette said: Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. As has been pointed out elsewhere, the Secretary's job is to interpret the constitution, not the SC. I'm not convinced that the secretary can mandate that a GR changes the SC. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
On Sun, Nov 16, 2008 at 09:20:13AM -0800, Steve Langasek wrote: On Sun, Nov 16, 2008 at 01:24:56PM +0100, Bernd Zeimetz wrote: The only thing you're doing is to make Lenny the release with the longest freeze time ever. Not that I disagree with the rest, but I don't think Robert has much chance of displacing sarge from that position of honor. Why would I want that? Honestly, the time wasted on this whole GR cycle is orders of magnitude more than the time it would have taken to just finish removing the sourceless firmware from the main kernel package and support loading it from the installer. Maybe, but that wouldn't have solved the actual problem. Which is, a selected group taking decisions about major issues without the endorsement of the project. Careful; given the uncompromising zealotry of the people arguing for the removal of sourceless firmware at all costs, Please would you (all) stop referring to these imaginary uncompromising zealots arguing imaginary things that I don't recall even reading in this discussion? The only zealots here are those who want to impose their view on the rest of the project. It happens they won't be able to, because a vote is already scheduled. Whatever we decide now, it will be by consensus. -- 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: DFSG violations in Lenny
On Sun, Nov 16, 2008 at 12:46:44PM -0800, Russ Allbery wrote: This is exactly why I'm going to be voting for one of the options that modifies the foundation documents and establishes a permanent and unambiguous decision. I think this has gone on far, far too long and wastes way too much time and energy, and it's clear that it's never going to be considered resolved short of a modification of the foundation documents, given that hardware requirements for firmware are not going to magically disappear. They probably won't, but there are no hardware requirements that prevent firmware source code from being distributed under a free license. -- 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: Proposed wording for the SC modification
- Peter Palfrader [EMAIL PROTECTED] wrote: This is not part of my GR as proposed and seconded. If anybody wants to change the words of either the DFSG or the SC they will need to propose an amendmend. As proposed this clarifies my and other people's view of what our foundation documents mean. You are welcome to add a note/comment/explanation to the SC, but this doesn't modify it. A desktop with a host cpu and components with firmware is directly analogous to a small cluster of computers. There is no *real* difference between a host programming its RAID controller and a cluster manager handing a blade its boot image. You are engaging in a mental evasion that, for you, allows your proposal to make sense. If you want this proposal to become law then you must come to terms with the fact that you are asking the project to distribute small non-free programs for execution on a variety of (usually) simplified architectures attached to the system by some network/bus. In the case of graphics, TOE, iSCSI and RAID the attached controller may not even be that much less capable than the host. Trying to differentiate between a USB bus and an Ethernet network in any meaningful way just blurs the picture further. I have drivers installed that upload firmware to my MIDI keyboard. I extracted the firmware from the windows executable they shipped me. Is my usb-attached sythensizer a computer? Do you want my Windows EXE extracted firmware in main? I can probably get m-Audio to approve us including it. You are asking the project to distribute a certain class of non-free software out of convenience. To square that act with our social contract you must alter our social contract's meaning. There is no way around it. Remember, the point of Debian is to keep code off of your computer that you can't understand (or at least have the opportunity to understand). If you don't have the source for your machine's behavior, or are locked out of it, you can't know for sure what it is doing with your information. We want to be sure and so do our *real* users. ps. Take all of that with a grain of salt since I agree that we should release Lenny with continued *temporary* exceptions for problematic, popular firmware. -- 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: Discussion: granting discretion to release team (was: Call for seconds: DFSG violations in Lenny)
On Mon, Nov 17, 2008 at 12:10:07AM +0100, Pierre Habouzit wrote: I would welcome a more permanent answer to the firmware question, really, I'm not really pleased with the trolls that arise on the subject prior to every release. May I ask who are those trolls you refer to? -- 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: Discussion: granting discretion to release team (was: Call for seconds: DFSG violations in Lenny)
Le lundi 17 novembre 2008 à 16:04 +0100, Robert Millan a écrit : On Mon, Nov 17, 2008 at 12:10:07AM +0100, Pierre Habouzit wrote: I would welcome a more permanent answer to the firmware question, really, I'm not really pleased with the trolls that arise on the subject prior to every release. May I ask who are those trolls you refer to? Maybe Robert Millan? -- .''`. : :' : 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: Discussion: Are you tal^Wtrolling to me?
Josselin Mouette [EMAIL PROTECTED] (17/11/2008): I'm not really pleased with the trolls that arise on the subject prior to every release. May I ask who are those trolls you refer to? Maybe Robert Millan? Given his asking “who” rather than “what”, looks like a rather nice candidate. Mraw, KiBi. signature.asc Description: Digital signature
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: Proposed wording for the SC modification
On Mon, Nov 17 2008, Stephen Gran wrote: This one time, at band camp, Josselin Mouette said: Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. As has been pointed out elsewhere, the Secretary's job is to interpret the constitution, not the SC. I'm not convinced that the secretary can mandate that a GR changes the SC. I think the only way to reconcile the constitution with the GR is to have a 3:1 vote, and subsequently to modify the foundation document. We can't just supersede a foundation document otherwise. manoj -- Q: What do you get when you cross a mobster with an international standard? A: You get someone who makes you an offer that you can't understand! 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: Proposed wording for the SC modification
On Mon, Nov 17 2008, Peter Palfrader wrote: On Mon, 17 Nov 2008, Josselin Mouette wrote: This will need wording to change the SC Since the proponents have not yet formulated a new version for the changes to the foundation documents, here it is. This is not part of my GR as proposed and seconded. If anybody wants to change the words of either the DFSG or the SC they will need to propose an amendmend. As proposed this clarifies my and other people's view of what our foundation documents mean. You are welcome to add a note/comment/explanation to the SC, but this doesn't modify it. You are making a permanent change to the statement made in the DFSG (all programs need source code); this is being passed with a 3:1 majority, so of course the foundation documnents will have to be changed. The only way to supersede the foundation document, as defined in the constitution, is to change it via a 3:1 vote. This is the only way to reconcile the GR with the constitution, in my opinion. manoj -- If all men were brothers, would you let one marry your sister? Author Unknown 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 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: Proposed wording for the SC modification
On Mon, Nov 17 2008, Adeodato Simó wrote: * Josselin Mouette [Mon, 17 Nov 2008 14:38:43 +0100]: Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. Therefore I think we should decide on a new wording before the vote instead of letting someone else decide on it. Can the SC be modified without a second vote? I don't see why we need a second 3:1 vote on a foundation document after having a 3:1 vote that supersedes part of it. manoj -- Before destruction a man's heart is haughty, but humility goes before honour. Psalms 18:12 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: Proposed wording for the SC modification
On Mon, Nov 17 2008, Charles Plessy wrote: the problem is that we were told that voting for your amendment makes it necessary to organise a vote to change the DFSG or the SC… I really understand your position, but apparently it is not me or you who decides. Can the Secretary clarify again what will hapen if Peter's option is voted ? That GR clearly refines the DFSG statement that all programs need source code. This supersedes the current DFSG, which allows for no such exception. So the we need to amend the FSG wiht the changes after the 3:1 vote. (Aside, on a personal note, anything else, to me, smells of deceptive and underhanded handling of our social contract). - What if Peter does not think that a second vote is necessary, but the Secretary does ? We need to see if the constitution mandates a second 3:1 vote after a first 3:1 vote to supersede some dictum of a foundation document. - What if a second vote is organised, but not option gets a 3:1 majority ? - What if no second vote is organised ? - What if Peter's option is voted with less than a 3:1 majority ? Then it fails. The interesting question is if Peter's options wins the 3:1 majority, but loses to another option on the ballot. I suppose a second vote can then be proposed separately to add the firmware exception to the DFSG. manoj -- Backed up the system lately? 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: Proposed wording for the SC modification
On Mon, Nov 17, 2008 at 10:19:49PM +0900, Charles Plessy wrote: Can the Secretary clarify again what will hapen if Peter's option is voted ? - What if Peter does not think that a second vote is necessary, but the Secretary does ? - What if a second vote is organised, but not option gets a 3:1 majority ? - What if no second vote is organised ? - What if Peter's option is voted with less than a 3:1 majority ? Is this really so important? If a 3:1 majority that supports this exists, they can easily ammend the SC as they see fit, possibly with another GR to decide whether to ammend it or just override it. If a simple majority exists, but not a 3:1 one, then we're in for stormy weather. Too bad. Note that I don't like 3:1 requisites either [1], but since I had to accept it when it was against my preferred choice [2], it's only fair that others do the same now. [1] http://www.debian.org/vote/2003/gr_sec415_tally.txt [2] http://www.debian.org/vote/2004/gr_non_free_tally.txt -- 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: Proposed wording for the SC modification
* Manoj Srivastava [Mon, 17 Nov 2008 09:32:33 -0600]: On Mon, Nov 17 2008, Adeodato Simó wrote: * Josselin Mouette [Mon, 17 Nov 2008 14:38:43 +0100]: Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. Therefore I think we should decide on a new wording before the vote instead of letting someone else decide on it. Can the SC be modified without a second vote? I don't see why we need a second 3:1 vote on a foundation document after having a 3:1 vote that supersedes part of it. And who is going to modify it if the original vote does not include a wording? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joaquín Sabina - A la orilla de la chimenea -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
On Mon, Nov 17, 2008 at 04:50:50PM +0100, Adeodato Simó wrote: * Manoj Srivastava [Mon, 17 Nov 2008 09:32:33 -0600]: On Mon, Nov 17 2008, Adeodato Simó wrote: * Josselin Mouette [Mon, 17 Nov 2008 14:38:43 +0100]: Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. Therefore I think we should decide on a new wording before the vote instead of letting someone else decide on it. Can the SC be modified without a second vote? I don't see why we need a second 3:1 vote on a foundation document after having a 3:1 vote that supersedes part of it. And who is going to modify it if the original vote does not include a wording? Guys, I think this is not productive. If the vote wins, it won't be by chance, it will mean there's a 3:1 majority that supports this change. At that point, if the wording is contentious, you can always propose another vote to resolve that. And looking at what others (e.g. Peter) had to say about this, it seems the position among those who support sourceless firmware is not unanimous. This would have to be resolved in some way, too. Either with a new vote, or by adding a new option to this ballot. -- 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]
civility in discussions
Hi, Folks, calling people discussion here trolls or lying, sniveling, unethical non-free lovers intent on destroying Debian's good name does nothing to promote a decent discussion, and does not belong on this list, in my opinion. If you want to call people nasty names, take it off list, please. manoj -- Justice is incidental to law and order. Edgar Hoover 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: DFSG violations in Lenny
On Mon, Nov 17, 2008 at 02:39:31PM +, Robert Millan wrote: It happens they won't be able to, because a vote is already scheduled. Whatever we decide now, it will be by consensus. Voting is not a way to achieve consensus, it's a way to take a decision when consensus failed. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpMbvKde1hl6.pgp Description: PGP signature
Re: civility in discussions
On Mon, Nov 17, 2008 at 10:17:04AM -0600, Manoj Srivastava wrote: Hi, Folks, calling people discussion here trolls or lying, sniveling, unethical non-free lovers intent on destroying Debian's good name does nothing to promote a decent discussion, and does not belong on this list, in my opinion. If you want to call people nasty names, take it off list, please. manoj Agreed. Though I'm new to this specific list, I just subscribed to find a plethora of name calling and insults. I feel like I'm back on gentoo-user, when I used to use Gentoo. Can we please keep the flames down to a minimum, or at least take it to private mail? -- Follow my Tweets at http://twitter.com/pobega AIM:BlockMeHarder MSN:[EMAIL PROTECTED] JIM:[EMAIL PROTECTED] SIP:[EMAIL PROTECTED] ICQ:467047394 signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, Nov 17, 2008 at 03:39:31PM +0100, Robert Millan wrote: On Sun, Nov 16, 2008 at 09:20:13AM -0800, Steve Langasek wrote: Careful; given the uncompromising zealotry of the people arguing for the removal of sourceless firmware at all costs, Please would you (all) stop referring to these imaginary uncompromising zealots arguing imaginary things that I don't recall even reading in this discussion? It's not zealotry if the firmware goes against the DFSG. I mean, why would you write a set of rules/guidelines only to break them? -- Follow my Tweets at http://twitter.com/pobega AIM:BlockMeHarder MSN:[EMAIL PROTECTED] JIM:[EMAIL PROTECTED] SIP:[EMAIL PROTECTED] ICQ:467047394 signature.asc Description: Digital signature
Re: Proposed wording for the SC modification
On Mon, Nov 17, 2008 at 04:50:50PM +0100, Adeodato Simó wrote: And who is going to modify it if the original vote does not include a wording? If a vote supersedes a part of a foundation document but does not specify editing instructions, I believe the only correct thing to do is to add the actual decision as an addendum to the original document (like the US does with its constitutional amendments). A later vote could then decide to strike that addendum and incorporate it in the document as a change in wording, but that's just cosmetics. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Proposed wording for the SC modification
On Mon, Nov 17, 2008 at 08:44:45AM -0600, Ean Schuessler wrote: A desktop with a host cpu and components with firmware is directly analogous to a small cluster of computers. There is no *real* difference between a host programming its RAID controller and a cluster manager handing a blade its boot image. Sure there is, the RAID controller doesn't run Debian GNU/Linux; it just runs some uploaded microcode. Your blade will run Debian GNU/Linux (or whatever else you hand it to). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
* Manoj Srivastava [Mon, 17 Nov 2008 09:38:19 -0600]: The interesting question is if Peter's options wins the 3:1 majority, but loses to another option on the ballot. I suppose a second vote can then be proposed separately to add the firmware exception to the DFSG. Is only interesting because we're not voting it in a separate ballot to begin with. I don't understand how you're reckoning a second vote could be needed if it passes 3:1 but does not win, and don't accept to run a separate vote first, as Peter requested. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joaquín Sabina - Flores en la tumba de un vasquito -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
* Robert Millan ([EMAIL PROTECTED]) [081117 15:28]: On Sun, Nov 16, 2008 at 09:20:13AM -0800, Steve Langasek wrote: Honestly, the time wasted on this whole GR cycle is orders of magnitude more than the time it would have taken to just finish removing the sourceless firmware from the main kernel package and support loading it from the installer. Maybe, but that wouldn't have solved the actual problem. Which is, a selected group taking decisions about major issues without the endorsement of the project. But this selected group has the endorsement of the project, see [EMAIL PROTECTED], by the constitution that we all agreed to hold up, and by the decisions of officers under roles of the constitution. That you personally don't agree is of course ok, but that doesn't make the decision unconstitutional. You are of course also free to try to override the decision by an GR, details see the constitution. But please stop telling FUD about the way Debian works. Thanks. The only zealots here are those who want to impose their view on the rest of the project. So you agree that you're an zealot? Ok, seems to be consistent with your behaviour. Cheers, Andi -- 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: Proposed wording for the SC modification
* Antti-Juhani Kaijanaho ([EMAIL PROTECTED]) [081117 18:02]: On Mon, Nov 17, 2008 at 04:50:50PM +0100, Adeodato Simó wrote: And who is going to modify it if the original vote does not include a wording? If a vote supersedes a part of a foundation document but does not specify editing instructions, I believe the only correct thing to do is to add the actual decision as an addendum to the original document (like the US does with its constitutional amendments). A later vote could then decide to strike that addendum and incorporate it in the document as a change in wording, but that's just cosmetics. Even though I think this is ugly, I agree that this is the correct way to handle it. 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: Proposed wording for the SC modification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ean Schuessler wrote: - Peter Palfrader [EMAIL PROTECTED] wrote: This is not part of my GR as proposed and seconded. If anybody wants to change the words of either the DFSG or the SC they will need to propose an amendmend. As proposed this clarifies my and other people's view of what our foundation documents mean. You are welcome to add a note/comment/explanation to the SC, but this doesn't modify it. A desktop with a host cpu and components with firmware is directly analogous to a small cluster of computers. There is no *real* difference between a host programming its RAID controller and a cluster manager handing a blade its boot image. You are engaging in a mental evasion that, for you, allows your proposal to make sense. If you want this proposal to become law then you must come to terms with the fact that you are asking the project to distribute small non-free programs for execution on a variety of (usually) simplified architectures attached to the system by some network/bus. In the case of graphics, TOE, iSCSI and RAID the attached controller may not even be that much less capable than the host. Trying to differentiate between a USB bus and an Ethernet network in any meaningful way just blurs the picture further. I have drivers installed that upload firmware to my MIDI keyboard. I extracted the firmware from the windows executable they shipped me. Is my usb-attached sythensizer a computer? Do you want my Windows EXE extracted firmware in main? I can probably get m-Audio to approve us including it. I would rather ask two different questions: Do you want to install Debian/free software on your computer? Do you want to install Debian/free software on your keyboard/router/other device as well? These are two distinct questions. If you want to run debian and/or free software on your keyboard/router/etc. as well, than you'd have to select the hardware accordingly, ie buy hardware that is fully supported by free software. In this case you would also look out for open source bios and other code that might be present in ROM or other places of your hardware. Actually, I'm quite sure that there are many, many users out there, who want to install and run Debian on their computer, but who can not find a laptop with all the features they require and all the sources available for all the components of the laptop (eg. wireless). There are a lot of users who prefer using Debian + the odd sourceless firmware instead of switching to an even less free alternative. You are asking the project to distribute a certain class of non-free software out of convenience. To square that act with our social contract you must alter our social contract's meaning. There is no way around it. Remember, the point of Debian is to keep code off of your computer that you can't understand (or at least have the opportunity to understand). If you don't have the source for your machine's behavior, or are locked out of it, you can't know for sure what it is doing with your information. We want to be sure and so do our *real* users. The firmware code is kept off your computer. It adds no functionality to the OS compared to other users who have hardware without firmware or hardware with 'firmware stuff' hardwired to the hardware. One might even argue that the firmware is not part of the OS just as the BIOS is not part of the OS (Please, take this with a grain of salt, I don't intend to start new round of hair splitting). Cheers, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkhuQEACgkQC1NzPRl9qEWhDgCfWaRt2La1GUldaaQ3CKlhHo8N MsYAn3ndztPPkCdEOrUXABCTM1zZiZJz =2GEg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
- Michael Banck [EMAIL PROTECTED] wrote: Sure there is, the RAID controller doesn't run Debian GNU/Linux; it just runs some uploaded microcode. Your blade will run Debian GNU/Linux (or whatever else you hand it to). So it would be legitimate to distribute an install image for Windows Mobile cellular phones as a package in main? After all, its firmware. The device won't be running Debian. It will almost certainly have a different architecture than the desktop. Lots of people have cell phones so it will definitely be popular. Can you see any criteria that I'm missing here? -- 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: Proposed wording for the SC modification
Le lundi 17 novembre 2008 à 13:01 -0600, Ean Schuessler a écrit : So it would be legitimate to distribute an install image for Windows Mobile cellular phones as a package in main? No, the proposal wouldn’t allow that since it only lifts DFSG #2. Such an image would still fail DFSG #1, #3, #7, and probably #5 and #6. -- .''`. : :' : 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: Proposed wording for the SC modification
- Josselin Mouette [EMAIL PROTECTED] wrote: Le lundi 17 novembre 2008 à 13:01 -0600, Ean Schuessler a écrit : No, the proposal wouldn’t allow that since it only lifts DFSG #2. Such an image would still fail DFSG #1, #3, #7, and probably #5 and #6. No, it would not. The image is firmware and is not subject to DFSG requirements. -- 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: Proposed wording for the SC modification
Le lundi 17 novembre 2008 à 13:26 -0600, Ean Schuessler a écrit : No, the proposal wouldn’t allow that since it only lifts DFSG #2. Such an image would still fail DFSG #1, #3, #7, and probably #5 and #6. No, it would not. The image is firmware and is not subject to DFSG requirements. Have you actually read Peter’s proposal? -- .''`. : :' : 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: Proposed wording for the SC modification
On Mon, 17 Nov 2008, Manoj Srivastava wrote: On Mon, Nov 17 2008, Stephen Gran wrote: This one time, at band camp, Josselin Mouette said: Le lundi 17 novembre 2008 à 14:05 +0100, Peter Palfrader a écrit : This is not part of my GR as proposed and seconded. The Secretary made it clear that if your proposal wins, the SC *will* be amended. As has been pointed out elsewhere, the Secretary's job is to interpret the constitution, not the SC. I'm not convinced that the secretary can mandate that a GR changes the SC. I think the only way to reconcile the constitution with the GR is to have a 3:1 vote, and subsequently to modify the foundation document. We can't just supersede a foundation document otherwise. The foundation documents are like the law. This GR is like a decree of the government that tells us how the law will be applied. If the GR doesn't explicitely state that it modifies a foundation document, then it doesn't. If you believe that it does implicitely, then you vote against it (or propose an amendment where you explicitely modify the document). But you don't get to decide if the resolution modifies the foundation document or not. At best, you add additionnal notes near the foundation documents for people looking for exegisis. But your current stance is severly hurting our capacity to govern our project and I find it unacceptable (and it's a pity but this problem is not new, we already had this discussion for other votes). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed wording for the SC modification
Ean Schuessler wrote: So it would be legitimate to distribute an install image for Windows Mobile cellular phones as a package in main? After all, its firmware. The device won't be running Debian. It will almost certainly have a different architecture than the desktop. Lots of people have cell phones so it will definitely be popular. Can you see any criteria that I'm missing here? Ean, with all due respect, but I find your contributions to this discussion way below par as apparently you can't even be bothered to read the proposals under discussion. We are NOT discussing a blanket waiver of all DFSG or SC criteria for firmware. The only criterium that is considered for being waived in any practical sense is the one that requires source to be available for the firmware. So, given that we are just for example extremely unlikely to have the right to redistribute Windows Mobile, the answer to your question is a clear and totally undisputed by anyone NO. I would guess that including Windows Mobile would also violate several other of our principles that are not under discussion. So please take your pick. Now that that's been cleared up, can you please either keep your fingers off the keyboard for the remainder of this discussion period, or else start contributing to the discussion in an intelligent fashion? We already know what your position on the issue is, so there's really no need to keep repeating it (the same goes for some others BTW). TIA, FJP P.S. Please fix your mails. You are both breaking threads and CCing people that have not asked to be CCed. signature.asc Description: This is a digitally signed message part.
Re: Proposed wording for the SC modification
On Mon, Nov 17, 2008 at 09:14:41PM +0100, Raphael Hertzog wrote: The foundation documents are like the law. This GR is like a decree of the government that tells us how the law will be applied. A decree of the government does not do that. It gives supplemental rules and regulations compatible with the law (and generally requires a specific authorization in the law, but this varies from jurisdiction to jurisdiction). In any case, GRs are law, not decrees. The proper analogy for a decree would be a Project Leader or Delegate decision. If the GR doesn't explicitely state that it modifies a foundation document, then it doesn't. If you believe that it does implicitely, then you vote against it (or propose an amendment where you explicitely modify the document). The Project Secretary is charged with conducting General Resolution votes, and with judging disputes in the application of the Constitution. As such, the Project Secretary is not really a secretarial position - the best analogy is a chairperson of a decision-making body. As such, I believe it is the Project Secretary's duty (not a right, but duty) to ensure that any proposals and amendments are compatible with the Constitution, and it is also the Project Secretary's duty to refuse to conduct a vote he believes to be contrary to the Constitution. (I do not have an opinion on the actual case at hand. The above are general procedural comments.) -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Proposed wording for the SC modification
- Frans Pop [EMAIL PROTECTED] wrote: Ean, with all due respect, but I find your contributions to this discussion way below par as apparently you can't even be bothered to read the proposals under discussion. We are NOT discussing a blanket waiver of all DFSG or SC criteria for firmware. The only criterium that is considered for being waived in any practical sense is the one that requires source to be available for the firmware. So, given that we are just for example extremely unlikely to have the right to redistribute Windows Mobile, the answer to your question is a clear and totally undisputed by anyone NO. I would guess that including Windows Mobile would also violate several other of our principles that are not under discussion. So please take your pick. Now that that's been cleared up, can you please either keep your fingers off the keyboard for the remainder of this discussion period, or else start contributing to the discussion in an intelligent fashion? We already know what your position on the issue is, so there's really no need to keep repeating it (the same goes for some others BTW). I'm sorry, but I am dense. Please help me understand. If I have a Microsoft device and they provide an opensource Linux installer which ships a Windows Mobile based firmware then how would this not meet your distribution criteria? When considering Silverlight(tm) development tools this use case is not even far-fetched. I made the mistake in my earlier message of saying main. I should have said sourceless. In either case, the firmware in question could be distributed as part of our standard install images. Which part am I getting wrong? -- 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
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: Proposed wording for the SC modification
Ean Schuessler wrote: I'm sorry, but I am dense. Please help me understand. If I have a Microsoft device and they provide an opensource Linux installer which ships a Windows Mobile based firmware then how would this not meet your distribution criteria? When considering Silverlight(tm) development tools this use case is not even far-fetched. I made the mistake in my earlier message of saying main. I should have said sourceless. In either case, the firmware in question could be distributed as part of our standard install images. I guess I must be dense as well, because I really have no idea what you're talking about. Why would we ever want to include something like that in our installer images? How would such a phone be used here? Are we installing Debian onto the phone or what? If I do read you correctly then the installer you are talking about is some user space app that would be used to for example upgrade the firmware in a phone that is _not_ running Debian, but can maybe be connected to a system that does run Debian via USB. I suspect we already have examples of such utilities in Debian, and, as this for its primairy function (firmware update to external device) depends on something that at best belongs in non-free (IF we are allowed to distribute it at all), but is a lot more likely to be downloaded by a user as needed, I'd expect to find that open source installer in contrib. One huge difference here is that this would be a _service_ to the external device (upgrading its firmware while it is already running and usable). In this case loading the firmware onto the device is not a requirement to make it function as a peripheral device to the Debian system, the use case we're primairily interested in. I don't see any use case requiring either this installer of yours or that firmware to end up in our installer images. Anyway, I'd really prefer to concentrate first on the use cases that this GR is actually meant to solve instead of such, at least as far as I understand you (which may well be not at all), contrived, extreme examples. Let's first concentrate on whether we actually want to support those normal use cases and then worry if we maybe need further restrictions or tightening of definitions to prevent abuse in weird use cases. Or, maybe you can propose an amendment that clearly describes the holes you see and intends to close them? In the end there is still always something like common sense in the application of rules too. Problem now is that we have absolutely zero room to maneuver. I intend this to be my last contribution in this part of the thread. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Proposed wording for the SC modification
Le Mon, Nov 17, 2008 at 09:38:19AM -0600, Manoj Srivastava a écrit : On Mon, Nov 17 2008, Charles Plessy wrote: the problem is that we were told that voting for your amendment makes it necessary to organise a vote to change the DFSG or the SC… I really understand your position, but apparently it is not me or you who decides. Can the Secretary clarify again what will hapen if Peter's option is voted ? That GR clearly refines the DFSG statement that all programs need source code. This supersedes the current DFSG, which allows for no such exception. So the we need to amend the FSG wiht the changes after the 3:1 vote. (Aside, on a personal note, anything else, to me, smells of deceptive and underhanded handling of our social contract). - What if Peter does not think that a second vote is necessary, but the Secretary does ? We need to see if the constitution mandates a second 3:1 vote after a first 3:1 vote to supersede some dictum of a foundation document. Hi Manoj, What is the way of seeing if the constitution mandates a second vote? I think that it would be really be helpful if things could be explained in a more operational way. For instance : what does we need to amend means? That it would be better, but that we can continue without? That a vote with no Further discussion will be taken? That the GR will lose its effect if we do not amend the DFSG? Lastly, I read the mail of Lars with a great interest. Is it possible to vote a non-supermajority option stating that we will release Lenny even if it infringes the DFSG? That would nicely solve the problem. 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: Proposed wording for the SC modification
On Mon, 17 Nov 2008, Antti-Juhani Kaijanaho wrote: On Mon, Nov 17, 2008 at 09:14:41PM +0100, Raphael Hertzog wrote: The foundation documents are like the law. This GR is like a decree of the government that tells us how the law will be applied. A decree of the government does not do that. It gives supplemental rules and regulations compatible with the law (and generally requires a specific authorization in the law, but this varies from jurisdiction to jurisdiction). In any case, GRs are law, not decrees. The proper analogy for a decree would be a Project Leader or Delegate decision. Analogies do have limits of course but you get the meaning and I stand behind my logic. In our case the developer body has the right to rule on anything: change the law (parliament), change a delegate's decision (override the government), decide of sanctions (justice, we never did it fortunately) and any analogy with a country will fail due to that. However, here we have delegates (the RM) that have taken a decision and someone believes that the decision was wrong and want to override it. Instead of voting on that (and then creating a sort of jurisprudence) we came up with explanations on how the firmwares should be handled and for me this is exactly like a decree that fills the hole (maybe unintentionaly in our case, intentionaly in real cases probably) that were left in the law. If the GR doesn't explicitely state that it modifies a foundation document, then it doesn't. If you believe that it does implicitely, then you vote against it (or propose an amendment where you explicitely modify the document). The Project Secretary is charged with conducting General Resolution votes, and with judging disputes in the application of the Constitution. As such, the Project Secretary is not really a secretarial position - the best analogy is a chairperson of a decision-making body. As such, I believe it is the Project Secretary's duty (not a right, but duty) to ensure that any proposals and amendments are compatible with the Constitution, and it is also the Project Secretary's duty to refuse to conduct a vote he believes to be contrary to the Constitution. Like has already been said elsewhere, he applies the constitution and has to interpret it. I don't believe that it is his role to interpret the SC/DFSG and decide if a resolution is compatible. We have all agreed to defend the SC/DFSG but obviously we do have differing ways to interpret them and so does the secretary, he should not get a special power here. The developer body decides if a resolution is compatible or not with our foundation documents when they vote on it. If the secretary can't be convinced with this discussion, maybe we should aim at clarifying this in the constitution itself. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- 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
