[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[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

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

Reply to: