Re: kernel driver module with proprietary closed source piece.
I'm not an expert, but I hope my thoughts are helpful.
Sven Luther <firstname.lastname@example.org>:
> 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 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
> It would still taint the kernel,
I don't think so.
> and have to go into
> 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
> Also, i guess
> i cannot put a proprietary closed source stuff into even non-free,
> without at least a permission to redistribute it.
> 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
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