Re: non-free firmware
On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote:
> at least I lost track a bit, so this mail is basically a question to
> bring me up to speed.
> In 2004, there was a GR that decided to put everything in main under the
> DFSG. We had some discussions, but in the end, the result was that all
> the non-free firmware bits have to be removed from main before we can
> release etch.
> Now, my question is: Is there still work open? If so, what? Or is the
> current removal of firmware enough, and we can relax on this topic?
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.
Currently neither is done, and we have just reincorporated those modules, in
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.
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. 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.
So, basically, we have postponed the issue until later, when our
infrastructure is up to handling this, knowing that the removal of modules and
the build of non-free modules in non-free will probably not be such a
time-consuming issue that it will be causing major problems.
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.