Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[I'm not a developer, just one of Debians users - I hope it is not
inappropriate for me to comment on this issue here.]
For starters, I'd always thought that contrib was for packages that
Depend on a package out of non-free -- basically to ensure that people
who have only DFSG-free software in their sources.list or on their CDs
don't get broken packages. However, after reading up a bit I gather
contrib means something like "Packages here need something that is
non-free to operate."
Policy 2.2.2 has clarifying examples: "
- free packages which require contrib, non-free packages or packages
which are not in our
archive at all for compilation or execution, and
- wrapper packages or other sorts of free accessories for non-free programs. "
If ndiswrapper falls in the first category hinges on the definition of
"require".
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 and doesn't serve as a good
guideline as to what one is to expect to find in contrib. (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.)
Maybe a clarification of 'require' as used in Policy 2.2.2 and item 1
of the social contract would be helpful. As it stands I think the
first example doesn't apply.
The much more interesting question is, is it a wrapper package in the
sense of 2.2.2?
It certainly acts as a wrapper for (non-free) win32 drivers, on the
other hand most wrapper packages are for specific pieces of software,
whereas ndiswrapper can (theoretically) encapsulate all NIC drivers
that conform to a certain reasonably generic spec. Compare this to
java-package which works with 6 specific Java VMs (2 versions each by
3 vendors). So maybe it isn't a wrapper but implements an ABI? I don't
know, both viewpoints are certainly valid.
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.
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? ...
Such reasoning just invites endless discussions until someone writes a
small free component and people start to argue whether it is actually
useful or just a POC. IMHO that's something for users to decide.
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? Yet nobody is asking to remove
it, are they?
All that said, I don't use ndiswrapper as I'm lucky enough to have
hardware that works well with free drivers. On the other hand I have
one of those white iBooks with no wireless drivers in sight -- if
there were an "ndiswrapper" for the Mac I'd probably replace OS X with
Debian in a heartbeat. I would assume owners of PC laptops feel the
same way. From this angle it is certainly in the interest of users to
have this functionality in the Debian installer even, which AFAIK
can't load modules from contrib.
Thanks,
Christian
Reply to: