On Thu, Apr 29, 2004 at 10:06:58PM -0700, Thomas Bushnell, BSG wrote: > Xavier Roche <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital signature
