On Mon, Jan 09, 2006 at 11:03:13PM +0100, Sven Luther wrote: > > 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? > 3) an effort seems to be happening inside the upstream kernel to use the > request_firmware infrastructure which allows to load firmware code from > userland through an hotplug mechanism. There seem to be more and more > drivers going this way, since there aare more in current git than in 2.6.15 > which was released a week ago, qla2xxx being among them. And this seems like a good thing; for starters it makes it easier to test different firmware versions without having to do irrelevant recompiles of kernel code. > Here is a link to the relevant wiki page about the cleaning up of messy > licences : http://wiki.debian.org/KernelFirmwareLicensing > So, basically this means we have the following options : > a) we move the whole kernel to non-free :) Essentially a non-option. > b) we move the affected modules to non-free. Well those that have their > licencing solved, the others will simply no more be distributed, or > distributed form an unofficial source. Probably overkill, and causes significant problems unless we are able to provide better infrastructure for such modules in the installer. > c) we move the firmware in non-free, and actively use the request_firmware > mechanism. Seems like a pretty good division, but if there are users who *need* the non-free firmware, we still have problems unless there's some way for them to grab it in the installer. > d) we go for a new GR, asking for an exception for the linux kernel, in > order to still stay in main, even though the firmware is non-free, arguing > that said firmware is more akin to hardware, since it replaces firmware on a > prom or flash on the expansion card, and you thus lose no freedom if we > distribute it, and the pain the other solutions will cause to ourselves and > our users. So, see my latest post to -project about that. > I think everyone agrees that a) is not a possibility. Both b) and c) require a > non-negligible amount of work, altough b) is less work than c), but c) is the > better solution, and also to the best of my knowledge the one which upstream > seems to favour, altough both may mean a long-term additional work for the > kernel-team, work which the kernel team is not really prepared to make, which > leaves d). Not sure if d) is politically right right now with regard to the > GFDL situation, but that is another issue, which will then need to be debated. I don't consider this analogous to the GFDL. The firmware question is "what format must a work be made available in for us to consider it free?" The GFDL question is "what freedoms must the copyright holder have granted to us for us to consider it free?" > Also, if we go the BSP way, it has to make clear that it had to be a long > standing and coordinated effort, since random patches of dubious quality will > probably only make matters worse for the kernel team.. Seems like a poor fit for a BSP then, IMHO. BSPs work best when you can put people to work immediately with little learning curve. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature