Hi David, > > As there is some controversy over the definition of derived work > > (think Linus' comments on porting a driver or a filesystem from > > another operating system here), we use the EXPORT_SYMBOL_GPL > > annotations as a big warning sign that what you're doing is likely to > > be considered as a derived work. > Let's consider a totally original USB driver. There are an infinite > number of them, some still to be written.
if a new drivers is originally written for Linux, then you are breaking the GPL. There is no other way to name this. Using EXPORT_SYMBOL or EXPORT_SYMBOL_GPL make no difference here. You driver was meant to be running as Linux kernel module and thus it is derivative work. While there is a gray area, but this case has always been pretty clear. > > If the USB developers want to > > annotate their code with EXPORT_SYMBOL_GPL, why the hell do you want > > to argue about it? > Have I the wrong end of the stick? Isn't that mark restricting an > interface to GPL _callers_? Isn't it a technical switch that means, > "Don't use my software if yours isn't (also) GPL"? As such it's mere > political rhetoric, devoid of any binding power. What are you arguing here. It makes no difference if it is technical or not. The EXPORT_SYMBOL_GPL gives you a clear hint that when using this symbol, you have to obey to the GPL. Even the EXPORT_SYMBOL is protected by the same GPL license. And thus both has the same binding power to be used from GPL modules only. At this point I would strongly advise to talk to lawyer since you are obvious missing the point here. > > If you want to > > develop for Linux, you're most certainly better off always > > distributing your code under the GPLv2 > > I agree; but let's not disadvantage applications where regulatory > requirements prohibit GPL code, nor applications where the proprietor > simply chooses to keep the work proprietary. A proprietary module is > simply a piece of software. Many people couldn't use Linux if they > couldn't run proprietary software on it. First of all we are talking about kernel modules here. Not the userspace. So stop this FUD. > > But what I don't understand > > is why people insist using the Linux kernel for something it clearly > > can never really properly support (proprietary code)? > > > > That's defeatist. Of course the Linux kernel can properly support > ("run") proprietary code. It would be a miserable excuse for an > operating system if it couldn't. In userspace, yes, the kernel would "run" proprietary code fully legally without any problem. As a kernel module, the only safe answer is no. And in case of EXPORT_SYMBOL_GPL, it is pretty clear. You would obviously violate the license. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/