'GPL encumbrance problems'

[Andy Green]

jdow wrote:

>>> will have to open your work.  It seems that we crossed a threshold now
>>> and the signs are that if you generate kernel modules you can expect
>>> that sources will be demanded.

>> Not necessarily.  Look at the nVidia and ATI video drivers. They are
>> kernel modules and the source is not open. They use proprietary code in
>> the drivers.

I am working on embedded linux on Arm the last six months, I am quite
well aware of the options for argument on this.  For various reasons we
will be shipping full source for our kernelmode code.  Linus has written
about this question and he used the test that if there is a substantial
base of code intended for crossplatform use then he wouldn't kick up a
fuss.  For singleplatform kerne1lspace code, he was saying you should
open it.

> There are some young hotheads who insist that these drivers inherit
> some GPL headers, at least. Hence they must be themselves GPLed. There
> has been no serious effort to clarify the situation. It is in a rather

The issue is defined by copyright law AIUI, it is to do with when you
have made a work derived from another.  People are generally drawing the
line as linking stuff together as making a composed work that has to be
compatible with the licenses involved.  Linus has also said strongly
IIRC that syscalling into kernelspace from usermode is NOT linking for
these purposes.

gkh would probably be flattered with the young bit, but he does seem to
be a hothead about the kernel question and is talking about removing
kernel exports from non-GPL licensed kernel code.

Whatever way you look at it, the movement is towards kernelmode code
needing to be opened to be consonant with the kernel license, and
usermode code only needing to comply with LGPL unless you use GPL libs.

Compliance with the LGPL is not very hard, in the case where you are
linking to Fedora-packaged LGPL libs then Redhat are doing the hard work
in source archival terms, you just need a link on your site to a
matching SRPM at Redhat IMO.

Proper compliance with the GPL for an embedded product involving the
kernel + GNU stuff is much harder than it first looks when you consider
ongoing versions being generated, needing to capture sources for each...
we solved this by using RPM even on our embedded platform, so we capture
SRPMs when distributing binaries, basically you're into making your own
distro RH-style.

-Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4492 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20060118/1e748aaf/attachment-0001.bin>