[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NEW handling: About rejects, and kernels

On Mon, Apr 04, 2005 at 11:43:52PM +1000, Hamish Moffatt wrote:
> On Mon, Apr 04, 2005 at 11:13:55AM +0200, Wouter Verhelst wrote:
> > On Sun, Apr 03, 2005 at 11:22:51PM +1000, Hamish Moffatt wrote:
> > > Given some options:
> > > 
> > > 1. Don't distribute the firmware blob at all;
> > > 2. Provide a way to download the blob during install (while admitting
> > >    this won't work if the blob is the code for your ADSL modem);
> > > 3. Provide the blob on disk in the regular install media (ie in main);
> > > 4. Provide the blob on disk in a special tained installer
> > >    (ie in non-free or a special firmware section).
> > > 
> > > Which do you think makes the system *depend* less or more on non-free
> > > software? (Depend is the key word.)
> > 
> > Option 3
> Why?
> In all 4 cases, your hardware depends on the blob being loaded,
> regardless of whether Debian is involved.

Sorry, I seem to have forgotten to answer this one.

Policy, section 2.2.1:

     Every package in _main_ and _non-US/main_ must comply with the DFSG
     (Debian Free Software Guidelines).

     In addition, the packages in _main_
        * must not require a package outside of _main_ for compilation or
          execution (thus, the package must not declare a "Depends",
          "Recommends", or "Build-Depends" relationship on a non-_main_

If the firmware is not free, then it does not comply with the DFSG.

If the firmware loader is free, but we build installer images that end
up containing non-free software, then it build-depends on the non-main
package, so cannot be part of main.

If we build separate installer images that contain the non-free firmware
blob and put those images in main, then, of course, there is no problem
at all.
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 -- with thanks to fortune

Reply to: