Re: linux-2.6: includes nondistributable and non-free binary firmware

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Aug 17, 2006 at 01:19:33PM -0700, ldoolitt@recycle.lbl.gov wrote:
> On Thu, Aug 17, 2006 at 10:06:44PM +0200, maximilian attems wrote:
> > enough time is lost with any of those dfsg firmware wankers,
> > that do _zero_ work upstream or on the licensing front.
> 
> I repeat my offer to patch any (well, almost any) of these
> drivers to use request_firmware().  I need a volunteer who
> has the affected hardware and is willing to test my changes.
> It would also be nice if debian kernel developers expressed
> interest in incorporating such work (if any) for etch.

I can say that the debian kernel team is interested in incorporating such
changes, provided :

  1) it is not already too late for it. The RMs will have to judge on that.

  2) the proposed patches are well implemented patches of good quality, are
  well tested and result in no breakage.

  3) We are able to solve all those cases for etch, or remove the others.
  Doing it otherwise would be an injustice, and it would be better to postpone
  this.

  4) The d-i team implement the needed support in d-i to load non-free
  firmware or even module .udebs, and build non-free flavours of the installer
  images in an official way.

  5) There is seemless integration of these non-free drivers and firmware, and
  a user will not notice 

> One alternative sven mentioned is to move these drivers to
> non-free.  I don't see any existing framework for such
> package(s), but that would indeed involve less coding
> and debugging.

There is, we have prune-non-free in trunk/scripts on the svn repo, as well as
the linux-non-free-drivers (or whatever it is called), also in trunk in the
svn repo, and which Bastian Blank has been working on since a long time.

> I am concerned about etch, and the pipeline from upstream
> to Debian is long enough that I think it's too late to
> work upstream.

long enough ? We inaugurated same-day-uploads with the upstream 2.6.14
release, what do you find long enough about this.

But you are right, bringing it upstream will be a long fight, and only be
possible post 2.6.18, which is the targeted kernel for etch, so it is out of
the question.

> At least 12 of the 59 files are probably licensed "free enough"
> for upstream, so upstream will have limited interest in those
> cases.

:) Two of them thanks to previous work of the debian kernel team.

Ok.

Now that the above was said, my own position still is that it is best to not
delay the etch release, to pass a GR to keep the firmware in main for etch,
and to immediately actively start working on the solution for etch+1.

It is not as if this would come to a surprise to anyone interested in solving
this issue the right way, the kernel team has been discussing this over and
over since over a year now, and it is back then that help should have come,
not now.

So, let's not do it in a hurry, but instead do it right for etch+1, which
given the release date of the d-i team, is not doable anymore.

Friendly,

Sven Luther