Re: non-free firmware: driver in main or contrib?
Glenn Maynard writes:
> So you're saying that the loaded-at-runtime option allows for DFSG-free
> versions to be implemented, so they should be allowed in main to encourage
> that particular design option over the "static ROM" option. (There's
> also the EPROM option, which acts like hardware--the driver doesn't have
> to upload anything to work--but also allows for DFSG-free versions to be
> implemented.)
>
> That doesn't really change the fact that drivers that only work after
> pointing it at a non-free data block have a non-free dependency, and
> belong in contrib, though.
The driver operates as designed regardless of what is in the firmware
array, file, EEPROM, etc. The device does not. For me, the explicit
interface between peripheral and CPU makes the distinction clear.
Drawing the line elsewhere seems to lead to a place where we forbid
P6/K7/etc.-targeted binaries (optimized programs or CPU-specific
kernels) from being in main because they require non-free microcode.
Michael Poole
Reply to: