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

Re: non-free firmware in the linux kernel

On Tue, Jan 10, 2006 at 02:52:07AM -0800, Steve Langasek wrote:
> >   b) we move the affected modules to non-free. Well those that have their
> >   licencing solved, the others will simply no more be distributed, or
> >   distributed form an unofficial source.
> Probably overkill, and causes significant problems unless we are able to
> provide better infrastructure for such modules in the installer.
> >   c) we move the firmware in non-free, and actively use the request_firmware
> >   mechanism.
> Seems like a pretty good division, but if there are users who *need* the
> non-free firmware, we still have problems unless there's some way for them
> to grab it in the installer.

Both will need the same amount of work in the installer. we are speaking
network and scsi drivers here, those are used for the install and for the root

> >   d) we go for a new GR, asking for an exception for the linux kernel, in
> >   order to still stay in main, even though the firmware is non-free, arguing
> >   that said firmware is more akin to hardware, since it replaces firmware on a
> >   prom or flash on the expansion card, and you thus lose no freedom if we
> >   distribute it, and the pain the other solutions will cause to ourselves and
> >   our users.
> So, see my latest post to -project about that.

Yep, saw it first actually.

> > I think everyone agrees that a) is not a possibility. Both b) and c) require a
> > non-negligible amount of work, altough b) is less work than c), but c) is the
> > better solution, and also to the best of my knowledge the one which upstream
> > seems to favour, altough both may mean a long-term additional work for the
> > kernel-team, work which the kernel team is not really prepared to make, which
> > leaves d). Not sure if d) is politically right right now with regard to the
> > GFDL situation, but that is another issue, which will then need to be debated.
> I don't consider this analogous to the GFDL.  The firmware question is "what
> format must a work be made available in for us to consider it free?"  The
> GFDL question is "what freedoms must the copyright holder have granted to us
> for us to consider it free?"

I meant it would provide for a less strong standing on the GFDL front. They
will say, see you didn't like the GFDL, but you are accepting non-free
firmware, which is worse.

> > Also, if we go the BSP way, it has to make clear that it had to be a long
> > standing and coordinated effort, since random patches of dubious quality will
> > probably only make matters worse for the kernel team..
> Seems like a poor fit for a BSP then, IMHO.  BSPs work best when you can put
> people to work immediately with little learning curve.

Well, Maks asked this to be added. The learning curve is not that great, i
believe, but it needs to be coordinated and done right.


Sven Luther

Reply to: