Re: NEW handling: About rejects, and kernels
Scripsit Wouter Verhelst
> On Sat, Apr 02, 2005 at 02:39:57PM +0100, Henning Makholm wrote:
> > The installer images in question would of course need to be
> > labeled as containing non-free components, but that hardly
> > constitutes a "logistical problem" that is worth worrying about
> > for long.
> Actually, I think it is.
I still don't see what the logistical problem here is.
> That would constitute a first for shipping stuff from non-free on
> It would also provide problems with people that don't understand at
> first sight and wonder why Debian doesn't ship this
> horribly-non-free-firmware-that-requires-distribution-licenses which
> is distributed by all other distributions, too. We would need a very
> careful explanation of that.
I still don't see a problem. How would it be difficult to say
| Installer images x, y, and z belong to the 'main' distribution of
| Debian, and therefore do support various recent makes of hardware
| (link to list) that require non-free firmware that cannot go into
| 'main'. If you need to have one these devices work before you can
| access the network, you will want to use one of the installer images
| u, v, and w, from the 'non-free' section. These images contain
| drivers that we can legally distribute, but which do not provide the
| entire set of freedoms we try to guarantee in 'main'.
If you think this is a problem, you should consider the entire
non-free section a problem. There was a vote on that. It ended with
supporting the existence of non-free.
> Also, if some of these non-free firmware blobs one day are accompanied
> with some non-free configuration tool that needs to be run before the
> firmware can be uploaded, there's all kind of other problems.
I don't think even the current firmware apologists argue that we
should allow intrinsically non-free firmware loaders into main.
Anyway, I don't see that it would be a problem to include a non-free
configuration tool on a non-free installer image, provided that
someone is willing to maintain an udeb for it.
> A policy of simply allowing 'any' firmware in our regular non-free
> archives to be shipped on CD images would be problematic at best.
Not "any". "Any firmware whose license allows distribution for profit"
would be unproblematic, as far as I can see.
> Either they need to go in non-free, in which case they can't end up on
> CD images;
We do caution CD vendors that they do not necessarily get rights to
sell media with all of non-free on it, but there is nothing that
prevents us from manually selecting a set of individual packages from
non-free that *are* "CD safe" and distributing images (or jigdo
definitions) of discs that include them.
Henning Makholm "It was intended to compile from some approximation to
the M-notation, but the M-notation was never fully defined,
because representing LISP functions by LISP lists became the
dominant programming language when the interpreter later became available."