Scripsit Ben Johnson <[EMAIL PROTECTED]> > If the majority of the values is utilized no more than once or > twice, with only a handful that keep being used, it does not really > justify giving them human-friendly names, but what if the programmer > always needs a large number of them at hand ? Could you clarify this > to me please ?
I'm not really sure I understand what you are asking. It may well be that *you* would prefer having symbolic constants instead of magic numbers. My point is just that is quite conceivable that the programmer of the code in question _actually_ prefers working with the raw numbers, and that the code as distributed is therefore "source code" according to any reasonable definition. > Two problems remain in my opinion: > -security > -the unhackability of the driver, which, if not > contrary to the strict letter of the DFSG, are > colliding at least with its spirit, in my opinion. In my opinion, the spirit of the DFSG does not express any opinion about hackability. Badly written, horribly bug-ridden code that nobody alive has any idea how to begin fixing can still be free software. Our mechanism for avoiding such code in Debian is not articifically broadening the scope of the concept of legal freedom, but instead the very powerful concept of "the mainatiner's discretion". Practical unhackability is a _technical_ problem and should be handled through our procedures for resolving technical problems: 1) The maintainer should not package the code unless he feels that it can be maintained to Debian's standards of non-buggyness. 2) If somebody else thinks that the maintainer is deluding himself when he thinks the code is maintainable, he can try to convince the Technical Committee to override the maintainer's decision. 3) If the TC cannot be bothered to do anything about it, a GR can be proposed. -- 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]