Hallo, On Sun, Jan 08, 2006 at 11:10:46AM +0100, Sven Luther wrote: > On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: > > 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? From my point of view, the situation currently looks like this: 1. tg3 and qla2xxx driver status has been solved: upstream has relicensed the drivers - the sourcecode is licensed under the GPL, the firmware data is freely distributable as an aggregate work. 2. Some other drivers permit free distribution, but the license is too restrictive for Debian main. Among these drivers we find acenic, dgrs, smctr and keyspan. These are currently waiting for an updated license or will not likely be relicensed at all (like the acenic driver), thus they are put together in the linux-nonfree-2.6 package. 3. Some drivers still need to be checked, a somewhat outdated status is to be found here: http://wiki.debian.org/KernelFirmwareLicensing So there might still be some drivers we have to relocate from the main package to the non-free one, and possibly some drivers we might not distribute at all. > 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. I think the firmware is a data part of the driver, and the driver _as a whole_ is - in the social contract terms - the component we have to look at. If the driver source is available and the license is DFSG-free, it can be distributed in main. What we call firmware is a hexdump of data not executed on the host CPU but uploaded to the hardware during initialization, thus plain simple data from the CPU point of view, and a hexdump is the preferred format of redistribution of this part of the source. In the end, trying to solve this issue, we might find an agreement on the following question: Is the firmware the component which source has to be available in a different format, or is the driver as a whole - including the FW - the component, which we already have the sources from? Best regards Frederik Schueler -- ENOSIG
Attachment:
signature.asc
Description: Digital signature