Re: non-free firmware
On Sun, Jan 08, 2006 at 11:52:20AM +0100, Andreas Barth wrote:
> * Sven Luther (sven.luther@wanadoo.fr) [060108 11:12]:
> > There where two fully independent issues here :
> >
> > 1) some (many) of those firmware using modules had a sloppy licencing
> > situation, which meant the compiled kernels where indeed non-distributable.
> >
> > 2) those firmware blurbs come without source, and are thus non-free.
> >
> > We where working to solve 1), since without that, it was not even possible to
> > distribute these non-free firmwares from even non-free. I think once this is
> > solved the plan was to :
> >
> > 1) either make those drivers be able to load the firmware from an external
> > file, which we could then include in the initramfs from a non-free source.
> >
> > 2) remove those drivers entirely from the main linux-2.6, and have them
> > distributed from the linux-nonfree-2.6 package from our non-free section.
>
> This matches with what I remember.
>
>
> > Currently neither is done, and we have just reincorporated those modules, in
>
> With neither, you mean: neither the sloppy licensed modules nor the
> non-free firmware?
Nope, the sloppy licencing is being solved, but none of the solution to 2).
> > part because our external-module framework and linux-nonfree-2.6 packages
> > where not yet technically ready to handle this, and we chose to concentrate on
> > the other steps first, leaving this aside for later, when the infrastructure
> > would be ready.
>
> What needs to be done to get the infrastructure ready? Do you think it
> might make sense to try to get it done e.g. at a BSP?
waldi is working on it, and it is on our todo list, i am not sure it is
something which can be fixed in a BSP, altough maybe some brainstorm session
would be of benefit. Still i think there are other issues of bigger priority
right now, and my focus is on the .udeb integration in linux-2.6, as well as
some automated config file checking and a better split-config implementation.
Once the .udeb integration is done, the next step on my TODO list is indeed
the out-of-tree module thingy, which once finalized, would make the
linux-non-free-2.6 package easier. We would need to re-remove those drivers
though.
> > Now, there is a current of thinking who doesn't agree that those modules
> > require sources and that we should not worry about this, this could be in part
> > true (it is said that some of those firmwares where written directly with an
> > hex-editor, but i believe not all are done such), but it is rather unlikely we
> > will be able to determine that or not.
>
> Well, there might be cases where the binary blob is enough, but I think
> we agree that
> a) this is probably the exception and not the rule, and
> b) this requires a case-per-case-inspection.
And how exactly can you guarantee this is the case without being the guy who
wrote the code, and even so, how could we be sure to thrust such a guy
claiming that it is the ultimate source code ?
> > In any case, there are always those,
> > like with the GFDL situation, who would not want to worry about this and let
> > it slip in silently, or hope for another derogation, or simply believe it is
> > not an issue.
>
> Well, we as release managers have the task to make sure it doesn't slip
> away (that's one of the reasons there are cheat lis^W^Wtracking lists).
> If people think it's a non-issues, they can try to change the DFSG - for
> the release team, the current valid DFSG is part of the RC check list.
But as you said, it is highly unlikely that you will be removing the kernel
package, so you need to work with the kernel maintainers :)
The main problem is one of ressources, and we need a single person who can
devote time and effort to follow up on all those drivers, and see if the
firmware can be removed from them or not. Right now everyone is focused
on other stuff.
> > I suppose the right way to solve this (doing 1) is another matter and more of
> > the area of upstream work than debian work, it is the better solution though,
> > not sure if it would be ready for the etch timeframe though.
>
> The question of sloppy licenses is indeed an upstream issue - however,
> that doesn't mean we can shut our eyes when we come over such an issue.
> The DFSG-freeness is our own issue.
Nope, upstream didn't care about sloppy licence, the upstream issue is to have
the firmware removed from the driver and provide infrastructure to load it
from initramfs.
But the real problem is we are all volunteers, and if nobody has the will to
work on this, what can you do ? And if those more likely to work on this are
not convinced by the non-freeness or do not care ...
Friendly,
Sven Luther
Reply to: