Re: Discussion period: GR: DFSG violations in Lenny
On Mon, Nov 10 2008, Luk Claes wrote: Debian Project Secretary wrote: ,[ Proposal 2: allow Lenny to release with proprietary firmware ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` Wrong, the release doesn't decide what's in the archive or not. Debian is more than the releases although you seem to think it's not? So in no way is a decision about the release without talking about the archive in all its components going to override the SC. ,[ Proposal 3: (allow Lenny to release with DFSG violations ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` Same here. ,[ Proposal 4 ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` I am not sure what you consider to be wrong here. Are you objecting to the title of the proposal? Or to the majority requirement? The proposal title does not mention which parts of Debian would be give the authority; it just concentrates on what the project is allowing itself to do. In a way, the contents of parts of the archive (Sid and testing), are works in progress. When we release, collectively, we are releasing a finished version of the Debian system. No one person or group is responsible for the Debian system, in my view, we are all involved in it. And we are all collectively responsible for ensuring that the Debian system is 100% free. Even if there are missteps during the preparation phase, the finished product, whch would be the current incarnation of the Debian system, must meet the social contract. The language of the social contract leaves little wiggle room. manoj -- You can never tell which way the train went by looking at the tracks. 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, 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: Discussion period: GR: DFSG violations in Lenny
Debian Project Secretary wrote: ,[ Proposal 2: allow Lenny to release with proprietary firmware ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` Wrong, the release doesn't decide what's in the archive or not. Debian is more than the releases although you seem to think it's not? So in no way is a decision about the release without talking about the archive in all its components going to override the SC. ,[ Proposal 3: (allow Lenny to release with DFSG violations ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` Same here. ,[ Proposal 4 ] | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` Same here. Cheers Luk -- 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]
DFSG violations in Lenny: new proposal
Hi, The proposals we have before us either call for a delay in lenny, or in some way override or try to do an end run around the social contract. This is in contrast to the vote we had for etch, where we said that the blobs must be distributed under the DFSG -- the only thing that was conceded was that the blob, under the GPL, needs to have the preferred form of modification, and since there is no _proof_ that the blob is not actually the preferred form of modification, we investigate no deeper. While I think it is exceedingly unlikely the blobs are the preferred form of modification, I have personally written programs in hex, and while this is a sleight of hand (not examining that the blob does or does not violate the GPL), and does not meet the spirit of the social contract, at least it does not violate the letter. The fact that we are not meeting the spirit of the SC is why we have the general resolution: the project must stand behind it, and it is a very public acceptance of us turning Nelson's eye on potential GPL violations. Since the following does not, in my opinion, actually violate the SC, it should be a simple up/down vote. I think we need this in order to not either delay the release too much, and to not just sweep possible violations of the GPL and or DFSG under the rug. ,[ Proposal 5: allow Lenny to release with firmware blobs ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so, and the | firmware is distributed upstream under a license that complies | with the DFSG. ` This is just proposal 2 + the last clause of item 4. I am formally proposing this as an amendment, either to replace proposal 2; or as a formal alternative in its own right, and I am asking for seconds. manoj -- Just because he's dead is no reason to lay off work. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpD1yjRqhdGE.pgp Description: PGP signature
Re: DFSG violations in Lenny: new proposal
I second Manoj's proposal below. ma, 2008-11-10 kello 12:21 -0600, Manoj Srivastava kirjoitti: ,[ Proposal 5: allow Lenny to release with firmware blobs ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so, and the | firmware is distributed upstream under a license that complies | with the DFSG. ` This is just proposal 2 + the last clause of item 4. I am formally proposing this as an amendment, either to replace proposal 2; or as a formal alternative in its own right, and I am asking for seconds. signature.asc Description: Digitaalisesti allekirjoitettu viestin osa
Re: DFSG violations in Lenny: new proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manoj Srivastava wrote: ,[ Proposal 5: allow Lenny to release with firmware blobs ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so, and the | firmware is distributed upstream under a license that complies | with the DFSG. ` I second this proposal. - -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkYhFMACgkQrelPZQd5nnRguwCgjnYS2TmuwyiLYTVsBEfoWVw6 /HAAn1jWyU/3A3sPe7IpwwRY1WpMy0ni =x1Dq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: new proposal
On Mon, Nov 10, 2008 at 12:21:21PM -0600, Manoj Srivastava wrote: ,[ Proposal 5: allow Lenny to release with firmware blobs ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so, and the | firmware is distributed upstream under a license that complies | with the DFSG. ` Seconded. Neil -- mooch If stockhom sees my banana, he will want to eat it signature.asc Description: Digital signature
Re: Discussion period: GR: DFSG violations in Lenny
This one time, at band camp, Manoj Srivastava said: I am not sure what you consider to be wrong here. Are you objecting to the title of the proposal? Or to the majority requirement? The proposal title does not mention which parts of Debian would be give the authority; it just concentrates on what the project is allowing itself to do. In a way, the contents of parts of the archive (Sid and testing), are works in progress. When we release, collectively, we are releasing a finished version of the Debian system. No one person or group is responsible for the Debian system, in my view, we are all involved in it. And we are all collectively responsible for ensuring that the Debian system is 100% free. Even if there are missteps during the preparation phase, the finished product, whch would be the current incarnation of the Debian system, must meet the social contract. The language of the social contract leaves little wiggle room. I have to admit that I'm a bit curious how you justify needing a 3:1 supermajority to update a Packages file, but not to have the software in question served in the first place. It seems to me that what you're saying is that it's fine to have a non-free kernel or glibc side by side with a broken one in the same directory, so long as the non-free one isn't listed in the Packages file that the stable symlink points to. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: DFSG violations in Lenny: new proposal
This one time, at band camp, Manoj Srivastava said: ,[ Proposal 5: allow Lenny to release with firmware blobs ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so, and the | firmware is distributed upstream under a license that complies | with the DFSG. ` I take it then that you're fine with the discussed DFSG issues in glibc for release? Is there a particular reason that bit of software doesn't need to meet the DFSG, or is it just that it's particularly inconvenient to release without it? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: DFSG violations in Lenny: new proposal
Stephen Gran [EMAIL PROTECTED] writes: I take it then that you're fine with the discussed DFSG issues in glibc for release? Is there a particular reason that bit of software doesn't need to meet the DFSG, or is it just that it's particularly inconvenient to release without it? I think it's fairly obvious that glibc meets the DFSG in practice, in that no one is ever going to attempt to apply the ambiguous and badly-written portions of the Sun RPC license in a way that might violate the DFSG. It's certainly not an ideal situation, but on the spectrum of licensing issues that we might ignore it's not one that would keep me up at night. -- 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: DFSG violations in Lenny: new proposal
This one time, at band camp, Russ Allbery said: Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Russ Allbery said: I think it's fairly obvious that glibc meets the DFSG in practice, in that no one is ever going to attempt to apply the ambiguous and badly-written portions of the Sun RPC license in a way that might violate the DFSG. It's certainly not an ideal situation, but on the spectrum of licensing issues that we might ignore it's not one that would keep me up at night. I'm personally not worried about the firmware issue, either, or at least for the ones where the vendors intent is clear, even though the 'source' (whatever that is or was) is missing. Unredistributable object code is unredistributable, and I don't think that's in question here. But maybe I'm misreading you - are you saying that you think it's also fine for those bits of blobs, since the vendors pretty clearly wanted them to be included in free projects? No, I'm saying that the Sun RPC code is a full source code release under a BSD-style license. That the license is written poorly and buggily is not, in practice, much of an issue, since no one is going to enforce it in a non-free-software way. The situation is not at all comparable to firmware that doesn't include source code. My point was not to say anything about firmware, simply to point out that the two cases are very different and one cannot easily reason about one from the other. Then I suppose the best thing would be for you to downgrade the bug from RC. What I currently see is several RC bugs about DFSG issues, and lots of people arguing that we need a GR to release with one set, but not for the other. Presumably it's too inconvenient to move the entire archive to non-free. If we're going to release a badly broken Lenny, we might as well be consistent. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: DFSG violations in Lenny: new proposal
On Mon, Nov 10 2008, Andreas Barth wrote: * Matthew Johnson ([EMAIL PROTECTED]) [081110 22:03]: On Mon Nov 10 12:09, Russ Allbery wrote: Stephen Gran [EMAIL PROTECTED] writes: I take it then that you're fine with the discussed DFSG issues in glibc for release? Is there a particular reason that bit of software doesn't need to meet the DFSG, or is it just that it's particularly inconvenient to release without it? I think it's fairly obvious that glibc meets the DFSG in practice, in that no one is ever going to attempt to apply the ambiguous and badly-written portions of the Sun RPC license in a way that might violate the DFSG. It's certainly not an ideal situation, but on the spectrum of licensing issues that we might ignore it's not one that would keep me up at night. Also, it's in the process of being resolved. There are (according to another thread) talks with Sun about explicitly licensing it under a better licence. The stuff in the kernel is also in the process of being resolved. The difference being that the former is being resolved with a license change, and the latter is being resolved with code changes, and will require adjustments to the infrastructure. That makes the former a faster process. manoj -- Debug is human, de-fix divine. 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: DFSG violations in Lenny: new proposal
On Mon Nov 10 16:05, Manoj Srivastava wrote: Also, it's in the process of being resolved. There are (according to another thread) talks with Sun about explicitly licensing it under a better licence. The stuff in the kernel is also in the process of being resolved. The difference being that the former is being resolved with a license change, and the latter is being resolved with code changes, and will require adjustments to the infrastructure. That makes the former a faster process. And that if we release now, the glibc code which we ship will be free shortly, without having to update stable, whereas the code shipped in the kernel won't be free in Lenny, however long we wait (because the solution is to remove/replace it) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: DFSG violations in Lenny: new proposal
Hi, With a new option added to the list, the discussion period is extended again, by a week, starting 10 Nov 2008 21:28:29. The proposals, tentatively, as reproduced below. |+---+---+---+---+---| || 1 | 2 | 3 | 4 | 5 | |+---+---+---+---+---| | Robert Millan [EMAIL PROTECTED]| 1 | 1 | 1 | | | | Bas Wijnen [EMAIL PROTECTED] | 1 | | | | | | Manoj Srivastava [EMAIL PROTECTED] | 1 | 1 | | | 1 | | Holger Levsen [EMAIL PROTECTED] | 1 | 1 | 1 | 1 | | | Peter Samuelson [EMAIL PROTECTED] | 1 | 1 | 1 | | | | Hubert Chathi [EMAIL PROTECTED] | 1 | 1 | 1 | | | | Andreas Barth [EMAIL PROTECTED]| | | | 1 | | | Alexander Reichle-Schmehl [EMAIL PROTECTED] | | | | 1 | | | Reinhard Tartler [EMAIL PROTECTED] | | | | | | | Bernd Zeimetz [EMAIL PROTECTED] | | | | 1 | | | Neil McGovern [EMAIL PROTECTED] | | | | 1 | 1 | | Frans Pop [EMAIL PROTECTED] | | 1 | 1 | | | | [EMAIL PROTECTED] (Rémi Vanicat) | 1 | 1 | 1 | 1 | | | John H. Robinson, IV [EMAIL PROTECTED] | | | | | 1 | | Lars Wirzenius [EMAIL PROTECTED]| | | | | 1 | | Damyan Ivanov [EMAIL PROTECTED] | | | | | 1 | | Colin Tuckley [EMAIL PROTECTED] | | | | | 1 | |+---+---+---+---+---| || 7 | 7 | 6 | 6 | 6 | |+---+---+---+---+---| #+TBLFM: $2=vsum(@[EMAIL PROTECTED])::$3=vsum(@[EMAIL PROTECTED])::$4=vsum(@[EMAIL PROTECTED])::$5=vsum(@[EMAIL PROTECTED])::$6=vsum(@[EMAIL PROTECTED]) ,[ Proposal 1: reaffirm the Social Contract ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that we promised to deliver a 100% free operating system | (Social Contract #1); | | 3. Given that we have known for two previous releases that we have | non-free bits in various parts of Debian, and a lot of progress has | been made, and we are almost to the point where we can provide a | free version of the Debian operating system, we will delay the | release of Lenny until such point that the work to free the operating | system is complete (to the best of our knowledge as of 1 November 2008). ` ,[ Proposal 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) ` ,[ Proposal 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) ` ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and free software. We don't trade | them against each other. However during getting an release out of the | door, decisions need to be done how to
Re: DFSG violations in Lenny: new proposal
Hi, | Reinhard Tartler [EMAIL PROTECTED] | | | | | | I think you've missed to count [EMAIL PROTECTED] here. Cheers, Bernd -- 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: DFSG violations in Lenny: new proposal
On Mon, Nov 10, 2008 at 06:21:21PM +, Manoj Srivastava wrote: ,[ Proposal 5: allow Lenny to release with firmware blobs ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so, and the | firmware is distributed upstream under a license that complies | with the DFSG. ` I second this proposal -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8FztAu0dHs.pgp Description: PGP signature
Re: DFSG violations in Lenny: new proposal
On Mon, 2008-11-10 at 16:25 -0600, Manoj Srivastava wrote: [...] ,[ Proposal 2: allow Lenny to release with proprietary firmware ] [...] | 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) ` [...] ,[ Proposal 5: allow Lenny to release with firmware blobs ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); [...] | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so, and the | firmware is distributed upstream under a license that complies | with the DFSG. ` [...] So far as I can see, the only significant difference between #5 and #2 (or #3) is the requirement that upstream distributes under a license that complies with the DFSG. But it is surely irrelevant whether the licence text says we can modify the source when the copyright holder is deliberately withholding the source. (Further, in some cases the licence is GPLv2 which requires us to redistribute the source we don't have - though thankfully there are only 1 or 2 such cases left.) So why do you claim that #2 and #3 override the SC but #5 doesn't? Ben. signature.asc Description: This is a digitally signed message part
Re: DFSG violations in Lenny: new proposal
Le mardi 11 novembre 2008 à 04:49 +, Ben Hutchings a écrit : So far as I can see, the only significant difference between #5 and #2 (or #3) is the requirement that upstream distributes under a license that complies with the DFSG. But it is surely irrelevant whether the licence text says we can modify the source when the copyright holder is deliberately withholding the source. Do we have means to tell whether upstream has some sources for their firmware or they are working directly in hex? If we don’t, we are forced to consider all of them the same, and that means hex has to be considered an acceptable form of modification. Just like we sometimes accept documentation compiled to HTML as being its own source. -- .''`. : :' : 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
