I'm not an expert, but I hope my thoughts are helpful. Sven Luther <[EMAIL PROTECTED]>:
> There is a problem though, the current module contains code they control > plus a piece of proprietary code implementing a software ADSL decoder or > somethign such, which they don't have the sources for. It might not make any difference, but does this proprietary code run on the host, or is it downloaded onto an embedded system? I'm guessing the latter. > The ideal solution would be to move the proprietary part out of the the > actual kernel driver and into userspace, and they are working on this, i > think, but it is still not ready. If you take the proprietary part out of the driver, then the driver can be DFSG-free, but it still depends on the non-free stuff, so it would have to go into contrib rather than main, I think. > Now, i believe that releasing this driver, in its current state, without > moving the proprietary part into userspace, under the GPL is wrong, since > they are linking proprietary closed source code, which will break the > GPL of their driver and the linux kernel. I don't think it breaks the GPL of the kernel if the driver communicates with the kernel only through the standard module interface. However, there would be a problem with the driver itself being GPL if some of the source is not available. > Would it be possible to release this under a GPL + exception licence, or > something such ? I would guess it is possible. However, if the driver doesn't contain anything very clever, perhaps they might be willing to release it under a BSD licence or just make it public domain; it might be simpler. > It would still taint the kernel, I don't think so. > and have to go into > non-free, Yes. > but at least the code they wrote would be GPLed. It is indeed an advantage it at least part of the driver can be freely modified and redistributed, but BSD or public-domain would achieve that too. > Also, i guess > i cannot put a proprietary closed source stuff into even non-free, > without at least a permission to redistribute it. Yes. > I will encounter i guess the same kind of problems when they move the > proprietary part to userspace, i guess. If there is permission to redistribute the proprietary bit, then I don't think it really helps to move the proprietary part to userspace. For simplicity you might as well put the whole lot in non-free either way. If there is no permission to redistribute the proprietary bit, then there is an advantage in separating out the proprietary bit because Debian can then at least distribute the free and distributable part in contrib. Edmund
