Re: kernel firmwares: GR proposal
On Sun, Sep 10, 2006 at 02:16:26AM -0700, Steve Langasek wrote:
> Hi Frederik,
>
> On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
> > Overview:
>
> I asked you this question before privately and haven't seen an answer. You
> say below "So we propose this GR:"; does that mean that everything up to
> that is rationale, and not part of the text that developers will be voting
> on?
I guess so, but i suppose that when people vote, they take the rationale and
explanation in mind too.
> This is very unclear to me; if the intent is to vote on the whole document,
> I think some wording tweaks are needed. If the intent is to vote only on
> the part beginning with "1. We affirm [...]", then I think it's much shorter
> than it should be.
What would you have added ?
> > So, we propose this GR:
>
> > 1. We affirm that our Priorities are our users and the free software
> > community (Social Contract #4);
> > 2. We acknowledge that there is a lot of progress in the kernel firmware
> > issue; however, it is not yet finally sorted out;
> > 3. We give priority to the timely release of Etch over sorting every bit
> > out; for this reason, we will deliver firmware in udebs as long as it is
> > necessary for installation (like all udebs), and firmware included in
> > the kernel itself as part of Debian Etch, without further conditions.
>
> FWIW, while I originally thought that "sourceless firmware is ok for main"
> and "non-free firmware stays in main for etch" should be two separate
> questions, after reviewing the list of kernel blobs that Larry prepared, I
> see that the difference between the two is very small: the only blobs
> currently shipping under a non-free license are for AppleTalk, token ring,
> and USB audio, and none of those are relevant to the installer.
>
> So if we are going to make an exception, I think we should take care to make
> the smallest exception necessary. If we don't *need* to grant exceptions
> for firmware based on their license, only on whether or not they include
> source, I don't think we should include such firmware in the exception.
> This prevents anyone from trying to add such firmware to etch that isn't
> already included, which would be a regression vis-à-vis freeness.
Well, 3. is maybe not worded in the most clear of way, but my belief is that
the idea behind it are :
1) In the worst case, we will ship in etch the current kernel we have in
sid/etch, without the need to remove anything or doing any special work.
This would take care of adding non-free firmware, i believe.
2) The kernel team, and the ftp-masters, have full control over whatever new
non-free firmware goes in, so even if the GR allowed for adding new non-free
firmware, in practice it won't happen.
3) Since this proposal, a few things happened. Goswin and Wouter started to
work on the d-i part of the non-free stuff, and the qlogic firmware was
uploaded to non-free (and apparently upstream stopped shipping it, and
recomend to download from some random site over using the version still
present in the kernel source code).
4) If we have time to sort up a few firmwares and move them to non-free for
the etch time-frame, so much the better.
That said, i never fully understood the "we will deliver firmware in udebs as
long as it is necessary for installation (like all udebs)"
So, maybe 3. could be amended to something like :
3. We give priority to the timely release of Etch over sorting every bit
out; for this reason, we will release as part of Debian Etch, at most the
(non-free, sourceless, ...) firmware currently included in the linux
kernel package found in etch/sid/upcoming-2.6.18, both as .deb and the
repackaged .udebs, without further conditions.
This clearly states an upper bound on what firmware are concerned (exclusively
those in the .deb and repackaged .udebs), and insist a bit about the fact that
this is indeed an upper bound, and that it could be less.
Friendly,
Sven Luther
Reply to: