[Christian Pernegger] > Judging from its documentation ndiswrapper doesn't need any non-free > binaries, the module can be inserted even if no drivers are > "installed". It might not be very useful like that, but "useful" is a > very subjective thing in any case Not *that* subjective. I think you'd be pretty hard-pressed to find anyone who would consider it "useful" to print an init message to the kernel log, use up a bit of memory, and do absolutely nothing else. In some cases you are correct, "useful" is hard to define, so one has to be lenient. This isn't one of those cases. > (IMHO something is shown to be useful if a developer finds it worth > their time to create and maintain a package, but that's just me.) Well, until you find out whether the maintainer would have considered ndiswrapper "useful enough to create and maintain" if it could only be used with free drivers, or if it didn't support any drivers at all, this distinction doesn't help. > An argument I don't agree with however, is that there would have to > be a (DFSG-)free NDIS driver for ndiswrapper to rightfully be in main > -- mainly on the grounds that it is a very vague and unstable > criterion. I don't see what's vague about it. It's unstable, sure. > Should an FPS game with no free texture packs be in main? No. If it > has free texture packs but no maps? Probably not. What if there's a > free map editor? ... Moving something from contrib to main, when its status changes due to additional free software becoming available, is NOT HARD. It's been done before, for example with the Doom game engines. You don't need to worry that "contrib is forever". I mean, as well worry about all the software we label as "Priority: extra". That's another arbitrary line to draw, judging a package by its degree of usefulness to most people. Oh no, you might say, what if it becomes really popular in the future and deserves to be Priority: optional or even Priority: standard? Answer: you cross that bridge when you come to it. So with putting something in contrib or main. Classifications are allowed to change when the change is justified. > Rather, this line of reasoning could be used not to include > ndiswrapper at all -- how should the maintainer verify and fix bugs > in a package when those bugs only occur and can only be verified in > conjunction with non-free components? You have discovered one of the reasons Debian advocates free software. One of the reasons we have separate 'main' and 'contrib' sections. What you say is true: it may well be harder to find and fix bugs in software which uses non-free components, even if the bug is in a part of the software which is free. We think our users deserve free software, partly to avoid that very problem, so we use 'contrib' to label the contents of the archive that may suffer from these restrictions. Maintainers who have packages in 'contrib' and 'non-free' have accepted these limitations and are willing to try to do the job regardless.
Attachment:
signature.asc
Description: Digital signature