On Thu, Apr 29, 2004 at 10:06:58PM -0700, Thomas Bushnell, BSG wrote:
> Xavier Roche <roche@httrack.com> writes:
>
> > I fully agree: the firmware is a evil, proprietary code. But it is always
> > true: the fact that you load it on startup in the remote hardware, or the
> > fact that it already exists in ROM, doesn't change anything. The problem
> > is then, considering that we provide open drivers for proprietary hardware
> > and proprietary firmware [ROM], where is the limit ? In this view, all
> > drivers should be in [contrib], because they require propietary software
> > [firmware] to work. But drivers aren't in [contrib], because we consider
> > that there is a specific exception with hardware/firmware. Not making such
> > exception for distributing firmwares is then not logical, IMHO.
>
> I don't think this is right. If there is no dependency, the thing
> doesn't have to be in contrib.
>
> Remember, a thing goes in contrib because it is only useful with
> something in non-free. But a driver is useful for both the
> proprietary firmware and any free firmware that should arise. Even
> though the possibility of the latter is remote, I don't think it's so
> remote that it means the thing should go in contrib.
That doesn't matter. To date, the policy has always been that a package
must go in contrib if it has a dependency on something in non-free which
has no *current* free implementation. This makes a lot of sense; after
all, non-free is just software, so you could theoretically rewrite
everything in there, including libraries, firmware, and whatnot. If it
were accepted that a hypothetically (though nonexisting) free
implementation is enough to warrant moving a package from contrib to
main, why should we still have contrib at all?
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature