Re: Call for seconds: Resolving DFSG violations
[Robert Millan] + p + When ever a package in Debian is found to have been violating the + Debian Free Software Guidelines/cite/q for 60 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). + /p It seems pretty impractical to allow the release of lenny, as some of the options do, yet force/authorize somebody to immediately, upon lenny's release, fix the linux-2.6 situation _in lenny_. Since of course we've known about linux-2.6 for far longer than 60 (or 180) days. For that matter, some of these options have the curious effect of allowing the lenny release while simultaneously authorizing developers to fix the etch and sarge kernels. Not that that part is enforceable, I'm pretty sure the RMs wouldn't actually allow that to happen. Now if you change the wording to exempt our published releases from this entire process, so that it applies only to unstable and testing, it would be a lot easier to support. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Call for seconds: Resolving DFSG violations
On Sun, Oct 26, 2008 at 02:00:27PM -0500, Peter Samuelson wrote: [Robert Millan] + p + When ever a package in Debian is found to have been violating the + Debian Free Software Guidelines/cite/q for 60 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). + /p It seems pretty impractical to allow the release of lenny, as some of the options do, yet force/authorize somebody to immediately, upon lenny's release, fix the linux-2.6 situation _in lenny_. Since of course we've known about linux-2.6 for far longer than 60 (or 180) days. For that matter, some of these options have the curious effect of allowing the lenny release while simultaneously authorizing developers to fix the etch and sarge kernels. Not that that part is enforceable, I'm pretty sure the RMs wouldn't actually allow that to happen. Now if you change the wording to exempt our published releases from this entire process, so that it applies only to unstable and testing, it would be a lot easier to support. Hi, Note that (after someone else pointed out the same concern) I included wording to avoid this: however, moving packages in the \stable\ distribution may still require approval by the Release Team for \stable\ Perhaps we should also explicitly exclude oldstable? But what about versions before oldstable then? Or we could make it inclusive and list only unstable and experimental. -- 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: Resolving DFSG violations
Robert Millan wrote: I hereby propose the following General Resolution to stablish a procedure for resolving DFSG violations: I believe that the Debian project is way better off without this General Resolution and with the rules and social contract as they are to date. Even worse, I have the strong feeling that the options proposed will hurt the Debian project, delay lenny and future releases. It should not be voted on. DFSG-nonfreeness is currently some sort of a grey zone which allows us to release lenny at all. We should all know (at least by know) that we still have some skeletons in the closet and we all know that we need to work on fixing these problems. We should work on fixing these problems with upstream instead of continueing this discussion. Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Resolving DFSG violations
also sprach Robert Millan [EMAIL PROTECTED] [2008.10.24.1717 +0200]: I hereby propose the following General Resolution to stablish a procedure for resolving DFSG violations: I would generally second this, but I wish we would separate the two issues: first establish whether and how we want to deal with DFSG-non-free, and second decide whether we want to make (yet another) exception for lenny. In fact, I'd word it such that the affirmative would mean we stick to our promise we made for sarge, which we already violated for etch, and do *not* release lenny with non-free stuff. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems you don't sew with a fork, so I see no reason to eat with knitting needles. -- miss piggy, on eating chinese food digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Call for seconds: Resolving DFSG violations
Robert Millan [EMAIL PROTECTED] writes: The action of moving it may be performed by any of the developers (however, moving packages in the stable distribution may still require approval by the Release Team for stable). I don't understand this part. As a developer, how do I move a package from one distribution to another? I think that this action has to actually be taken by an ftpmaster. -- Ben Pfaff http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Resolving DFSG violations
On Fri, Oct 24 2008, Robert Millan wrote: I hereby propose the following General Resolution to stablish a procedure for resolving DFSG violations: I think that I would like to see an option to just release Lenny with an exception on the ballot, without any changes to the foundation documents or any other action: ,[ Option 7 ] |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 8 ] |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 kernel sources, 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. ` I would like to see this incorporated into the current proposal, or failing that, seek seconds for this proposal in its own right. If these options are incorporated into the GR proposal, I shall second that, or else I am hereby proposing these options as independent amendments to fit on the ballot. manoj -- Immortality consists largely of boredom. Zefrem Cochrane, Metamorphosis, stardate 3219.8 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: Resolving DFSG violations
On Fri, Oct 24, 2008 at 08:17, Robert Millan [EMAIL PROTECTED] wrote: When ever a package in Debian is found to have been violating the DFSG for By who? There is no standard. The action of moving it may be performed by any of the developers (however, As you know, there are developers with such insane views on the DFSG that all the packages in sid would instantly end up in non-free. It seems to me this proposal would just allow idealogical zealots additional methods of annoying technical contributing members. It should never come to vote. Sorry to be so harsh, it just seems like the 800th time this has been talked about. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for seconds: Resolving DFSG violations
On Fri, Oct 24, 2008 at 12:22:14PM -0700, Jeff Carr wrote: On Fri, Oct 24, 2008 at 08:17, Robert Millan [EMAIL PROTECTED] wrote: When ever a package in Debian is found to have been violating the DFSG for By who? There is no standard. I don't think we need a standard to define things like availability of source code. But do not trouble yourself, we haven't yet come to a situation in which people claim a binary blob to be source code. It seems to me this proposal would just allow idealogical zealots I still don't know who are those zealots you keep talking about. I'd appreciate that if you have actual arguments you explain them, rather than ressorting to this kind of cheap talk. -- 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: Resolving DFSG violations
On Fri, Oct 24, 2008 at 01:28:09PM -0500, Manoj Srivastava wrote: ,[ Option 7 ] |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'm fine with this. ,[ Option 8 ] |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 kernel sources, 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. ` I find this one to be deceitful. First, because it's technically equivalent to further discussion. Second, because the release team has already expressed their intent to infringe the Social Contract, which in principle is supposed to have more weight (backed by 3:1 majority) than a GR approved by simple majority (like this option would require). I see it as feasible that they would infringe this text as well. Nevertheless I would merge it in my proposal if you still want me 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: Call for seconds: Resolving DFSG violations
On Fri, Oct 24, 2008 at 05:39:31PM +0200, martin f krafft wrote: also sprach Robert Millan [EMAIL PROTECTED] [2008.10.24.1717 +0200]: I hereby propose the following General Resolution to stablish a procedure for resolving DFSG violations: I would generally second this, but I wish we would separate the two issues: first establish whether and how we want to deal with DFSG-non-free, and second decide whether we want to make (yet another) exception for lenny. On one hand, I don't think an option that doesn't allow some kind of exception for Lenny is likely to be accepted, taking into account that we're so close to release (in fact I haven't made a clear decision myself). On the other, if we implement the proposed mechanism for dealing with DFSG violations, work will start in their enforcement, and at that point making an exception would have to revert that to get DFSG-infringing packages back to main. It is much simpler that, for those who would support my proposed reform but still want Lenny to be an exception, they have an option that allows this exception and post-pones the reform at the same time. In fact, I'd word it such that the affirmative would mean we stick to our promise we made for sarge, which we already violated for etch, and do *not* release lenny with non-free stuff. Manoj wrote an option along these lines (another reply in this thread). I have some concerns with that one, but I'm willing to incorporate it if after reading my reply you're still interested in it (please have a look). -- 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: Resolving DFSG violations
On Fri, Oct 24, 2008 at 09:41:53AM -0700, Ben Pfaff wrote: Robert Millan [EMAIL PROTECTED] writes: The action of moving it may be performed by any of the developers (however, moving packages in the stable distribution may still require approval by the Release Team for stable). I don't understand this part. As a developer, how do I move a package from one distribution to another? By uploading a new version of the package. -- 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: Resolving DFSG violations
On Fri, Oct 24 2008, Robert Millan wrote: ,[ Option 8 ] |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 kernel sources, 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. ` I find this one to be deceitful. First, because it's technically equivalent to further discussion. Second, because the release team has already expressed their intent to infringe the Social Contract, which in principle is supposed to have more weight (backed by 3:1 majority) than a GR approved by simple majority (like this option would require). I see it as feasible that they would infringe this text as well. I think this is different from frther discussion in that it is an recent and unequivocal expression of developer intent, expressly delaying Lenny until we get out act together. I do not believe the RM's will ignore a GR. Nevertheless I would merge it in my proposal if you still want me to. If we must have a GR, I would feel better with these options on the ballot. manoj -- The more control, the more that requires control. 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]
