Scripsit Tom Rauchenwald <[EMAIL PROTECTED]>
> I am not a DD, so maybe my opinion is idiotic. But: the thing is free,
> it allows people to use non-free drivers, but it is entirerly up to the
> user to use those drivers. I don't know, but for me this discussion is
> pointless. Does ndiswrapper require non-free packages? no.
Well, that's the point of contention. I think it is not meaningful to
speak about whether the software, viewed as a bag of bits that live in
a vacuum, "requires" this or that other software. The question only
makes sense when we put it in a context and ask: Does ndiswrapper
require a non-free software *to do its thing*?
Unfortunately the answer depends on what one takes "ndiswrapper's
thing" to be. I think the schism in the current thread is based mostly
on differing intitial assumptions about how one views the purpose of
ndiswrapper.
Case 1: Ndiswrapper is for users who have hardware XYZ; it promises to
make this hardware useful with Linux. It cannot keep this promise
without also having a driver, and the only existing driver for XYZ is
non-free. From this viewpoint it is clear that ndiswrapper should be
in contrib.
Case 2: Ndiswrapper is for users who already have some driver software
written to the NDIS specification, never mind where they got it, and
want to run this driver. From this point of view, ndiswrapper is akin
to a programming language implementation, or a shared library - it can
be in main independently of the freedom of any programs that use it.
Thus from this perspective it is clear that ndiswrapper should be in
main.
The tragedy is that both viewpoints - "I want to use this hardware"
and "I want to run this driver" - are possible and legitimate and the
package descriptions does not clearly invalidate one of them, yet they
lead to incompatible conclusions about where the package should be
filed.
> if the user decides to use non-free drivers, then it's his choice,
> not debian's, so what.
The point of the distinction between main and contrib is to support
the user in his choice. We want that if a user finds package that
promises some functionality in 'main', then he can ideed get that
functionality without resorting to software outside main. That is why
the differing views of what functionality ndiswrapper promises is
important.
Personally I favor using a test somebody invented an earlier time we
discussed a similar problem: To determine whether A "requires" B for
the purpose of the social contract, assume hypothetically that B was
free and packaged, and then ask whether ordinary packaging practice
would lead to A a declaring a "Depends:" relationship on B in that
situation. This test would allow us to move the question into the
technical realm.
I think that according to this test, we would conclude that
ndiswrapper does not "require" the driver it wraps. If we had a
handful of prackages that provided free NDIS drivers, the driver
packages would depend on ndiswrapper, not the other way around. We
don't let libfoo depend on <program that uses libfoo>, or let ruby
depend on <package that provides a ruby script>, even though we
_could_ do this with virtual packages if we thought it would be
useful.
This is just parallel to the fact that we can have a library in main
without having any clients for the library in main. An example is
libc5 - it exists in sarge *only* to support old applications,
presumably non-free and certainly not in main themselves. Yet I have
not heard anybody suggest that it ought to have been in contrib for
that reason.
--
Henning Makholm "... a specialist in the breakaway
oxidation phenomena of certain nuclear reactors."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
