Re: non-free firmware
* 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?
> 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?
> 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.
> 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.
> 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.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: