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.
