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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature