Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard wrote:
>On Thu, Apr 14, 2005 at 09:18:46AM -0300, Humberto Massa
>wrote:
>
>>> Then all the people who think that creating a binary
>>>kernel module requires creating a derivative work and hence
>>>can be restricted by the GPL are wrong. Take that argument
>>>up with them.
>>
>>I took. Google my name on lkml and you'll see. They ARE
>>wrong. Linus himself studied carefully the situation and
>>came to the conclusion they are wrong,
>
>
>"Linus himself" is, as far as I understand, a programmer, not
>a lawyer.
So am I (altough I *am* a para, after all). This does not
preclude him from being right, does it?
>His opinion and study of this topic has no more weight on
>this issue than any other "armchair lawyer", and far less
>than Eben Moglen, for instance.
>
>(I'm not claiming he's right or wrong--just that it's not
>useful to cite "Linus himself" as a source about legal issues
>just because he's a well- known programmer.)
I wasn't. I was simply stating that me -- as a programmer,
too, but mainly as a paralegal, after doing some research on
the subject -- shared his views on this.
>The FSF FAQ says that *all* software linking against GPL
>libraries must GPL-compatible[1]. [2] contradicts the above
>even more directly.
Yeah, but the GPL does not. And that is the problem. If the
GPL specifically stated "any works that does link, either
dynamically or not, to the Program are to be considered a work
based on the Program for the effects of this license", this
would be substantiated. but it's not.
>Now, it's possible that they're wrong;
I'm glad you admit that. I admit I can be wrong, too, but I
sincerely don't think so.
>there's the obvious theory, for example, that they've long
>since realized this, but have no way of fixing it without
>admitting to a "loophole" in the GPL.
I think the latest "GPLv2 or later" debates, started by rumors
of the contents of the GPLv3, mostly proves that they can't
fix it at all :-) At least, not without creating (a) a license
that is incompatible with the GPLv2 or (b) a license that is
substitutable by the GPLv2, and hence, that adds no additional
restriction, so it can't add restrictions about linking.
>I've seen lots of these "derivative work" arguments (and
>others, such as whether the GPL is a contract), and have
>never seen a reply from the FSF addressing them; given their
>potential severity, that at least raises an eyebrow.
The "at least raises an eyebrow", in my personal opinion, is
translated by "yeah, they are agreeing that this is a
loophole, and the best they can do is shut up about it."
>Of course, I've never raised these with them personally,
>since I'm not even qualified to tell which arguments have
>enough grounding in reality to avoid wasting their time, and
>I don't know whether anyone else has; so I don't place too
>much weight in that particular theory. (I don't believe
>they're unaware of the arguments, though, and dispelling
>misconceptions about the GPL is entirely in their interest,
>so I'd expect to see responses to these things.)
The most relevant "response" to this theory IMHO is the lack
of response, that occurred when Linus (as "project manager" of
sorts IRT the kernel) made his statement almost two years ago
that he did not consider kernel modules as derivative works
*in* *principle*. It's reasonable to assume that if someone
(especially EM) tought he was completely off his marker, this
someone would have called attention to the subject.
>>If you make a kernel module that only uses something
>>EXPORT_SYMBOL()'d from the kernel, you are NOT in principle
>>writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d
>>symbols, then you are incurring in (b) above and your kernel
>>module is most certainly a derivative work.
>
>
>The notion that what is a derivative work changes based on
>whether a symbol was declared with EXPORT_SYMBOL or
>EXPORT_SYMBOL_GPL seems fundamentally absurd to me.
But not to me. I consider EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL
as specific permissions to use symbols respectively in *any*
module, or in *GPL-only* modules. The existence, purpose, and
even the implementation of those two macros construe each use
of them as a special documentation about the "intimacy" of the
kernel modules with the *implementation* of the kernel
internals, in a way that would help determine (by filtration,
abstraction, comparison) if a kernel module is a derivative
work of the kernel (and hence subject to GPL terms).
>(If somebody is reimplementing the Linux kernel API, he might
>just as easily reimplement the "EXPORT_SYMBOL_GPL" symbols,
>for compatibility with drivers that need them, for example.)
This is not really true. To reimplment GPL'd symbols without
(potentially) infringing on the kernel copyright, you would
have to "clean-room" such implementation, which is not really
easy when everybody that touched a kernel-x.y.z.tar.gz is
'dirty' :-)
HTH,
Massa
Reply to: