Re: kernel firmwares: GR proposal
On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
> > Also, though the firmware loader allows us to put the firmware where it
> > belongs to (main or non-free, depending on the case), the installer can
> > as of now only take udebs from main. Fixing this is not too hard, but
> > it is doubtful whether we can fix this in time for etch,
>
> "because we are not willing to try to fix it and we have not given anyone
> else sufficient information to"
Oh come one, this is all free software, and it is freely available both in
the debian archive, which holds source, and in our svn repository.
> Sorry to be so annoyed. I can't even find 'anna', which is supposedly the
> module which needs to be fixed. Where do I download it from? I have asked
> debian-boot on previous occasions.
http://www.debian.org/devel/debian-installer will give you all the links you
want, but for the lazy :
svn://svn.debian.org/svn/d-i/trunk/packages/anna
Also, it is in the main/debian-installer section of the debian archive, even
with source and all.
> > and we do not
> > want to depend on that (and even then, we still would have non-free
> > firmware, see above). But since there is lots of hardware which needs
> > firmware for correct operation, the installer would not work for
> > mainstream hardware otherwise.
> >
> > There are two ways how to deal with it:
> > 1. Accept these issues as transitional issues for now; or
> > 2. Delay etch for some serious time.
>
> Like a month or two, maybe. If people actually bother to work on it, or to
> accept other people's work on it.
Current estimates place this between 6 month and a year. The fact is the d-i
team need at least a month or two of testing for this, even if the change was
instantaneous, there are loads of packages which will trigger NEW, and so on.
Also, finding, approaching and convincing people to clarify the licence of the
problematic ones, is something which will take some serious time.
I know you proposed patches for this so long ago, but back then the kernel
infrastructure was not mature enough for it, this has changed.
Furthermore, during the delay while we work on it, we still will have sarge
out there, which will have a less free situation than we currently have in
etch/sid, so you don't gain much by delaying.
Let's take the time to do this right, instead of hurying, and doing it for
etch+1 will allow us to do that.
> > In our social contract, we promised that the users and the free software
> > community are our priorities. We firmly believe that our users profit
> > very much from releasing etch in time, and that this is important enough
> > that we can accept the transitional status with having a few firmware
> > images left in main that should belong somewhere else. Of course,
> > everyone who wants to make the number of such firmware images as small
> > as possible is welcome to help converting old firmware loaders to the
> > new standard, and working on the Debian installer. We are happy if this
> > issues become smaller or even vanishes, but we do not want this to be a
> > release blocker.
>
> OK, this is good. :-) Does this mean that the patches converting the tg3
> driver to use firmware loading will be reaccepted?
What is the position of the upstream author of the tg3 driver about this, and
even if he is still (i think it was him) strongly opposed, is your patch
upstream-quality ?
> > So, we propose this GR:
> >
> > 1. We affirm that our Priorities are our users and the free software
> > community (Social Contract #4);
>
> Technically this is wrong. The priorities are "our users and free
> software". Not "the free software community". Please fix this; it means
> something different.
>
> > 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.
>
> This ("without further conditions") would seem to promise that firmware will
> be included even if it doesn't actually carry a license which permits
> redistribution (as is the case for over 50 BLOBs in the upstream Linux
> kernel). Is this correct? Are you specifically ordering the ftpmasters to
> carry material which is technically improperly licensed?
Well, as said, it is no worse than the current situation, but given that the
upstream authors of those badly licenced firmwares are the ones who distribute
them under these licences in the first place, so it is highly doubtful they
will sue us over it, even if it was not a plain misinformed mistake.
As for users suing us, which i am not sure the GPL permits, well, we just
orient them upstream.
> If so, that's OK by me (it doesn't give me any legal liability), and it has
> the substantial benefit of actually addressing the status of the majority of
> upstream BLOBs in etch. But it should be *very clear* that this is what is
> happening: that this GR is making a *legal liability* decision for Debian.
As does the status quo, so we can continue and discuss this issue another
couple of years, and not be in any way legally better off.
Let's get etch out of the way, and seriously concentrate on fixing this issue
post etch, both the technical one, as well as the legal one.
> Note that I am not comfortable personally working on the drivers
> containing improperly licensed firmware. (Except for working on getting a
> proper license, that is.) You may well find that the other volunteers for
Yeah, that is something which is needed. We need someone to go over larry's
list, which i have copiedto the debian wiki, and find out who the copyright
holder of those problematic firmwares are, and then we can contact them,
taking the broadcom original letter i wrote as a sample.
> converting drivers to firmware loading are not comfortable working on them
> either. This is bound to be a problem, given that the number of BLOBs with
> good, clear licenses is quite small.
Bah.
> > We want to emphasize that the success of this GR is considered as
> > necessary by the kernel and release team for successfully delivering etch
> > in time (and to allow us a successful planning of that).
>
> This is actually a reasonable GR which I could support, except for the
> misleading prologue.
Mmm. I am not sure about this, will think it over and reply to this part
tomorrow.
Friendly,
Sven Luther
Reply to: