On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: > Hi, > > 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. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
