On Tue, Feb 21, 2006 at 02:09:35PM +0000, Ian Jackson wrote: > I miswrote `achieved' as `required'. So I withdraw my previous motion > and propose the following instead, and call for a vote. Since you've called for a vote, I vote "no" on this resolution as written. I do agree that we should render an opinion of some sort on this issue rather than letting it linger, so if this fails the 3:1 majority I think we should try to figure out what the consensus position of the committee is and vote that rather than leaving nothing but a very complex statement that we *don't* agree with. ;) Comments interspersed below. > WHEREAS > 1. ndiswrapper's purpose is to allow non-free drivers to be used. > 2. While there may be cases where ndiswrapper can be used > with a DFSG-free driver, these are exceptional. > 3. The Committee is by and large satisfied with the intent behind the > language in the Policy Manual regarding the distinction between > non-free and contrib. I agree up to this point. > 4. The Committee does not wish to overturn or change established > political policy about the distinction between main and contrib, > and does not wish to usurp the political authority of the Project > Leader. I agree in principle with what you've written here, but I disagree that it supports your conclusion. The ndiswrapper package is currently in main; saying that it belongs in contrib *is* an overturning, both of the package maintainer's judgement and of the judgement of the ftpmaster who approved it into the archive. I don't see how we can discern here an "established policy" that says ndiswrapper belongs in contrib when it sits in main today. > 5. The Committee's reading of the current Policy Manual wording is > that ndiswrapper falls fairly clearly into the area currently > defined for `contrib'. Up until this evening I was of the opinion that this was the case; then Anthony presented an analogous scenario on IRC that I found persuasive. Supposing that lesstif had not been written yet today, and there were no free packages in Debian that used this API, would lesstif have to be put in contrib? And I think the answer is no; I think writing a new free software application to use the motif API would be lame and not worthwhile, but that's indeed not a reason to put lesstif in contrib instead of main because lesstif doesn't depend on those applications, it merely extends the capabilities of the free operating system to include running motif apps. Likewise, ndiswrapper doesn't depend on any particular driver, it just allows those drivers to be used with Debian; nor did iBCS depend on any particular SCO Unixware binary, so there was no reason to yank it out of the kernel and move it to contrib. It just took looking at an analogous scenario outside a driver context for me to figure this out. > 6. However, the language in the Policy Manual is somewhat unclear and > ambiguous, and by some readings inconsistent. Certainly a fair statement any which way :) > THE COMMITTEE CONCLUDES THAT > 6. ndiswrapper belongs in contrib. > 7. References to `package outside of main', `packages which are not in > our archive at all', etc., in the relevant part of the Policy > Manual, should be changed to refer to `programs' or `software'. > 8. The policy manual should be clarified to make it clear that free > software to talk to non-free software over a network can remain in > main. In our opinion the relevant principle is that: > (i) If the user or administrator who is in charge of the Debian > installation would have to adopt non-free software X to make > sensible use free software Y, then Y goes in contrib. > (ii) However, if free software Y is used by the user or administrator > of the Debian system to cope to with someone else's use of non-free > software X on another system not under their control, then Y goes > in main. > AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS > 9. ftpmasters and the ndiswrapper maintainers should cooperate to move > nsidwrapper to contrib. (If the required 3:1 supermajority is > achieved, the ftpmasters and ndiswrapper maintainers are hereby > required to do so.) > 10. The Policy Manual maintainers should take steps to adjust the > language regarding main and contrib to clarify and improve it. The > Maintainers should take our opinion in paragraphs 7 and 8 as > advisory; they should also have regard to opinions from the Leader > about the correct effect. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature