Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
Branden Robinson [EMAIL PROTECTED] writes: I intend to. I'm sorry to offend you by asking people more familiar with the GNU Emacs Manual to assist. What bugs me is that you've now issued *TWO* proposals without ascertaining their effect first. How many more times are you going to make proposals before getting the facts down?? I hope none, but I fear otherwise. I would be ok with a proportional limit, provided that it was set high enough to cause no problems for things already in the archive. So anything failing DFSG 3 that happens to be in main due to an oversight should be grandfather by my proposal? That's what no problems means, and would be grounds for rejecting my proposal outright as an attempt to repeal DFSG 3. Does your proposal contradict DFSG 3 or not? If so, then it's totally illegitimate, because if you want to amend the DFSG, such proposals are powerless to accomplish it. I assume, therefore, that your proposal does *not* conflict with DFSG 3--and that this is, in fact, your opinion. (It is also my opinion that your proposal does not conflict with DFSG at all.) If it doesn't conflict: then it either is purely clarificatory, or else it suggests restrictions beyond those required by DFSG. If you want it to be purely clarificatory, then it has to take as a prior presumption that previous actions are still allowed--that is, if it has no further restrictive effect, then approving it should not suddenly result in existing packages being removed from main. If it does have that effect, then the attempt at clarification has ipso facto failed, because it's amounting to a new restriction. If it's a new restriction (and I am not intrinsically opposed to new restrictions), then I ask that it not restrict in such a way as to cause packages currently in main to get thrown out. So, please answer the following for me. These are pretty simple yes/no questions. 1) Do you believe your proposal to contradict the DFSG? 2) If the answer to question (1) is no, then do you see your proposal as merely clarifying practice, or do you see it as imposing an additional restriction beyond those currently believed to obtain? Thomas
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
On Sun, Dec 02, 2001 at 10:46:32PM -0800, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: I intend to. I'm sorry to offend you by asking people more familiar with the GNU Emacs Manual to assist. What bugs me is that you've now issued *TWO* proposals without ascertaining their effect first. How many more times are you going to make proposals before getting the facts down?? I hope none, but I fear otherwise. Debian is a collective effort. It is unreasonable to expect a person to vet all 6000 packages in the Distribution before issuing a proposal. One of the strengths of having a large and vital Project is that this kind of work can be parallelized. I did in fact research the impact of my proposals on several GNU manuals -- I don't know of anything else in Debian yet licensed under the GNU FDL -- and discussed the impact in my proposals. Failing to achieve 100% certainty in a proposal's effects is not the same thing as not ascertaining the effect at all. Does your proposal contradict DFSG 3 or not? That is not a determination that you or I am solely empowered to make. If it doesn't conflict: then it either is purely clarificatory, or else it suggests restrictions beyond those required by DFSG. And in practice Debian has applied several restrictions in the past not clearly found in the DFSG. A review of the debian-legal archives will turn up some, but there is no centralized clearinghouse for this sort of information; no effort to collect precedent into a single location. Anthony Towns encouraged doing so. That none yet exists is a poor reason to object to me starting one. If you want it to be purely clarificatory, Not purely, no, and I was rock-solid clear about this in the proposal. If it's a new restriction (and I am not intrinsically opposed to new restrictions), then I ask that it not restrict in such a way as to cause packages currently in main to get thrown out. Asked and answered. Message-ID: [EMAIL PROTECTED] So anything failing DFSG 3 that happens to be in main due to an oversight should be grandfather by my proposal? That's what no problems means, and would be grounds for rejecting my proposal outright as an attempt to repeal DFSG 3. No, the existence of packages with unmodifiable text already in main is something that should inform our process, but cannot be determinative because of the possibility that there is already something in main that should not be. My proposal is a guideline, not a suicide pact. I believe Debian should have a standard a priori the GNU Emacs Manual (for example), and not reason backwards on the assumption that everything that is in main must belong there. People find DFSG violations in main regularly. The intent of my proposal is not to grant categorical immunity to any class of these violations. 1) Do you believe your proposal to contradict the DFSG? No. 2) If the answer to question (1) is no, then do you see your proposal as merely clarifying practice, or do you see it as imposing an additional restriction beyond those currently believed to obtain? Fallacious: false alternative. The proposal clarifies current practice, which is to *RELAX* the restrictions imposed by DFSG 3 and 4. It furthermore attempts to provide rules-of-thumb to help prevent us from relaxing these guidelines too greatly. Message-ID: [EMAIL PROTECTED] As I understand it, a package that makes it into [main] complies to all points of the DFSG. However, your proposal will allow packages that don't fully comply the DFSG to enter [main], if the violation is not too grave. I consider this inconsistent. Well, depends on what you mean by comply. Under what I understand to be your interpretation of comply, everything licensed under the GPL or LGPL would have to be removed from main because the text of these licensed is copyrighted and licensed under terms that forbid modification. I agree that this violates an iron-fisted interpretation of DFSG 3. However, the DFSG and Social Contract were passed when many, many GPL'ed packages were already part of Debian, and as far as I know, few people have ever proposed that GPL'ed software be removed from Debian. This isn't to say that non-modifiable text isn't solely a problem of the FSF's -- the BSD licenses are also affected, and, in a sense, anything with a copyright notice is as well. Interpret DFSG 3 *THAT* strictly and there wouldn't be much left *in* Debian. Just public domain materials. We may as well just fold up shop and quit if that's the case. -- G. Branden Robinson| Human beings rarely imagine a god Debian GNU/Linux | that behaves any better than a [EMAIL PROTECTED] | spoiled child. http://people.debian.org/~branden/ | -- Robert Heinlein pgph8obZmIf32.pgp Description: PGP signature
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
Branden Robinson [EMAIL PROTECTED] writes: I believe Debian should have a standard a priori the GNU Emacs Manual (for example), and not reason backwards on the assumption that everything that is in main must belong there. People find DFSG violations in main regularly. The intent of my proposal is not to grant categorical immunity to any class of these violations. I can't parse the first sentence here; perhaps that's the problem. Can you reword it? Of course there might be something in main that should not be there, but if we are going to have a policy that casts doubt on them, I really want to know what the effect will be, at least on some pretty big candidates. I would oppose any policy in this area in which a restriction on amounts works to block the GNU Emacs manual, for example, and I'd want to think carefully about other cases too. One question I have is why we must be content neutral in our guidelines. My inclination is, along with you, to say that we should be content neutral. But perhaps we might reasonably say that the guideline will in practice allow for whether Debian agrees with the statements expressed or not. This might be in the area of cases that exceed the guidelines but we might want to cut an exception. It seems like we should be more willing to cut exceptions for cases where the views expressed in the invariant sections are in tune with Debian itself. I'm certainly sensitive to the problem that a content-sensitive policy seems to actively promote big arguments. But I wonder if, for those cases where an exception is being discussed, we aren't already in the realm of big discussion, at least, and it might be reasonable to include as part of the discussion whether we agree with the statements or not. I have in mind that the statements in the GCC or GNU Emacs manuals are ones that Debian agrees with; that some horrid novella is something Debian is neutral about; that a Nazi screed advocating total censorship is something we are against. [Substitute even clearer examples here if you like; my point is not the particular examples.] So, if we do add a paragraph to your proposal (and I hope we do) saying these are just guidelines, and if you think a package should be added that exceeds the guidelines, then let's talk about it on debian-legal (or whatever other words to that effect)--I'd like to say that some kind of consonance with Debian's principles and goals is one of the things we want to take into account in making such exceptions.
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
HELP, PLEASE HELP!!! Hackers have put my user id into multiple redistributing lists of your technical forum. I can't unsubcribe with automated system because my user id is not in the main list. Please help. I received tons of unwanted mails. Please forward this request to the list owner. Thanks --- Branden Robinson [EMAIL PROTECTED] wrote: On Sun, Dec 02, 2001 at 10:46:32PM -0800, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: I intend to. I'm sorry to offend you by asking people more familiar with the GNU Emacs Manual to assist. What bugs me is that you've now issued *TWO* proposals without ascertaining their effect first. How many more times are you going to make proposals before getting the facts down?? I hope none, but I fear otherwise. Debian is a collective effort. It is unreasonable to expect a person to vet all 6000 packages in the Distribution before issuing a proposal. One of the strengths of having a large and vital Project is that this kind of work can be parallelized. I did in fact research the impact of my proposals on several GNU manuals -- I don't know of anything else in Debian yet licensed under the GNU FDL -- and discussed the impact in my proposals. Failing to achieve 100% certainty in a proposal's effects is not the same thing as not ascertaining the effect at all. Does your proposal contradict DFSG 3 or not? That is not a determination that you or I am solely empowered to make. If it doesn't conflict: then it either is purely clarificatory, or else it suggests restrictions beyond those required by DFSG. And in practice Debian has applied several restrictions in the past not clearly found in the DFSG. A review of the debian-legal archives will turn up some, but there is no centralized clearinghouse for this sort of information; no effort to collect precedent into a single location. Anthony Towns encouraged doing so. That none yet exists is a poor reason to object to me starting one. If you want it to be purely clarificatory, Not purely, no, and I was rock-solid clear about this in the proposal. If it's a new restriction (and I am not intrinsically opposed to new restrictions), then I ask that it not restrict in such a way as to cause packages currently in main to get thrown out. Asked and answered. Message-ID: [EMAIL PROTECTED] So anything failing DFSG 3 that happens to be in main due to an oversight should be grandfather by my proposal? That's what no problems means, and would be grounds for rejecting my proposal outright as an attempt to repeal DFSG 3. No, the existence of packages with unmodifiable text already in main is something that should inform our process, but cannot be determinative because of the possibility that there is already something in main that should not be. My proposal is a guideline, not a suicide pact. I believe Debian should have a standard a priori the GNU Emacs Manual (for example), and not reason backwards on the assumption that everything that is in main must belong there. People find DFSG violations in main regularly. The intent of my proposal is not to grant categorical immunity to any class of these violations. 1) Do you believe your proposal to contradict the DFSG? No. 2) If the answer to question (1) is no, then do you see your proposal as merely clarifying practice, or do you see it as imposing an additional restriction beyond those currently believed to obtain? Fallacious: false alternative. The proposal clarifies current practice, which is to *RELAX* the restrictions imposed by DFSG 3 and 4. It furthermore attempts to provide rules-of-thumb to help prevent us from relaxing these guidelines too greatly. Message-ID: [EMAIL PROTECTED] As I understand it, a package that makes it into [main] complies to all points of the DFSG. However, your proposal will allow packages that don't fully comply the DFSG to enter [main], if the violation is not too grave. I consider this inconsistent. Well, depends on what you mean by comply. Under what I understand to be your interpretation of comply, everything licensed under the GPL or LGPL would have to be removed from main because the text of these licensed is copyrighted and licensed under terms that forbid modification. I agree that this violates an iron-fisted interpretation of DFSG 3. However, the DFSG and Social Contract were passed when many, many GPL'ed packages were already part of Debian, and as far as I know, few people have ever proposed that GPL'ed software be removed from Debian. This isn't to say that non-modifiable text isn't solely a problem of the FSF's -- the BSD licenses are also affected, and, in a sense, anything with a copyright notice is as well. Interpret DFSG 3 *THAT* strictly and there wouldn't be much left *in* Debian. Just public domain
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
On Sun, Dec 02, 2001 at 11:43:34PM -0800, Tran Nam Binh wrote: HELP, PLEASE HELP!!! Hackers have put my user id into multiple redistributing lists of your technical forum. I can't unsubcribe with automated system because my user id is not in the main list. Please help. I received tons of unwanted mails. Please forward this request to the list owner. Thanks Please take your grievance to [EMAIL PROTECTED] The readers of these mailing lists *DO NOT* have the power to unsubscribe you. -- G. Branden Robinson| Exercise your freedom of religion. Debian GNU/Linux | Set fire to a church of your [EMAIL PROTECTED] | choice. http://people.debian.org/~branden/ | pgpQ4ClOCD8qu.pgp Description: PGP signature
Re: REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable text
On Sun, Dec 02, 2001 at 11:30:47PM -0800, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: I believe Debian should have a standard a priori the GNU Emacs Manual (for example), and not reason backwards on the assumption that everything that is in main must belong there. I can't parse the first sentence here; perhaps that's the problem. Can you reword it? Debian should develop an interpretive standard for the DFSG based on premises that do *not* include: The GNU Emacs Manual must be in main come hell or high water. More generally, Debian's interpretive standard should not regard any particular package which happens to be in main at present as somehow deserving of being there. Not the Linux kernel, not the GNU C Library, not insert your favorite shell/editor/terminal emulator here. What legitimizes a work under the DFSG is the license as applied to that work. Period. Should we look before we leap, and not interpret the DFSG in such a way that would decimate main? Absolutely. I believe I have done so with respect to my own proposal, and while I would not be happy to see the GNU Emacs Manual rendered non-free (which is by no means a certainty, let's keep in mind), it's not a deal-breaker for me. Your mileage may vary. Some people regard all things GNU with a sort of religious reverence. I personally just try to accord the FSF the respect I think it has earned. That doesn't mean I think Debian should subordinate its own standards or needs to the FSF's desires. But, my proposal isn't about the FSF. It's about DFSG 3 and 4, and how we apply them. -- G. Branden Robinson|There is no housing shortage in Debian GNU/Linux |Lincoln today -- just a rumor that [EMAIL PROTECTED] |is put about by people who have http://people.debian.org/~branden/ |nowhere to live.-- G. L. Murfin pgp32fgJaOHCT.pgp Description: PGP signature
Bug#106280: debian-policy: There should be a note on devfs
Package: debian-policy Version: 3.5.6.0 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The quoted version of policy says that the package must call MAKEDEV. As long as this section is being changed, we should probably note that on devfs systems, MAKEDEV will turn itself into a no-op. - -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux bohr 2.4.16 #2 SMP Wed Nov 28 05:25:00 EST 2001 i686 Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages debian-policy depends on: ii fileutils 4.1-7 GNU file management utilities. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8C04d5lsmI6uA7bQRAonkAJ9zEbwge9kXPOuW+YWSrf1EhR5DLwCgo1DV NG86iXCjYEwZQ9lxF/VtO1M= =zJh4 -END PGP SIGNATURE-
Re: LSB Status
Previously Anthony Towns wrote: Things break. That's what happen when things fail. You'll notice we don't guarantee anything better for our own init scripts. LSB does so we will need to start caring. You can't selectively implement the LSB, that would make the whole thing worthless. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: LSB Status
On Mon, Dec 03, 2001 at 12:04:30PM +0100, Wichert Akkerman wrote: Previously Anthony Towns wrote: Things break. That's what happen when things fail. You'll notice we don't guarantee anything better for our own init scripts. LSB does so we will need to start caring. You can't selectively implement the LSB, that would make the whole thing worthless. Eh? The LSB does no such thing: An init.d shell script may declare using the Required-Start: header that it must not be run until certain boot facilities are provided. This infomration is used by the installation tool or the boot-time boot-script execution facility to ensure that init scripts are run in the correct order. The LSB is specifically designed *not* to require major changes to the way distributions or systems are set up to function. As a matter of implementation quality we may wish to do something to that effect, but it's not a requirement, and not doing it certainly doesn't make the whole thing worthless. And there's little point worrying about implementation quality when we don't have an implementation in the first place. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it. C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who can't deal with deconstructionist humor. Code Blue. -- Mike Hoye, see http://azure.humbug.org.au/~aj/armadillos.txt
Bug#106280: debian-policy: There should be a note on devfs
Previously Anthony DeRobertis wrote: The quoted version of policy says that the package must call MAKEDEV. As long as this section is being changed, we should probably note that on devfs systems, MAKEDEV will turn itself into a no-op. Why? Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#106280: debian-policy: There should be a note on devfs
Wichert Akkerman writes: Previously Anthony DeRobertis wrote: The quoted version of policy says that the package must call MAKEDEV. As long as this section is being changed, we should probably note that on devfs systems, MAKEDEV will turn itself into a no-op. Why? Because calling MAKEDEV on a devfs system just looks plain wrong, even though it isn't. Not really a big deal, though.
French Translation
I am studying at Strathclyde Uni and am at present studying Hotel Hospitality. I Have a assessment and am stuck on the translation of the French language. Would you be able to help. The question is. I must translate the following into sound menu English. - Supreme de volaille Cardinal Labalu which I think is Breast of chicken in a lobster butter cream sauce served with lobster clawe truffle - Tranche de Turbotin Poche Bonne-Femme no idea just to do with poached Turbot - Oeuf Brouilles Yvette somthing to do with eggs -Fillet de Merlan Anglaise Would you be able to help me.
