* Sven Luther ([EMAIL PROTECTED]) [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
