GPL modules for a differently licensed OS'
GPL modules for a differently licensed OS'
Posted Sep 5, 2007 13:08 UTC (Wed) by and (guest, #2883)In reply to: GPL modules for a differently licensed OS' by madscientist
Parent article: Relicensing: what's legal and what's right
> The first is the "mere aggregation" clause which confirms the FSF's
> belief that just putting two unrelated programs together on a CD (or on
> a hard disk) doesn't constitute a derived work. The FSF's position, as
> far as it can be collapsed into a single sentence, is that if the
> virtual runtime image in RAM of a program requires GPL'd code, then the
> total is a derived work.
Agreed. But this isn't this definition consistent with my original point:
if a OS is *BSD licensed and one of its drivers is GPL, the OS per se runs
fine without the driver (except that it has reduced functionality, but
that is also the case for a non-GPLed OS running GPLed user space
programs) and is thus not a derived work in this sense. The "code shares
the same address space" definition is also not really applicable, because
the kernel also has access to all user space memory, so GPLed user space
would still be impossible on top of non-GPL kernels. If the "system
library" is applied to prevent this, it sounds to me that it can then
equally be applied to the drivers, but IANAL.
On the other hand drivers can't run without the OS so they are clearly a
derived work. That's why non-GPL linux kernel modules are not
distributeable, strictly speaking. Or am I still missing something? In any
case it's damn muddy business ;)
