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]