On Wed, 19 Aug 2015, Rich Freeman wrote: > It sounds like you not only expect them to comply with the license, > but also with the kernel devs personal interpretation of copyright > law.
What is a license but a statement of the intent of the authors as to what can and can't be done with their work? Well, it does have some legal force too... If you'd try to take away their right to decide about that next thing they'd do is modify the license to be even larger and explicitly cover all corner cases. But the world of licenses is complex enough so the next best thing is saying "this is GPLv2 and we consider this to be derived work". You can try to bypass that but will hit walls such as EXPORT_SYMBOL_GPL. And intent does matter in copyright law, if explicitly stated as in this case. > I think the real issue here is what constitutes a "derived work." I > suspect the GPU legal teams have given these practices a thumbs-up, > and there is probably a reason that the Linux foundation hasn't tried > to sue them over it. That has always been the issue but I'll allow myself to quote an email on the matter: --- Newsgroups: fa.linux.kernel From: Linus Torvalds <torva...@osdl.org> Subject: Re: Linux GPL and binary module exception clause? Original-Message-ID: <pine.lnx.4.58.0312040753550.2...@home.osdl.org> Date: Thu, 4 Dec 2003 15:59:35 GMT Message-ID: <fa.j5ccqt9.1e20...@ifi.uio.no> On Thu, 4 Dec 2003, Jason Kingsland wrote: > > - anything that has knowledge of and plays with fundamental internal > > Linux behaviour is clearly a derived work. If you need to muck > > around > > with core code, you're derived, no question about it. > > > If that is the case, why the introduction of EXPORT_SYMBOL_GPL and > MODULE_LICENSE()? It is really just documentation. This is exactly so that it is more clear which cases are black-and-white, and where people shouldn't even have to think about it for a single second. It still doesn't make the gray area go away, but it limits it a bit ("if you need this export, you're clearly doing something that requires the GPL"). Note: since the kernel itself is under the GPL, clearly anybody can modify the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be against the license per se. But it doesn't make a module that needs that symbol any less needful of the GPL - exactly because the thing is just a big cluehint rather than anything else. Linus --- Apparently the Linux foundation considers some pieces to be *clearly* GPL-only and these are marked as such. And I don't see a way for vendors around this other than to avoid the usage of such symbols - this is what they have done so far and this is what they will continue doing. If they want their drivers to be useful to anyone using linux that is. > The reason neither party talks about it openly > is probably because they can't be 100% sure which way a court will go > so it isn't in anybody's interest to stir things up. Who wants to go court when the current scheme is effective. The whole issue of "derivative work" is more applicable to binary kernel modules anyway. In this case we have the source code, and the kernel module build system will not allow a module that claims a certain license to use certain symbols. They (vendors) can: a) change their license to say "GPL" but then people would be allowed to demand full source code from them including binary blobs. b) apply the patch you posted - not really practical, definitely wouldn't be popular but I don't really see how that would be illegal. Full GPL would apply to the kernel anyway. c) avoid the usage of such symbols. and they will do c) because they really don't have a choice.