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: 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: 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: 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: 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: DFSG violations in Lenny
Robert Millan wrote: On Wed, Nov 12, 2008 at 08:48:44AM +0100, Raphael Hertzog wrote: No it's really not funny. I'm sick of reading ad nauseam your opinion. Then don't read it. Me, I'm sick of reading personal attacks, but I choose to read anyway out of responsibility. If you're sick of personal attacks, stop this bullshit and spend your time on something useful. Like fixing RC bugs so Lenny can be released SOON. You're wasting a lot of people's time here, time which could be spent on making Lenny the best release ever. The only thing you're doing is to make Lenny the release with the longest freeze time ever. and I'll support the RM in their difficult job…) So do I. If the project grants them an exception to release Lenny (like we did for Sarge and Etch), I'll support that too. To start the same bullshit again for the next release, a few days before the release? *sigh* Bernd ... who will look for a different distribution to spend his time on, if Robert's proposals will pass the GR. -- 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: DFSG violations in Lenny
- Robert Millan [EMAIL PROTECTED] wrote: Or rather, I propose the following alternative which incorporates Manoj's rewritten #2 (in addition to removing the last sentence in #4): Option 2 (allow Lenny to release with propietary firmware) ~~ 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so. (Since this option overrides the SC, I believe it would require 3:1 majority) This seems rational and pragmatic. I second this proposal. -- 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: DFSG violations in Lenny
- Bas Wijnen [EMAIL PROTECTED] wrote: So what's the problem? We want to provide a 100% free software distribution. Appearantly we currently can't do that. We're far on the way, but not there yet. We may have thought we were there, but we were wrong. So indeed, people currently running Debian don't run a 100% free software system. The simple obvious thing to do, seems to be (to me at least) to remove non-free parts from main, and tell people the truth: currently, we can't offer a 100% free solution, please use this stuff from non-free, we're working on free solutions. Instead you seem to invent a new rule, which says the number of users of Debian must be as high as possible, and you even want to break SC#1 for this rule. I think parallels can be drawn between this situation and the recent financial crisis. Certain banks found a way to bend the rules on what they considered to be good investments. Because they took stable investments to the casino with slanted odds they started to make lots of money. Other banks saw this and began to feel uncomfortable and jealous about what they were seeing and followed suit. Soon, many banks were caving in to their greed and by the time the whistle blew the damage was very deep. As the smoke clears we see that financial institutions who followed their values are the big winners. They stood on rock while others built castles on sand. Just because something is popular doesn't mean its right. The first lesson anyone must learn in the stock market is that following the crowd is a doomed behavior. If you focus on short term results at the expense of long term strategy then, eventually, the value of your organization will disappear. Warren Buffet and his teacher Benjamin Graham say always look for value. I agree that we must be sensible about providing users with a workable product. Let's just make sure thou shalt not steal doesn't turn into steal when convenient. If we must break the rules then please lets do steal when you have no other choice and pay back with interest later. -- 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: DFSG violations in Lenny
Bernd Zeimetz [EMAIL PROTECTED] writes: Robert Millan wrote: So do I. If the project grants them an exception to release Lenny (like we did for Sarge and Etch), I'll support that too. To start the same bullshit again for the next release, a few days before the release? 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. -- 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: DFSG violations in Lenny
On Sun, Nov 16, 2008 at 01:24:56PM +0100, Bernd Zeimetz wrote: Robert Millan wrote: On Wed, Nov 12, 2008 at 08:48:44AM +0100, Raphael Hertzog wrote: No it's really not funny. I'm sick of reading ad nauseam your opinion. Then don't read it. Me, I'm sick of reading personal attacks, but I choose to read anyway out of responsibility. If you're sick of personal attacks, stop this bullshit and spend your time on something useful. Like fixing RC bugs so Lenny can be released SOON. You're wasting a lot of people's time here, time which could be spent on making Lenny the best release ever. 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. 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. Bernd ... who will look for a different distribution to spend his time on, if Robert's proposals will pass the GR. Careful; given the uncompromising zealotry of the people arguing for the removal of sourceless firmware at all costs, statements like this are only likely to encourage them. :P -- 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]
Discussion: granting discretion to release team (was: Call for seconds: DFSG violations in Lenny)
Given that this is supposed to be the discussion period, I'd like to share my standpoint regarding one option. Andreas Barth wrote: | 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. I am extremely hesitant when it comes to this option. In fact, I think it's going to end up below Further discussion on my ballot. The main reason for that is that IMO the main reason that we're having this discussion is that the firmware question was handled rather badly by the current release team (RT). They themselves bear a heavy responsi- bility especially for the way the discussion started (IMO things have now settled down into a fairly reasonable discussion and voting process). We've already had two releases where this was an issue and in both cases it was decided by a GR. Why should the current release team think they could handle it differently? Just compare the way this started (by someone noticing that RC bugs had been tagged lenny-ignore without _any_ prior public discussion) to the way it was handled by the previous release team. For Etch, Steve Langasek *as RM* opened the discussion on debian-vote with this mail: http://lists.debian.org/debian-vote/2006/08/msg00032.html In summary: the previous RT anticipated on the resistance against such waivers, opened a discussion with the project and proposed a resolution to allow the release to go forward. This resulted in a very controlled vote (well, except for ...) and in the end the permission of the project was obtained without any real bloodshed. It's no secret that I've not been happy with the way the current RT has handled a number of things, including for example removals from testing. They seem to think they are mandated a large degree of freedom to beat the archive into shape for the release, no matter the cost and the frustration this may cause developers. IMO this is fundamentally wrong. Important decisions regarding the release, such as waiving structural RC issues, the support of architectures and the removal of packages should be made in discussion with the project at large and *not* by a select team. However careful they are it is impossible that they can correctly weigh all arguments all by themselves, even if only because they are just not aware of all the facts (for which of course they cannot be blamed given the size and diversity of the project). It is especially wrong because the way it is done is largely silent. Only very few people will actually notice the removal of a package or the addition of a tag to a BR when those happen. Most developers will only notice later on, for example when things break. Supporting this option on the ballot would effectively grant the RT broad powers and only increase the kind of problems we've seen in this release cycle. So, although I completely disagree with Robert Milan on his viewpoints regarding firmware, I do thank him for bringing the matter to the attention of the project. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Discussion: granting discretion to release team (was: Call for seconds: DFSG violations in Lenny)
On Sun, Nov 16, 2008 at 10:29:35PM +, Frans Pop wrote: We've already had two releases where this was an issue and in both cases it was decided by a GR. Why should the current release team think they could handle it differently? Maybe because in http://www.debian.org/vote/2004/vote_004 then later in http://www.debian.org/vote/2006/vote_007 there was a large majority of people thinking that the firmwares issues should not postpone a release. Maybe also because AFAICT, all but one firmware issue that were known when etch was released have been addressed. 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. But I really think the project stated strongly and twice that firmwares issues shouldn't postpone a release, hence I think that the RT wasn't abusing its powers while tagging those bugs lenny-ignore, because it was following pre-established consensus. Note that AFAICT I've seen no release team member (myself included) being against the vote. The vote will tell if we took a decision that the project won't endorse, and if it's the case, it will be rescinded. I have absolutely no strong feelings on the subject, unlike you apparently. Unless I'm mistaken, we haven't released Lenny without asking anyone, or sent any rash mail to d-d-a saying we would accept any firmwares without discussion from now on. We've marked bugs lenny-ignore, and you can watch progress on that front on [0]. | 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. I am extremely hesitant when it comes to this option. In fact, I think it's going to end up below Further discussion on my ballot. FWIW, I believe that any delegate that sees one of his decision loose with a decent margin should just resign. I dont think this § from Andi's proposal has any real implication. If the project votes one way or the other than firmwares should not postpone the release, then it will underline that we made the right choice in the first place, and I will feel we did represent the project consensus as delegates. Constitution is clear about this (§8.3): a Delegate must make choices that follow the consensus. I genuinely believe we did, two prior votes are here to support that. If the project rescind our choices with a clear majority, so be it. It will mean that we (and in particular I) don't represent Debian well after all. As a consequence I will resign from my RT membership if that should happen. [0] http://bugs.debian.org/tag:lenny-ignore my point with this URL, is that lenny-ignore tags are highly visible and traceable. It's not an intent of the release team to rub things under the carpet. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpkNCLlCsyc3.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
On Wed, Nov 12, 2008 at 08:48:44AM +0100, Raphael Hertzog wrote: No it's really not funny. I'm sick of reading ad nauseam your opinion. Then don't read it. Me, I'm sick of reading personal attacks, but I choose to read anyway out of responsibility. It smells like you have the truth and you want to impose it. The only individuals in a position to impose anything are Release Team members, and I'm not entitled to force them to comply with the Social Contract; only the project as a whole is. (And yes, I hope your resolution won't pass Which is my resolution? You mean any of the options in which the developers get to decide what we do about Lenny? My hope is that whatever we decide, it is the result of the widest consensus possible, and that it is decided by the developers as a whole, not by a few selected ones. and I'll support the RM in their difficult job…) So do I. If the project grants them an exception to release Lenny (like we did for Sarge and Etch), I'll support that too. -- 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 (new proposal)
On Tue, Nov 11, 2008 at 03:39:40PM +0100, Robert Millan wrote: I'm responding to this by proposing the following alternate option: | The Social Contract is our promise to the free software community. | | Neither the Release Team, nor any selected group of individuals, is | empowered to ammend the Social Contract, or grant exceptions to it; | Only the developers as a whole may do so, subject to the conditions in | section 4 of the Constitution. | | We acknowledge that such exceptions have been granted in the past (for | Sarge and for Etch), and that at the time of writing, a proposal that | might grant a similar exception for Lenny is scheduled to be voted on. | | We encourage any developers who -now and in the future- feel that one such | exception would be justified, to participate in its discussion and try to | reach consensus that can be endorsed by the majority of the project. Subject to the condition that, if my option gets enough sponsors, the Secretary would accept including it with Andreas' in a separate ballot. Seconded. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, 10 Nov 2008, Robert Millan wrote: On Mon, Nov 10, 2008 at 05:47:59PM +0100, Johannes Wiedersich wrote: With binary blobs inside or outside of debian, my computer will run just the same. It's just that outside main it won't be supported by debian -- at least not officially. It will be harder to install, as well. I think I said this before, but I don't mind repeating it ad nauseam ;-) No it's really not funny. I'm sick of reading ad nauseam your opinion. It smells like you have the truth and you want to impose it. (And yes, I hope your resolution won't pass and I'll support the RM in their difficult job…) 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: DFSG violations in Lenny
On Mon, Nov 10 2008, Johannes Wiedersich wrote: On Sun, 9 Nov 2008 19:27:59 +0100 Robert Millan wrote: I think you're trying to imply that somehow SC #1 and SC #4 are not consistent. That is, that our priorities are our users is incompatible with our system being 100% free. They are incompatible. As noted in the thread on debian-devel [1], even debian's own servers won't run debian any more, because they require non-debian firmware. The kernel is not the OS. That is why it is Debian GNU?Linux, not just Linux. And if the firmware is removed, but the re free drviers remain, and we can get the non-free blobs from elsewhere, it will just be Debian + non-free blobs. Frankly, just because I do nt ever use official kernels, and I use nvidia drivers, has not led me to conclude I do not run Debian. That sound bite seems like hyperbole to me, and weakens your argument. manoj -- LILO, you've got me on my knees! (from David Black, [EMAIL PROTECTED], with apologies to Derek and the Dominos, and Werner Almsberger) 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 10, 2008 at 02:23:46PM +0100, Johannes Wiedersich wrote: Debian won't run on a large fraction of hardware any more. ... To restate the obvious: After the transition a lot of current debian users won't be using debian anymore. So what's the problem? We want to provide a 100% free software distribution. Appearantly we currently can't do that. We're far on the way, but not there yet. We may have thought we were there, but we were wrong. So indeed, people currently running Debian don't run a 100% free software system. The simple obvious thing to do, seems to be (to me at least) to remove non-free parts from main, and tell people the truth: currently, we can't offer a 100% free solution, please use this stuff from non-free, we're working on free solutions. Instead you seem to invent a new rule, which says the number of users of Debian must be as high as possible, and you even want to break SC#1 for this rule. No, I don't agree. I don't even agree that this is a good target. We shouldn't have many users as a goal. It may be a means to help free software. But you're trying to argue that we should harm free software for the purpose of getting more users. Let's not do that, please. Note that the SC is quite clear about helping users who need non-free things. We provide infrastructure and such, outside of Debian itself. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manoj Srivastava wrote: On Mon, Nov 10 2008, Johannes Wiedersich wrote: On Sun, 9 Nov 2008 19:27:59 +0100 Robert Millan wrote: I think you're trying to imply that somehow SC #1 and SC #4 are not consistent. That is, that our priorities are our users is incompatible with our system being 100% free. They are incompatible. As noted in the thread on debian-devel [1], even debian's own servers won't run debian any more, because they require non-debian firmware. The kernel is not the OS. That is why it is Debian GNU?Linux, GNU Software + the kernel = the OS [*]. GNU alone is not an OS, the kernel alone is not an OS. But without a working kernel (including network) it won't be possible to download the non-free blobs necessary to install or run the OS. (Assuming that there are people out there with just one computer, those people will need a whole non-free OS apart from debian just in order to be able to download the firmware and install debian in the first place (debian lacking the network card's firmware). A whole non-free OS just to compensate for the removal of some small binary blobs from d-i media!). not just Linux. And if the firmware is removed, but the re free drviers remain, and we can get the non-free blobs from elsewhere, it will just be Debian + non-free blobs. Why that distinction? If I add a non-free blob to a debian kernel it is no longer a debian kernel. Hence: If I add a non-free blob to a computer running debian it won't run debian any more. If you insist that Debian is 100% free, then a computer that is _running_ non-free code (opposed to having non-free data as well) is not running debian. Frankly, just because I do nt ever use official kernels, and I use nvidia drivers, has not led me to conclude I do not run Debian. That sound bite seems like hyperbole to me, and weakens your argument. Well, if you modify the code of your web browser you're not running mozilla any more. So by analogy, if you modify the core of your OS you are not running debian. I have never concluded that I haven't run debian, just because my wireless requires some firmware (I use debian's stock kernel). Other parts of my computer also run on sourceless software (bios, etc. also the software that presumably runs inside my monitor...). However, some others have concluded that those blobs are to be removed from debian, hence I won't run debian any longer. If you disagree with this, where exactly do you draw the line between a computer running debian and a computer running a different distribution? (Debian, ubuntu, debian software + red hat kernel, etc.) For the archives and installation media 100% is 100%. How much is 100% debian on a computer? Is 50% enough or is 3:1 a better rule? (I would draw a different distinction: software that runs on the computer as opposed to software that runs on peripherials, but debian has decided on a different criterium). It's all a bit too much of hair splitting, I admit. But it was the hair splitting of others that moved the firmware out of debian. So please include the non-free firmware in debian and in the installer and amend the SC as necessary. Johannes [*] from http://www.debian.org/intro/about WHAT is Debian? [...] At the core of an operating system is the kernel. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkYZSsACgkQC1NzPRl9qEVqqACfUDGibH6+bpCayAc7SRAOVLH0 xUkAn0wOd3681SkaBLvUyvNoDosfYUV8 =jHaR -END PGP SIGNATURE- -- 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 10, 2008 at 05:47:59PM +0100, Johannes Wiedersich wrote: With binary blobs inside or outside of debian, my computer will run just the same. It's just that outside main it won't be supported by debian -- at least not officially. It will be harder to install, as well. I think I said this before, but I don't mind repeating it ad nauseam ;-) There's no reason a modified version of Debian that includes non-free blobs needs to be harder to install or harder to find. Take, for example, the NSLU builds which include non-free firmware. They are in fact better maintained for NSLU hardware than official builds, since almost nobody uses pure Debian on a NSLU (network requires a USB dongle). Whether it's harder to install or not, it depends on you. We don't have a foundation document saying it must be. -- 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 Mon, Nov 03, 2008 at 05:57:04PM +0100, Andreas Barth wrote: To give an example, I can remember well that during release of Sarge, we noticed on Saturday (that was while already the cd images were partially done) that the upgrade of sendmail will stop delivering any mails in the queue, but due to the options we had (either skip the release for at least another week, or deliver this version of sendmail and document it in the release notes) we decided to not stop the release. Such things can happen with any part of the release policy, and I think that's the adequate behaviour. You're mixing unrelated things. We don't promise to our users that Debian is 100% bug-free. We just try and do our best. On the other hand, we _do_ promise to our users that Debian is 100% free. If you're not comfortable with keeping this promise, the appropiate procedure is seeking the approval of the project, like was done for etch. But so far you haven't. And you stated your intent to release lenny with SC violations that the project hasn't approved. That is the whole reason I care about this. I don't really feel strongly about whether we should make an exception or not, as long as it is the result of consensus and is endorsed by the majority of the project, not by a few selected ones. Yeah, I really mean what I said. If you don't believe me, check what I voted last time: http://www.debian.org/vote/2006/vote_007_tally.txt You'll see that I'm not the radical zealot some try to present me as. Proof is written. -- 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
* Marc Haber [EMAIL PROTECTED] [081109 21:00]: On Sun, Nov 09, 2008 at 07:27:59PM +0100, Robert Millan wrote: How is shipping packages in non-free instead of main supposed to be against the interests of our users? Non-free is not part of Debian, and there have been movements to kick non-free from Debian's infrastructure. The possibility of not having an aptable kernel in Debian proper is a non-option for me. And the option to have an kernel in Debian main that is not distributeable by law and that could cause everyone's license to use the Linux kernel at all being terminated (GPLv2 has no automatic reinstallment of rights) if someone of the many copyright holders brought it into a trial is much better? Because that is the current state of affairs if there are things without source in the Linux sourcecode... Hochachtungsvoll, Bernhard R. Link -- 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 03, 2008 at 05:57:04PM +0100, Andreas Barth wrote: | Debian's priorities are our users and free software. We don't trade them | against each other. I believe this phrase invalidates SC #1. - If this is so, why is it not explicit? - If it is not, what is, in your judgement, the correct interpretation of SC #1? | 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. What does the word continue mean in this phrase? Are you trying to imply that the release team is _already_ empowered to make decisions that override SC #1? - If you are, why is it not explicit? - If you're not, then please remove the continue from that phrase. -- 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 09, 2008 at 08:22:00PM +0100, Marc Haber wrote: On Sun, Nov 09, 2008 at 07:27:59PM +0100, Robert Millan wrote: How is shipping packages in non-free instead of main supposed to be against the interests of our users? Non-free is not part of Debian, and there have been movements to kick non-free from Debian's infrastructure. The possibility of not having an aptable kernel in Debian proper is a non-option for me. You're not alone there. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] There's no sensation to compare with this Suspended animation, A state of bliss -- 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] writes: or that we help our users by moving the Linux kernel plus the installer out of main, How is shipping packages in non-free instead of main supposed to be against the interests of our users? You seem to forget that non-free is not a part of Debian. Technically, you are right - moving the Kernel to non-free wouldn't be against the interest of our users. Debian wouldn't have any users anymore, so their interests couldn't be violated. It's a great idea: Stopping a (felt) steady decline of Debian with a big bang. Yay. Marc -- BOFH #333: A plumber is needed, the network drain is clogged pgpr9u2Ix9OGL.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
On Sun, Nov 09, 2008 at 07:27:59PM +0100, Robert Millan wrote: How is shipping packages in non-free instead of main supposed to be against the interests of our users? Non-free is not part of Debian, and there have been movements to kick non-free from Debian's infrastructure. The possibility of not having an aptable kernel in Debian proper is a non-option for me. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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 03, 2008 at 05:57:04PM +0100, Andreas Barth wrote: Perhaps replace it with delay Lenny indefinitly. This indefinitely is only so because of the technical requisites that have been decided by the Linux maintainers and by the release team. That is, that DFSG violations can't be fixed unless a working blob is packaged in non-free. There's nothing in the Social Contract or in this GR that mandates the release is post-poned for a long time. That would only be the consequence of a technical decision that is not yet taken. When you take it, it will be your own responsibility, not that of the project. Therefore, it doesn't belong in this GR to assert that Lenny will be delayed indefinitely. -- 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
* Robert Millan ([EMAIL PROTECTED]) [081109 18:26]: On Mon, Nov 03, 2008 at 05:57:04PM +0100, Andreas Barth wrote: | Debian's priorities are our users and free software. We don't trade them | against each other. I believe this phrase invalidates SC #1. I'm not argueing about believes here, but what our Foundation Document says. - If it is not, what is, in your judgement, the correct interpretation of SC #1? The Social Contract needs to be read as one coherent document and neither does #1 habe precedence on #2, #3, .., nor #2, #3, ... have precedence on #1. It is the same that different parts of e.g. a constitution sometimes collide, and unless there are special rules on that, one has to consider the situation, and how much each part might be negativly affected by a decision, and then take the route that does - in whole - the least damage. Unless you think we help our users by either not releasing Lenny for another year (or more), or that we help our users by moving the Linux kernel plus the installer out of main, you seem to want to violate social contract #4. There are situations where a large violation of #4 is worse than a small violation of #1. Of course, there are also situations where a small violation of #4 is less worse than a large violation of #1. I don't think calling the developers at large for a decision on each single case is appropriate. However, there is a group of developers in Debian who work hard on the release, and who seem the appropriate group to make the day-to-day-decisions. For this reason, I think backing their current authorization up to make decisions on behalf of Debian about the release of Lenny is the correct way to go, and that's what my proposal says. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
Hi, no need to cc: me, I read -vote. On Thursday 30 October 2008 18:29, Robert Millan wrote: I hereby propose this General Resolution: Option 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). Option 2 (allow Lenny to release with proprietary firmware) ~~~ 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. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 3 (allow Lenny to release with DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages 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 fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) I second to vote on all there three options, under whatever title they are summarized. regards, Holger pgpPNbFtRwY3r.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
Alexander Reichle-Schmehl [EMAIL PROTECTED] writes: Andreas Barth schrieb: In case any of the proposals get enough seconds, I would propose then: | 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 acknoledge 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. Should you need to propose this, consider it seconded by me. Should you do a s/acknoledge/acknowledge/ and/or s/therefor/therefore/ I'll still second it. I second both Andreas Barth's proposal with and without Alexander's proposed corrections. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpohFiGIk3eg.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan [EMAIL PROTECTED] writes: Option 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). Option 2 (allow Lenny to release with proprietary firmware) ~~~ 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. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 3 (allow Lenny to release with DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages 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 fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) I second those 3 option as stated above -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFJDxhtRmmq/NCejAsRAgGAAJ9URJc8DNYh5eRMO1jyqqZ2F+z8ygCePO1w nlznelqF84I9Qh1t9fnoXvA= =FHNH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
Option 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). Option 2 (allow Lenny to release with proprietary firmware) ~~~ 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. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 3 (allow Lenny to release with DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages 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 fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) I second all of the above options. I also approve in advance changing the two instances of 1 November 2008 to some later date, in case the Project would like to take responsibility for any regressions discovered after 1 November. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
* Robert Millan ([EMAIL PROTECTED]) [081027 16:15]: Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. 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. The headline is tendious. I would expect after reaffirm the Social Contract that we indeed want to release Lenny to our users and not withhold it. Perhaps replace it with delay Lenny indefinitly. And I want to remind all of you that the default option is that the release managers can decide to make a case-by-case-exception to any of the rules in the release policy, for the simple reason that as time passes by, it get too late to fix some of the bugs. To give an example, I can remember well that during release of Sarge, we noticed on Saturday (that was while already the cd images were partially done) that the upgrade of sendmail will stop delivering any mails in the queue, but due to the options we had (either skip the release for at least another week, or deliver this version of sendmail and document it in the release notes) we decided to not stop the release. Such things can happen with any part of the release policy, and I think that's the adequate behaviour. In case any of the proposals get enough seconds, I would propose then: | 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 acknoledge 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. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
Hi! Andreas Barth schrieb: In case any of the proposals get enough seconds, I would propose then: | 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 acknoledge 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. Should you need to propose this, consider it seconded by me. Should you do a s/acknoledge/acknowledge/ and/or s/therefor/therefore/ I'll still second it. Best regards, Alexander signature.asc Description: OpenPGP digital signature
Re: Call for seconds: DFSG violations in Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Barth schrieb: In case any of the proposals get enough seconds, I would propose then: | 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 acknoledge 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. Should you need to propose this, consider it seconded by me. And by me. Should you do a s/acknoledge/acknowledge/ and/or s/therefor/therefore/ I'll still second it. Me too. - -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkPZ4cACgkQBnqtBMk7/3kw3wCggag1qBhjXV+0IiFy/bJclaTJ 3I4AnAhubtiVJ6amrhsP0MaIN+UbA4HS =cZif -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: DFSG violations in Lenny
I have previously seconded these proposals, but this is to confirm that I still second these, with the modifications. Option 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). Option 2 (allow Lenny to release with proprietary firmware) ~~~ 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. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 3 (allow Lenny to release with DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages 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 fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) pgp2BnHx2n6RY.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
On Thu, Oct 30 2008, Robert Millan wrote: Option 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). Option 2 (allow Lenny to release with proprietary firmware) ~~~ 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. (Since this option overrides the SC, I believe it would require 3:1 majority) I second these versions of the proposed sets of resolutions/amendments, and just the options quoted above. (I have seconded in the past, but this is just to reafirm I agree with the changes). manoj -- You have a message from the operator. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgp2PelYNWdFC.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
The title of option 2 contains a typo: s/propietary/proprietary/. I hereby second the options 2 and 3 of Robert's proposal as quoted below. Option 2 (allow Lenny to release with propietary firmware) ~~ 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; however, it is not yet finally sorted out; 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself 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. Option 3 (allow Lenny to release with any DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages distributed by Debian relative to the Etch release in Lenny 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat fixing of DFSG violations as a best-effort process. signature.asc Description: This is a digitally signed message part.
Consequences for the lenny release, was: Call for seconds: DFSG violations in Lenny
Robert Millan [EMAIL PROTECTED] writes: 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat fixing of DFSG violations as a best-effort process. Did anyone already writeup a summary of stuff that would be covered by this note? My questions in particular: - are the violations in glibc covered here? - are the violations in portmap covered here? - what other violations are currently known to exist in lenny? AFAIUI and have if Robert's option 2 (allow Lenny to release with proprietary firmware) gets voted over option 3 (allow Lenny to release with any DFSG violations) all these issues have the potential to delay the lenny release until they are fixed. Is my understanding correct? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Consequences for the lenny release, was: Call for seconds: DFSG violations in Lenny
On Thu, Oct 30, 2008 at 12:57:49PM +0100, Reinhard Tartler wrote: AFAIUI and have if Robert's option 2 (allow Lenny to release with proprietary firmware) gets voted over option 3 (allow Lenny to release with any DFSG violations) all these issues have the potential to delay the lenny release until they are fixed. Is my understanding correct? Yes (except that option 2 is not more Robert's than option 3 is). -- 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
Hi, Here's a revised set of options with a number of changes relative to the first one: - Added option 1 / point 2 - Remove confusing sentence from options 2,3 / point 4 - Replaced option 2 / point 2 (written by Manoj Srivastava) - Simplify option 2 / point 4 not to assert that firmware must be in udebs (suggested by Holger Levsen) - Added to the best of our knowledge phrase to each option (suggested by Peter Samuelson and Hubert Chathi) - Typo fix (spotted by Frans Pop) I hereby propose this General Resolution: Option 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). Option 2 (allow Lenny to release with proprietary firmware) ~~~ 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. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 3 (allow Lenny to release with DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages 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 fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) -- 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: DFSG violations in Lenny
On Thu, Oct 30, 2008 at 05:29:20PM +, Robert Millan wrote: Hi, Here's a revised set of options with a number of changes relative to the first one: - Added option 1 / point 2 - Remove confusing sentence from options 2,3 / point 4 - Replaced option 2 / point 2 (written by Manoj Srivastava) - Simplify option 2 / point 4 not to assert that firmware must be in udebs (suggested by Holger Levsen) - Added to the best of our knowledge phrase to each option (suggested by Peter Samuelson and Hubert Chathi) - Typo fix (spotted by Frans Pop) I hereby propose this General Resolution: You can't do that, only the secretary can. You're supposed to propose one (or several) options and get seconds for it/them. That's all. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpCiwBSPmZBA.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 10:54:35PM +0200, Holger Levsen wrote: Hi, On Monday 27 October 2008 20:36, Robert Millan wrote: - 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 in udebs as long as it is necessary for installation (like all udebs) *and* - firmware included in the kernel itself 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. Aeh, if we'd vote on this, would that mean that we could deliver the firmware in udebs but not in debs? Not all debian installers use udebs, fai for example doesnt and I'm sure there are others... How about making it less specific, like: ... deliver firmware as part of Debian Lenny as long 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. -- 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] Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. 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. Seconded. (This is from the initial proposal.) I suggest, however, appending the phrase to the best of our knowledge as of 1 November 2008. Option 3 (allow Lenny to release with any DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages distributed by Debian relative to the Etch release in Lenny 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat fixing of DFSG violations as a best-effort process. Seconded. (This is from the initial proposal.) Option 2 (allow Lenny to release with propietary firmware) ~~ 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so. Seconded. (This is after Manoj expanded point 2 and Robert shortened point 4.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
I second the following proposals, as I believe that they should be voted on: (Robert Millan's unammended Option 1:) Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. 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. (Robert Millan's option 2, with expanded point 2 and shortened point 4:) Option 2 (allow Lenny to release with propietary firmware) ~~ 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so. (Since this option overrides the SC, I believe it would require 3:1 majority) (Robert Millan's unammended option 3:) Option 3 (allow Lenny to release with any DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages distributed by Debian relative to the Etch release in Lenny 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) I would also suggest adding the clause to the best of our knowledge to point 3 in options 2 and 3. I would, naturally, also second such an amended proposal. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA pgpkhWJXfoU4H.pgp Description: PGP signature
Call for seconds: DFSG violations in Lenny
I propose the following General Resolution. If you wish to second only one or two of the options, please indicate which ones clearly, so the Secretary can account them separately. Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. 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. Option 2 (allow Lenny to release with propietary firmware) ~~ 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; however, it is not yet finally sorted out; 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself 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. (Since this option overrides the SC, I believe it would require 3:1 majority) Option 3 (allow Lenny to release with any DFSG violations) ~~ 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 on DFSG compliance issues; however, they are not yet finally sorted out; 3. We assure the community that there will be no regressions in the progress made for freedom in the packages distributed by Debian relative to the Etch release in Lenny 4. We give priority to the timely release of Lenny over sorting every bit out; for this reason, we will treat fixing of DFSG violations as a best-effort process. (Since this option overrides the SC, I believe it would require 3:1 majority) -- 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: DFSG violations in Lenny
On Mon, Oct 27 2008, Robert Millan wrote: Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. 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. Option 2 (allow Lenny to release with propietary firmware) ~~ 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; however, it is not yet finally sorted out; 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself 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. (Since this option overrides the SC, I believe it would require 3:1 majority) I second The proposals labelled Options 1 and Option 2 quoted above. manoj -- What is research but a blind date with knowledge? Will Harvey Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpydqNlvdmuC.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, Oct 27 2008, Robert Millan wrote: Option 2 (allow Lenny to release with propietary firmware) ~~ 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; however, it is not yet finally sorted out; 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself 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. (Since this option overrides the SC, I believe it would require 3:1 majority) While I have seconded this proposal, how about a change in wording: , | 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 | | 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 in udebs as | long as it is necessary for installation (like all udebs), and | firmware included in the kernel itself 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. ` The changes are just to item 2., which is expanded to explain a little more about the progress we actually made in the kernel, and also to explain these are new issues (not something we have been ignoring for years). I would like to propose this as a formal amendment to the proposal, and hope it would be acceptable to the proposer. manoj -- A great many people think they are thinking when they are merely rearranging their prejudices.-- William James Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpLfmyGi7aHu.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
Hi, I second the options quoted below. That's the first one for the pre-lenny GR, and the first one of the post-lenny GR. (While I agree that this is important, I don't think we should set procedures in the SC; if this is to be written down in a foundational document, it must be the constitution IMO.) Thanks, Bas On Mon, Oct 27, 2008 at 04:23:05PM +0100, Robert Millan wrote: Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. 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. On Mon, Oct 27, 2008 at 04:56:12PM +0100, Robert Millan wrote: Option 1 (set an upper limit) ~ The developers resolve that the following rule shall take effect inmediately after Lenny is released: When ever a package in Debian is found to have been violating the DFSG for 180 days or more, and none of the solutions that have been implemented (if any) is considered suitable by the maintainers, the package must be moved from Debian (main suite) to the Non-free repository (non-free suite). The action of moving it may be performed by any of the developers (however, moving packages in distributions other than unstable or experimental may still require approval by the corresponding Release Team). When this happens, any known DFSG violation in the package must be resolved before the package can be moved back into Debian. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, 27 Oct 2008, Robert Millan wrote: 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself 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. Sorry, I fail to parse this. You lost me somewhere around 'like all udebs'. Could you please explain this in something that does not try to compete with german sentences in length? :) (Also, isn't we allow sourceless firmware ... as long as the license complies with the DFSG a no-op?) Thanks, Peter -- | .''`. ** 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: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 10:55:56AM -0500, Manoj Srivastava wrote: On Mon, Oct 27 2008, Robert Millan wrote: Option 2 (allow Lenny to release with propietary firmware) ~~ 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; however, it is not yet finally sorted out; 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself 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. (Since this option overrides the SC, I believe it would require 3:1 majority) While I have seconded this proposal, how about a change in wording: , | 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 | | 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 in udebs as | long as it is necessary for installation (like all udebs), and | firmware included in the kernel itself 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. ` The changes are just to item 2., which is expanded to explain a little more about the progress we actually made in the kernel, and also to explain these are new issues (not something we have been ignoring for years). I would like to propose this as a formal amendment to the proposal, and hope it would be acceptable to the proposer. I accept and second it. -- 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: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 08:22:57PM +0100, Peter Palfrader wrote: On Mon, 27 Oct 2008, Robert Millan wrote: 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself 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. Sorry, I fail to parse this. You lost me somewhere around 'like all udebs'. Could you please explain this in something that does not try to compete with german sentences in length? :) It's the same from http://www.debian.org/vote/2006/vote_007 with s/Etch/Lenny/g. A decomposition would be: - 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 in udebs as long as it is necessary for installation (like all udebs) *and* - firmware included in the kernel itself 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. (Also, isn't we allow sourceless firmware ... as long as the license complies with the DFSG a no-op?) The license for a sourceless blob can be GPL or BSD, which are licenses that comply with the DFSG, or it could be any sort of non-free license (including lack of license). Of course, the code itself wouldn't comply with DFSG #2, but the license would. Anyway, this specific text is already tested and known to work so I think this proves it is solid :-) -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan [EMAIL PROTECTED] writes: I propose the following General Resolution. If you wish to second only one or two of the options, please indicate which ones clearly, so the Secretary can account them separately. Option 1 (reaffirm the Social Contract) ~~~ 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. 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. Option 2 (allow Lenny to release with propietary firmware) ~~ 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; however, it is not yet finally sorted out; 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself 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. (Since this option overrides the SC, I believe it would require 3:1 majority) I hereby second both the first and second proposition - -- Rémi Vanicat -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFJBhcfRmmq/NCejAsRAtjPAJ9sNTEnYYAoM4NfaAspXNx+mI/abgCbBAsG 695w+deC0o2PrCVWqldscec= =8ysi -END PGP SIGNATURE- -- 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, Oct 27, 2008 at 08:36:06PM +0100, Robert Millan wrote: (Also, isn't we allow sourceless firmware ... as long as the license complies with the DFSG a no-op?) The license for a sourceless blob can be GPL or BSD, which are licenses that comply with the DFSG, or it could be any sort of non-free license (including lack of license). Of course, the code itself wouldn't comply with DFSG #2, but the license would. Anyway, this specific text is already tested and known to work so I think this proves it is solid :-) Though, if the as long as the license complies with the DFSG doesn't really have any effect (other than what's already covered by we are legally allowed to do so), I think it is confusing and shouldn't be in the text. I propose the following alternatative to Option 2 (removes last sentence): Option 2 (allow Lenny to release with propietary firmware) ~~ 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; however, it is not yet finally sorted out; 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so. (Since this option overrides the SC, I believe it would require 3:1 majority) -- 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: DFSG violations in Lenny
On Mon, Oct 27, 2008 at 09:04:33PM +0100, Robert Millan wrote: I propose the following alternatative to Option 2 (removes last sentence): Or rather, I propose the following alternative which incorporates Manoj's rewritten #2 (in addition to removing the last sentence in #4): Option 2 (allow Lenny to release with propietary firmware) ~~ 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so. (Since this option overrides the SC, I believe it would require 3:1 majority) -- 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: DFSG violations in Lenny
Hi, On Monday 27 October 2008 20:36, Robert Millan wrote: - 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 in udebs as long as it is necessary for installation (like all udebs) *and* - firmware included in the kernel itself 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. Aeh, if we'd vote on this, would that mean that we could deliver the firmware in udebs but not in debs? Not all debian installers use udebs, fai for example doesnt and I'm sure there are others... regards, Holger pgpCkZfH8ovyo.pgp Description: PGP signature
Re: Call for seconds: DFSG violations in Lenny
On Mon, Oct 27 2008, Robert Millan wrote: On Mon, Oct 27, 2008 at 09:04:33PM +0100, Robert Millan wrote: I propose the following alternatative to Option 2 (removes last sentence): Or rather, I propose the following alternative which incorporates Manoj's rewritten #2 (in addition to removing the last sentence in #4): Option 2 (allow Lenny to release with propietary firmware) ~~ 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 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 in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Lenny, as long as we are legally allowed to do so. (Since this option overrides the SC, I believe it would require 3:1 majority) In case there was any doubt, I second this altered proposal as well. manoj -- WAIT Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpeA2xk4iJ6w.pgp Description: PGP signature
