I'd like to try to think about this from another point of view. I'm going to go back and say some things that we're all probably aware of and then develop from there:
Why does contrib exist ? ------------------------ 1. Dependency-completeness for main: There is one clear technical reason why contrib has to exist: without it, packages which Depend on or Recommend non-free packages would either have to be in non-free themselves, or be in main and cause main to have unsatisfiable dependencies. (This argument is based on the already taken political decision to have `non-free', of course.) Note that using contrib for these packages, rather than non-free, is in some sense a political decision: putting something in non-free is making a statement not just about technicalities but also about the legal and political situation, and the Project feels it inappropriate to apply the `non-free' label to packages which are not themselves directly encumbered. But this political decision seems to have been clearly taken by the Project as a whole and seems to be undisputed. 2. Assurance of Free-ness to users: Following on from this, it is clear that if you tell your system not to offer you non-free software, the software system as a whole should not just exclude packages that are themselves non-free or that Depend on non-free packages (1, above), but also packages which, if you install them, will directly result in the installation and execution of non-free software on your computer, without significant further confirmation. (And any such offer subject to confirmation would arguably be inapproprite given that the user has already said `no' in the general case.) For example, if the package selection and installation system installs an installer package, or a package which automatically downloads and installs non-free content, then the computer will have the non-free stuff on it and the user might not be aware of the status of the code. For a variety of reasons, both practical (the user needs to know their legal situation) and political, the Project has decided that these kinds of programs should be in contrib too. Additional uses for contrib --------------------------- Some people seem to be arguing, effectively, that the two situations above are the only reasons for contrib to exist and that no package not falling under one of those two headings should be in contrib. However, it seems clear to me that the Project has decided otherwise, both from close reading of the policy, and from past actions: Firstly, close reading of the policy for contrib: * 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. The first of these covers _all_ of my items 1 and 2 above (providing we read `package' to mean `something packaged and distributed' and not `Debian format package', which seems most reasonable). An interpretation of the second bullet which likewise only covers things which _have_ to be in contrib for practical reasons would be completely subsumed by the first bullet. So, if the second bullet means anything at all it means that some additional packages, which do not need to be in contrib for the practical reasons I describe above, are still to be put in contrib. Secondly, prior practice: No-one has mentioned the various emulators and game-file runners recently in this thread, but they provide a very clear example. In general, the Project has classified into contrib emulators and executables which require non-free components to be supplied by the user before they are useful - typically, game engines and certain hardware emulators. The program in question generally stayed in contrib until there was something resembling Free data or code for it to work with. In some cases there was originally _one particular_ non-free data file required, but in other cases there were a variety of different non-free components any one of which would do, and where the emulator was the program which Now, we don't have a clear statement of the reasons for this. But I can think of only one possible reason: The Project disapproves, politically, of the non-free status of the required components. It expresses this disapproval by relegating the corresponding emulator into `contrib'. You might argue that no opprobrium is involved and that there is no question of status at issue, but the high feelings on both sides of this debate (and the amount of time spent arguing over it) give the lie to that suggestion. (Reasons that don't make sense: 1. We don't want to encourage copyright infringement by distributing things which require users to play fast and loose. This doesn't make sense because there is no relevant difference between contrib and main. 2. We want to warn the user about the resulting non-free status and hence lower standards (lower maintainability) of the system so that they don't use non-free software unawares. This makes no sense because the user has to deliberately choose to obtain the non-free component.) Conclusions ----------- (i) ndiswrapper falls squarely into the `contrib because we politically disapprove' I category describe above. So: (ii) This is a political decision, since neither of the two practical reasons apply. The Committee should explicitly make its decision a _recommendation_ to the package maintainers and ftpadmins, and should explicitly indicate that it might be overruled by the Project Leader. Nevertheless: (iii) The committee should issue an opinion because it has been asked to and because in practice no-one else probably will ! Aside about `technical' ----------------------- I'm deeply unconvinced by arguments along the lines of `this is in the [technical Policy Manual' or `this is an argument about the technicalities of wording'. Whether a decision is technical or not depends on the reasons for it, and the reasoning used. It doesn't depend on the location of the governing text. And technicalities of wording are not technical questions about the design and operation of computers. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]