Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 24, 2005 at 05:33:50PM +, Henning Makholm wrote: Scripsit Paul Hedderly [EMAIL PROTECTED] What we have is source code (yes code that can be compiled) which is unencumbered, we can modify,compile, distribute etc... whether it is _harder_ to modify or not because of choices the _owner/author_ has made or not... is nothing to do with freedom. What you are showing here is that code that can be compiled is not a working defintion of source code. It not only works, but has been used for a long time. What you are showing is that you have a dislike for source that is hard to modify (fair enough) and would like for it not to be called 'source code' if you feel it is hard to read/modify. 'source code' does not mean 'code that came from the original source untouched' (lets face it, define 'original source' when there is more than one person working on code with different trees, working machines etc...) it literally means code that can be used to generate a binary. So please stop making weird claims about the meaning of words and definitions and state plainly that you don't like hard to read/modify (ugly?) source code and would like Debian to ban using such. We can argue and vote on that... -- Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Friday 04 March 2005 17:47, Thiemo Seufer wrote: Kalle Kivimaa wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: Source code is source code. Obfuscated or not does not change that. It fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you would have to show that it is not source and the gcc already prooves you wrong there. If you use 'obfuscation' or in other words 'readability' as measurement what source is then a lot of perl code would not qualify in my eyes. Source code is commonly defined as the author's most preferred source of making modifications. That's not the common definition but the GPL one. IMO the IOCCC stuff is source, and it's unlikely the author wrote it in the final form. But wouldn't that make the NV driver GPL incompatible even if considered open source? `Allan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit Paul Hedderly [EMAIL PROTECTED] On Thu, Mar 24, 2005 at 05:33:50PM +, Henning Makholm wrote: Scripsit Paul Hedderly [EMAIL PROTECTED] What you are showing here is that code that can be compiled is not a working defintion of source code. It not only works, but has been used for a long time. No it hasn't. Nobody has ever claimed that, say, Bison output qualifies as source code even though it is evidently compilable. At least not until the recent influx of people who want to force Debian to use a free-as-in-beer definition of freedom instead of time-honored free-as-in-speech. What you are showing is that you have a dislike for source that is hard to modify (fair enough) and would like for it not to be called 'source code' if you feel it is hard to read/modify. Strawman. Under that definition all code in a language that somebody doesn't understand would cease to be source code either. That is obviously not workable either. it literally means code that can be used to generate a binary. No it doesn't. -- Henning Makholm Ambiguous cases are defined as those for which the compiler being used finds a legitimate interpretation which is different from that which the user had in mind. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Mon, Mar 07, 2005 at 07:31:22AM -0600, John Hasler wrote: Henning Makholm writes: Yes, but we shouldn't act as if it was a _freedom_ problem. If it was deliberately made bloody horribly ugly and painful in order to make changing it difficult, it's a freedom problem. Not really. How NV choose to do stuff is totally up to NV. What we have is source code (yes code that can be compiled) which is unencumbered, we can modify,compile, distribute etc... whether it is _harder_ to modify or not because of choices the _owner/author_ has made or not... is nothing to do with freedom. -- Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit Paul Hedderly [EMAIL PROTECTED] What we have is source code (yes code that can be compiled) which is unencumbered, we can modify,compile, distribute etc... whether it is _harder_ to modify or not because of choices the _owner/author_ has made or not... is nothing to do with freedom. What you are showing here is that code that can be compiled is not a working defintion of source code. -- Henning Makholm Logic is a system for talking about propositions that can be true or false, or at least enjoy properties that are generalized versions of truth and falsehood. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
This one time, at band camp, Henning Makholm said: Scripsit Paul Hedderly [EMAIL PROTECTED] What we have is source code (yes code that can be compiled) which is unencumbered, we can modify,compile, distribute etc... whether it is _harder_ to modify or not because of choices the _owner/author_ has made or not... is nothing to do with freedom. What you are showing here is that code that can be compiled is not a working defintion of source code. However, code that we can modify,compile, distribute etc and is unencumbered is. Please, folks, it's ugly != it's non-free. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpTtkazASorU.pgp Description: PGP signature
Re: Let's stop feeding the NVidia cuckoo
* Henning Makholm ([EMAIL PROTECTED]) [050307 09:50]: Scripsit Nick Phillips [EMAIL PROTECTED] I also think that it would be a very good thing if we were to use our collective discretion more often -- to say, for example, well, you could call this source, but it's bloody horribly ugly and painful source, and we don't want that kind of crap in Debian a bit more often. Yes, but we shouldn't act as if it was a _freedom_ problem. It's a _quality_ problem and should be treated as such, i.e. without invoking the DFSG. Agreed. Especially as it's too horibly broken is by itself a serious bug. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
* John Hasler ([EMAIL PROTECTED]) [050307 14:50]: Henning Makholm writes: Yes, but we shouldn't act as if it was a _freedom_ problem. If it was deliberately made bloody horribly ugly and painful in order to make changing it difficult, it's a freedom problem. There are sure to be borderline cases, but it usually isn't all that hard to tell the difference between appalling style and deliberate obfuscation. My guide for freedom issues within Debian is the SC and the DFSG. What is yours? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Mon, Mar 07, 2005 at 08:31:18AM +, Henning Makholm wrote: Scripsit Nick Phillips [EMAIL PROTECTED] I also think that it would be a very good thing if we were to use our collective discretion more often -- to say, for example, well, you could call this source, but it's bloody horribly ugly and painful source, and we don't want that kind of crap in Debian a bit more often. Yes, but we shouldn't act as if it was a _freedom_ problem. It's a _quality_ problem and should be treated as such, i.e. without invoking the DFSG. Sorry, yes. That's what I was trying to say. Or part of it, at least. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Sat, Mar 05, 2005 at 12:40:53AM +0100, Goswin von Brederlow wrote: Maybe I'm too unclear. They are guidelines. As such they don't define what source is or what forms of 'source' are acceptable but use the broadest term saying just 'source'. If something is still acceptable as source (like having source without #define's) or not (like having a plain gcc -S output) has to be decided case by case. Just saying obfuscating violates DFSG#2 doesn't cut it in my opinion. That is far to broad a generalization to be usefull at all. Say the upstream author has personal references to NDA protected materials (e.g. /* see page 17 of foobar */) in his source and has to remove them before release. Why would that make the source unacceptable? Having somewhat obfuscated source violates the spirit of free software and up to some level that can be tolerated. As long as the software comes under a free license (and follows it) and the maintainer is happy working with the source in the form it is in why should anyone object? The world isn't blackwhite but has shades of grey. Is that clearer? I think I agree with you pretty much completely; IMO it is actually impossible to define source in a way that is both cut-and-dried and useful. I also think that it would be a very good thing if we were to use our collective discretion more often -- to say, for example, well, you could call this source, but it's bloody horribly ugly and painful source, and we don't want that kind of crap in Debian a bit more often. There are many good reasons for doing this -- maintainability, the chances of hiding a trojan, the fact that we want to distribute something that we can be proud of, the fact that we want to distribute something that our users can modify to their needs... If someone wrote a windowing system (say, a rewrite of X) in Brainfuck and gave you the source, it would be way way worse than any obfuscated C source you're ever likely to see. In fact you'd probably have more chance of making useful changes to binaries built from C code than to Brainfuck source that big. So let's just accept that we can't have cut and dried rules about this, please. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit Nick Phillips [EMAIL PROTECTED] I also think that it would be a very good thing if we were to use our collective discretion more often -- to say, for example, well, you could call this source, but it's bloody horribly ugly and painful source, and we don't want that kind of crap in Debian a bit more often. Yes, but we shouldn't act as if it was a _freedom_ problem. It's a _quality_ problem and should be treated as such, i.e. without invoking the DFSG. -- Henning Makholm The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Nick Phillips [EMAIL PROTECTED] I also think that it would be a very good thing if we were to use our collective discretion more often -- to say, for example, well, you could call this source, but it's bloody horribly ugly and painful source, and we don't want that kind of crap in Debian a bit more often. Yes, but we shouldn't act as if it was a _freedom_ problem. It's a _quality_ problem and should be treated as such, i.e. without invoking the DFSG. Exactly. Thanks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Henning Makholm writes: Yes, but we shouldn't act as if it was a _freedom_ problem. If it was deliberately made bloody horribly ugly and painful in order to make changing it difficult, it's a freedom problem. There are sure to be borderline cases, but it usually isn't all that hard to tell the difference between appalling style and deliberate obfuscation. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Scripsit John Hasler [EMAIL PROTECTED] Henning Makholm writes: Yes, but we shouldn't act as if it was a _freedom_ problem. If it was deliberately made bloody horribly ugly and painful in order to make changing it difficult, it's a freedom problem. True. But in that case I would not agree with Nick's hypothetical you could call this source. -- Henning MakholmNej, hvor er vi altså heldige! Længe leve vor Buxgører Sansibar Bastelvel!
Re: Let's stop feeding the NVidia cuckoo
Justin Pryzby wrote:
On Fri, Feb 25, 2005 at 03:47:32PM -0500, David Nusinow wrote:
On Fri, Feb 25, 2005 at 03:25:48PM -0500, Glenn Maynard wrote:
Obfuscated code does not satisfy DFSG#2. I hope nobody seriously
disagrees with this.
Let's not be so fast with this. I haven't taken a look at the driver
source ..
(I just gave a brief look; I put them in
http://tonelli.sns.it/mirror/X/xc/programs/Xserver/hw/xfree86/drivers/nv/
)
Just because the code doesn't use #defines or enums doesn't
necessarily make it obfuscated; it may just be that Vojkovich sees
that as too indirect, and prefers to write outb(0x3241, 0x51) because
he happens to know the port ID numbers and values off the top of his
head.
I agree; or he simply fishes them out of documentation, and
he does not see the need to use #defines,
since he has the documentation in its hand.
Is it *actively* obfuscated, or just not as clean as you would like?
Please compare :
v
/*
* Initialize DAC palette.
*/
if(pLayout-bitsPerPixel != 8 )
{
for (i = 0; i 256; i++)
{
pVga-DAC[i*3] = i;
pVga-DAC[(i*3)+1] = i;
pVga-DAC[(i*3)+2] = i;
}
}
^^^
that comes from nv_dac.c , or
v
case 'h': /* SETHI */
/* Has to be sethi i, xx */
if ((insn 0xc1c0) !=
0x0100) {
prom_printf(insn_h, p,
addr, insn);
prom_halt();
}
set_addr(addr, q[1], fmangled,
(insn 0xffc0) | (p[1] 10));
break;
^
that comes from kernel-source/arch/sparc/mm/btfixup.c
I dont see any of the two to be quite more comprehensible than the other.
On the other hand, neither the GPL nor the DFSG state that any laymen
(such as me) should be able to understand
the deep meaning of the above code.
If it is actively obfuscated (has been run through a sed script to
remove whitespace, or similar), then someone needs to ask nv for the
real source
how will we ever be able to know this? How do we go and prove that
they are keeping a secret version of the code that is better than what
they are relasing?
Anyhow, there are comments in the NV code ... this is more
than can be said of a lot of open source code around :-)
Is there someplace we can download the code (call it what you like)
without also downloading the rest of X11?
http://tonelli.sns.it/mirror/X/xc/programs/Xserver/hw/xfree86/drivers/nv/
-
Actually , the whole linux kernel may be subject to the same complaints
that Ben Johnson reports against nv drivers !
- there are many occurrences of hexadecimals with no explanation or comments.
Just try find -name '*.c' | xargs egrep -5 '0x[1-9]' | less -S
Look at how much code in kernel uses magic hexadecimals with almost no comments:
do we go and delete the whole kernel for this reason? :-)
- defines are no help either: I have no clue at what this line
arch/ppc/kernel/align.c:#define RA(inst)(((inst) 0x001F) 16)
is supposed to be defining.
-
a.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
A Mennucc [EMAIL PROTECTED] writes: Justin Pryzby wrote: On Fri, Feb 25, 2005 at 03:47:32PM -0500, David Nusinow wrote: On Fri, Feb 25, 2005 at 03:25:48PM -0500, Glenn Maynard wrote: Obfuscated code does not satisfy DFSG#2. I hope nobody seriously disagrees with this. I seriously disagree. Source code is source code. Obfuscated or not does not change that. It fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you would have to show that it is not source and the gcc already prooves you wrong there. If you use 'obfuscation' or in other words 'readability' as measurement what source is then a lot of perl code would not qualify in my eyes. And since the source would be DFSG free you and anybody else would be free to edit it, comment it, reverse engeneer it and make it more readable. I find that option important enough to overlook other minor (and changeable) details. In my eye even _deliberate_ obfuscation (which remains to be proven) does not violate the letter of DFSG#2 while it does not follow its spirit. There are other sources in Debian that are far more unreadbale or even compiler output (e.g. pascal to c compiler output). Sometimes it is either that or no package at all. And is that in the users interest? If you want to argue against obfuscated source you have to pull the GPLs 'The source code for a work means the preferred form of the work for making modifications to it.' out of your hat or similar license terms. Under that term deliberatly obfuscated code would not be source. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Goswin von Brederlow [EMAIL PROTECTED] writes: Source code is source code. Obfuscated or not does not change that. It fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you would have to show that it is not source and the gcc already prooves you wrong there. If you use 'obfuscation' or in other words 'readability' as measurement what source is then a lot of perl code would not qualify in my eyes. Source code is commonly defined as the author's most preferred source of making modifications. If the author actually works with the obfuscated files, then fine, that is source. But if the author works with the unobfuscated version, then the obfuscated files are something like Java class files, not source. Or do you claim that any precompiled Java class package should be able to go into main because you can always use gcj to compile those files into native code? That would help Debian Java support, though :) -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Kalle Kivimaa [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] writes:
Source code is source code. Obfuscated or not does not change that. It
fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you
would have to show that it is not source and the gcc already prooves
you wrong there. If you use 'obfuscation' or in other words
'readability' as measurement what source is then a lot of perl code
would not qualify in my eyes.
Source code is commonly defined as the author's most preferred source
of making modifications. If the author actually works with the
obfuscated files, then fine, that is source. But if the author works
with the unobfuscated version, then the obfuscated files are something
like Java class files, not source.
Which in itself is near impossible to proove. We have to believe that
what is released as source by the author is source (as defined by its
license mainly) unless it becomes too unbelievable. e.g. a char foo =
{ 0x12, ... } that shows a gcc footprint when disassembled would be
absolutely unbelievable.
Having a #define REG1 0x4653 or just 0x4653 wherever REG1 is
used certainly isn't out of the believable.
Or do you claim that any precompiled Java class package should be able
to go into main because you can always use gcj to compile those files
into native code? That would help Debian Java support, though :)
Java class files are bytecode binaries. And while gcj can cross
compile from bytecode binary to native code they clearly are not
source. Their main inteded purpose is to be run on a java VM and not
being input for gcj.
But where (obfuscated) source ends and binary begins is very unclear
and probably overlapping too. I couldn't write down any consistent
rule for it. I can only go by gut feeling there.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Kalle Kivimaa wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: Source code is source code. Obfuscated or not does not change that. It fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you would have to show that it is not source and the gcc already prooves you wrong there. If you use 'obfuscation' or in other words 'readability' as measurement what source is then a lot of perl code would not qualify in my eyes. Source code is commonly defined as the author's most preferred source of making modifications. That's not the common definition but the GPL one. IMO the IOCCC stuff is source, and it's unlikely the author wrote it in the final form. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
* Kalle Kivimaa ([EMAIL PROTECTED]) [050304 17:35]: Goswin von Brederlow [EMAIL PROTECTED] writes: Source code is source code. Obfuscated or not does not change that. It fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you would have to show that it is not source and the gcc already prooves you wrong there. If you use 'obfuscation' or in other words 'readability' as measurement what source is then a lot of perl code would not qualify in my eyes. Source code is commonly defined as the author's most preferred source of making modifications. No. There are people running around claiming this, but that doesn't make it truth. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
sorry, wrong posting
(I must switch to a better news reader!)
a.
A Mennucc wrote:
Justin Pryzby wrote:
On Fri, Feb 25, 2005 at 03:47:32PM -0500, David Nusinow wrote:
On Fri, Feb 25, 2005 at 03:25:48PM -0500, Glenn Maynard wrote:
Obfuscated code does not satisfy DFSG#2. I hope nobody seriously
disagrees with this.
Let's not be so fast with this. I haven't taken a look at the driver
source ..
(I just gave a brief look; I put them in
http://tonelli.sns.it/mirror/X/xc/programs/Xserver/hw/xfree86/drivers/nv/
)
Just because the code doesn't use #defines or enums doesn't
necessarily make it obfuscated; it may just be that Vojkovich sees
that as too indirect, and prefers to write outb(0x3241, 0x51) because
he happens to know the port ID numbers and values off the top of his
head.
I agree; or he simply fishes them out of documentation, and
he does not see the need to use #defines,
since he has the documentation in its hand.
Is it *actively* obfuscated, or just not as clean as you would like?
Please compare :
v
/*
* Initialize DAC palette.
*/
if(pLayout-bitsPerPixel != 8 )
{
for (i = 0; i 256; i++)
{
pVga-DAC[i*3] = i;
pVga-DAC[(i*3)+1] = i;
pVga-DAC[(i*3)+2] = i;
}
}
^^^
that comes from nv_dac.c , or
v
case 'h': /* SETHI */
/* Has to be sethi i, xx */
if ((insn 0xc1c0) !=
0x0100) {
prom_printf(insn_h, p,
addr, insn);
prom_halt();
}
set_addr(addr, q[1], fmangled,
(insn 0xffc0) | (p[1] 10));
break;
^
that comes from kernel-source/arch/sparc/mm/btfixup.c
I dont see any of the two to be quite more comprehensible than the other.
On the other hand, neither the GPL nor the DFSG state that any laymen
(such as me) should be able to understand
the deep meaning of the above code.
If it is actively obfuscated (has been run through a sed script to
remove whitespace, or similar), then someone needs to ask nv for the
real source
how will we ever be able to know this? How do we go and prove that
they are keeping a secret version of the code that is better than what
they are relasing?
Anyhow, there are comments in the NV code ... this is more
than can be said of a lot of open source code around :-)
Is there someplace we can download the code (call it what you like)
without also downloading the rest of X11?
http://tonelli.sns.it/mirror/X/xc/programs/Xserver/hw/xfree86/drivers/nv/
-
Actually , the whole linux kernel may be subject to the same
complaints that Ben Johnson reports against nv drivers !
- there are many occurrences of hexadecimals with no explanation or
comments.
Just try find -name '*.c' | xargs egrep -5 '0x[1-9]' | less -S
Look at how much code in kernel uses magic hexadecimals with almost
no comments:
do we go and delete the whole kernel for this reason? :-)
- defines are no help either: I have no clue at what this line
arch/ppc/kernel/align.c:#define RA(inst)(((inst)
0x001F) 16)
is supposed to be defining.
-
a.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Fri, Mar 04, 2005 at 05:08:36PM +0100, Goswin von Brederlow wrote: In my eye even _deliberate_ obfuscation (which remains to be proven) does not violate the letter of DFSG#2 while it does not follow its spirit. There are other sources in Debian that are far more unreadbale or even compiler output (e.g. pascal to c compiler output). Sometimes it is either that or no package at all. And is that in the users interest? What a wonderful reason to treat them as guidelines instead of defintions; then we can talk meaningfully about whether it violates the spirit, even while obeying the letter. Oh wait... -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
Joel Aelwyn [EMAIL PROTECTED] writes: On Fri, Mar 04, 2005 at 05:08:36PM +0100, Goswin von Brederlow wrote: In my eye even _deliberate_ obfuscation (which remains to be proven) does not violate the letter of DFSG#2 while it does not follow its spirit. There are other sources in Debian that are far more unreadbale or even compiler output (e.g. pascal to c compiler output). Sometimes it is either that or no package at all. And is that in the users interest? What a wonderful reason to treat them as guidelines instead of defintions; then we can talk meaningfully about whether it violates the spirit, even while obeying the letter. Oh wait... -- Joel Aelwyn [EMAIL PROTECTED] ,''`. Maybe I'm too unclear. They are guidelines. As such they don't define what source is or what forms of 'source' are acceptable but use the broadest term saying just 'source'. If something is still acceptable as source (like having source without #define's) or not (like having a plain gcc -S output) has to be decided case by case. Just saying obfuscating violates DFSG#2 doesn't cut it in my opinion. That is far to broad a generalization to be usefull at all. Say the upstream author has personal references to NDA protected materials (e.g. /* see page 17 of foobar */) in his source and has to remove them before release. Why would that make the source unacceptable? Having somewhat obfuscated source violates the spirit of free software and up to some level that can be tolerated. As long as the software comes under a free license (and follows it) and the maintainer is happy working with the source in the form it is in why should anyone object? The world isn't blackwhite but has shades of grey. Is that clearer? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
