Re: Bug#353277: ndiswrapper in main
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.
Reply to: